Belastungstest: Workloads für Storage Spaces Direct mit VM Fleet simulieren

    VM-Fleet IOPSVM Fleet kann Storage Spaces Direct Cluster mit simu­lierten Work­loads unter Last setzen. Es bringt dafür mehrere Skripte mit und baut auf Diskspd, um dann innerhalb von auto­matisch generierten VMs Arbeits­last zu erzeugen. Dieser Bei­trag zeigt, wie eine Umgebung für VM Fleet vorbe­reitet wird und Tests konfiguriert werden.

    Nach dem Aufbau eines Clusters mit Storage Spaces Direct (S2D) macht es Sinn, wenn man diesen im Vorfeld annähernd einer Belastung aussetzt, wie sie folgend im produktiven Einsatz zu erwarten ist. Doch auch darüber hinaus, um seine Maximalleistung besser einzugrenzen. Dafür lässt sich die Hardware-Konfiguration samt Firmware und Treiber prüfen, indem man verschiedene Workloads nachbildet.

    Die relative "Maßeinheit", um Vergleiche beim Storage anzustellen, lautet auch hier IOPS. VM Fleet hilft uns bei diesem Vorhaben mit verschiedenen fertigen Skripten und erlaubt es, eine definierte Anzahl an VMs speziell für diesen Zweck zu erzeugen und dann in ihnen I/O mit Diskspd zu generieren. Das Gesamtergebnis spiegelt schlussendlich die lesenden- und/oder schreibenden IOPS wider, in Zusammenhang mit essentiellen Messdaten zu Latenzen bzw. Durchsätzen.

    Fujitsu PRIMERGY RX2540 M2

    Für diesen Test verwende ich zwei Fujitsu PRIMERGY RX2540 M2 Knoten, welche als Gesamteinheit für S2D zertifiziert sind. Die Messer­gebnisse dieser S2D-Hybrid-Ausstattung liefern keine IOPS im High-End Segment, zeigen jedoch schon die Möglichkeiten einer derartigen Konfiguration.

    Ausstattung für das Storage Spaces Direct PoC Lab

    Meine hier konfigurierte Hyper-converged-Umgebung besteht aus folgenden Hardware-Komponenten auf jedem der 2 Knoten:

    • 2 x Intel Xeon E5-2620@2.10 GHz v4 CPUs
    • 128 GB (8 x 16) DDR4 RAM
    • HBA PSAS CP400i inkl. Expander
    • 2 x Samsung MZ7KM240 SATA-SSD 240 GB (Cache für S2D, 1:3)
    • 6 x Seagate ST2000NX0253 2.5 SATA-HDD 1,82 TB (Kapazität für S2D)
    • 25 GbE QLogic FastLinQ QL45212H RDMA Adapter (RoCE)
      Direct-connect (ohne Switche), kein SET

    Windows Server 2016 Datacenter der Hosts startet von einem zusätzlichen SSD-RAID-Spiegel.

    Voraussetzungen für VM Fleet

    Bevor wir VM Fleet verwenden können, müssen ein paar Voraus­setzungen erfüllt sein. Dazu zählt generell erst einmal, dass Hyper-V und das Feature Failover-Cluster aktiviert sind. Das Betriebs­system sollte mit den aktuellen Updates versorgt sein und die Cluster-Validierung keine Fehler zeigen. Datacenter Bridging (DCB) ist auf den beiden Fujitsu-Knoten installiert und konfiguriert (trotz switchless).

    Wenn S2D dann aktiviert ist, erhalten die Cluster Shared Volumes den Knoten­namen und es sollte eines pro Knoten vorhanden sein. Zusätzlich ist ein CSV mit dem Namen Collect für die VM Fleet-Skripte und das VM-Core-Image der späteren Gast-VMs erforderlich. Hier werden hinterher auch die Ergebnisse gespeichert. Die Volumes im 2-Wege-Spiegel erstelle ich nach folgendem Muster:

    New-Volume -StoragePoolFriendlyName "S2D*" -FriendlyName Collect `
    -FileSystem CSVFS_ReFS -Size 300GB

    Cluster Shared Volumes des S2D-Clusters für VM Fleet (umbenannt)

    Master-Image erstellen

    Das bereits angesprochene Core-Image dient zukünftig für die Test-VMs. Dafür erstelle ich eine Server-Core-VM auf Basis von Windows Server 2016. Die VM fahre ich nach Erstellung herunter und lege die VHDX dann auf dem Collect-CSV ab.

    Master-Image für die virtuellen Maschinen von VM-Fleet

    Wichtig für die spätere Weiter­verarbeitung innerhalb der PS-Skripte ist das hier festgelegte lokale Passwort, dieses muss vermerkt werden.

    VM Fleet herunterladen und installieren

    Das 2,5 MB große ZIP-Archiv für VM Fleet kann man von GitHub herunterladen, es ist dort über den Link Clone or download erreichbar. Beim Entpacken verwende ich in diesem Lab den Zielordner C:\DeployRepository und lege hier den Inhalt des Ordners diskspd-master ab. Für die Installation von VM Fleet auf dem Collect-CSV ist der Aufruf install-vmfleet.ps1 erforderlich:

    .\install-vmfleet.ps1 -source C:\DeploymentRepository\diskspd-master\Frameworks\VMFleet\

    VM-Fleet mittels PowerShell installieren

    Nachdem VM Fleet installiert wurde, erscheint im Collect-CSV der Ordner control inklusive aller nötigen Skripte. Für den künftigen synthetischen Workload muss zusätzlich das Diskspd Tool herunter­geladen und unter C:\ClusterStorage\Collect\control\tools die diskspd.exe gespeichert werden.

    Test-VMs erstellen und anpassen

    Wurden alle Vorbereitungen getroffen, dann lassen sich die Test-VMs ausrollen. Dafür verwenden wir das Skript create-vmfleet.ps1 wie folgt:

    .\create-vmfleet.ps1 -BaseVHD "C:\ClusterStorage\Collect\MASTER.vhdx" `
    -VMs 10 -AdminPass <VMPASSWORD> -ConnectUser <HOSTADMIN> `
    -ConnectPass <HOSTPASSWORD>

    Virtuelle Maschinen für VM-Fleet erzeugen

    In diesem Beispiel werden 10 VMs pro CSV erstellt, der Failover Cluster Manager sollte letztendlich dieses Bild zeigen:

    Der Failover Cluster Manager zeigt die automatisch angelegten VMs

    Um reelle Bedingungen zu schaffen, passe ich alle ausgerollten virtuellen Maschinen im ausgeschalteten Zustand folgendermaßen an:

    .\set-vmfleet.ps1 -ProcessorCount 4 -MemoryStartupBytes 8192MB `
    -MemoryMaximumBytes 8192MB -MemoryMinimumBytes 8192MB

    Starten der VMs und Cluster testen

    Für die endgültigen Belastungstests müssen die hochverfügbaren VMs gestartet werden, dafür liefert VM Fleet das Skript start-vmfleet.ps1 und zum Herunterfahren das Pendant stop-vmfleet.ps1.

    Starten und Stoppen der VM-Fleet 

    In zwei separaten PowerShell-Konsolen starte ich jetzt den VM Fleet Monitor zu den IOPS/BW/Latenzen + Software Storage Bus (SSB) Cache mit watch-cluster.ps1 -sets 'CSV FS','SSB Cache' und für die CPU-Auslastung mit watch-cpu.ps1. Die Messwerte werden hier von Performance Countern herangezogen, schauen Sie sich das Skript zu watch-cluster genauer an. Im bestehenden PS-Fenster leite ich den ersten 3-minütigen Stresstest ein:

    .\start-sweep.ps1 -b 4 -t 4 -o 4 -w 10 -d 180

    Stresstest starten und überwachen

    Alle Ergebnisse werden abschließend im Cluster Shared Volume unter C:\ClusterStorage\Collect\control\result pro VM gespeichert.

    Aufschlüsseln der Testparameter und nützliche Skripte

    Schauen wir uns die Parameter einmal genauer an, damit klar wird, wie die Ergebnisse zustande kommen:

    -b 4: Block size in KB

    -t 4: Anzahl der Threads

    -o 4: Outstanding IO (QD)

    -w 10: Write Ratio, hier: w = 10 = 10% Schreibzyklen = 90% lesend

    -d 180: Duration = 180 Sek. = 3 Min. (+ 120 Sek. Warm-up und Cool-down)

    IO ist hierbei standardmäßig random (-p r).

    Es ist natürlich interessant einige Szenarien durchzuspielen und ggfs. VMs neu auszurollen bzw. unterschiedliche Parameter wie 30% Schreibzyklen (-w 30) bei 8KB random zu definieren. Das folgende Diagramm zeigt die Messwerte unterschiedlicher Block sizes mit 8 Threads/pro File bei einem Outstanding IO von 4, Latenzen steigen hier linear.

    Messreihe zu unterschiedlichen Blockgrößen

    Nützliche Skripte für VM Fleet sind allgemein:

    destroy-vmfleet.ps1: Test-VMs werden pausiert und wieder entfernt

    Hinweis: Nach der Nutzung von VM Fleet ist es wichtig, die Umgebung anschließend wieder aufzuräumen, da VM Fleet auch virtuelle interne Switche erstellt.

    test-clusterhealth.ps1: Prüft den Gesamtzustand (RDMA, S2D health, etc.)

    set-, check-, clear-pause.ps1: IO Pausen-flags setzen, prüfen + löschen

    Keine Kommentare