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

    Storage-Performance messen mit DiskSpdDas kosten­lose Diskspd kann die Per­for­mance eines Storage-Systems mes­sen und ver­schie­dene Anwen­dungs­lasten simu­lieren. Relative Bench­mark-Werte werden dann in IOPS, also Input/Output Operations per Second ausge­geben und liefern einen Richt­wert für seine Leistungs­fähigkeit.

    Bei Anwendungen wie Microsoft Exchange oder SQL Server kann es nötig sein, die Performance des Speichersystems im Vorfeld zu ermitteln, um ihnen die nötige Lese-/Schreibleistung plus Latenz bei entsprechender Benutzeranzahl und Konfiguration zu liefern. Gerade bei einem zentralen Storage für eine größere Anzahl an virtuellen Maschinen spielen diese Kennwerte eine große Rolle, auch etwa wenn man QoS konfigurieren möchte.

    Herunterladen von Diskspd für die Prüfumgebung

    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.

    Workload-Parameter für den Testlauf und Ergebnisse

    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:

    -c16G Größe der Testdatei festlegen, in diesem Fall auf 16 GB
    -d300 Gibt die Testdauer in Sekunden an, sie entspricht also 5 Minuten
    -r Mit diesem Schalter wird zufällig gelesen und geschrieben (Random), typisch für Echtzeit-Transaktions­verarbeitung (Online-Transaction-Processing, kurz OLTP)
    -w30 Gibt das prozentuale Schreiben an, 30 bedeutet 30% Schreiben und 70% Lesen.
    -b8k 8 KB (Block size) ist ein dominierender IO Workload für SQL Server. Diese generieren unterschiedlichen IO. Typisch für Exchange wären 64 KB.
    -t4 Bei kleinem IO justieren wir die Anzahl der Threads pro File (t) gleich der Anzahl der CPU Kerne
    -o8 Mit "o" (Outstanding IO) wird die Warteschlangentiefe (Queue depth) angegeben.
    -h Dieser Parameter schaltet das Hardware write- und OS-Caching ab.
    -L Gibt die durchschnittliche Wartezeit (Average Latency) zum Vervollständigen eines IO aus.
    c:\Test.dat Bestimmt, wie die Testdatei benannt und wo diese abgelegt wird. (In diesem Fall in der VM auf dem CSV, mit Volume im SAN) Auch SMB-Freigaben lassen sich hier in UNC-Notation hinterlegen.

    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.

    Der Fokus liegt auf Total 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.

    Keine Kommentare