Hardware für Storage Spaces Direct auswählen und validieren

Es ist zwar bekannt, dass die in Windows Server 2016 enthal­tenen Storage Spaces Direct (S2D) zerti­fizierte Hard­ware erfordern. Allerdings reicht es nicht, wenn Kompo­nenten nur für Windows Server zuge­lassen sind. Und selbst wenn sie der Hersteller für S2D getestet hat, ergibt sich daraus nicht immer ein brauch­bares System.

Storage Spaces Direct fasst lokale Laufwerke über alle Cluster-Knoten hinweg zu einem Storage-Pool zusammen. Darauf lassen sich dann hochverfügbare Volumes für Hyper-V einrichten, disaggregiert oder hyper-converged. Das Attraktive an dieser Lösung ist, dass hier Standard-Hardware und bekannte Features wie das Windows Failover-Clustering zum Einsatz kommen.

Doch Standard-Hardware bedeutet nicht beliebige Rechner und Komponenten, das gilt übrigens ganz allgemein für das Windows-Clustering. Gerade bei einem zentralen Storage für eine Vielzahl virtueller Maschinen und oftmals kritischen Applikationen sollte man die Hardware sorgfältig auswählen.

Mysteriöse Fehler aufgrund ungeeigneter Hardware

Oftmals stolpere ich in Community-Foren über Berichte zu Fehlern bei der Konfiguration einer S2D-Lösung, welche sich die Betreffenden nicht erklären können. Storage Spaces Direct lässt sich beispielsweise in solchen Fällen zwar aktivieren und der Pool wird gebildet, doch wenn später ein Knoten aus Wartungs­gründen neu gestartet werden muss, sollten die hochver­fügbaren Volumes online bleiben. Genau dieses Verhalten funktioniert jedoch nicht.

Im weiteren Verlauf stellt sich dann heraus, dass die Cluster-Validierung schon eine nötige SES-Protokoll-Unterstützung (SCSI Enclosure Services), welche eine Voraussetzung bei S2D ist, nicht sauber verifizieren konnte. Aber alle separat zusammen­gestellten Komponenten sind für S2D laut der einzelnen Hersteller zertifiziert! Auch Firmware und Treiber wurden aktuell eingespielt.

Einzelne Komponenten oder eine Gesamtlösung?

Ist es deshalb sinnvoll, hier auf einzelne Komponenten zurückzugreifen? Oder macht eine Gesamtlösung, also die Cluster-Knoten komplett von einem Hersteller zu beziehen, mehr Sinn? Grundsätzlich müssen alle Systeme und Komponenten bei S2D für Windows Server 2016 nach Microsofts Windows Server Katalog zertifiziert sein.

Einzelne Komponenten wie Host-Bus-Adapter lassen sich hier suchen und man kann überprüfen, ob der Hersteller diese für Windows Server 2016 getestet hat. Die Empfehlung für S2D lautet jedoch, eine Komplett­lösung zu kaufen. Partner wie beispielsweise DataON, Dell EMC oder Fujitsu findet man für das Software-Defined Data Center auf der entsprechenden Microsoft Seite.

Software-Defined Data Center (SDDC) zertifiziert

Doch für Windows Server 2016 zertifiziert alleine reicht hier nicht aus. Schauen wir uns das Beispiel des oben genannten HBAs an. Über die Suchfunktion innerhalb des Windows Server Katalog habe ich nötige Infos zu einem Dell HBA330 nachgeschlagen.

Unterhalb der Kategorie zu Certified for Windows Server 2016 erkennt man, dass der Hersteller diesen HBA speziell für Storage Spaces Direct geprüft hat. Die zusätzlichen Punkte zu Software-Defined Data Center (SDDC) Premium und Standard weisen auf diesen Sachverhalt hin.

Tests für eine Premium-Zertifizierung sind weit­reichender als die für eine Standard­auszeichnung und umfassen unter anderem den vollen Virtual Networking Stack oder auch System Center Virtual Machine Manager. Tauchen die SDDC-Klassifi­zierungen nicht auf und der Controller erhält nur die Zertifizierung für Windows Server 2016, kann das bedeuten, dass der Hersteller die Komponente für S2D nicht getestet oder diese den Test nicht bestanden hat.

Validierung für Failover-Cluster fragt viele Bedingungen ab

Ob eine Hardware-Konfiguration für Storage Spaces Direct genügt, prüft für uns vor der Cluster-Erstellung die Cluster-Validierung nach einem vorgegebenen Prüfkatalog. Dieser wurde durch Microsoft seit dem Release (RS1) von Windows Server 2016 laufend für S2D aktualisiert.

Den Link zur Validierung erreicht man wie gewohnt über die GUI des Failovercluster-Manager (Validate Configuration/Cluster überprüfen…) oder via PowerShell nach folgendem Muster in Deutsch:

$Node = "S2D-CORE-A","S2D-CORE-B","S2D-CORE-C"

Test-Cluster -Node $Node -Include "Storage Spaces Direct",`
"Netzwerk","Hyper-V-Konfiguration","Inventar","Systemkonfiguration"

Das damit erzeugte Prüfprotokoll ist nicht nur wichtig für die Klärung, ob eben Knoten den Anforderungen entsprechen, sondern es dient auch im möglichen Support-Fall zusammen mit Microsoft als Beleg.

Insgesamt sollte eine Validierung der Konfiguration (Hyper-V, Netzwerk und S2D) am Anfang stattfinden und immer dann, wenn beispielsweise Knoten oder andere Komponenten hinzugefügt bzw. ausgetauscht werden.