Ist die Konfiguration der Server korrekt, können Sie mit dem Erstellen des Failover-Clusters fortfahren. Das System benötigt einen Namen und eine eigene IP-Adresse. Bei einem Fail-over-Cluster, der mit dem Active Directory arbeitet, wird ein Computerobjekt in eben diesem AD angelegt. Sofern eine der Netzwerkkarten in den Servern ein Standard-Gateway hat, kommt dieses Subnetz automatisch als das primäre Cluster-Netzwerk zum Einsatz. Sie müssen nur noch eine freie IP-Adresse für den Cluster angeben. Achten Sie zudem darauf, dass Sie die Option "Add all eligible Storage to the Cluster" abwählen, andernfalls kann es dazu kommen, dass die Datenträger einzeln hinzugefügt werden. Die Konfiguration des Storage passiert erst, nachdem unser Cluster fertig ist.

Steht der Failover-Cluster soweit, richten Sie ein Quorum (auch als Witness bezeichnet) ein. Bei einer geraden Anzahl an Cluster-Knoten muss zwingend ein Quorum vorhanden sein, damit es zu einer ungeraden Anzahl an Entscheidungsträgern kommen kann. Da die S2D-Knoten den Speicher jeweils an Bord haben, können Sie mit nur einem "Cloud Witness" oder einem "File Share Witness" arbeiten. Bei einem „Cloud Witness“ auf Basis von Microsoft Azure müssen die Server eine aktive Onlineverbindung haben, dies ist in vielen Fällen jedoch nicht gewollt.

Daher konfigurieren wir ein "File Share Witness", in diesem Fall auf dem Domaincontroller. Da das Quorum niemals im Cluster selbst liegen darf (so wie auch der DC), bietet sich dieses System an. Sie können natürlich auch eine eigene VM oder einen eigenen Server für diese Aufgabe installieren, letztendlich liegen allerdings lediglich ein paar KByte Daten in zwei Dateien auf dem System. Zu beachten ist, dass Sie die Computerkonten der Cluster-Knoten sowie das Cluster-Computerobjekt freigeben müssen. Daher ist es sinnvoll, wenn diese Maschine ebenfalls Mitglied im gleichen AD ist. Eine Freigabe mit einem "Everybody / Allow All" wäre auch möglich, ist aber deutlich unsicherer.

Jetzt erstellen Sie auf dem Quorum-Server eine Freigabe und setzen eine Schreibberechtigung für die Knoten und das Cluster-Objekt. Im S2D-Cluster rufen Sie nun im Kontextmenü des Clusters unter "More Actions" die Option "Configure Cluster Quorum Settings" auf. Nach der Vorbemerkung wählen Sie die zweite Option "Select the Quorum Witness", um nach einem Klick auf "Next" die Option "Configure a file share witness" anzusteuern. Nach einem weiteren Klick auf "Next" geben Sie den Freigabepfad ein und bestätigen ihn. Der Button "Browse" ist an dieser Stelle sinnfrei, am besten öffnen und prüfen Sie den Pfad vorab per Windows Explorer und kopieren ihn dann vollständig in die Zwischenablage.

Anschließend wechseln Sie in die Netzwerkübersicht des Clusters. Benennen Sie hier die vorhandenen Netzwerke optimalerweise um – diese werden im Standard lediglich hochgezählt. Ein konkreter Name sorgt für Übersichtlichkeit und eine einfachere Bearbeitung. Sie finden im Failover-Cluster-Manager nach einem Klick auf die Netzwerke im unteren Reiter "Network Connections" die Namen der lokalen Adapter, um die Benennung der Netze hiervon abzuleiten.

In den Einstellungen der Livemigration bringen Sie die Karten in die gewünschte Reihenfolge. In unserem Beispiel mit der zuvor beschriebenen Ausstattung möchten wir die beiden 100-GBit/s-Ports für die primäre Livemigration nutzen, daher ordnen wir diese beiden Karten ganz oben an. Das Managementnetzwerk verbleibt aktiv, allerdings an der untersten Stelle. Dies hat den Hintergrund, dass ein Ausfall des 100-GBit/s-NIC trotzdem noch Livemigrationen erlaubt, allerdings mit beschränkter Bandbreite. Schalten wir das Managementnetzwerk an dieser Stelle ab, würden wir im Fehlerfall vielleicht nicht sofort merken, warum eine Livemigration im Cluster nicht mehr möglich ist.

