Storage Replica für Hyper-V Failover-Cluster unter Windows Server 2016 einrichten

    Storage Replica (SR) Stretched ClusterDiese Anleitung beschreibt die Ein­richtung einer synchronen Volume-Repli­kation mit Storage Replica (SR) für einen Hyper-V Failover-Cluster. Es wird gezeigt, wie SR in einem Stretched Cluster die Speicher-Sets über Stand­orte hinweg syn­chron hält und sie hoch­verfüg­bar 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 Netzwerk­konfiguration 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.

    Installation des Features Storage Replica (Speicherreplikat) auf den Knoten

    Nach einem Neustart empfiehlt es sich, über Test-SRTopology die Infrastruktur auf Herz und Nieren für die Speicher­replikation 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.

    Beginnend mit dem Quell-Datenvolume wird die Replikation aktiviert.

    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.

    Als erstes wird das Ziel-Datenvolume ausgewählt, dann folgt man dem Wizard.

    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

    Übersicht über den Replikationsstatus im Failovercluster-Manager.

    Eine weitere Hilfe stellt in diesem Fall der Failovercluster-Manager dar, denn hier erfahren Sie, wie der aktuelle Replikations­status 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.

    3 Kommentare

    Bild von Timo F.
    Timo F. sagt:
    21. Januar 2016 - 17:35

    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

    Bild von Marcel Küppers
    22. Januar 2016 - 4:39

    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

    Bild von Timo F.
    Timo F. sagt:
    22. Januar 2016 - 7:19

    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