Alles muss passen

von Jan Kappen

Storage Spaces Direct soll für hochverfügbaren, softwaredefinierten Storage sorgen. Dieser Speicher kann für andere Server oder Cluster zur Verfügung stehen oder gar der Virtualisierung in Form einer hyperkonvergenten Infrastruktur dienen. Doch die komplexe Inbetriebnahme verzeiht keine Fehler in Sachen Netzwerk, Storage oder Cluster. Weshalb am Ende passende Leistungstests stehen müssen.

Bevor Sie in die Storage-Spaces-Direct-(S2D)-Installation einsteigen, sollten Sie unbedingt unseren Artikel zur Technologie und Planung von Storage Spaces Direct [1] herunterladen. Diese Informationen sind ein wichtiger Bestandteil eines S2D-Projekts, das produktiv gehen soll.

Sind all diese Planungen und Vorbereitungen erledigt, geht es an die Installation der Server. Dabei gehen wir davon aus, dass die Maschinen Teil des Active Directory (AD) sind, da die bisherigen S2D-Cluster zwangsweise Teil des AD sein mussten – erst mit Windows Server 2025 ist dies keine Pflicht mehr.

Storage Spaces Direct und das Active Directory

Beim Active Directory gibt es einige Dinge, die Sie beachten sollten und die sich in den letzten Jahren als Best Practice etabliert haben. Als Erstes ist es in sehr vielen Fällen sinnvoll, die Systeme in einem eigenen Management-AD aufzubauen und zu betreiben. Dieses AD kann entweder schon vorhanden sein oder Sie bauen es im Zuge der Cluster-Installation auf. Dieses Vorgehen reduziert die Abhängigkeit enorm, wenn ausschließlich die Cluster-Knoten mit diesem AD arbeiten müssen. Diese Struktur können Sie zudem härten und nach Belieben ändern, ohne dass es Probleme gibt. Da der Hypervisor auf keinen Fall Teil des produktiven AD sein sollte, bietet sich diese komplett getrennte und isolierte Umgebung an.

Auch sollten Sie das AD nicht im Cluster selbst betreiben. Es ist ein typischer Supportfall bei Failover-Clustern, die die Verbindung zum Active Directory nicht herstellen konnten. Dies passiert, weil das Verzeichnis in eben diesem Cluster laufen sollte, der jetzt nicht mehr starten kann, weil das AD nicht erreichbar ist. Dieses Henne-Ei-Problem können Sie sehr einfach lösen, indem Sie mindestens einen Domain-Controller außerhalb des Fail-over-Clusters betreiben.

Da ein Microsoft-Failover-Cluster seine Konfiguration standardmäßig ins Active Directory schreibt und dieses für die Authentifizierung der Server untereinander verantwortlich ist, muss der Verzeichnisdienst grundsätzlich zur Verfügung stehen. Ein Failover-Cluster kann zwar möglicherweise mit zwischengespeicherten Anmeldedaten starten, es gibt aber keine Garantie dafür, dass es wirklich funktioniert.

Windows Server 2025 aufsetzen

Die Server installieren wir mit Windows Server 2025 in der Datacenter-Edition, die Voraussetzung für S2D ist. Die Standardlizenz erlaubt dies nicht. Nach der Installation sollten Sie die aktuellsten Updates einspielen, dies ergibt insbesondere kurz nach der Veröffentlichung des Servers Sinn, da einige Fehler behoben werden. Sie sollten dies unbedingt vor dem Beginn der Konfiguration durchführen, da Sie ansonsten möglicherweise auf Fehler treffen, die nach dem Patchen nicht mehr auftreten.

Installieren Sie für sämtliche Hardware die passenden Treiber, sodass sich keine unbekannten Geräte mehr im Gerätemanager zeigen. Insbesondere die Treiber für die Netzwerkkarten sind sehr wichtig, da Sie ohne eine aktuelle Version möglicherweise nicht alle Einstellungen setzen können oder Microsoft veraltete, eigene Treiber mitbringt, die nicht die volle Performance der Karten nutzen.