Die Einstellung der Livemigration kann nicht vollständig über den Failover-Cluster erfolgen, einige Optionen sind nur lokal konfigurierbar. Hier hilft die PowerShell, um die Settings auf allen Knoten identisch einzurichten:

Dieser Befehl aktiviert auf allen Knoten im Failover-Cluster die Livemigration per SMB-Protokoll. Dies sorgt für eine aktive Nutzung von RDMA (sofern vorhanden) und SMB-Multichannel. Mit dieser Funktion werden die Daten über beide 100-GBit/s-Ports gleichzeitig verschickt beziehungsweise empfangen, ohne dass wir LACP oder dergleichen benötigen. Die gleichzeitige Anzahl der Livemigrationen pro Knoten musste bis Anfang 2024 noch pro Knoten festgelegt werden, ist aber mittlerweile eine Cluster-Option und Sie richten dies wie folgt ein:

Die Zahl können Sie jederzeit auf einen Wert Ihrer Wahl anpassen. Je höher die Bandbreite zwischen den Knoten, desto mehr VMs können gleichzeitig migrieren.

Nach all diesen Vorarbeiten aktivieren wir nun die S2D-Funktion per PowerShell mit Enable-ClusterS2D  -verbose. Der Parameter "-verbose” liefert mehr Informationen zu dem Vorgang. Sie erhalten eine Übersicht über die Anzahl und Typen der gefundenen und einbezogenen Datenträger. Im Hintergrund entsteht jetzt automatisch ein neuer Storage-Pool und die Datenträger werden Teil davon. Je nach Disklayout wird ein Cache automatisch erzeugt und zugewiesen, bei einem einzelnen Typ von Datenträgern stehen alle davon zum direkten Speichern von Daten zur Verfügung.

Anschließend erzeugt S2D im Hintergrund automatisch einen neuen, virtuellen Datenträger mit dem Namen "ClusterPerformanceHistory". Dieser dient dazu, Performancedaten des Clusters und der Datenträger zu sammeln. Mithilfe dieser Daten haben Sie zum Beispiel im Windows Admin Center eine Übersicht der Latenz- sowie IO-Werte. Dies erlaubt eine direkte Ansicht der Metriken für einen bestimmten Zeitraum – auch nachträglich. Sie können sich die Informationen zum Storage-Pool und dem ersten virtuellen Datenträger mit den folgenden Befehlen anzeigen lassen:

Damit nun Daten und virtuelle Server im Cluster gespeichert werden können, müssen Sie weitere virtuelle Datenträger erzeugen. Dies geschieht per Power- Shell (oder im Windows Admin Center). Sie müssen allerdings die Größe und das Layout der vDisk berücksichtigen. Beachten Sie an dieser Stelle auf jeden Fall die Reserve im Speicherpool, über die wir bereits gesprochen haben. Beim Erstellen müssen Sie einen Namen, das Dateisystem, den Speicherpool und die Größe des Volumes angeben. Den "Friendlyname" können Sie frei vergeben.

Sind die Datenträger einmal erzeugt und formatiert, stehen sie danach als CSV-Datenträger auf den Knoten unter "C:\ClusterStorage" mit diesem Namen zur Verfügung. Das "FileSystem" ist in den meisten Fällen "CSV- FS_ReFS", kann aber auch "CSVFS_NTFS" sein. ReFS als Dateisystem bietet bei einem S2D-Cluster einige Vorteile, NTFS kommt nahezu nicht zum Einsatz. Der "StoragePoolFriendlyName" ist der automatisch erstellte Speicherpool bei der Aktivierung von S2D. Da der Name immer mit "S2D" beginnt, können Sie den Pool mit "S2D*" ansprechen, Sie müssen den Namen nicht zwingend vollständig angeben. Hier ein einfaches Beispiel:

Die Größe des Datenträgers legen Sie mit dem Parameter "Size" fest. Hierbei handelt es sich um den nutzbaren Speicherplatz. Sie müssen beachten, dass Windows (einschließlich der PowerShell) mit Binärzahlen (Basis 2) zählt, während für Laufwerke häufig Dezimalzahlen (Basis 10) zum Einsatz kommen. Dies ist der Grund, warum ein Laufwerk mit "einem TByte" in Windows die Größe 909 GByte aufweist. Dieses Verhalten ist normal und Sie sollten dies bei der Größenplanung berücksichtigen. Legen Sie also ein Laufwerk mit "909 GB" an, entsteht ein Volume mit 1 TByte.

