Testreihe WS 2016, Teil 2: S2D und Replicas
Plattform für Hyperkonvergenz
Mit Storage Spaces Direct (S2D) von Windows Server 2016 lassen sich hyperkonvergente Cluster einrichten, die keine externen Speichersysteme benötigen. Neu ist auch die Funktion Storage Replica, die komplette VMs an einen anderen Standort repliziert. LANline hat sich diese beiden Features genauer angeschaut.
Microsoft hat die mit Windows Server 2012 (WS 2012) eingeführten Storage Spaces in der neuen Version WS 2016 deutlich ausgebaut. Bislang waren per SAS angebundene externe Disk-Systeme erforderlich, um Storage Spaces nutzen zu können. Die neue Version Storage Spaces Direct (S2D) kann jetzt die in einem Server lokal verbauten Laufwerke als Speicher nutzen und in einem hochverfügbaren Cluster-Verbund so bereitstellen, dass alle Nodes auf den Speicher zugreifen können. Um eine hohe I/O-Performance sicherzustellen, verwendet S2D schnellen SSD-Speicher als Write- und Read-Cache. Mit der neuen S2D-Technik lassen sich auf Basis von Standard-Server-Hardware hyperkonvergente Lösungen aufbauen, die Storage, Compute und Networking bereitstellen.
S2D ist - ebenso wie die weiter unten diskutierte neue Funktion Storage Replica für die Remote-Site-Replikation - nur in der Datacenter Edition von WS 2016 enthalten. Zu den verschiedenen WS-2016-Editionen siehe den Beitrag "Betriebssystem für die Cloud" unter Link Die Einstiegskonfiguration einer S2D-Lösung besteht aus mindestens zwei Servern, die als Cluster-Verbund konfiguriert sind. Derzeit unterstützt Microsoft bis zu 16 Server pro S2D-Cluster. Die maximale Brutto-Speicherkapazität des Storage-Pools beträgt 1 PByte. Pro TByte Cache-Speicherkapazität sollten 4 GByte RAM vorhanden sein, damit der Server die S2D-Metadaten im Arbeitsspeicher vorhalten kann.
Redundanzmechanismen
Welche Redundanzmechanismen man nutzen kann, hängt von der Anzahl der Hyper-V-Hosts und der eingesetzten Laufwerke ab. Jeder Host muss über mindestens vier SAS- oder SATA-Kapazitätslaufwerke für die Speicherung der Daten verfügen. Als Cache-Devices unterstützt S2D SSD- wie auch NVMe-Speicher. Aus Redundanzgründen sollte man pro Server mindestens zwei Cache-Laufwerke einsetzen. Zudem empfiehlt Microsoft, alle Server eines Clusters mit denselben Laufwerkstypen und -größen zu bestücken. Kommen NVMe-, SSD- und HDD-Laufwerke zum Einsatz, konfiguriert S2D die NVMe-Drives automatisch als Cache und bildet aus SSDs und HDDs einen Storage-Pool mit Auto-Tiering. Welche Laufwerke als Cache Verwendung finden, kann der Administrator auch manuell konfigurieren.
Bei einem Cluster mit zwei Nodes erstellt S2D automatisch einen Storage Pool, der alle gespeicherten Daten auf beiden Nodes ablegt, was mit einem RAID-1 vergleichbar ist. Sind drei Server vorhanden, empfiehlt Microsoft, einen Drei-Wege-Spiegel einzurichten. Dieser erhöht die Redundanz dahingehend, dass zwei der drei Server ausfallen können, ohne dass Daten verloren gehen. Allerdings hat diese Konfiguration einen hohen Speicherbedarf, da alle Daten dreifach vorzuhalten sind. Alternativ lässt sich S2D mit drei Servern auch für Single Parity konfigurieren. Dies bietet einen mit RAID-5 vergleichbaren Schutz: Es darf maximal ein Laufwerk oder ein kompletter Server ausfallen.
Einen besseren Schutz bietet die ab vier Servern unterstützte Dual Parity, vergleichbar mit RAID-6. Bei dieser Konfiguration dürfen wie beim Drei-Wege-Spiegel bis zu zwei Server ausfallen. Dual Parity bietet eine umso höhere Effizienz der Speichernutzung, je mehr Server zum Einsatz kommen. Mit sieben Servern beträgt die nutzbare Kapazität bereits 66,7 Prozent, während sie beim Drei-Wege-Spiegel immer bei nur 33 Prozent liegt. Im Endausbau mit 16 Servern erreicht Dual Parity eine Storage-Effizienz von 80 Prozent. S2D unterstützt auch einen Mischbetrieb aus Mirror und Dual Parity, der Schreibvorgänge zunächst auf dem Mirror-Gerät ausführt und die Daten nachträglich auf Parity-Laufwerke verschiebt. Für Testzwecke lässt sich S2D unter Hyper-V auch mit virtuellen Servern implementieren.
Da S2D alle Schreibvorgänge über das lokale Netzwerk auf einen oder mehrere andere Server des Cluster-Verbunds übertragen muss, empfiehlt Microsoft eine 10GbE-LAN-Infrastruktur. Die maximale I/O-Performance lässt sich mit RDMA (Remote Direct Memory Access) erzielen. Die Host-CPU muss hier die Daten einer Applikation im RAM für den Weitertransport zu einem anderen Rechner nicht mehr verarbeiten: Die Daten lassen sich direkt von Netzwerkkarte zu Netzwerkkarte übertragen. Microsoft unterstützt mit SMB Direct (Server Message Block) die RDMA-Verfahren RoCEv2 (RDMA over Converged Ethernet) und iWarp.
Der neue virtuelle Switch des WS 2016 verfügt mit Switch Embedded Teaming (SET) über ein integriertes Netzwerk-Teaming. Damit können VMs wie auch der Host mit RDMA dasselbe physische NIC-Team nutzen. Um RDMA einsetzen zu können, ist aber spezielle NIC- und Switch-Hardware erforderlich, die LANline für diesen Test jedoch nicht zur Verfügung stand.
Für den Test von S2D setzten wir zwei Dell-T620-Server ein, die mit je vier SAS-Festplatten für den S2D-Kapazitätspool und je einer Plextor-PCIe-SSD für den S2D-Cache bestückt waren. Zunächst installierten wir die Datacenter Edition von WS 2016 und aktivierten die Failover-Cluster-Dienste und die Hyper-V-Rolle. Damit hatten wir einen Hyper-V-Cluster mit zwei Nodes am Start.
Im nächsten Schritt bereiteten wir den Cluster für die S2D-Konfiguration vor. Auf den für S2D bereitgestellten Platten dürfen keine Partitionen vorhanden sein. Um die Platten zu säubern, findet sich auf der S2D-Dokumentationsseite von Microsoft (siehe Infokasten) ein Powershell-Skript. Dieses löscht alle im Server vorhandenen Datenplatten und stellt sie als RAW-Devices bereit. Nachdem wir dieses Skript ausgeführt hatten, wollten wir S2D per Powershell mit folgendem Befehl aktivieren:
Enable-ClusterStorageSpacesDirect
Der Vorgang schlug zunächst mit eine Warnmeldung fehl: "The CIM method returned the following error code: 51001". Wie sich herausstellte, konnte S2D die Datenplatten nicht korrekt erkennen, denn diese waren durch unseren Dell PERC H310 Raid-Controller als RAID-0 konfiguriert. S2D benötigt als Bustyp aber zwingend SAS oder SATA. Auf der sicheren Seite ist man mit einem einfachen Pass-Through-SAS-Host-Bus-Adapter, der SAS- und SATA-Laufwerke ohne RAID-Konfiguration direkt ans Betriebssystem durchreicht.
Bei unseren Test-Servern haben wir zunächst die Firmware des RAID-Controllers aktualisiert. Anschließend änderten wir die Konfiguration der Datenplatten im Controller-Setup-Menü von RAID auf Non-RAID. Dann führten wir erneut den Enable-S2D-Befehl aus, der aber dieselbe Fehlermeldung wie zuvor anzeigte. Um dem Problem auf die Spur zu kommen, überprüften wir mit folgendem Befehl unsere S2D-Cluster-Konfiguration:
Test-Cluster -Include „Storage Spaces Direct“
In der HTML-Report-Ausgabe war zu sehen, dass die Datenplatten unter Windows immer noch mit dem Bus-Type RAID angezeigt wurden, obwohl wir sie im RAID-Controller auf Non-RAID umgestellt hatten. Nach einigem Suchen stießen wir auf einen Workaround, den zwar Microsoft offiziell nicht unterstützt, mit dem sich aber die Datenplatten zum S2D-Storage-Pool erfolgreich hinzufügen ließen. Hierzu führten wir im Cluster den folgenden Powershell-Befehl aus, durch den S2D alle Bus-Typen akzeptiert:
(Get-Cluster).S2DBusTypes=4294967295
Wenn nur der RAID-Bus-Typ aktiviert werden soll, ist als Wert 256 anzugeben. Anschließend konnten wir die S2D-Konfiguration durchführen. Das Powershell-Cmdlet erstellte automatisch aus den vorhandenen Datenplatten einen S2D-Pool. Die PCIe-SSDs ließen sich von dem Cmdlet zunächst nicht als Cache-Devices hinzufügen. Wir führten dies deshalb manuell durch. Zunächst ließen wir uns den Device-Namen anzeigen mit:
Get-PhysicalDisk | Group Model -NoElement
Nun konnten wir die SSDs mit folgendem Befehl als Cache-Device aktivieren:
Enable-ClusterS2D -CacheDeviceModel „PLEXTOR PX-AG256M6e“
Microsoft empfiehlt, pro Cluster nur einen großen Pool zu verwenden. Ist S2D mit mehreren Pools konfiguriert, muss der Administrator bei Kapazitätserweiterungen die zusätzlichen Laufwerke mit dem Powershell-Befehl Add-PhysicalDisk manuell dem gewünschten Pool hinzufügen.
Arbeiten mit S2D-Volumes
Sobald der S2D-Pool vorhanden ist, kann der Administrator darin die gewünschten virtuellen Disks erzeugen. Dies ist entweder über die grafische Oberfläche des Failover Cluster Managers oder über das Cmdlet New-Volume möglich. Wir verwendeten das Cmdlet und legten zwei Volumes mit 300 und 400 GByte Größe an. Dann installierten wir auf jedem Volume eine WS-2016-VM und konfigurierten sie im Failover Cluster Manager mit der Hochverfügbarkeitsrolle.
Die zwei Test-VMs ließen sich beliebig zwischen den beiden Hyper-V-Hosts hin- und herverschieben. Auch eine Storage-Migration auf das zweite Volume des S2D-Pools verlief erfolgreich. Um die Redundanzfunktionen zu testen, entfernten wir aus einem Server eine Festplatte. Alle S2D-Speicherressourcen blieben online, die Hosts und VMs haben von dem Ausfall nichts mitbekommen.
Für die Überwachung des S2D-Systems bietet Microsoft mit den Produkten der System-Center-Familie leistungsfähige Werkzeuge an. In unserer Testumgebung verwendeten wir den Failover Cluster Manager, um den Plattenausfall sichtbar zu machen. Im Pools-Menü finden sich im unteren Hauptfensterbereich Reiter mit den virtuellen und physischen Disks. Hier wurde die fehlende Festplatte erkannt und als fehlend deklariert. Nachdem wir die Platte wieder in den Server gesteckt hatten, erschien sie in der Ansicht wieder als funktionsfähig.
Einen guten Schutz vor Ausfällen bietet auch die neue WS-2016-Funktion Storage Replica. Damit können Administratoren wichtige VMs an einen entfernten Standort replizieren, um sie in einem Störfall schnell wieder online bringen zu können. Storage Replica unterstützt die synchrone und asynchrone Replikation. Die synchrone Replikation empfiehlt sich nur bei sehr leistungsfähigen Standortverbindungen mit hoher Bandbreite und niedriger Latenz. Denn die Anwendung erhält erst dann die Bestätigung für einen Schreibbefehl, nachdem dieser auf dem Replica-System abgeschlossen ist. Bei Anwendungen mit hohem Änderungsvolumen und zu langsamen Verbindungen kann es schnell zu unangenehmen Latenzen kommen. Die asynchrone Replikation erfolgt mit einem relativ geringen Zeitversatz. Der Administrator kann wählen, ob die Replikationsdaten im Abstand von 30 Sekunden, fünf oder 15 Minuten übertragen werden.
Storage Replica führt eine hardwareunabhängige Block-Level-Replikation durch und verwendet SMB 3 als Übertragungsprotokoll. Sowohl auf dem Quell-Server als auch dem Zielsystem muss WS 2016 Datacenter installiert und die Storage-Replica-Funktion aktiviert sein. Zudem müssen Größe und Blockgröße der Zielpartition identisch sein. Als Speicherort für die Replikations-Logs empfiehlt sich ein schnelles SSD-Laufwerk.
Die Replikationsfunktionen lassen sich in mehreren Varianten nutzen. Der Server-to-Server-Modus überträgt die Daten von einem WS-2016-Server zu einem anderen. Bei der Cluster-to-Cluster-Replikation erfolgt die Replikation zwischen Nodes zweier unterschiedlicher Cluster. Am interessantesten ist die Stretched-Cluster-Replikation: Hier werden die VM-Daten von einem Knoten an Standort A zu einem anderen Knoten desselben Clusters an Standort B übertragen. In dieser Konfiguration können beim Ausfall einer Site die Nodes des überlebenden Standorts die ausgefallenen VMs automatisch wieder online bringen. Schließlich kann der Administrator auch noch eine lokale Replikation auf denselben Server durchführen. Dies ist sinnvoll, um eine initiale Replica-Kopie zu erstellen, diese zum Beispiel auf eine USB-Disk zu speichern und an den Zielstandort zu verschicken.
Für den LANline-Test verwendeten wir die Server-to-Server-Replikation. Wir entfernten dafür einen Hyper-V-Server aus dem Test-Cluster und fügten dann auf dem Quell- und Ziel-Server das Storage-Replica-Feature hinzu. Auf dem Cluster mussten wir zudem die Rolle Hyper-V Replica Broker installieren und Name, Netzwerk und IP-Adresse für die Replikationsinstanz angeben. Dann aktivierten wir im VM-Menü die asynchrone Replikation. Der Assistent stellte fest, dass auf dem Ziel-Host in den Hyper-V-Einstellungen die Replica-Konfiguration noch fehlte. Dies konnten wir direkt aus dem Assistenten heraus erledigen. Der Wizard bietet auch die Option, zusätzliche Recovery Points zu erstellen, zum Bespiel stündlich oder täglich.
Nachdem wir alle erforderlichen Einstellungen durchgeführt hatten, starteten wir die Replikation. Diese war nach etwa 15 Minuten abgeschlossen. Um die korrekte Funktionalität zu testen, stoppten wir die primäre VM und starteten dann auf dem anderen Hyper-V-Host die Replica-Kopie. Der Administrator kann wählen, ob er die Replica zur primären VM machen will und die Replikationsrichtung umgedreht wird. Die VM ließ sich problemlos hochfahren, sodass wir mit der Kopie weiterarbeiten konnten.
Fazit
Mit Storage Spaces Direct (S2D) und Storage Replica hat Microsoft den WS 2016 um zwei interessante Funktionen erweitert. S2D macht aus Standard-Hardware-Servern hyperkonvergente Appliances, die in einem System Compute, Storage und Networking bereitstellen. Das Setup ist nicht ganz trivial. Es belohnt die Mühen aber mit einer sich weitgehend selbst regelnden Storage-Lösung, die sich durch Hinzufügen weiterer Laufwerke oder kompletter Server einfach skalieren lässt. Wer selbst eine S2D-Lösung aufbauen möchte, sollte vorher die Hardwareanforderungen genau studieren, um sich vor Überraschungen wie zum Beispiel inkompatiblen RAID-Controllern zu schützen.
Die Replikationsfunktionen bieten einen relativ einfach zu implementierenden Notfallschutz. Im Zusammenspiel mit einem standortübergreifenden Stretched Cluster können bei einem Standortausfall die überlebenden Knoten die betroffenen VMs sogar automatisch wieder online bringen. Ein Wermutstropfen für kleinere Unternehmen ist die erforderliche Datacenter-Lizenz, ohne die sich diese Funktionen nicht nutzen lassen.
- Teil 1: Nano-Server und Container
- Teil 2: Storage Spaces Direct (S2D) und Replicas
- Teil 3: Shielded VMs und Host Guardian Service (in Kürze)
Tel.: 089/31764900
Web: www.microsoft.com
S2D-Dokumentation: docs.microsoft.com/en-us/windows-server/storage/storage-spaces/hyper-converged-solution-using-storage-spaces-direct
Lesen Sie mehr zum Thema
