Bei Verzögerungen im Hypervisor – erkenntlich durch die Metrik "KAVG" – handelt es sich um die sogenannte "Kernel Command Latency". AVG steht für "average", also den Mittelwert. Dieser setzt sich zusammen aus der Summe der Verzögerungen, die in Sende- und in Empfangsrichtung auftreten und wird, wie auch die anderen Verzögerungsmetriken, in Millisekunden angegeben. Ein Wert von "2" sollte hier dauerhaft nicht überschritten werden und weist in der Regel auf Queuing hin.

Weiterhin gibt es Verzögerungen durch Queuing – QAVG und QUED – wobei QAVG für die mittlere Verzögerung in der Warteschlage steht und QUED die Anzahl der Einträge in der Warteschlage angibt. Liegt der Wert von QAVG im selben Bereich wie KAVG, ist die Ursache der Verzögerung tatsächlich die Warteschlage in Senderichtung, was auf HBA-Überlast schließen lässt. Bei hohem Messwert von KAVG und einer QAVG-Zahl von nahe "0" könnte allerdings die Verzögerung auf dem Rückweg, beispielsweise durch massive CPU-Überlast, verursacht sein. Der Schwellenwert für QAVG ist der gleiche wie der von KAVG – QUED sollte möglichst klein sein, im Idealfall "0" oder "1".

Die sogenannte "Device Latency" (DAVG) gibt an, wie lange es durchschnittlich dauert, bis nach dem Senden einer Anfrage das Storage-System eine Antwort zurückgibt. Hohe Werte weisen hier auf mögliche Überlast des Storage-Systems hin, der Zielwert liegt kleiner als 25 Millisekunden. Hierbei ist zwingend das Gesamtsystem zu betrachten. In einem Fall beobachteten wir, dass bei sehr hoher Device Latency das eigentliche Storage-System völlig unterfordert war. Ursache dafür: Die verwendete logische Festplatte (LUN) war synchron auf ein anderes Storage-System gespiegelt, auf dem gerade ein RAID-Rebuild stattfand.

Die vom Gastsystem sichtbare Verzögerung ist unter der Bezeichnung "GAVG" bekannt. Während bei blockbasiertem Storage die Einzelwerte von DAVG und KAVG zusammen mit deren Summe GAVG darstellen, steht bei NFS lediglich GAVG als Metrik zur Verfügung. GAVG sollte wie DAVG 25 Millisekunden nicht überschreiten.

Warnsignal-Abbrüche – sogenannte ABRTS/s – finden statt, wenn ein Gastsystem eine Anfrage sendet und für eine gewisse Zeit keine Antwort vom Storage-System bekommt. In diesem Fall kann das Gastsystem die Anfrage abbrechen. Bei Windows zum Beispiel erfolgen diese "Aborts" typischerweise nach 60 Sekunden und werden vom Hypervisor mitgezählt. Dies sollte unter normalen Umständen niemals auftreten.

Paketverluste beim Senden und Empfangen
Die Messwerte, die ESXi bezüglich des Netzwerks erfassen kann, sind in vielen Fällen nicht ausreichend, um potenzielle Netzwerkprobleme aufzuspüren. So kann ESXi zwar erkennen, wenn aufgrund von Überlast zu sendende Pakete verworfen werden mussten. Pakete, die an anderer Stelle im Netz verlorengehen (Switches, Router, WAN), kann ESXi allerdings nicht darstellen. Wer neben der vSphere-Infrastruktur auch das Netzwerk betreut, kann die Analyse natürlich Ende-zu-Ende durchführen. In der Regel liegt die Verantwortung für das Netz allerdings bei einem anderen IT-Team, das bei der Analyse zwingend involviert sein muss.

Folgende Metriken sind zur Analyse der Netzperformance verfügbar: MbTX/s, PKTTX/s, MbRX/s und PKTRX/s. Diese Werte geben den Durchsatz in MBit/s beziehungsweise Paketen pro Sekunde (PKT/s) in Sende- (TX) und Empfangsrichtung (RX) an.

Paketverluste beim Senden (angezeigt durch die Metrik "%DRPTX") treten auf physischen Netzwerkkarten (vmnic##) auf, wenn die Summe der zu sendenden Daten die verfügbare Bandbreite der Karte übersteigt. Mögliche Gegenmaßnahmen sind eine Aufrüstung der Netzinfrastruktur auf höhere Geschwindigkeit oder eine bessere Verteilung der Last über die verfügbaren Netzwerkkarten beziehungsweise ESXi-Hosts. Treten Paketverluste beim Senden nur bei einzelnen VMs auf, hilft bei Windows-Gastsystemen möglicherweise eine Konfigurationsänderung des Treibers weiter.

ESXi zählt nur empfangene Pakete, keine verloren gegangen (%DRPRX). Folglich gehen die Pakete auf dem Weg vom Empfangspuffer der physischen Netzwerkkarte zur VM oder dem entsprechenden VMkernel-Port verloren. Treten Paketverluste für alle Empfänger gleichermaßen auf, liegt die Ursache mit hoher Wahrscheinlichkeit an CPU-Überlast. Sind nur einzelne VMs betroffen, könnte die Ursache beim Gastsystem liegen. Bekommt das Gastsystem zum Beispiel nicht ausreichend CPU-Leistung zugeteilt, kann dieses eventuell die Pakete nicht so schnell entgegennehmen wie nötig. Ein typisches, wenn auch unbedenkliches Beispiel sind hier die "parent VMs" von Instant-Clone-VMs, wie sie in virtualisierten Desktopumgebung üblich sind. Da diese virtuellen Maschinen keine CPUs mehr zugeteilt bekommen, liegt der Messwert hier meist bei 100 Prozent DRPRX.

Fazit
In einer vSphere-Umgebung stehen viele Performanceindikatoren zur Verfügung. Bei Analysen von Performanceproblemen, die typischerweise Tuning-Maßnahmen vorausgehen, ist es zunächst wichtig herauszufinden, welche der vier Kernressourcen – CPU, RAM, Storage oder Netz – limitierend wirkt. Dieser Beitrag hat Ihnen ein Grundverständnis der wichtigsten Performanceindikatoren vermittelt. Allerdings ist es in Umgebungen mit einigen Hundert oder gar Tausend ESXi-Hosts kaum möglich, mit Performancecharts oder esxtop proaktiv die gesamte Umgebung auf Performanceprobleme zu untersuchen. In großen Umgebungen sollten Sie in Betracht ziehen, die VMware-Software Aria Operations (ehemals vRealize Operations) einzusetzen. Neben der Möglichkeit, aktuelle Performanceprobleme auch in größeren Umgebungen aufzuzeigen, ist sie auch in der Lage, basierend auf beobachteten Messwerten der Vergangenheit und Extrapolation auf mögliche Engpässe hinzuweisen, die mittel- oder langfristig auftreten könnten.

Im ersten Teil des Workshops haben wir erklärt, wie Sie Metriken mit esxtop analysieren und CPU-Schwellenwerte festlegen. Im zweiten Teil ging es um das Arbeitsspeicher-Management beim ESXi-Host. Dabei haben wir Begriffe wie Transparent Page Sharing, Ballooning und Memory Compression erklärt.