Die Resilienz des Datenträgers legen Sie so fest: Verwenden Sie zwei Server, baut das System automatisch einen Zwei-Wege-Spiegel, bei drei Knoten wird entsprechend ein Drei-Wege-Spiegel erstellt. Nutzen Sie vier oder mehr Server, definieren Sie über den Parameter "ResiliencySettingName" und die Optionen "Mirror" oder "Parity" das Layout der Datenträger. Anbei zwei Beispiele für virtuelle Datenträger, der erste im Spiegellayout, der zweite als Parität:

Wenn Sie bei zwei Knoten einen virtuellen Datenträger benötigen, der sowohl eine lokale Spiegelung als auch eine Spiegelung über die beiden Server hinweg besitzt ("Nested Resiliency"), müssen Sie das Storage-Tier-Layout angeben. Diese Layouts sind Vorlagen, die die Anzahl der Redundanzen der physischen Datenträger beinhalten. Sie bringen die aktuell vorhandenen Layouts mit einem einfachen PowerShell-Befehl auf den Bildschirm:

Ab Windows Server 2019 ist diese Art von Layout möglich, in dieser OS-Version musste das Storage-Tier-Layout allerdings noch per Hand erstellt werden. Mit Windows Server 2022 und 2025 ist es automatisch vorhanden und aktiv. In der Praxis ist häufig zu beobachten, dass Admins ausschließlich das Nested-Layout "NestedMirrorOnHDD" berücksichtigen und die SSD-Variante fehlt. Sie können letztere manuell erstellen und nutzen, sollte dies notwendig sein:

Der Parameter "NumberOfDataCopies” definiert hierbei, wie viele Kopien insgesamt entstehen. Vier Kopien auf zwei Servern bedeutet, dass immer zwei pro Server vorhanden sind. Ein Datenträger in diesem Layout erzeugt beispielsweise dieses Kommando:

Schauen Sie sich die virtuellen Datenträger nun mittels Get-VirtualDisk an, zeigt die Ausgabe im Reiter "StorageEfficiency", für den neuen Datenträger eine Storage-Effizienz von circa 25 Prozent. Weiterhin ist ersichtlich, dass die Größe von einem TByte einen "FootprintOnPool" von 4 TByte hat.

Jetzt können Sie weitere virtuelle Datenträger erstellen. Dabei gilt die Faustregel, dass die Anzahl der vDisks gleich der Anzahl der Cluster-Knoten ist oder jeweils das mehrfache davon. Damit kann der Failover-Cluster die Datenträger gleichmäßig verteilen und jeder Server kümmert sich im Normalbetrieb um die Hälfte der CSV-Datenträger. Achten Sie dabei darauf, die Reservekapazität zu berücksichtigen und lassen Sie ausreichend Platz.

Eine Vergrößerung von virtuellen Datenträgern ist jederzeit im laufenden Betrieb möglich. Dieser Vorgang benötigt keine Downtime und ist sehr schnell und einfach erledigt. Es ist daher zu empfehlen, die vDisks immer etwas kleiner als das mögliche Maximum anzulegen. Dies garantiert ausreichend Reserve und zur Not vergrößern Sie einen oder mehrere Datenträger nachträglich. Deren Verkleinerung ist hingegen nicht so einfach im laufenden Betrieb möglich, sollten Sie bei der Größenberechnung einen Fehler gemacht haben. Das Windows Admin Center zeigt die benötigte Kapazität sehr gut grafisch an – an diesen Werten können Sie sich orientieren.

Wenn Sie nach der Installation das WAC öffnen und eine Verbindung zum S2D-Cluster herstellen, können Sie im linken Seitenmenü in der Rubrik "Clusterressourcen" den Punkt "Laufwerke" anklicken. Dies liefert Ihnen eine grafische Übersicht des gesamten Speicherplatzes (verfügbar und die empfohlene Rücklage).

Jetzt sind wir an einem Punkt, an dem wir unsere Installation testen sollten. Dabei geht es darum, die maximale Performance und Leistung herauszufinden. Diese Werte zeigen, wie der Failover-Cluster arbeitet, mit welcher Performance zu rechnen ist und ob irgendetwas möglicherweise nicht so funktioniert, wie es sollte. Solch ein Check zeigt weiterhin, ob die Systeme auch unter hoher Last über einen längeren Zeitraum sauber arbeiten oder ob es zum Beispiel thermische Probleme gibt.

