Storage Replica: LUNs und Volumes replizieren in Windows Server 2016

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.

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.

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).

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.