Tags: Storage, Disaster Recovery, Windows Server 2016, Cluster
Diese Anleitung beschreibt die Einrichtung einer synchronen Volume-Replikation mit Storage Replica (SR) für einen Hyper-V Failover-Cluster. Es wird gezeigt, wie SR in einem Stretched Cluster die Speicher-Sets über Standorte hinweg synchron hält und sie hochverfügbar macht.
Das Feature Storage Replica (Speicherreplikat) von Windows Server 2016 dient in erster Linie dem Disaster Recovery, um Daten-Volumes im Worst Case verfügbar zu halten. Zusätzlich kann im Zusammenspiel mit einem Windows Failover-Cluster, wo sich ein Teil der Knoten an Standort A und ein anderer Teil an Standort B befindet (Stretched Cluster), der jeweils gemeinsame Speicher im Katastrophenfall automatisch aktiviert werden.
Cluster Shared Volumes für einen Hyper-V Failover-Cluster werden blockbasiert mittels SMB3 und RDMA (Remote Direct Memory Access) von einer Seite zur anderen übertragen. Beim Failover können virtuelle Maschinen im sekundären RZ weiter Ihre Dienste anbieten.
Voraussetzungen für einen Stretched Cluster
Im ersten Schritt installiert man Windows Server 2016 auf die zukünftigen Knoten und nimmt diese dann in das Active Directory auf. Cluster-Knoten sollten möglichst die gleiche zertifizierte Hardware haben und einen identischen Softwarestand aufweisen.
An Standort A greifen die Knoten auf ein gemeinsames iSCSI-Target zu, welches aus einer Daten-LUN und einer Log-LUN besteht. An Standort B gibt es ein identisches zweites Storage-Set. Zu beachten ist, dass die Daten-LUNs an beiden Standorten für die Replikation die gleiche Größe benötigen.
Bei der synchronen Replikation werden die Blöcke zeitgleich an Standort A und B geschrieben. Entsprechend führen umfangreiche Veränderungen von VMs in einem Hyper-V-Cluster zu einem hohen Datenaufkommen, und dementsprechend müssen WAN bzw. die Netzwerkkonfiguration performant und die Latenzen gering sein.
Aus diesem Grund wird bevorzugt SMB Direct (Port 5445) eingesetzt. Prüfen Sie daher nach der Installation des Storage Replica Features, ob die Firewall-Regeln der Windows-Nodes geschrieben wurden (SMB-in Port 445) und passen Sie ggfs. ihre Firewall-Appliances an.
Installation von Rollen und Features
Als erstes installiert man das Feature Multipfad-E/A über die GUI des Server Manager, um den gemeinsamen Speicher der Knoten redundant anzusprechen, anschließend die Rolle Hyper-V inklusive zugehöriger Verwaltungstools. Die iSCSI Target Volumes stellt in diesem Beispiel ein Windows Server bereit.
Nach dem Verbinden mit den Initiatoren werden sie über die Datenträgerverwaltung mit GPT initialisiert und mit ReFS formatiert. Auf den Knoten benötigt man außerdem die Rolle des Dateiservers und das Feature Failoverclustering (ebenfalls mit den Verwaltungstools), bevor abschließend das Feature Storage Replica (Speicherreplikat) ausgebracht wird.
Nach einem Neustart empfiehlt es sich, über Test-SRTopology die Infrastruktur auf Herz und Nieren für die Speicherreplikation untersuchen zu lassen. In einer PowerShell-Zeile sieht das Rollen- und Feature-Deployment folgendermaßen aus:
$ClusterNodes = "SR-SRV-01", "SR-SRV-02", "SR-SRV-03", "SR-SRV-04"
$ClusterNodes | % {Install-WindowsFeature -ComputerName $_ -Name Multipath-IO,Hyper-V,FS-Fileserver,Failover-Clustering,Storage-Replica -IncludeManagementTools}
Clusterbildung, Quorum und Cluster Shared Volumes
Die Cluster-Bildung kann über die GUI des Failover-Clustermanagers stattfinden oder über ein PowerShell-Kommando. Vorab ist es nötig, die Cluster-Validierung über die Knoten laufen zu lassen, um den Rechnerverbund fehlerfrei zu formen. Die Anleitung für die grundlegende Einrichtung eines Failover-Clusters finden Sie in einem anderen Beitrag. Folgender Beispiel-Aufruf bringt Sie schnell ans Ziel:
New-Cluster –Name StretchedClu –Node SR-SRV-01, SR-SRV-02, SR-SRV-03, SR-SRV-04 –IgnoreNetwork 192.168.10.0/24 –StaticAddress 192.168.1.55
Um ein Troubleshooting zu vermeiden, lohnt sich auch ein Blick in die DNS Zone, um den Host-A-Eintrag des virtuellen Cluster-Objektes und die zugehörige IP zu validieren.
Ist der Cluster erstellt, startet man beispielsweise mit cluadmin.msc die GUI des Managers und modifiziert zuerst das Quorummodell in Richtung Freigabezeugen. Hier lässt sich eine private Cloud oder Azure-Freigabe festlegen.
Legen Sie dann mit folgendem Cmdlet die Seitenzugehörigkeit fest, d.h. in diesem Beispiel zwei Knoten im RZ01 und die beiden anderen im RZ02:
(Get-ClusterNode "SR-SRV-01").Site="RZ01"
(Get-ClusterNode "SR-SRV-02").Site="RZ01"
(Get-ClusterNode "SR-SRV-03").Site="RZ02"
(Get-ClusterNode "SR-SRV-04").Site="RZ02"
(Get-Cluster).PreferredSite="RZ01"
Danach ist eine namentliche Änderung der Cluster-Datenträger im Bereich Speicher sinnvoll und das Quell-Datenvolume muss in ein Cluster Shared Volume gewandelt werden.
Replikation aktivieren
Über das Kontextmenü des Quell-Datenvolume lässt sich die Replikation aktivieren. Der Assistent führt Step-by-Step durch die Konfiguration und fragt zu Beginn nach einem Ziel-Volume, welches eine identische Größe aufweisen muss wie die Quelle.
Als nächstes wird der zugehörige Quell-Log-Datenträger und anschließend der Ziel-Log Datenträger mit einer Mindestgröße von 8 GB bestimmt. Danach kann das Zielvolume überschrieben werden oder ein Zusammenführen (Seeding) stattfinden.
Benötigen Sie eine gewisse Schreibreihenfolge, beispielsweise für SQL Server, können Sie dies im nächsten Dialog festlegen. Nach Bestätigung der definierten Replikationsgruppen wird die Konfiguration ausgeführt und Storage Replica aktiviert.
Replikation überwachen in Eventlogs und mit Cluster-Manager
Im Anschluss an die Einrichtung der Partnerschaft ist es hilfreich, die Eventlogs zu SR im Auge zu behalten. In der Ereignisanzeige der Knoten unter Anwendungs- und Dienstprotokolle => Microsoft => Windows => StorageReplica => Admin, oder über PowerShell mit:
Get-WinEvent –ProviderName Microsoft-Windows-StorageReplica –MaxEvents 15 | fl
Eine weitere Hilfe stellt in diesem Fall der Failovercluster-Manager dar, denn hier erfahren Sie, wie der aktuelle Replikationsstatus ist, und von hier aus lassen sich Einstellungen zu SR verwalten, darunter auch das Entfernen der Replikation.
Hochverfügbare virtuelle Maschinen
Über das Kontextmenü Rollen des Failovercluster-Managers lassen sich nun hochverfügbare virtuelle Computer erstellen und deren gesamte Konfiguration auf dem Cluster Shared Volume (C:\ClusterStorage\Volume(X)) ablegen.
Die Volumes samt VMs werden von A nach B synchronisiert. Mehr zur Einrichtung von hochverfügbaren virtuellen Maschinen finden Sie hier.
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.
Verwandte Beiträge
- Fujitsu mit Eternus-Storage-Systemen für "Kleine"
- Anleitung: Storage Spaces Direct auf Cluster mit zwei Knoten einrichten
- Überblick: Windows Server 2016 Storage Spaces Direct im 2-Node-Cluster
- Server 2016 Failover-Cluster: SMB-Multichannel im selben Subnet
- Speicher-Management: Open-E bringt Data Storage Software v7
Weitere Links
3 Kommentare
Hallo. Vielen Dank für die sehr guten Erklärungen für Server 2016 Funktionen.
Ich habe eine kurze Frage:
Hier wird nun von zwei Clustern gesprochen (Cluster A+B) wobei von A zu B synchronisiert wird. Beide Seiten greifen auf ein iSCSI Target zu. Da drauf kann dann SOFS für die virtuellen Maschinen konfiguriert werden? Und wenn Cluster A wegbricht wird Cluster B aktiv und die virtuellen Maschinen können dort weiterlaufen?
Die Frage nun: Funktioniert das ganze auch mit nur 2 Servern?
Beide Server sind gegenseitig über 10G direkt angeschlossen und nutzen lokale Festplatten und Hyper-V läuft ebenso auf den Maschinen?
Vielen Dank vorab.
Grüße Timo
Hallo Timo,
"Hallo. Vielen Dank für die sehr guten Erklärungen für Server 2016 Funktionen."
Vielen Dank für Dein Feedback!
"Ich habe eine kurze Frage:"
Naja, ich sehe mehrere :)
"Hier wird nun von zwei Clustern gesprochen (Cluster A+B) wobei von A zu B synchronisiert wird. Beide Seiten greifen auf ein iSCSI Target zu. Da drauf kann dann SOFS für die virtuellen Maschinen konfiguriert werden?"
Genau, ein sogenannter Stretched Cluster, ein Disaster Recovery Beispiel. Fällt ein Standort aus, kann auf das zweite RZ geschwenkt werden. Die iSCSI LUNs sind ja bereits shared Storage. Ein Scale-out File server wäre nicht mehr nötig. Auf den LUNs werden die virtuellen Maschinen platziert.
"Und wenn Cluster A wegbricht wird Cluster B aktiv und die virtuellen Maschinen können dort weiterlaufen?"
Genau :)
"Die Frage nun: Funktioniert das ganze auch mit nur 2 Servern? Beide Server sind gegenseitig über 10G direkt angeschlossen und nutzen lokale Festplatten und Hyper-V läuft ebenso auf den Maschinen?"
Es gibt bei Storage Replica auch ein Server zu Server Szenario:
https://www.windowspro.de/marcel-kueppers/storage-replica-unter-windows-server-2016-einrichten
Aber ich denke Du meinst ein verteiltes 2 Knoten Cluster? Ein Cluster braucht ja shared Storage. Eine Hyper-converged Umgebung mit Storage Spaces Direct würde zur Zeit (TP4) vier Knoten min. voraussetzen.
Viele Grüße,
Marcel
Guten Morgen und vielen Dank für die schnelle Antwort.
Jop, Server-zu-Server geht, allerdings dann wohl nur mit manuellem Eingreifen, sollte einer der beiden Nodes ausfallen.
Hyper-Converged ist genial, leider aber eben nur ab 4 Hosts was für viele kleinere Kunden zu viel ist.
Interessant wäre wirklich die Möglichkeit zwei Nodes mit lokalen Platten und Hyper-V zu betreiben. Dort über Storage Spaces jeweils die gleiche lokale Konfiguration vorzunehmen und über SOFS bereitzustellen. Und Hyper-V würde im Fall eines Node Ausfalls alle Maschinen automatisch bei sich wieder hochfahren. HA mit Shared Nothing eben - natürlich über 10G oder RDMA angebunden =)
Grüße Timo