Storage Replica: LUNs und Volumes replizieren in Windows Server 2016

    Stirage Replica von Server zu ServerMicrosoft erweitert das Di­saster Recovery von Windows Server in der Version 2016 um Storage Replica. Dieses Feature kann Volumes oder LUNs zwischen Stand­orten syn­chroni­sieren. Es unter­stützt die Repli­kation zwischen Servern, Clustern und innerhalb von Clustern.

    Seit Windows Server 2012 erlaubt Hyper-V die asynchrone Replikation virtueller Maschinen von einem Rechenzentrum zu einem anderen. Storage Replica dagegen arbeitet unabhängig von der Anwendung, in diesem Fall von Hyper-V, und repliziert die VMs bevorzugt synchron von Host zu Host.

    Auch länger schon zum Funktionsumfang des Betriebs­systems gehört das verteilte File-System DSF-R mit integrierter Replikation. Aufgrund diverser Ein­schrän­kungen (lange RPO, keine offenen Dateien) ist es jedoch für das Disaster Recovery nicht gut geeignet und hat für diesen Zweck spätestens in Server 2016 ausgedient.

    Im Gegensatz dazu arbeitet Storage Replica blockbasiert und verwendet für den Transport das etablierte SMB3-Protokoll. Dieses unterstützt auch die verschlüsselte Übertragung von Daten, was sich Storage Replica zunutze macht.

    Varianten von Storage Replica

    Wie von einer Lösung für das Disaster Recovery zu erwarten, soll die Downtime von Anwendungen möglichst gering sein und eine getrennte Datenhaltung gewährleisten.

    Anwendungsfall Stretched Cluster

    Storage Replica erfüllt diese Anforderungen und berücksichtigt dabei verschiedene Anwendungs­szenarien:

    • Server to Server: Replikation von einem Server zu einem anderen
    • Stretched Cluster: Replikation der Daten in einem verteilten Cluster, wo sich beispielsweise die Hälfte der Knoten an Standort A und die andere Hälfte an Standort B befindet.
    • Cluster to Cluster: Replikation von einem Cluster zu einem anderen

    Das zweite Rechenzentrum, in das die Daten repliziert werden, kann viele Kilometer entfernt sein, um auch im Fall von Natur­kata­strophen ohne Datenverlust für das Unternehmen einsatz­bereit zu bleiben.

    Anwendungsfall Cluster to Cluster

    Voraussetzungen und Handhabung

    Storage Replica ist ein Feature, das man bis dato vor allem von Enterprise-SANs kannte. Der Vorteil einer Replikation mit Bord­mitteln liegt jedoch auf der Hand, sie läuft mit herkömm­licher Hardware und wird mit bekannten Tools wie dem Failover Cluster Manager oder PowerShell verwaltet.

    Storage Replica (SR) arbeitet mit lokalen Datenträgern, Storage Spaces, SAS, Fibre Channel oder iSCSI-Volumes. Bei Cluster-zu-Cluster kann es auch von Storage Spaces Direct (S2D) zu Storage Spaces Direct replizieren. Als Dateisysteme kommen ReFS, NTFS und CSVFS in Frage, die Laufwerke sollten jedoch als GPT (GUID Partition Table) initialisiert sein. Die Ziel-Volumes des sekundären Standorts müssen dieselbe Größe aufweisen wie jene des primären.

    Damit die synchrone Replikation mit geringer Latenz über Distanzen bis zu 50 km erfolgen kann, werden RDMA-fähige Netzwerk­adapter unterstützt, also SMB Direct. Eine asynchrone Replikation, beispielsweise Server-to-Server, kann dagegen gut mit hohen Latenzen umgehen und Begrenzungen hinsichtlich der Entfernung zwischen den Stand­orten entfallen fast gänzlich.

    Da Storage Replica Logfile-basiert arbeitet, sollten für die schnelle Speicherung Flash-Speicher, SSDs oder NVMe, zum Einsatz kommen. Die Applikationen sind bei einer synchronen Replikation abhängig von einem schnellen Ackknowledge beim Speichern der Blöcke.

    Ablauf einer synchronen und asynchronen Replikation

    Wenn eine Anwendung Blöcke schreibt (A), werden diese im primären Log festgehalten und unmittelbar via SMB 3.1.1 (+ RDMA) zum Zielserver übertragen (B). Blockweise wird dann auf der sekundären Site in das entsprechende Log geschrieben (C). Anschließend bestätigt (Ackknowledge) der Zielserver den Schreibvorgang (D) und der Ausgangsserver bestätigt wiederrum der Anwendung den erfolgreichen Schreibvorgang (E). Danach erst wird der Block aus den Log-Volumes in die Data-Volumes übertragen (F).

    Ablauf einer synchronen Storage-Replikation

    Die IO-Operation ist also erst fertiggestellt, wenn die Blöcke auf beiden Seiten geschrieben wurden. Es ist somit notwendig, die Latenz im Vorfeld genau abzuklären, damit Speichervorgänge mit der nötigen Performance ablaufen. Das Cmdlet Test-SRTopology wurde genau für diese Aufgabe entwickelt. Die synchrone Storage-Replikation verliert dementsprechend im Disaster Recovery Fall keine Daten.

    Im Gegensatz dazu arbeitet die asynchrone Replikation ohne Latenz­abhängig­keit, jedoch mit möglichem Datenverlust bei einem Disaster-Ereignis.

    Hier schreibt die Applikation den Datenblock (A) und auch dieser wird in das Log-Volume geschrieben (B), jedoch mit dem Unterschied, dass anschließend ein direkter Ackknowledge die Anwendung erreicht. Erst danach wird der Block zur sekundären Site via SMB 3.1.1 (TCP/IP oder RDMA) übertragen und dort in das Log geschrieben. Es geht eine erneute Bestätigung an die primäre Site und die Blöcke werden abschließend vom Log in die Datenbank transferiert.

    2 Kommentare

    Bild von 12321
    12321 sagt:
    24. März 2017 - 8:35

    Hallo,

    ist für jeden Knoten in einem Stretched Cluster die Windows Datacenter Lizenz notwendig, oder kann man aus jedem Cluster jeweils einem Knoten diese zuweisen und über die Rollen dann die Synchronisation laufen lassen?
    Und kann die Technologie auch für eingebundene CSV (SAN) genutzt werden?
    Danke für eine Antwort

    Bild von Marcel Küppers
    24. März 2017 - 19:20

    Hallo,

    alle Server müssen Datacenter sein.

    Im Fall von Hyper-V: wenn ein RZ mehr als zwei virtuelle Maschinen betreibt, ist eine Datacenter ja nötig, unabhängig vom SR Feature.

    Das Dateisystem kann CSVFS, NTFS oder ReFS sein, da SR unterhalb des File system als Filter Treiber sitzt. Auch im Falle eines Stretched Clusters.

    Gruß,
    Marcel