Microsoft hat beim Windows Server 2019 die Storage-Spaces-Direct- Funktionen (S2D) deutlich ausgebaut, um im Markt für Hyper­converged Infrastructure (HCI) eine wichtigere Rolle zu spielen. Als zentrales Verwaltungs-Tool dient das Windows Admin Center (WAC), das um zahlreiche HCI-Features ergänzt wurde. LANline hat die S2D-Plattform in einer 3-Node-Konfiguration getestet.

Der Markt für hyperkonvergente Infrastrukturlösungen wird auch in den kommenden Jahren stark wachsen. HCI-Plattformen eignen sich gut für die Server- und Desktop-Virtualisierung, da sie sich relativ einfach implementieren, verwalten und erweitern lassen. Zudem sind derartige Lösungen, die Server, Storage und Netzwerk in einer Appliance vereinen, preislich meist günstiger als klassische Konzepte, bei denen die physischen Virtualisierungs-Hosts an dedizierte Speichersysteme angebunden sind.

LANline nimmt die steigende Bedeutung von HCI zum Anlass, eine HCI-Testreihe durchzuführen. Getestet werden Software-Lösungen, die sich auf vom jeweiligen Anbieter zertifizierten Standard-Servern installieren lassen. Den Anfang der Reihe macht Windows Server 2019 (WS2019), der sich mit den in der Datacenter Edition enthaltenen Storage-Spaces-Direct-Funktionen (S2D) als HCI-Plattform einsetzen lässt.

Die Startkonfiguration eines S2D-Clusters besteht aus mindestens zwei Nodes. Pro Cluster unterstützt WS2019 wie bei WS2016 maximal 16 Nodes und bis zu 416 physische Laufwerke. Durch die neuen Cluster-Sets lassen sich mehrere Cluster zu einem Verbund zusammenfassen. Dies erhöht die Skalierbarkeit auf derzeit 64 Nodes pro Cluster-Set. Höhere Node-Zahlen sind technisch bereits möglich, werden aber von Microsoft offiziell noch nicht supportet. Innerhalb eines Cluster-Sets kann der Administrator ähnlich wie bei Azure sogenannte Fault Domains und Availability-Zonen konfigurieren. Die auf der Plattform laufenden VMs lassen sich zwischen den Clustern eines Sets hin und her verschieben. Ein Cluster-Set darf auch aus unterschiedlichen Cluster-Typen bestehen, wodurch man zum Beispiel S2D-Cluster mit traditionellen Hyper-V-Clustern und File-Clustern zu einem Verbund zusammenfassen kann.

Für sehr leistungshungrige Anwendungen unterstützt WS2019 nun auch Persistent Memory. Intel bietet neben den Optane- 3D-Xpoint-NVMe-SSDs jetzt mit Optane-Speicher im DDR4-Format noch schnellere Speichermedien an. Die neuen Speichermodule unterstützen einen Mischbetrieb, bei dem sich ein Teil des Speichers als RAM und der andere Teil als persistenter Highspeed-Datenspeicher nutzen lässt, der sich dem Betriebssystem wie eine normale Disk präsentiert.

Vor unerwarteten Komplettausfällen von S2D-Systemen schützen die Replikationsfunktionen von WS2019 Storage Replica und Hyper-V Replica. Damit lassen sich komplette Volumes sowie einzelne VMs oder VM-Gruppen synchron in ein zweites nahe gelegenes RZ oder asynchron an einen entfernten Standort replizieren. Eine Replikation in die Azure-Cloud von Microsoft ist ebenfalls möglich.

Im April 2019 hat Microsoft mit Azure Stack HCI ein neues Produkt angekündigt. Dabei handelt es sich allerdings nicht um die schon seit Längerem verfügbare Azure-Stack-Komplettlösung, sondern um eine zertifizierte S2D-Plattform auf Basis von WS2019. Der Produktname Azure Stack soll darauf hinweisen, dass diese HCI-Lösung dieselben Basistechniken wie Azure nutzt und für die Anbindung an die Azure-Cloud optimiert wurde.

Aufbau der Testumgebung