Da ein Admin einen solchen Belastungstest nicht mal eben aus dem Hut zaubert, hat Microsoft vor einigen Jahren begonnen, eine PowerShell-Skript-Sammlung namens "VMFleet" [1] zu veröffentlichen, die in der Lage ist, eine definierte Anzahl an VMs für Benchmarks zu erzeugen. Diese Skripte wurden vor einigen Jahren in einem eigenen PowerShell-Modul zusammengefasst. Mittels VMFleet erzeugen Sie eine beliebige Anzahl VMs, die auf Kommando Last am System anlegen.

Als Vorbereitung für den Benchmark benötigen wir CSV-Datenträger, optimalerweise einen pro S2D-Knoten. Deren Größe und Layout sollten sich daran orientieren, wie der Cluster danach produktiv arbeitet. Es ergibt wenig Sinn, einen Test mit einem Zwei-Wege-Spiegel durchzuführen, wenn danach "Nested Resiliency" zum Einsatz kommt. Lassen Sie allerdings noch 200 GByte Speicherplatz (plus die Spiegelblöcke) frei, da noch ein Service-Datenträger erforderlich ist. Diese "Collect"-vDisk speichert die Skripte und Vorlagen.

Sind unsere Datenträger am Start, müssen wir einmalig einen Windows Server 2025 in der Core-Variante installieren. In den Beispielen ist das lokale Kennwort "adminpass". Wichtig ist, dass dieses Passwort bekannt ist, da es später während des Deployments der Flotte Verwendung findet. Nach der Grund- installation können Sie die VM wieder herunterfahren und die VHDX-Datei in "Gold.vhdx" umbenennen sowie auf den erstellten Collect-Datenträger kopieren. Die Installation der VMFleet-Skripte passiert nun mittels PowerShell:

Ist Ihr System online, lädt es die benötigten Daten aus der PowerShell-Gallery herunter und speichert sie lokal. Danach importieren Sie das Modul und richten VMFleet mittels Install-Fleet ein. Hierbei entstehen die notwendigen Pfade und Dateien auf dem Collect-Datenträger. Der Pfad dorthin ist zwingend notwendig – ist der Datenträger nicht vorhanden oder heißt anders, schlägt die Einrichtung fehl. Hat alles geklappt, erzeugen Sie VMs:

Als "basevhd” geben Sie die im Vorfeld abgelegte "Gold.vhdx"-Datei an, von dieser werden jeweils Kopien erzeugt und daraus neue VMs erstellt. Die Anzahl der VMs definieren Sie mit dem Parameter "vms". Dies bestimmt die Anzahl an VMs pro Knoten, hinterlegen Sie also bei zwei Knoten eine "10", entstehen in Summe 20 VMs – zehn pro Knoten. Der "adminpass" ist das lokale Kennwort für die manuell installierte VM. Dieses ist notwendig, damit sich die VMs während der Erstellung anpassen und vorbereiten lassen. Die letzten beiden Parameter "connectuser" und "connectpass" sind Benutzername und Kennwort von einem Account, der auf die Cluster-Knoten zugreifen darf. Diese Daten sind notwendig, damit die VMs über eine interne Netzwerkverbindung mit dem Cluster-Knoten sprechen können. Sind die VMs erstellt, können Sie bei Bedarf noch deren Hardwarespezifikationen ändern. Wenn zum Beispiel jede VM mit zwei vCPUs und 4 GByte RAM laufen soll, nutzen Sie den Befehl:

Allzu viele Ressourcen brauchen die VMs nicht, da der Benchmarktest auch bei einer recht geringen Ausstattung an RAM gut funktioniert und Last erzeugt. Die VMs starten Sie denkbar einfach mit Start-Fleet. Damit booten die Systeme, verbinden sich per Netzwerk mit dem Host und warten auf weitere Befehle. Sie können nun entweder einen zeitlich beschränkten Testlauf durchführen oder die Systeme für eine unbegrenzte Zeit in den Testzustand versetzen. Um zu verstehen, wie die Tests funktionieren und mit welchen Parametern Sie testen, schauen wir uns einmal ein Beispiel an:

