Test: Thomas-Krenn Microsoft HCI-Cluster
Server-Hardware für Microsoft HCI-Cluster
Fortsetzung des Artikels von Teil 1
Installation des S2D-Clusters
Zunächst schlossen wir beide Server über jeweils vier LAN-Kabel an den 10-GBit/s-Switch des Testnetzes an und verbanden die zwei 25-GBit/s-Ports für das Storage-Netz per DAC-Kabel direkt mit dem anderen Server. Dann installierten wir auf der internen M.2-SSD das Betriebssystem Windows Server 2022 Datacenter. S2D unterstützt sowohl die Core-Version als auch die Desktop-Variante, wir wählten letztere. Nach Abschluss der Windows-Installation spielten wir per Windows-Update-Funktion die aktuellen Microsoft-Patches ein und fügten zudem die für S2D benötigten Windows-Features Hyper-V und Failover-Cluster inklusive der Verwaltungstools hinzu.
Im nächsten Schritt konfigurierten wir die Netzwerkkarten für den S2D-Cluster-Einsatz. Zwei Karten pro Server wiesen wir dem Management-Netz zu, zwei Karten dem VM-Netzwerk und die beiden 25-GBit/s-Karten dem SMB-Storage-Netz. Hyper-V verwendet seit Windows 2022 die traditionellen LBFO-Teams (Load Balancing and Failover) nicht mehr. Stattdessen kommt das Switch Embedded Teaming (SET) zum Einsatz. Wir erstellten mit Hilfe des Powershell-Befehls New-VMSwitch drei SET-Switches für das Management-, das VM- und das Storage-Netz. Anschließend fand sich unter den Netzwerkadaptern für jeden SET-Switch eine neue virtuelle NIC, der wir noch die richtige IP-Adresse zuweisen mussten.
Nachdem die Vorbereitungsarbeiten abgeschlossen waren, starteten wir im Failover Cluster Manager den Validation Wizard, um zu prüfen, ob beide Server die Voraussetzungen für eine Cluster-Installation erfüllen. Der Check wurde erfolgreich abgeschlossen, und wir klickten auf die Create-Cluster-Schaltfläche. Der Assistent legte mit den zwei Servern einen neuen Cluster an und wies die Netzwerkkarten der drei SET-Switches automatisch den drei Cluster-Netzwerken für Management-, VM- und Storage-Netz zu. Als Cluster-Quorum konfigurierten wir ein File Share Witness, das wir zuvor auf einem unserer zwei Domänencontroller angelegt hatten.
Als letzten Schritt mussten wir nun noch die S2D-Konfiguration durchführen. Sie erfolgt über das Powershell-Cmdlet Enable-ClusterStorageSpacesDirect, das alle vorhandenen leeren Daten-Disks der Cluster-Nodes standardmäßig zu einem großen Storage-Pool zusammenfasst.
Wenn unterschiedlich schnelle Laufwerkstypen vorhanden sind, verwendet S2D automatisch die schnellsten Drives als Cache-Laufwerke. Bei unserem Test-Cluster waren pro Node vier NVMe-SSDs vom selben Typ verbaut, weshalb wir die Hinweismeldung erhielten, dass keine Disks für den Cache konfiguriert wurden. Mit den schnellen NVMe-SSDs der Test-Server wirkte sich dies nicht negativ aus. Sind in einem Server NVMe-SSDs und SAS-/SATA-SSDs vorhanden, nutzt S2D die NVMe-Disks als Cache. Wenn zusätzlich auch HDDs als dritter Storage-Tier vorhanden sind, bildet die Software aus den HDDs den Capacity Tier, aus den SAS-/SATA-SSDs den Performance Tier und aus den NVMe-SSDs den Cache-Tier. Ein zusätzliches Tiering innerhalb des HDD-Layers, das schnelle und langsamere Plattentypen unterscheiden könnte, unterstützt S2D nicht. Bei einer Bestückung der Server mit HDDs ist deshalb darauf zu achten, dass alle Platten dieselbe Geschwindigkeit haben. Beim Test-Cluster hat das S2D-Setup aus den insgesamt acht NVMe-SSDs einen 1-Tier-Disk-Pool mit einer Bruttokapazität von rund 6 TByte erstellt.
Wie S2D die Redundanz der gespeicherten Daten sicher stellt, legt der Systemverwalter bei der Erstellung der Volumes fest, auf denen Hyper-V die VMs speichert. Für das Testsystem wählten wir einen einfachen Zweiwege-Spiegel, der die Daten automatisch zwischen den zwei Nodes spiegelt. Mit den vier Platten pro Server wäre es auch möglich, einen Nested Mirror zu konfigurieren, der die Daten doppelt spiegelt, sodass jede Datei vier Mal vorhanden ist. Ab einer Cluster-Größe von drei Nodes unterstützt S2D auch einen 3-Way-Mirror, der auf jedem der drei Nodes eine Dateikopie speichert.
Zum Abschluss muss das neue Volume noch zu den Cluster Shared Volumes (CSV) hinzugefügt werden. Dadurch mounten beide Hyper-V-Hosts das Volume unter dem Pfad C:\ClusterStorage und können gleichzeitig darauf zugreifen. Im Hyper-V Manager konfigurierten wir das neue S2D CSV-Volume als Default-Storage-Pfad, wodurch neue VMs automatisch auf dem hochverfügbarem S2D-Storage erstellt wurden.
S2D-Betrieb per MMC- oder WAC-Konsole
Für die Verwaltung eines S2D-Clusters lassen sich wahlweise die klassischen MMC-Konsolen Failover-Cluster-Manager und Hyper-V-Manager verwenden. Microsoft hat mittlerweile zahlreiche Managementfunktionen in das Windows Admin Center (WAC) integriert, sodass sich die moderne browserbasierte Konsole als nahezu gleichwertige Alternative nutzen lässt.
Wir legten mit beiden Verwaltungswerkzeugen eine neue W2022-Test-VM an. Sowohl der Failover-Cluster-Manager als auch die WAC-Cluster-Konsole richteten die VM automatisch als hochverfügbare Cluster-Rolle ein, die beim Ausfall eines Hosts automatisch auf dem zweiten Hyper-V-Server neu gestartet wird. Auch ein neues Volume konnten wir über beide Tools erfolgreich auf dem S2D-Storage-Pool erstellen.
Das WAC enthält auch einen Deployment-Assistenten für die Einrichtung von Windows-Clustern. Der Systemverwalter kann damit unter anderem die Netzwerkkarten für die Management-, VM-Netzwerk- und Storage-Kommunikation auswählen. Der Wizard legt anschließend im Hyper-V-Manager automatisch die benötigten SET-Switches an. Das Erzeugen des S2D-Clusters mit der Konfiguration der lokalen Datenlaufwerke als Disk-Pool für den HCI-Cluster ist aber auch hier ein nachgelagerter Schritt, der per Powershell umgesetzt werden muss.
- Server-Hardware für Microsoft HCI-Cluster
- Installation des S2D-Clusters
- Ausfallsichere HCI-Plattform
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
