Storage Replica verstehen Speicher in Windows Server 2019 replizieren

Autor Thomas Joos |

Storage-Replica ist der Replikation von DFS (Distributed File System) deutlich überlegen. Storage Spaces Direct und Storage Replica arbeiten in diesem Zusammenhang auch miteinander. Die Funktion wird als Serverfeature über den Server-Manager installiert und steht danach zur Verfügung. Die Verwaltung erfolgt über die PowerShell oder den Failovercluster-Manager. In Windows Server 2019 kann auch die Standard-Edition ein Volume zu einem Ziel replizieren

Anbieter zum Thema

Microsoft-Netzwerke effektiv verwalten
Microsoft-Netzwerke effektiv verwalten
(Microsoft-Netzwerke effektiv verwalten)

Die Speicherreplikation bietet vor allem drei verschiedene Einsatzszenarien. Im ersten Szenario können Sie wichtige Datenträger schnell und einfach auf andere Server (ServerA ->ServerB), auch in anderen Rechenzentren replizieren. Dadurch erhalten Sie eine Absicherung Ihrer Daten, vor allem im Katastrophenfall.

Das zweite wichtige Einsatzgebiet ist das Replizieren von Daten in einem Geo-Cluster, auch Stretched Cluster genannt (Clusterknoten1 -> Clusterknoten2). Ein Einsatzgebiet kann zum Beispiel die Replikation von virtuellen Servern und deren Konfigurationsdaten sowie virtueller Festplatten zwischen verschiedenen Rechenzentren sein. Dabei sind die Clusterknoten auf verschiedene Rechenzentren verteilt.

Die beiden Szenarien lassen sich auch zu einem gemeinsamen Einsatzszenario verbinden. In diesem replizieren Sie die Daten eines Clusters zu einem anderen Cluster in einem anderen Rechenzentrum (Clusterknoten1-Cluster1 -> Clusterknoten1-Cluster2). Dabei sind die Cluster aber nicht auf verschiedene Rechenzentren aufgeteilt, sondern Bestandteil eines einzelnen Rechenzentrums. Die Daten werden also nicht innerhalb eines Clusters repliziert, sondern zwischen verschiedenen Clustern. Die Cluster selbst sind dann natürlich idealerweise in verschiedenen Rechenzentren verteilt.

 

Die Replikation kann synchron und asynchron konfiguriert werden. Größere Unternehmen können mit der Technologie auch auf Clusterebene Daten zwischen Rechenzentren replizieren (Stretched Cluster). Dadurch lassen sich Geo-Cluster aufbauen, also Cluster deren Knoten international in verschiedenen Rechenzentren verteilt sind.

Der Vorteil der neuen Technologie ist die Unabhängigkeit von Speicherlösungen und Speicherherstellern. Sie können jeden beliebigen Speicher replizieren, solange dieser mit einem Server auf Basis von Windows Server 2019 verbunden ist und funktioniert. Die Replikation erfolgt über das Server Message Block (SMB)-Protokoll mit Windows Server 2019. Dabei kann das Protokoll auf die ganze Bandbreite zurückgreifen, welche durch die Adapter zur Verfügung gestellt werden.

Sie können Bitlocker-Laufwerke replizieren sowie Datenträger auf denen die Datendeduplizierung aktiviert ist. Auch Multichannel und Multipath werden unterstützt, was vor allem für die Replikation in Clustern eine wichtige Rolle spielt (siehe Kapitel 9 und 34). Die Daten lassen sich während der Übertragung zwischen Quell- und Ziel-Server verschlüsseln und signieren. Wollen Sie Failover-Szenarien umsetzen, können Sie auch nur einzelne Laufwerke verwenden, Sie müssen das Failover nicht für alle replizierten Laufwerke eines Servers auf einmal starten.

Sie können zum Beispiel zwei Cluster in physisch getrennten Rechenzentren betreiben und den gemeinsamen Speicher der Cluster replizieren lassen. Fällt ein Rechenzentrum aus, kann das andere Rechenzentrum sofort übernehmen. Hier ist auch die neue Funktion zum Verwendung von Microsoft Azure als Cloudzeuge interessant.

Ablauf der Replikation

Das Betriebssystem schreibt Blöcke auf den Quell-Server (Schritt 1). Storage-Replika erkennt das und speichert die Vorgänge in der Protokolldatei. Außerdem überträgt der Quell-Server die Daten mit SMB sowie RDMA zum Zielserver übertragen (Schritt 2). Anschließend schreibt der Server im Ziel-Standort die Daten ein sein Protokoll (Schritt 3). Danach bestätigt der Ziel-Server die erfolgreiche Replikation (Schritt 4), und der Quell-Server meldet, dass er die Bestätigung empfangen hat (Schritt 5). Anschließend werden auch die Protokolle entsprechend angepasst (Schritt 6).