Für den LANline Test von WS2019 S2D kamen drei Server vom Typ Dell Power­Edge T640 zum Einsatz, von denen jeder mit einer 10-Core-Intel-Xeon-CPU, 64 GByte RAM und zwei 10-GBit/s-LAN-Ports bestückt war. Zudem verfügte jeder Server für die S2D-Konfiguration über sechs SAS-HDDs (10k, 600 GByte), zwei SATA-HDDs (7k, 1 TByte) und zwei SATA-SSDs (240 GByte). Die drei Server waren über einen 10-GBit/s-LAN-Switch von Netgear sowie über einen 1-GBit/s-LAN-Switch von Dell miteinander verbunden. Für die Bereitstellung der Backend-Infrastruktur liefen auf einer Dell-Workstation vier virtuelle WS2016-Server mit Domänen-Controller, Virtual Machine Manager, PKI-Server und Windows Admin Center.

Um einen S2D-Cluster einrichten zu können, muss der Administrator zunächst auf allen beteiligten Nodes die Failover-Cluster- und die Hyper-V-Rolle installieren. Wir fügten zudem die Clustering- und Hyper-V-Management-Tools hinzu. Soll ein S2D-Cluster auch als File-Server zum Einsatz kommen, lässt sich diese Rolle ebenfalls aktivieren.

Das WAC-Dashboard zeigte einen Host-Ausfall sofort an, erzeugte dazu jedoch keine Warnmeldungen.

WS2019-Cluster unterstützen neben den bisherigen Cluster-Rollen File-Server und Scale-out-File-Server (SOFS) auch den sogenannten Infrastructure SOFS. Dieser lässt sich bislang nur mit Hilfe eines PowerShell-Kommandos konfigurieren. Der Infrastructure SOFS sorgt unter anderem dafür, dass neue SMB-Verbindungen immer auf dem Server starten, der für das jeweilige Volume der Koordinator-Node ist. Dadurch ist es nicht mehr erforderlich, Redirect-IO-Verbindungen nachträglich auf den Koordinator-Node umzuhängen.

Für die Netzwerkverbindungen eines S2D-Clusters sollte mindestens ein 10-GBit/s-LAN mit einer möglichst niedrigen Latenz vorhanden sein. Die beste Performance lässt sich mit einer RDMA-Konfiguration (Remote Direct Memory Access) erzielen. Hierfür unterstützt WS2019 die Protokolle iWARP (Internet Wide-Area RDMA Protocol) und RoCEv2 (RDMA over Converged Ethernet). Die Netzwerkkarten und die LAN-Switches müssen ebenfalls RDMA beherrschen, damit die Nodes eines S2D-Clusters ihre Memory-Inhalte unter Umgehung von CPU, Cache und Betriebssystem direkt über das LAN von einem RAM-Speicher zum RAM eines anderen Servers übertragen können.

Beim Einsatz von RoCEv2 muss man auf den beteiligten WS2019-Servern die Funktion Data Center Bridging aktivieren. Microsoft empfiehlt für S2D-RDMA-Konfigurationen, den Hyper-V-Switch-Typ Switch Embedded Teaming (SET) zu verwenden. Damit lässt sich derselbe physische NIC-Port sowohl für RDMA als auch für den sonstigen Netzwerk-Traffic nutzen.

Den LANline-Test führten wir ohne RDMA- und SET-Konfiguration durch, weil der 10-GBit/s-LAN-Switch der Testumgebung keine RDMA-Protokolle unterstützte. Für das VM-Netzwerk konfigurierten wir auf den Cluster-Nodes normale 10-GBit/s-Verbindungen und für das Management-Netz 1-GBit/s-Verbindungen.

Für 3-Node-Cluster richtet das S2D-Setup automatisch eine 3-Wege-Spiegelung ein.

Installation und Konfiguration

Nachdem wir die Vorarbeiten abgeschlossen hatten, ließen wir auf allen drei Servern ein bei Microsoft im Web erhältliches Skript laufen, das die lokalen Datenlaufwerke säuberte. Auf den von S2D genutzten Laufwerken dürfen keine alten Partitionen oder sonstigen Daten mehr vorhanden sein. Anschließend führten wir das Pow­erShell-Cmdlet-Test-Cluster aus, um zu überprüfen, ob sich die drei Server erfolgreich zu einem Cluster hinzufügen lassen. Der Check verlief erfolgreich, sodass wir im nächsten Schritt per Cmdlet New-Cluster den Failover-Cluster erstellten. Als Cluster-Quorum konfigurierten wir ein Fileshare Witness, das auf dem Domänen-Controller lag.

