Storage-Performance (IOPS) unter Hyper-V messen mit Diskspd

Sie finden Diskspd in der TechNet Gallery und können von dort das ZIP-Archiv kostenlos herunterladen. Es beinhaltet mehrere Versionen, unter anderem eine 64-Bit-Variante im Ordner amd64fre, die für unsere Benchmark-Maschine mit Windows Server 2012 R2 genau passt. Wer anstelle des Konsolenfensters eine grafische Oberfläche benötigt, wird beim Projekt DiskSpeed fündig, hier erhält man die Diskspd GUI.

Ein Test wird von verschiedenen Faktoren positiv und negativ beeinflusst, zum Beispiel von RAID-Level, Controller, Suchzeit oder Rotationsgeschwindigkeit.

Meine hier genutzte virtuelle Maschine verrichtet Ihren Dienst in einem Hyper-V Failover-Cluster Labor, bestehend aus zwei Host-Knoten und zwei Cluster Shared Volumes in einem 10 Gbit iSCSI SAN. Die zentrale EqualLogic Storage-Appliance ist mit 12 konventionellen 840 GB SAS-HDDs bestückt, welche mit einer Geschwindigkeit von 10.000 RPM rotieren. Der Verbund arbeitet im RAID 6 Level.

Die Test-VM führt zum Zeitpunkt des synthetischen Workloads keine weiteren IO- oder CPU-lastigen Prozesse aus und wurde speziell für diesen Zweck erstellt.

Diskspd mit Parametern ausführen

Diskspd kann in der VM selbst oder in der Parent Partition laufen. Ich entscheide mich für einen schnellen Test innerhalb der VM und starte Diskspd.exe in einer Konsole auf dem virtuellen Server als Administrator (cmd.exe oder PowerShell) mit verschiedenen Parametern, beispielsweise einer Blockgröße von 8 KB, welche eine der typischen Seitengrößen für Microsoft SQL Datenbank Server darstellt.

Darüber hinaus werden zusätzliche Parameter übergeben:

diskspd.exe -c16G -d300 -r -w30 -b8k -t4 -o8 -h -L c:\Test.dat

Bedenken Sie, dass diese Simulation auch die CPUs belastet, eine Testdatei von 16 GB Größe erstellt und die LUN beansprucht. Bei Produktivsystemen sollten diese Belastungstests zuvor geplant werden, auch um aussagekräftige Resultate zu ermitteln. Denn zusätzlicher Workload anderer Maschinen auf dieser LUN können Werte stark verfälschen. Um Engpässe aufzudecken kann dieser Umstand jedoch gewünscht sein.

Beschreibung der Testparameter

Für Informationen über zusätzliche Parameter (sie sind Case-sensitive!) und ihre Verwendung gibt man diskspd.exe ohne Zusätze ein. Im Folgenden schlüsseln wir unsere Testparameter aus dem obigen Aufruf genauer auf:

Auswertung der Diskspd-Ergebnisse

Schaut man sich die Ergebnisse genauer an, erkennt man gut, dass Diskspd diese gruppiert ausgibt und zwar in Total IO, Read IO und Write IO.

Write IO würde nicht generiert, wenn der Parameter -w0 gesetzt wäre. In der Konsole erkennt man oben die relativ gleichmäßige Belastung der CPU-Kerne, welche demnach keinen Flaschenhals darstellt, da wir uns hier nicht am Limit bewegen (Durchschnitt 24,42 %). Als nächstes springen wir direkt in die Kategorie Total IO und sehen hier drei wichtige Kenndaten: Einen Durchsatz von 211,51 MB/s, 27.073,71 IOPS und eine Latenz von 1,179 ms. Je mehr IOPS und je geringer die Latenz, umso besser.

Diese Werte geben also die Möglichkeiten des Storage Subsystems wieder. Mein Blick gilt den Latenzwerten als wichtigen Indikator. Würde ein synthetischer Load für Exchange generiert, lässt sich dieser in Verhältnis zur Zahl Ihrer Exchange-Mailboxen inklusive der IOPS pro Mailbox setzen. Im Exchange-Umfeld bleibt jedoch JetStress das Tool der Wahl, um vorab das Storage künstlich zu belasten.

Auch zuvor gesammelte Daten aus dem Performance-Monitor einer bestehenden Installation können als Grundlage herangezogen werden.

Natürlich ist es interessant, ein paar Szenarien durchzuspielen, also Diskspd mit verschiedenen Parametern zu beschicken. Beispielsweise könnte man die Blockgröße auf 64 KB (-b64K) festlegen und sequentiell (-s) schreiben statt Random (-r). Sequentiell gilt besonders großen Dateien aus zusammenhängenden Blöcken wie sie beim Backup vorkommen.