Ist das erledigt, achten Sie auf generelle Einstellungen wie die korrekte Zeitzone und richten Sie alles so ein, wie es Ihrem Serverstandard entspricht. Nun sollten Sie im BIOS der Server die Einstellungen überprüfen und gegebenenfalls so anpassen, dass die Maschinen mit der bestmöglichen Performance laufen. Die meisten Systeme bieten einen Profilmanager, der alle notwendigen Einstellungen in einem Profil vereint und direkt passend setzt. In Windows Server 2025 stellen Sie weiterhin die Energie-Optionen so ein, dass das System bestmöglich arbeitet. Diesen Vorgang unterstützt das GUI jedoch nicht mehr so gut, am einfachsten ist daher eine Überprüfung und Konfiguration per PowerShell. Mit powercfg /l erhalten Sie die verfügbaren Default-Profile sowie das aktive Profil und mit dem folgenden Befehl aktivieren Sie das "High Performance"-Profil:

Nun fügen Sie die Systeme als Mitglied ins AD hinzu. Ein Neustart ist an dieser Stelle nicht zwingend notwendig, da dies im nächsten Schritt nach der Installation der Hyper-V-Rolle sowieso erforderlich ist.

Virtuelle Switches einrichten

Nach diesen Vorbereitungen kommen wir zur Installation der notwendigen Rollen ("Hyper-V") und Features ("Failover Clustering"). Setzen Sie RoCE-fähige Netzwerkkarten ein, müssen Sie zusätzlich noch das Feature "Data Center Bridging" einspielen. Dieser Vorgang erfordert zwingend einen Neustart. Sind die Server wieder da, melden Sie sich am besten mit einem AD-Konto an den Systemen an, um die Konfiguration fortzusetzen.

Je nach Netzwerkdesign müssen Sie nun die NICs einrichten und als virtuelle Switches konfigurieren. Als Beispiel für diesen Workshop nutzen wir zwei Server mit einem 100-GBit/s-Dual-Port-NIC sowie einem 25-GBit/s-Dual-Port-NIC. Die beiden 100-GBit/s-Ports richten wir für eine direkte Verbindung untereinander ein, sodass die Storage-Kommunikation im Cluster über diese Adapter läuft. Die anderen beiden Ports machen wir zu einem SET vSwitch, um die VMs mit dem Netzwerk zu verbinden. Auf Basis der virtuellen Switches erzeugen wir noch einen weiteren (virtuellen) Adapter, der für die Anbindung an das Active Directory und das allgemeine Management zur Verfügung steht.

Das Anlegen der virtuellen Switches müssen wir per PowerShell erledigen, denn der Hyper-V-Manager lässt dies nicht mehr zu, nur im Windows Admin Center klappt der Vorgang via GUI. Wie betont greifen wir aber auf ein Cmdlet zurück:

Bei den Switches müssen Sie darauf achten, dass deren Namen auf jedem Server identisch sind, nur dann sind Livemigrationen der VMs im Cluster problemlos möglich. Die Benamung der vSwitches wird auch bei dem Cluster-Validierungstest geprüft und gegebenenfalls beanstandet. Ist das alles erledigt, können wir die Karte konfigurieren und mit IP-Adresse, Subnetzmaske und so weiter ausstatten. Prüfen Sie danach, ob die Verbindung zum AD-Controller und zum Partnersystem problemlos möglich ist.

RoCE-Adapter konfigurieren

Bei den 100-GBit/s-Ports benötigen wir eine etwas umfangreichere Konfiguration. Wir beginnen mit den statischen IP-Adressen sowie der passenden Subnetzmaske. Diese Karten erhalten kein Default-Gateway und keine DNS-Server-Einstellungen. Weiterhin schalten Sie in den erweiterten Optionen die DNS-Registrierung ab und deaktivieren im Reiter "WINS" die Option "NetBIOS über TCP/IP".

Damit RoCE korrekt arbeitet, müssen Sie die Adapter mit einem VLAN ausstatten. Dieses muss zwingend in der Karte selbst gesetzt werden, ein "Untagged"- beziehungsweise "Access"-Port auf dem Switch funktioniert nicht (sofern Sie überhaupt mit Switches arbeiten). Wechseln Sie in die "Erweiterten Eigenschaften" der Netzwerkkarte und suchen Sie dort nach der VLAN-ID-Einstellung. Vergeben Sie eine passende ID – auf beiden Systemen natürlich jeweils die gleiche.