Zum Abschluss aktivierten wir auf dem ersten Cluster-Node mit dem PowerShell-Kommando Enable-Clusters2d die S2D-Funktionen für den 3-Node-Cluster. Standardmäßig konfiguriert S2D den schnellsten vorhandenen Laufwerkstyp als Cache-Device. Sind zum Beispiel NVMe-Laufwerke, SATA-SSDs und HDDs vorhanden, verwendet S2D die NVMe-SSDs als Cache-Devices für den SATA-SSD-Performance-Tier und den HDD-Kapazitäts-Tier. S2D unterstützt zudem den seit WS2016 verfügbaren CSV-Read-Cache. Dieser verwendet den RAM des Hyper-V-Hosts, um Leseoperationen der VMs zwischen zu speichern.

Für den LANline-Test gaben wir beim S2D-Setup die Option -cachestate disabled an, um die SSDs als Performance-Tier und die HDDs als Kapazitäts-Tier nutzen zu können. Es ist auch möglich, ein bestimmtes Laufwerksmodell als Cache-Device zu konfigurieren. Um Volumes erstellen zu können, muss der Administrator zunächst auf dem S2D-Cluster einen oder mehrere Storage-Pools erstellen.

Mit den Default-Einstellungen wird ein einziger Storage-Pool angelegt, der bei einem 3-Node-Cluster automatisch eine 3-Wege-Spiegelung konfiguriert. Bei 2-Node-Clustern wird ein 2-Wege-Spiegel erstellt. Bei Clustern ab vier Nodes kann der Administrator zwischen verschiedenen Resilienztypen wählen. Neben der Spiegelung stehen hier auch eine Single- und eine Dual-Parity-Redundanz zur Verfügung, die mit RAID-5 und RAID-6 vergleichbar ist.

Die Dual-Parity-Redundanz lässt sich auch mit einer Spiegelung kombinieren. Dieser Typ heißt Mirror-accelerated Parity und bietet eine bessere Performance als die reine Parity-Konfiguration. Dabei werden die Daten zunächst in den gespiegelten Teil geschrieben und später auf den Parity-Bereich verschoben.

Mit S2D kann der Administrator zudem angeben, wie viel Prozent eines Volumes die Lösung auf dem Performance-Tier speichern soll und wie viel Prozent auf dem Kapazitäts-Tier.

Für den Test legten wir mit dem Cmdlet New-StoragePool zunächst einen Default-Storage-Pool mit 3-Wege-Spiegelung an. Anschließend standen die sechs SSDs als Performance-Tier mit 1,3 TByte Raw-Kapazität und die 24 HDDs als Kapazitäts-Tier mit 15,3 TByte Raw-Kapazität zur Verfügung. S2D hat die 600-GByte-10k-Disks und die 1-TByte-7,2k-Disks in denselben Kapazitätspool integriert, wodurch das System von den 1-TByte-Disks 400 GByte verschenkt hat und die Performance des Pools aufgrund der unterschiedlichen Spindeldrehzahlen eine leichte Unwucht aufwies. Um dies zu vermeiden, kann der Administrator die Pools manuell konfigurieren und zum Beispiel für 10k-HDDs und 7,2k-HDDs jeweils einen eigenen Kapazitätspool anlegen.

Um auf dem neuen S2D-Cluster VMs installieren zu können, erstellten wir mehrere Volumes. Der Administrator kann hierfür die WAC-Konsole, PowerShell oder die Cluster-GUI nutzen. Die 3-Wege-Spiegelung war aufgrund der Node-Anzahl fest vorgegeben. Beim ersten Volume gaben wir als Größe 100 GByte an, die wir auf 30 GByte SSD-Tier und 70 GByte HDD-Tier verteilten. Dann erstellten wir zwei reine Performance-Volumes und zwei reine Kapazitäts-Volumes. Als Filesystem wählten wir jeweils ReFS (Resilient Filesystem) und fügten es als Cluster Shared Volume (CSV) zum S2D-Cluster hinzu, wodurch alle drei Nodes Zugriff auf die Volumes hatten. ReFS unterstützt unter WS2019 nun auch eine Deduplizierung und Datenkomprimierung. Bisher war dies nur mit NTFS möglich. Wir aktivierten diese Funktion für alle Volumes.

