In diesem Dokument werden wir ein Tool aus den VMware Labs besprechen, das uns helfen wird, unser Speichersystem zu testen, unter einem virtuellen Appliance namens VMware IO Analyzer. Dieses einfache Appliance wird uns Grafiken zur Leistung auf MV- und Host-Ebene anzeigen, es wird dafür Iometer verwenden & esxtop,

Wir werden das Appliance von der Website VMware Labs, herunterladen, es kommt im OVF-Format und wir importieren es mit dem VMware-Client in unsere virtuelle Infrastruktur.

Sobald das Appliance bereitgestellt ist, bevor wir es einschalten, können wir eine zusätzliche Festplatte erstellen, die wir für die Tests verwenden werden, Wir geben an, dass die Festplatte mit 'Thick Provision Eager Zeroed' vorab gefüllt wird.’ und wir werden es im Datastore platzieren, wo wir die Tests durchführen wollen. Wir werden zudem das 100 MB große löschen, das mitgeliefert wird,

Wir starten das virtuelle Appliance, wir gehen in dessen Konsole und wählen die Option “Netzwerk konfigurieren” um die Netzwerkkonfigurationseinstellungen anzupassen,

Wir werden eine statische oder dynamische IP-Adresse konfigurieren.

Sobald wir eine Sitzung gestartet haben, können wir uns von einem anderen Gerät mit einem Browser verbinden.

Wir müssen die Hosts hinzufügen, auf denen wir die IO Analyzer-Appliances haben, um das Benchmarking in unserem SAN durchzuführen, Und das alles von “IOMETER-TESTS”

Anschließend wählen wir jeden Host aus, jede IO Analyzer vApp, eine Workload zum Testen und die IP-Adresse der vApp. Wir werden mehrere MVs gegen verschiedene/dieselben Datastores einführen, um das Verhalten der(s) Kabine(s). Wir werden mindestens 120 Sekunden angeben, empfohlen zwischen 5 und 10 Protokoll.

Wir können diese Einstellungen speichern, um sie später zu laden, es kommen mehrere Beispielvorlagen, in diesem Fall werde ich die von ‚Exchange_2007.icf‘ verwenden, neben den folgenden:

– Umtausch 2003 – 4k block 80% Zufällig – 60% Lesen
– Umtausch 2007 – 8k block 80% Zufällig – 55% Lesen
– SQL Server – 16k block 100% Zufällig -66% Lesen
– Oracle OLTP – 8k block 88% Zufällig – 72% Lesen
– Oracle DW – 32k block 20% Zufällig – 90% Lesen
– Max IOPS 4k block 0% Zufällig – 100% Lesen
– Max TP – 32k block 0 % Zufällig – 100% Lesen

* Wenn wir keine Ergebnisse erhalten und einen Fehler ‚InvalidEsxtopCsvFile‘ haben’ kann es sein, dass wir keine Verbindung zu den Hosts haben oder dass wir ein Sonderzeichen im root-Passwort haben (das könnte behoben werden, indem man das Zeichen ” vor dem Symbol einfügt).

Während des Stresstests werden wir sehen, wie in den MVs des IO Analyzers das Iometer automatisiert geladen wird, wir können zum Tab “Ergebnisse anzeigen” Um den Prozess zu beobachten, bevor wir auf die Berichte warten 🙂

Sobald die Zeit vergangen ist, Wir gehen zum “ERGEBNISSE” & wir werden den Bericht auswählen. Dieses Bild stammt aus einer 'Labor'-Umgebung’ sehr arm, in der wir nur eine Festplatte von einem VAPP in einem Datenspeicher gescannt haben.

Wir werden Statistiken auf Gastebene beobachten (Überblick über das Appliance von Iometer) und auf Hostebene (esxtop). Auf Gästebene:

– IOPS: Anzahl der E/S-Operationen pro Sekunde.
– ReadIOPS: Anzahl der Leseoperationen pro Sekunde.
– WriteIOPS: Anzahl der Schreiboperationen pro Sekunde.
– MBPS: Gesamtdurchsatz pro Sekunde.
– ReadMBPS: Durchsatz beim Lesen pro Sekunde.
– WriteMBPS: Durchsatz beim Schreiben pro Sekunde.

Auf Hostebene:

– CMD's: Anzahl der E/S-Operationen pro Sekunde.
– READS/s: Anzahl der Leseoperationen pro Sekunde.
– WRITES/s: Anzahl der Schreiboperationen pro Sekunde.
– MBREADS/s: Durchsatz beim Lesen pro Sekunde.
– MBWRITES/s: Durchsatz beim Schreiben pro Sekunde.
– DAVG/cmd (msec): Die Latenz zwischen den HBA und den Festplatten.
– KAVG/cmd (msec): Latenz, die vom vmkernel erzeugt wird (sollte nahe sein zu 0.00 Frau).
– GAVG/cmd (sec): Die vom Gast gesehene Gesamtlatenz (DAVG + KAVG)
– QAVG/cmd (sec): Die durchschnittliche Warteschlangenlatenz.

Daten als Referenz:

– Festplatten mit 7200 Umdrehungen pro Minute (rpm) (SATA) zwischen 75 – 100 IOPS.
– 10K rpm Festplatten (SATA) zwischen 125 – 150 IOPS.
– 10K rpm Festplatten (SAS) Briefumschlag 140 IOPS.
– 15K rpm Festplatten (SAS) zwischen 175 – 210 IOPS.
– SSD Festplatten ab 6000 IOPS!!!

Dieses andere Bild, mit etwas höherer Leistung, da es eine 'Produktions'-Umgebung ist, wir werden den kombinierten Scan von zwei Maschinen über zwei verschiedene Datastores, die sich in zwei verschiedenen Kabinen befinden, sehen, würde uns als klare Vergleichsbasis dienen.

Wenn wir wollen, wir können das Verhalten einer unserer Maschinen mit einem manuellen Prozess aufzeichnen, bei dem wir unsere aktuelle Last exportieren und dann in IO Analyzer importieren. Zu diesem Zweck stützen wir uns auf den Befehl 'vscsiStats',’ um die Statistiken der VM zu erhalten, wenn wir 'vscsiStats -l' ausführen’ nos listará todas las MVs de este host con sus worldGroupID (GID) y sus discos virtuales (handleID). Con ‘vscsiStats -s -t -w GID -i handleID’ comenzaremos a recolectar la información de la carga en dicho vHD para posteriormente reproducirlo. Guardaremos en un archivo la traza con ‘logchannellogger vscsiStats-traceChannel /tmp/stats.log’

Pararemos el proceso con ‘CTR + X’ cuando tengamos suficiente información, además pararemos el proceso de recolección con ‘vscsiStats -x -w GID -i handleID’.

Con ‘vscsiStats -e /tmp/stats.log > /tmp/stats.csv’ convertiremos los resultados en un fichero CSV.

Lo primero será subir las trazas desde “TRACE UPLOAD”, indicarle un nombre & Beschreibung, Wir werden den vollständigen Pfad zur Datei im CSV-Format sowie den Namen des Hosts, der sie hat, geben & das Root-Passwort. “Hochladen”,

Wir werden wie zuvor einen Host auswählen, die vApp von IOAnalyzer und die neu generierte Trace, wir werden die Festplatte angeben, auf der die Analyse durchgeführt wird, die Ausführungsgeschwindigkeit (0.5x, 1.0x, 2.0x…) & Wir geben “Laufen”,

Und das ist es, wir werden die Ergebnisse von zuvor auf einer anderen MV durchgeführten Analysen sehen, die wir hierher verschoben haben, um einen neuen Speicher auszuprobieren, etc…