Theoretisch könnten alle vier 100-GBit/s-Ports die gleiche VLAN-ID bekommen, zur besseren Abgrenzung voneinander sollten Sie jeder Verbindung jedoch eine eigene ID zukommen lassen. Je nach Konfiguration können Sie die ID auch von dem IPv4-Subnetz ableiten: Zum Beispiel kann "S2DNode1" auf dem ersten 100-GBit/s-Port die IP-Adresse 192.168.101.11 erhalten und als VLAN die "101". Der zweite Port arbeitet mit 192.168.102.11, also wird hier "VLAN 102" konfiguriert. Das ist keine Pflicht, erleichtert aber das Verständnis.

Neben der VLAN-ID müssen wir in den erweiterten Eigenschaften noch die Paketgröße anpassen. Diese setzen wir vom Standard-Wert auf 9014 Bytes, die Option ist häufig unter "Jumbo Packet" oder "Jumbo Frames" zu finden. Überprüfen Sie nun die Option "Network Direct Functionality" (oder ähnlich), hier muss das RDMA-Protokoll aktiv sein. Bei NVIDIA/Mellanox-Adaptern erreichen Sie dies, indem Sie "RoCE v2" aktivieren.

Setzen Sie die Einstellungen auf allen Knoten und testen Sie, ob Sie die jeweils anderen Systeme erreichen können. Dies geht am einfachsten mit einem Ping oder dem Test-NetConnection-Cmdlet in der PowerShell. Achten Sie jedoch darauf, dass Sie die ICMP-Kommunikation in der lokalen Windows Firewall vorher erlaubt haben. Dies ist standardmäßig nicht mehr der Fall, bei Windows Server 2025 sind die entsprechenden Regeln mit dem Namen "Core Networking Diagnostics" schon vorhanden. Sie müssen diese allerdings aktivieren.

Quality of Servive an den Start bringen

Nun schalten wir "Priority Flow Control" (PFC) ein. Hierzu müssen wir wieder die PowerShell bemühen, da eine Konfiguration per GUI nicht möglich ist. Als Erstes deaktivieren wir die DCBX-Funktionalität, da Windows diese nicht unterstützt:

Als Nächstes entfernen wir alle möglicherweise schon vorhandenen Richtlinien und legen danach die vier benötigten Richtlinien an. Zur Erklärung: Die Regel "SMB" ist am wichtigsten, diese Policy setzt für Kommunikation auf Port 445 (SMB) die Prioritätsklasse drei. Damit wird SMB-Traffic mit der Priorität drei markiert. Im nächsten Schritt definieren wir dann, welche der acht möglichen Klassen wir als "lossless" festlegen:

Nun definieren wir die Priorität drei als die Klasse, die "lossless" arbeiten soll, für alle anderen Klassen deaktivieren wir "NetQosFlowControl". Die Klasse drei ist hierbei nicht zufällig gewählt, sondern industrieweit der Standard.

In allen Dokumentationen von Microsoft und Drittherstellern wird Priorität drei verwendet. Sie tun gut daran, dies nicht eigenmächtig für Ihre Installation zu ändern:

Nachdem wir die Klassen angelegt und aktiviert beziehungsweise deaktiviert haben, können wir nun QoS für die Adapter aktivieren. Damit QoS nur auf den von uns gewählten Adaptern zum Einsatz kommt, deaktivieren wir es im ersten Schritt für alle Adapter, um die Funktion danach wieder für ausgewählte Karten einzuschalten.

Beachten Sie dabei, dass diese Vorgänge auf einem Remotesystem zu einer kurzen Verbindungsunterbrechung führen:

Ähnlich ist es mit der RDMA-Funktion, die meist für alle Karten im Betriebssystem aktiv ist, auch wenn es nicht genutzt wird. Damit RDMA nur auf den gewünschten Adaptern im Einsatz ist, schalten wir die Funktion einmalig für alle Karten ab, um sie danach dann für die Karten unserer Wahl wieder zu aktivieren:

Ist die "Flow Control”-Funktion in den Karten noch aktiv, sollten Sie diese ebenfalls abschalten. Dies lässt sich entweder in den Eigenschaften des NIC durchführen oder per PowerShell:

Zu guter Letzt haben wir noch die Option, ein Prozent für den Cluster-Traffic auf den Karten zu reservieren. Dies ist in den meisten Fällen nicht notwendig, da die zur Verfügung stehende Bandbreite in der Regel nicht vollständig ausgelastet wird. Letztendlich schadet es aber auch nicht, diesen Puffer anzulegen:

Nachdem wir alles notwendige eingerichtet haben, erlauben die folgenden Befehle, alle Einstellungen zu überprüfen:

Auch die Kommunikation untereinander sollten Sie jetzt erneut testen. Ein einfacher Ping von jedem Host auf die zukünftigen Cluster-Partner verrät Ihnen, ob die Pakete erfolgreich ankommen oder ob irgendwo ein Fehler in der Konfiguration ist. Sollten Sie noch ungenutzte Adapter in Ihren Servern haben, deaktivieren Sie diese. Häufig befinden sich auf dem Mainboard noch 1-GBit/s-Ports, die keine Verwendung haben. Sobald sie abgeschaltet sind, werden sie beim folgenden Cluster-Validierungstest nicht mehr berücksichtigt und geben keine (unberechtigten) Warnungen oder Fehler aus.

Validierungstest für den Cluster durchführen

Nachdem wir das Netzwerk der Systeme nun vollständig gesetzt haben, unterziehen wir die Knoten einer Validierung. Dieser Cluster-Validierungstest ist sehr wichtig, da nur ein Cluster ohne Fehler Support genießt. Der Check untersucht sehr schnell und umfangreich unsere Einstellungen. Dies erfolgt für sehr viele Optionen automatisch, was manuell per Hand in der kurzen Zeit nicht machbar ist. Der Test zeigt mögliche Schnitzer oder Fehleingaben sehr gut auf, Sie können diese Warnungen oder Fehler dann beheben und erneut prüfen. So erhalten Sie zudem ein sicheres Gefühl für Installation und Betrieb des Clusters.

Der Cluster-Test lässt sich per PowerShell, Windows Admin Center oder klassisch über den Failover-Cluster-Manager durchführen. Auf jeden Fall ist es wichtig, dass Sie alle Server aufnehmen, die Teil Ihres S2D-Failover-Clusters sind. Ist dies erledigt, müssen Sie die Art der Tests manuell auswählen. Der Standard testet nicht die S2D-Konfiguration, sondern einen Cluster auf Basis von LUNs per iSCSI oder Fibre Channel. In allen drei Varianten deaktivieren Sie die "klassischen" Storage-Tests und wählen "Storage Spaces Direct" aus.

Nach Abschluss der Tests erhalten Sie eine detaillierte Übersicht über den Zustand der Server, der Hardware und der getätigten Einstellungen. Überprüfen Sie den Bericht, insbesondere die Warnungen und Fehler. Fehler führen wie erwähnt dazu, dass Ihr Failover-Cluster keinen Support erhält – ganz davon abgesehen, dass die Konfiguration in der aktuellen Form nicht geeignet ist. Warnungen müssen Sie auch beachten, manche lassen sich einfach beheben, zum Beispiel ein ausstehender Neustart oder ein unterschiedliches Patchlevel der Server.

Fazit

Teil 1 dieses Workshop baute unsere Storage-Space-Direct-Umgebung bis zu einem funktionierenden Cluster auf. Doch wartet noch einiges an Arbeit in Teil 2, in dem wir das Quorum konfigurieren, die Livemigration einrichten und schließlich S2D aktivieren.

Storage Spaces Direct einrichten und testen (1)

Alles muss passen

Storage Spaces Direct und das Active Directory

Storage Spaces Direct und das Active Directory

Windows Server 2025 aufsetzen

Virtuelle Switches einrichten

RoCE-Adapter konfigurieren

Quality of Servive an den Start bringen

Validierungstest für den Cluster durchführen

Fazit