Verwaltung und Redundanzfunktionen

Für die Verwaltung von S2D-Clustern empfiehlt Microsoft das neue Windows Admin Center (WAC) als zentrales Management-Tool. WAC wurde für WS2019 um weitere Funktionen ergänzt. Wir mussten aber für einige Aufgaben nach wie vor auf die klassischen Konsolen zurückgreifen. Zudem gibt es Funktionen wie zum Beispiel den bereits erwähnten Infrastructure SOFS, die sich bislang nur per PowerShell einrichten lassen. Um VMs im Cluster als hochverfügbare Rolle zu konfigurieren, damit WS2019 sie bei einem Host-Ausfall automatisch von einem anderen Hyper-V-Server des Clusters neu startet, nutzen wir den Failover-Cluster-Manager. Die automatische Lastverteilung zwischen den Hyper-V-Nodes des S2D-Clusters konfigurierten wir über den VMM.

Der S2D-Test-Cluster ließ sich sowohl zum WAC als auch zum VMM problemlos hinzufügen, und wir installierten anschließend drei WS2019-VMs und zwei WS2016-VMs. Für das Performance-Monitoring der physischen Laufwerke hat Microsoft das neue Cmdlet Get-StorageHistory (vormals Get-PhysicalDiskIoReport) entwickelt. Es zeigt für jedes Laufwerk die durchschnittliche und maximale IO-Latenz an. Zudem speichert ein S2D-Cluster die Storage-Performance-Daten jetzt automatisch für ein ganzes Jahr, sodass auch historische Analysen möglich sind.

Um die Redundanzfunktionen zu testen, schalteten wir einen der drei Cluster-Nodes hart aus, indem wir die Stromzufuhr kappten. Das Dashboard der WAC-Konsole zeigte schnell an, dass der Node und seine zehn Laufwerke nicht mehr verfügbar waren. Die Integrität des S2D-Gesamtsystems wurde aber nach wie vor als fehlerfrei angegeben, vermutlich weil nach dem Ausfall eines Nodes immer noch ein redundanter 2-Wege-Spiegel vorhanden war. Die von dem ausgefallenen Hyper-V-Host bedienten Volumes hat sofort ein anderer Node übernommen. Die zwei vom Ausfall betroffenen VMs wurden nach etwa drei Minuten von einem anderen Node automatisch wieder hochgefahren.

Die WAC-Konsole kann bei S2D-Clustern für jedes Laufwerk die aktuelle und historische IO-
Latenz anzeigen.

Als letzten Test schalteten wir bei einem weiteren Node den Strom aus, sodass nur noch ein Server im Betrieb war. Dies hatte zur Folge, dass alle Volumes offline gingen, weil das Quorum mit nur einem Node nicht mehr funktioniert. Die Daten waren aber nach wie vor unversehrt vorhanden. Nach dem Hochfahren dieses Nodes stand der S2D-Cluster wieder mit allen Ressourcen zur Verfügung.

Die Erweiterung eines S2D-Clusters ist sehr einfach. 30 Minuten nachdem man einen neuen Server mit identischer Laufwerkskonfiguration hinzugefügt hat, beginnt der S2D-Cluster automatisch damit, die vorhandene Last auf die neuen Ressourcen umzuverteilen.

Fazit

Mit Storage Spaces Direct (S2D) bietet Microsoft auf Basis von Windows Server 2019 eine leistungsfähige und einfach zu erweiternde HCI-Plattform an. Ab einer Anzahl von vier Nodes kann der Administrator zwischen verschiedenen Performance- und Kapazitätskonfigurationen wählen. Mit zwei oder drei Nodes bieten der 2- beziehungsweise 3-Wege-Spiegel einen ausfallsicheren Betrieb. Um bezüglich des Supports durch Microsoft auf der sicheren Seite zu sein, empfiehlt es sich, eine für WS2019 S2D zertifizierte Hardwarelösung einzusetzen. Entsprechende Systeme sind mittlerweile von zahlreichen Anbietern erhältlich.

Christoph Lange.