Server fällt für Sekunden aus

[elmexubi]

Hallo zusammen,
ich habe hier ein Problem, das mich zur Verzweiflung bringt
-> esxi Server V5.10 (799733) auf einem Dell Poweredge 520
(von dell angepasst inst cd, in der der RAID Treiber eingebunden ist)
Als Gastbetriebssystem ist windows 2003 64 bit installiert.

Jetzt habe ich das Problem das der Gast sporadisch (also 1 bis 2 mal am Tag ) eine bis zwei Sekunden lang nicht reagiert. Das reicht manchmal leider aus um die Verbindungen zur Datenbank zu trennen (das ganze läuft als SQL Server).
Im Eventlog des Servers ist nichts ungewöhnliches festzustellen (der gast merkt selber offensichtlich gar nicht, dass er kurz offline geht)
Die Systemlast des Gast ist auch nicht besonders hoch.
Trotzdem tritt das ganze nur unter Belastung auf. Nachts ist der Server konstant online (ich habe eine Monitoring auf dem Server)
In den logdateien des ESXI Servers findet sich ebenfalls kein Fehler.
Der ESXI Server selber (den ich auch monitore lässt sich IMMER anpingen, das Problem bezieht sich nur auf den Gast)

Meine bisherigen versuche der Lage Herr zu werden:

1.) Beide Netzwerkkarten des esxi Servers aktiviert und an verschiedenen switches angeschlossen (eine karte nun im standby mode)
2.) Im gast die vmxnet 3 adapter installiert.

Das hat es aber beides gar nicht gebracht. ich bin nun ratlos.
Hardware kann es ja eigentlich nicht sein - der esxi host lässt sich ja anpingen.

Kann mich jemand in die richtige Richtung schubsen?

Gruß

Elmar

[weigeltchen]

Du hast aber auch den ältesten Stand von 5.1 auf dem Host. Diese Version hatte so einige Problemchen. Unabhängig vom aktuellen Problem würde ich auf jeden Fall die aktuellen Patches einspielen.

[irix]

Wird zu besagtem Zeitpunkt ein Snapshot der VM fuer Backup/Replikation gemacht?

Gruss
Joerg

[kastlr]

Hallo zusammen,

überprüfe doch mal, ob in deiner Umgebung eine hohe Anzahl von "Packet Drops" vorkommt.

Large packet loss at the guest OS level on the VMXNET3 vNIC in ESXi 5.x / 4.x
The output of esxtop shows dropped receive packets at the virtual switch

Gruß,
Ralf

[UrsDerBär]

Überprüfe auch ob im EventLog der VM vielleicht sowas steht wie NetzwerkLink Disconnection. Habe dieses Probleme bei nem Kunden. Effekt ist ungefähr der gleiche. Nach einiger Recherche war es da ein Problem Problem mit einem bestimmten Netzwerkadapter von Intel, leider noch nicht behoben.

[elmexubi]

Hallo!

Danke erst mal für Eure Antworten:

@UrsDerBär: Nein, im Eventlog des ESXI Server ist zu diesem Zeitpunkt kein Eintrag vorhanden.
Übrigens -wie gesagt- auch im eventlog des gast nicht

@kastlr: habe ich den von die verlinkten Artikel richtig verstanden, das sich das auf Probleme beim Einsatz des vmxnet3 adapters bezieht? Nun meine Probleme traten ja auch schon meim Intel Treiber auf.

@irix nein. Die ausfälle sind auch wahllos über den tag verteilt.

@weigeltchen: yo werd ich mal machen - obwohl das bisher noch nie nötig war, ich setze sogar noch ein esxi server 3i produktiv ein. noch NIE ein Problem gehabt.

[kastlr]

Hallo,

der Artikel "The output of esxtop shows dropped receive packets at the virtual switch" beschreibt, das "Dropped packets" mit beliebiger vNIC auftreten können.

Melde dich doch einfach mal, "nachdem" du die Solution verwendet hast, denn erst dann haben wir auch ein klares Ergebnis.

Gruß,
Ralf

[Supi]

@Kastlr: Hm, den KB-Eintrag kannte ich noch nicht.
Ohne den Thread zu kapert, aber ein ähnliches Problem haben wir beim V-Motion einer VM.
Anwendungsserver-VM greift auf Datenbank-VM (Oracle 10) zu. Immer beim Vmotion verliert der Client auf dem Anwendungsserver ganz kurz die Verbindung,was reicht, damit die Anwendung neu gestartet werden muss.
Beides Server 2008 Systeme mit VMXNET3 Adapter.

[UrsDerBär]

VMXNET3: Nun der ist manchmal eh problematisch. Habe die allesamt wieder rausgeworfen. Funzte immer ne weile gut und dann nur noch Ärger. Trotz abschalten von diversenen Einstellungen gemäss Anleitung von VmWare.

Hast mal testweise versucht ihn mit einer Intel zu betreiben?

[elmexubi]

@kastlr: Danke für den Tipp. Werd ich mal testen.

@UrsDerBär: Ja - auf einer Intel (also der Anfangseinstellung) ist das Prob ja überhaupt erst aufgetreten.

Gruß
Elmar

[elmexubi]

Hallo zusammen,

