Heute werden wir die Kennzahlen des Speicher-Subsystems in vSphere analysieren. Speicherprobleme sind die häufigste Ursache für langsame virtuellen Maschinen. Während das Troubleshooting bei CPU und RAM auf Hypervisor-Ebene endet, müssen wir bei Festplattenproblemen möglicherweise das Netzwerk und das Speichersystem untersuchen.
Ich werde das Thema anhand des Beispiels des blockbasierten Zugriffs auf das Speichersystem behandeln, obwohl die Zähler beim Dateizugriff ähnlich sind.
Ein wenig Theorie
Wenn es um die Leistung des Speicher-Subsystems virtueller Maschinen geht, achtet man in der Regel auf drei miteinander verbundene Parameter:
- die Anzahl der Ein- und Ausgabeoperationen (Input/Output Operations Per Second, IOPS);
- der Durchsatz (Throughput);
- die Latenz der Ein- und Ausgabeoperationen (Latency).
Die Anzahl der IOPS ist normalerweise wichtig für belastungstypische Anforderungen (random): Zugriff auf Blöcke auf der Festplatte, die an verschiedenen Orten liegen. Beispiele für solche Lasten sind Datenbanken, Geschäftsanwendungen (ERP, CRM) usw.
Bandbreite ist wichtig für sequentielle Belastungen: Zugriff auf Blöcke, die direkt hintereinander liegen. Hier können beispielsweise Dateiserver (aber nicht immer) und Überwachungssysteme solche Lasten erzeugen.
Der Durchsatz steht in folgender Beziehung zur Anzahl der Ein- und Ausgabeoperationen:
Throughput = IOPS * Blockgröße, wobei die Blockgröße die Größe des Blocks ist.
Die Blockgröße ist eine ziemlich wichtige Kennzahl. Moderne Versionen von ESXi unterstützen Blöcke mit einer Größe von bis zu 32.767 KB. Ist der Block größer, wird er in mehrere Blöcke aufgeteilt. Nicht alle Speichersysteme können effektiv mit so großen Blöcken arbeiten, deshalb gibt es in den erweiterten Einstellungen von ESXi den Parameter DiskMaxIOSize. Mit diesem Parameter kann die maximale Blockgröße, die vom Hypervisor zugelassen wird, verringert werden (mehr dazu ). Ich empfehle, sich vor der Änderung dieses Parameters mit dem Hersteller des Speichersystems zu beraten oder zumindest die Änderungen in einer Testumgebung zu testen.
Eine große Blockgröße kann sich negativ auf die Leistung des Speichersystems auswirken. Selbst wenn die Anzahl der IOPS und der Durchsatz relativ gering sind, können bei großer Blockgröße hohe Latenzen auftreten. Achten Sie daher auf diesen Parameter.
Latenz – der interessanteste Parameter für die Leistung. Die Latenz der Ein- und Ausgabeoperationen für die virtuelle Maschine setzt sich zusammen aus:
- der Latenz innerhalb des Hypervisors (KAVG, Average Kernel MilliSec/Read);
- Die Verzögerung, die durch das Datennetzwerk und den Speicher (DAVG, Average Driver MilliSec/Command) verursacht wird.
Die Gesamtverzögerung, die im Gastbetriebssystem sichtbar ist (GAVG, Average Guest MilliSec/Command), ist die Summe aus KAVG und DAVG.
GAVG und DAVG werden gemessen, während KAVG berechnet wird: GAVG–DAVG.
Lassen Sie uns genauer auf KAVG. Bei normalem Betrieb sollte KAVG streben, null zu sein oder zumindest wesentlich geringer als DAVG. Der einzige mir bekannte Fall, in dem KAVG erwartungsgemäß hoch ist, ist eine IOPS-Beschränkung auf dem VM-Disk. In diesem Fall wird KAVG steigen, sobald Sie versuchen, das Limit zu überschreiten.
Die bedeutendste Komponente von KAVG ist QAVG – die Warteschlange für die Verarbeitung innerhalb des Hypervisors. Die anderen Komponenten von KAVG sind vernachlässigbar klein.
Die Warteschlange im Festplattentreiber und die Warteschlangen zu den LUNs haben eine feste Größe. Für stark belastete Umgebungen kann es sinnvoll sein, diese Größe zu erhöhen. beschreibt, wie man die Warteschlangen im Adaptertreiber erhöht (gleichzeitig erhöht sich die Warteschlange zu den LUNs). Diese Einstellung funktioniert, wenn nur eine VM mit der LUN arbeitet, was selten der Fall ist. Wenn mehrere VMs auf einer LUN sind, muss auch der Parameter Disk.SchedNumReqOutstanding (Anweisung ). Durch Erhöhung der Warteschlange verringern Sie QAVG und KAVG entsprechend.
Aber schauen Sie sich zunächst die Dokumentation des HBA-Anbieters an und testen Sie die Änderungen auf einer Laborumgebung.
Die Größe der Warteschlange zur LUN kann durch die Aktivierung des SIOC-Mechanismus (Storage I/O Control) beeinflusst werden. Dieser gewährleistet einen gleichmäßigen Zugriff auf die LUN von sämtlichen Servern im Cluster, indem die Warteschlange zu den LUNs auf den Servern dynamisch angepasst wird. Das bedeutet, dass, wenn auf einem der Hosts eine VM läuft, die unverhältnismäßig viel Leistung benötigt (noisy neighbor VM), SIOC die Länge der Warteschlange zur LUN auf diesem Host verkürzt (DQLEN). Weitere Informationen .
Jetzt haben wir KAVG behandelt, jetzt etwas über DAVG. Hier ist alles einfach: DAVG ist die Verzögerung, die durch die externe Umgebung (Datennetzwerk und Speicher) verursacht wird. In jedem modernen und weniger modernen Speicher gibt es eigene Leistungszähler. Für die Problemanalyse mit DAVG lohnt es sich, einen Blick darauf zu werfen. Wenn alles auf der Seite von ESXi und dem Speicher in Ordnung ist, überprüfen Sie das Datennetzwerk.
Um Performance-Probleme zu vermeiden, wählen Sie die richtige Path Selection Policy (PSP) für Ihr Storage-System (SCS). Praktisch alle modernen SCS unterstützen PSP Round-Robin (mit ALUA, Asymmetric Logical Unit Access, oder ohne). Diese Richtlinie ermöglicht die Nutzung aller verfügbaren Pfade zum SCS. Im Fall von ALUA werden nur die Pfade zu dem Controller verwendet, der das LUN besitzt. Nicht für alle SCS auf ESXi gibt es Standardregeln, die die Round-Robin-Politik festlegen. Falls für Ihr SCS keine Regeln vorhanden sind, verwenden Sie das Plugin des SCS-Herstellers, das die entsprechende Regel auf allen Hosts im Cluster erstellt, oder erstellen Sie die Regel selbst. Details .
Einige SCS-Hersteller empfehlen auch, die Anzahl der IOPS für den Pfad von dem Standardwert 1000 auf 1 zu ändern. In unserer Praxis hat dies ermöglicht, mehr Leistung aus dem SCS herauszuholen und die Zeit, die für den Failover bei einem Ausfall oder einer Aktualisierung der Controller benötigt wird, erheblich zu verkürzen. Überprüfen Sie die Empfehlungen des Anbieters, und wenn es keine Einwände gibt, versuchen Sie diesen Parameter zu ändern. Details .
Die wichtigsten Leistungszähler des Speicher-Subsystems der virtuellen Maschine
Die Leistungszähler des Speicher-Subsystems in vCenter sind in den Abschnitten Datastore, Disk, Virtual Disk gesammelt:
Im Abschnitt Datastore Hier finden Sie Metriken zu den Datenspeichern von vSphere, auf denen die VMs gespeichert sind. Hier finden Sie die Standardzähler für:
- IOPS (Durchschnittliche Lese-/Schreibanfragen pro Sekunde),
- Durchsatz (Lese-/Schreibrate),
- Latenzen (Lese-/Schreib-/Höchste Latenz).
Aus den Namen der Zähler ist im Prinzip alles klar. Ich möchte nochmals betonen, dass hier die Statistik nicht für eine bestimmte VM (oder VM-Disk) gilt, sondern allgemein für den gesamten Datastore. Meiner Meinung nach lässt sich diese Statistik in ESXTOP besser betrachten, zumindest weil die minimale Messperiode dort 2 Sekunden beträgt.
Im Abschnitt Festplatte Hier finden Sie Metriken zu den Blockgeräten, die von den VMs verwendet werden. Es gibt Zähler zum Typ IOPS summation (Anzahl der Ein-/Ausgabeoperationen über die Messperiode) und mehrere Zähler, die sich auf den Blockzugriff beziehen (Commands aborted, Bus resets). Diese Informationen lassen sich meines Erachtens ebenfalls besser in ESXTOP betrachten.
Abschnitt Virtueller Datenträger – das nützlichste Werkzeug zur Problemuntersuchung der Leistung des Festplattensystems der VM. Hier können Sie die Leistung der einzelnen virtuellen Festplatten einsehen. Diese Informationen sind entscheidend, um festzustellen, ob ein spezifisches Problem bei einer bestimmten virtuellen Maschine vorliegt. Neben den Standardmetriken wie der Anzahl der Ein-/Ausgabeoperationen, dem Lese-/Schreibvolumen und den Verzögerungen finden Sie in diesem Abschnitt nützliche Zähler, die die Blockgröße anzeigen: Lese-/Schreibanforderungsgröße.
Im Bild unten ist das Leistungsschema der VM-Festplatte dargestellt, auf dem die Anzahl der IOPS, die Verzögerungen und die Blockgröße zu sehen sind.
Die Leistungsmetriken können auch für den gesamten Datenspeicher angezeigt werden, wenn SIOC aktiviert ist. Hier sind die grundlegenden Informationen zu durchschnittlicher Latenz und IOPS dargestellt. Standardmäßig können diese Informationen nur in Echtzeit eingesehen werden.
ESXTOP
In ESXTOP gibt es mehrere Bildschirme, die Informationen zum Festplattensystem des Hosts insgesamt, zu einzelnen virtuellen Maschinen und deren Festplatten anzeigen.
Beginnen wir mit den Informationen zu den virtuellen Maschinen. Der Bildschirm „Disk VM“ wird mit der Taste „v“ aufgerufen:
NVDISK – dies ist die Anzahl der VM-Festplatten. Um Informationen zu jeder Festplatte anzuzeigen, drücken Sie „e“ und geben Sie die GID der gewünschten VM ein.
Die Werte der anderen Parameter auf diesem Bildschirm sind aus ihren Bezeichnungen ersichtlich.
Ein weiterer nützlicher Bildschirm bei der Problemuntersuchung ist der Disk-Adapter. Er wird mit der Taste „d“ aufgerufen (im Bild unten sind die Felder A, B, C, D, E, G ausgewählt):
NPTH – die Anzahl der Pfade zu LUNs, die von diesem Adapter aus sichtbar sind. Um Informationen zu jedem Pfad am Adapter zu erhalten, drücken Sie „e“ und geben Sie den Namen des Adapters ein:
AQLEN – die maximale Queue-Größe am Adapter.
Auf diesem Bildschirm finden Sie auch die oben genannten Verzögerungszähler: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.
Auf dem Bildschirm Disk device, der mit der Taste „u“ aufgerufen wird, sind Informationen zu einzelnen Blockgeräten – LUNs (im Bild unten sind die Felder A, B, F, G, I ausgewählt) dargestellt. Hier können Sie den Zustand der Warteschlange zu den LUNs einsehen.
DQLEN – die Größe der Warteschlange für das Blockgerät.
ACTV – die Anzahl der Ein-/Ausgabeoperationen im Kern von ESXi.
QUED – die Anzahl der Ein-/Ausgabeoperationen in der Warteschlange.
%USD – ACTV / DQLEN × 100%.
LOAD – (ACTV + QUED) / DQLEN.
Wenn %USD hoch ist, sollten Sie erwägen, die Warteschlange zu erhöhen. Je mehr Befehle in der Warteschlange sind, desto höher sind QAVG und entsprechend KAVG.
Auch auf dem Bildschirm Diskgerät kann überprüft werden, ob VAAI (vStorage API for Array Integration) auf dem SAN aktiv ist. Dazu müssen die Felder A und O ausgewählt werden.
Der VAAI-Mechanismus ermöglicht es, einen Teil der Arbeit vom Hypervisor direkt auf das SAN zu verlagern, wie beispielsweise das Nullsetzen, das Kopieren von Blöcken oder Sperren.
Wie auf dem obigen Bild zu sehen ist, funktioniert VAAI auf diesem SAN: Die Primitive Zero und ATS werden aktiv genutzt.
Tipps zur Optimierung der Arbeit mit dem Speichersystem auf ESXi
- Achten Sie auf die Blockgröße.
- Stellen Sie die optimale Warteschlangenlänge am HBA ein.
- Vergessen Sie nicht, SIOC auf den Datenspeichern zu aktivieren.
- Wählen Sie PSP entsprechend den Empfehlungen des SAN-Herstellers aus.
- Stellen Sie sicher, dass VAAI funktioniert.
Nützliche Artikel zum Thema:
Quelle: habr.com
