Im HTML5-basierten vSphere-Client stehen unter dem Reiter "Monitor" für die meisten Objekte Performancecharts zur Verfügung. Overview-Charts verschaffen einen groben Überblick, während die Advanced-Performancecharts detaillierte Analysen erlauben. Diese grafisch dargestellten Indikatoren sind auch für Dokumentationszwecke sehr hilfreich. So können Sie beispielsweise die Effekte von Tuning-Maßnahmen in einem Vergleich der Metriken vor und nach der Optimierung leicht verständlich darstellen.

Metriken mit esxtop analysieren
Wer von Linux das Werkzeug "top" kennt, wird sich auch mit "esxtop" nach einer Einarbeitungsphase leicht zurechtfinden. Esxtop kommt in der Regel direkt auf dem ESXi-Host zum Einsatz. Neben der interaktiven Benutzung unterstützt esxtop auch einen Batch-Modus, um die erfassten Messwerte im CSV-Format zu speichern. Die so gewonnenen Messdaten lassen sich über Skripte oder auch eine beliebige Tabellenkalkulation weiter auswerten.

Führen Sie esxtop interaktiv aus, ist es wichtig, dass ESXi der Wert der Umgebungsvariable "$TERM" bekannt ist. Viele Linux-Terminals verwenden zum Beispiel xterm-256color, was ESXi nicht unterstützt. Abhilfe schafft vor Aufruf von esxtop das Kommando TERM=xterm. Da esxtop auf dem ESXi-Host läuft, müssen Sie bei der Metrikenanalyse Ihrer virtuellen Maschine (VM) sicherstellen, dass sie während der Messung nicht auf einen anderen ESXi wandert. Am einfachsten stellen Sie hierzu, sofern DRS aktiviert ist, das Automation-Level temporär auf manuell. Alternativ können Sie auch eine Regel im Cluster erzeugen, um die VM gezwungen auf dem betreffenden Host auszuführen.

Nach Aufruf von esxtop steht Ihnen außerdem über die Option "h" oder "?" eine kurze Hilfeseite mit nützlichen Kommandos zur Verfügung (Bild 1). Mit den unter "Switch display" angegebenen Optionen schalten Sie zwischen verschiedenen Ansichten um; beim Start zeigt das Tool per default die CPU-Ansicht an. Mithilfe der Taste "F" können Sie Metriken je nach Bedarf löschen oder hinzufügen. In den Ansichten zu CPU und RAM sehen Sie interne Prozesse, die sich mittels "V" auch ausblenden lassen.

CPU-Schwellenwerte festlegen
Haben Sie mithilfe der Performancecharts oder mittels esxtop Messwerte erfasst, stellt sich die wichtige Frage: Welche sind akzeptabel? Zwar gibt es hier in der Regel keine festen Schwellenwerte, aber eine hilfreiche Übersicht finden Sie hier. Duncan Epping, Autor der Seite, hat hier die wichtigsten Performanceindikatoren mit einem Schwellenwert sowie einer kurzen Erklärung zusammengestellt.

Eine virtuelle CPU (vCPU), die bereit ist, Code auszuführen, muss vom Scheduler des ESXi-Hosts einen physischen CPU-Kern zugeteilt bekommen. Ist dies nicht möglich, wächst dieser Messwert an. Die Metrik "%RDY" (CPU Ready Time) sagt aus, wieviel Prozent der Zeit, in der eine vCPU Code ausführen wollte, dies nicht möglich war. Wann immer eine virtuelle CPU bereit ist, Code auszuführen, muss der Scheduler zunächst einen physischen CPU-Kern zuteilen. Dadurch ergibt sich eine minimale Verzögerung zwischen dem Zeitpunkt, in dem die vCPU bereit ist und dem Moment, in dem sie beginnt, Code auszuführen. Das Resultat ist, dass %RDY fast nie null Prozent beträgt, selbst wenn der ESXi-Host ausreichend Ressourcen frei hat. Werte zwischen null und ein Prozent lassen sich daher als "nahe null" interpretieren.

Das Ziel ist es, den Messwert unter zehn Prozent zu halten. Hierbei müssen Sie beachten, dass in %RDY zwei verschiedene Ursachen eingehen: die CPU-Überlast des Hosts und die Begrenzung der CPU-Leistung durch ein Limit (VM oder Ressource Pool). Messen Sie also sehr hohe Werte bei manchen VMs, nicht aber bei anderen auf demselben Host, sollten Sie konfigurierte CPU-Limits überprüfen. Der Anteil, der aufgrund von CPU-Limits in %RDY eingeht, lässt sich am Messwert "%MLMTD" (Max Limited) erkennen. Ist dieser größer als Null, greift ein CPU-Limit im Scheduler ein.

Der Scheduler des ESXi-Hosts führt ein sogenanntes "relaxed co-scheduling" aus, was bedeutet, dass temporär auch nur ein Teil der vCPUs einer VM gescheduled werden kann. Dies darf aber nur für relativ kleine Zeitspannen im Bereich einiger zehn Millisekunden erfolgen, da sonst das Gastbetriebssystem erkennt, dass einige CPUs nennenswert Fortschritt machen, andere aber nicht. Das Erkennen dieses "clock skew" genannten Effekts kann die VM empfindlich stören und bis zum Absturz führen.

Stellt der Scheduler die Gefahr fest, dass die VM clock skew erkennt, hält er die virtuelle Maschine an, bis ausreichend CPU-Kerne verfügbar sind. Hauptursache ist hier übermäßige Verwendung von VSMP (Virtual Symmetric Multiprocessing). Abhilfe schafft häufig, den VMs weniger virtuelle CPUs zuzuordnen. Die Bauernregel "viel hilft viel" ist bei der CPU-Virtualisierung eher kontraproduktiv. In der Praxis zeigt sich allerdings, dass VMs in der Regel eher über- als unterdimensioniert sind, was die Anzahl virtueller CPUs angeht. Der Zielwert von "%CSTP" (Co-Scheduling Stops), den Sie nicht überschreiten sollten, liegt, je nach Quelle, zwischen zwei und drei Prozent.

Die Metrik "%SWPWT" (Swap Wait) ist strenggenommen ein Messwert, der auf Speicherengpässe hinweisen kann. Haben Sie RAM stark überprovisioniert, kann es sein, dass ESXi Speicherseiten der VMs auf das Storage-System auslagert. Greift die VM auf eine ausgelagerte Speicherseite zu, muss sie warten, bis der Hypervisor die Speicherseite vom Storage gelesen hat. Findet also Swapping auf Hypervisor-Ebene statt, kann dies die Performance virtueller Maschinen stark reduzieren. Wie stark die VM unter diesem Effekt leidet, lässt sich mit "%SWPWT" quantitativ erfassen.

ln/jm/Torsten Mutayi

Im zweiten Teil der Workshop-Serie geht es um das Arbeitsspeicher-Management beim ESXi-Host. Dabei erklären wir Begriffe wie Transparent Page Sharing, Ballooning und Memory Compression.