Tags: Storage, Virtualisierung, Windows Server 2016, Hardware
Es ist zwar bekannt, dass die in Windows Server 2016 enthaltenen Storage Spaces Direct (S2D) zertifizierte Hardware erfordern. Allerdings reicht es nicht, wenn Komponenten nur für Windows Server zugelassen sind. Und selbst wenn sie der Hersteller für S2D getestet hat, ergibt sich daraus nicht immer ein brauchbares 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 Wartungsgründen neu gestartet werden muss, sollten die hochverfü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 zusammengestellten 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 Komplettlö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 weitreichender als die für eine Standardauszeichnung und umfassen unter anderem den vollen Virtual Networking Stack oder auch System Center Virtual Machine Manager. Tauchen die SDDC-Klassifizierungen 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.
Täglich Know-how für IT-Pros mit unserem Newsletter
Marcel Küppers arbeitet seit über 25 Jahren in der IT, aktuell als Team Leader, zuvor als Consultant und Infrastructure Architect unter anderem für den japanischen Konzern JTEKT/TOYODA mit Verantwortung über die Europastandorte Krefeld und Paris. Darüber hinaus wirkte er als Berater im EU-Projekt-Team für alle Lokationen des Konzerns mit und ist spezialisiert auf hochverfügbare virtualisierte Microsoft-Umgebungen plus Hybrid Cloud Solutions. Zertifizierungen: MS Specialist und MCTS für Hyper-V/SCVMM, MCSE, MCITP, MCSA. Zusätzlich zertifiziert für PRINCE2 Projektmanagementmethode.
// Kontakt: E-Mail, Twitter, LinkedIn //
Verwandte Beiträge
Weitere Links