nachdem ich alle Eure Tipps beherzigt habe und nichts davon wirklich geholfen hat, habe ich mich mit der Situation abgefunden. Sind die USer halt 2 * in der Woche aus der Datenbank geflogen.. nicht wirklich schön, aber nicht zu ändern.

Jetzt habe ich allerdings die Lösung gefunden, und vielleicht nützt es ja noch jemandem, der irgendwann mal auf das gleiche Problem stößt.

Diese VM hatte ein paar Snapshots, die habe ich for 2 Wochen - der guten ordnung halber- einfach mal gelöscht, sprich konsolidiert (das hat übrigens schlanke 12 Stunden gedauert..).

Seitdem ist der Sekundenschlaf nicht mehr vorgekommen.
Das Problem ist gelöst

Wundert mich, das dieses Verhalten nicht bekannter ist.....

Gruß!

Elmex Ubi

[irix]

Ich habe dich gefragt ob von der VMs snapshots gemacht werden aber da kam ja nix mehr.

- Offene Snapsshot kosten Performance
- Der Commit der Snaps kann die VM verlangsamen und auch zum stehenbleiben bringen. Da haengst dann von den Services ab wie die darauf reagieren.

Wir haben Kunde welche Ihre DBs nicht mehr mit VM Snaps sichern bzw. Replizieren koennen aus obigen Grund.

Gruss
Joerg

[elmexubi]

Hi!

es wird aber mitnichten ein Snapshot zu diesem Zeitpunkt erstellt.
Der Snapshot den ich gelöscht habe war einfach nur einer, den ich zum Installations Zeitpunkt der Kiste erstellt habe. Ich hatte deine Frage so verstanden, als das du meintest ob ZU DEM ZEITPUNKT ein Snapshot erstellt wird. Und das habe ich übrigens in meinem Antwortpost verneint.

Kam also schon noch was....

Das also ein Snapshot quasi nur durch seine Existenz schon dieses Verhalten auslösen kann, war mir neu und ist so auch noch nicht dokumentiert, oder?

Gruß!

Elmex

[irix]

Nein.. ist nicht normal und vorhandene Snaps sorgen nicht fuer den Stillstand.
Aber wenn der 12h fuer den Commit benoetigt hat die Frage wie gross der schon war und ja der ESXi muss mehr Files "offen" halten und es kostet halt ein wenig Performance und mit der Menge der VMs multipiliert es sich.

Es waere nur schoen zuwissen gewesen das die VMs Snaps hat.

[Dayworker]

Der Snapshot den ich gelöscht habe war einfach nur einer, den ich zum Installations Zeitpunkt der Kiste erstellt habe.

Ich verstehe den Sinn dahinter nicht, weshalb man einen Snapshot direkt nach der Installation erstellt und dann nur noch im gesnapshoten Modus weiterarbeitet. Mag ja sein, daß das VMFS damit geschickter umgeht als die VMware-Desktopprodukte. Dort sind jedenfalls Snapshots mit nicht nur meßbaren Performanceeinbrüchen verbunden und hier wie dort sind Snapshots kein Backup sondern nur Mittel zum Zwecke eines Backups.

[elmexubi]

das hat ja auch
... direkt keinen Sinn....

Es ist nur so, das ich es immer so mache, wenn ich eine VM installiere.
Erst richte ich das Betriebssystem ein, installier alle Patches.

DANN mache ich einen Snapshot und dann installiere ich die Anwendersoftware. Das hat den Sinn, das manche Software (zumindest bei uns) so kompliziert zu installieren ist und dich zum Integrationszeitpunkt vor irreversible Entscheidungen stellt, das ich es immer als sehr angenehm empfunden habe, einen kompletten Startover machen zu können.
Das blöde war, das ich hier leider vergessen habe (und es nachher als unnötig erachtet habe), den Snapshot wieder zu löschen. Ist ja nicht jedem klar, das das SOLCHE Auswirkungen haben kann. Mir zumindest nicht! Mit den 2% Performanceverlust von denen ich ausgegangen war hätte ich bei dieser brutalen Powerkiste durchaus leben können.
Aber Komplettfreezes standen halt nicht auf meinem Beipackzettel unter Nebenwrkungen.

[Dayworker]

Wie du auf lediglich 2% Performanceverlust kommen kannst, ist mir ein Rätsel. Die Schreib-Performance ist bei einem komplettvirtualisierenden Hypervisor immer die Achillesferse, da die IO-Performance innerhalb der Gäste durch die Controller-Abbildung in SW immer sowohl von der Systemgesamt- als auch der Gast-Auslastung abhängig ist. Mit einem aktiven Snapshot spielt das provisionierte VMDK-Format (Thin/Thick beim ESXi bzw Sparse/Preallocated bei allen VMware-Desktopprodukten) auch keine Rolle mehr, da Snapshots zumindest bisher immer im Format Thin bzw Sparse abgespeichert sind. Selbst aus datenrettungstechnischer Sicht sind aktive Snapshots nur Murks. Das hängt einfach mit der Art und Weise zusammen, wie Schreib-Anforderunges des Gastes zur Speicherplatzalloziation auf dem Host führen und wie der Hypervisor diese abarbeitet sowie die prinzipielle Verwundbarkeit gesnapshotteter VMs, wenn ein Snapshot-Teil beschädigt wird.