Mit diesem Befehl startet ein zeitlich begrenzter Benchmark, der 300 Sekunden lang läuft. Dies wird über den Parameter "-d" geregelt. Der erste Parameter "-b" definiert die Größe der Blöcke und der hier aufgeführte Wert "4" testet mit 4 KiB. Kleine Blockgrößen sorgen für bessere Benchmarkwerte, sind aber selten realistisch für ein Hyper-V-Fail- over-Cluster mit einem bunten Strauß an unterschiedlichen Applikationen und Systemen. Als Faustregel gilt: Je kleiner die Blocksize, desto höher die I/O-Werte und je größer die Blocksize, desto höher der Durchsatz. Dies ist allerdings abhängig von vielen anderen Faktoren, unter anderem von dem Parameter "-t". Hiermit definieren Sie die Anzahl an Prozessen pro Ziel ("Number of threads per target"). Die Option "-o" gibt an, wie viele ausstehende I/O-Anforderungen pro Ziel und pro Prozess zum Einsatz kommen ("Number of outstanding I/O requests per-target per-thread").

Ein sehr wichtiger Wert ist "-w", er beschreibt den Anteil an Schreib-I/Os und kann sich zwischen 0 und 100 bewegen. Wobei "0" heißt, dass keine schreibenden Tests stattfinden, sondern dass es ausschließlich lesenden Zugriff auf das System gibt. Ein derartiger Zugriff ist immer die schnellste Form von Test, da von Datenträgern schneller gelesen als geschrieben werden kann. Der langsamste Test hingegen wäre ein Wert von 100, das heißt das System wird ausschließlich mit Schreib-I/O belastet und getestet. Da sowohl 0 als auch 100 in der Realität eher selten vorkommen, sind 30 schreibend und 70 lesend oder 50/50 praxisnah. Überlegen Sie einfach kurz, welche Werte am besten zu Ihrer Umgebung passen.

Noch besser ist es, die Daten aus Ihrem Storage- oder Monitoringsystem zu bekommen. Der Parameter "-p" definiert einen schließlich zufälligen I/O ("random I/O"). Eine vollständige Liste und Beschreibung aller Parameter liefert [2]. In Echtzeit bringen Sie Performancewerte mit Watch-Cluster zum Vorschein. Hierbei ist insbesondere die aktuelle I/O-Leistung interessant, sowie die Latenzen für die Schreib- und Lesezugriffe. Wenn Sie den Befehl mit dem Parameter "-Sets *" ergänzen, erhalten Sie noch deutlich mehr Informationen.

Sie können nun unterschiedliche Dinge testen und auswerten. Interessant ist natürlich ein Test unterschiedlicher Parameter, insbesondere die Blockgröße und das Verhältnis zwischen Lese- und Schreib-I/O. Weiterhin kann es auch hilfreich sein, zu sehen, wie sich der Cluster bei einer steigenden Anzahl an VMs verhält. Wenn Sie den Test mit jeweils zehn VMs pro Knoten begonnen haben, können Sie jederzeit weitere VMs dazu installieren und den gleichen Check wiederholen. Sie werden sehen, dass die Performance bei einer steigenden Anzahl an VMs vielleicht noch etwas ansteigt, dann aber irgendwann abfällt.

So sind Sie zum einen in der Lage, eine mögliche Grenze auszumachen, die nicht überschritten werden sollte, zum anderen erzeugen Sie sich damit eine Baseline und Referenz für später. Bemerken Sie irgendwann nach Wochen, Monaten oder Jahren auf einmal eine deutliche Steigerung der Latenz, können Sie dies eventuell durch einen Vergleich mit den VMFleet-Benchmarks untersuchen. Ein längerer Test mit voller Belastung zeigt Ihnen, ob die Systeme auch lange Zeit mit viel Last laufen können, ohne auf Probleme zu stoßen.

Um den VMFleet-Aufbau wieder vollständig zu entfernen, nutzen Sie die Befehle Stop-Fleet und Remove-Fleet, die alle laufenden VMs herunterfahren und den gesamten Aufbau entfernen. Anschließend sollten Sie die Knoten überprüfen, ob noch ungewollte Konfigurationen vorhanden sind, zum Beispiel die internen vSwitches. Die Datenträger können Sie komplett entfernen, damit die finalen vDisks in der gewünschten Größe entstehen können. Und ein letzter Tipp: VMFleet verändert im Failover-Cluster die Option der automatischen CSV-Ausbalancierung. Um die automatische Verteilung der CSV-Datenträger wieder zu aktivieren, nutzen Sie (get-cluster).CsvBalancer = 1.

Ein S2D-Cluster unter Windows Server 2025 liefert Ihnen einen der schnellsten Software-defined Storage am Markt. Die Planung des Designs und der verwendeten Hardware ist der wichtigste und umfangreichste Teil und entscheidet im späteren Betrieb über die Leistung und die Zuverlässigkeit.