Tags: Storage, Disaster Recovery, Windows Server 2016
Microsoft erweitert das Disaster Recovery von Windows Server in der Version 2016 um Storage Replica. Dieses Feature kann Volumes oder LUNs zwischen Standorten synchronisieren. Es unterstützt die Replikation 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 Betriebssystems gehört das verteilte File-System DSF-R mit integrierter Replikation. Aufgrund diverser Einschränkungen (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 Anwendungsszenarien:
- 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 Naturkatastrophen ohne Datenverlust für das Unternehmen einsatzbereit 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 Bordmitteln liegt jedoch auf der Hand, sie läuft mit herkömmlicher 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 Netzwerkadapter 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 Standorten 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 Latenzabhängigkeit, 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.
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.
Ähnliche Beiträge
- PPT-Folien zu Webinar über neue Storage Features von Windows Server 2016
- Storage Replica für Hyper-V Failover-Cluster unter Windows Server 2016 einrichten
- Storage Replica unter Windows Server 2016 einrichten
- Veeam bringt Backup & Replication 12 mit Direct-to-Object-Storage, MFA, PostgreSQL-Support
- Vergleich: Storage Replica versus DFS Replication
Weitere Links
2 Kommentare
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
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