Übersicht über Speicherreplikate
Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016
Das Speicherreplikat ist eine Windows Server-Technologie, durch die die Replikation von Volumes zwischen Servern oder Clustern für die Notfallwiederherstellung möglich ist. Darüber hinaus ermöglicht sie Ihnen, Stretched Failovercluster zu erstellen, die sich über zwei Standorte erstrecken und bei denen alle Knoten synchron bleiben.
Das Speicherreplikat unterstützt sowohl die synchrone als auch die asynchrone Replikation.
- Die synchrone Replikation spiegelt Daten an physischen Standorten mit ausfallsicheren Volumes wider, um auf Dateisystemebene sicherzustellen, dass während eines Ausfalls kein Datenverlust auftritt.
- Die asynchrone Replikation spiegelt Daten zwischen Standorten über regionale Bereiche über Netzwerklinks mit höherer Latenzen wider, jedoch ohne die Garantie, dass beide Standorte über identische Kopien der Daten zur Zeit eines Ausfalls verfügen.
Gründe für die Verwendung von Speicherreplikaten
Das Speicherreplikatfeature bietet Funktionen für Notfallwiederherstellung und -bereitschaft in Windows Server. Mit Windows Server können Sie Daten synchron in unterschiedlichen Racks, Etagen, Gebäuden, Campusumgebungen, Bezirken und Städten schützen und müssen sich nicht mehr um Datenverluste sorgen. Da alle Daten an einem weiteren Standort vorhanden sind, schützen Sie sich mit dieser Konfiguration gegen Datenverlust bei einem Notfall. Dasselbe gilt, bevor eine Notfallsituation eintritt. Bei Verwendung von Speicherreplikaten können Sie Workloads vor einem Katastrophenfall ohne Datenverlust an sichere Standorte verlagern, wenn Sie rechtzeitig über das Ereignis informiert sind.
Speicherreplikate ermöglichen eine effizientere Verwendung von mehreren Rechenzentren. Indem Cluster gestreckt oder repliziert werden, können Workloads in mehreren Rechenzentren ausgeführt werden, um einen schnelleren Datenzugriff für Benutzer und Anwendungen mit der jeweils geringsten Entfernung zu ermöglichen. Gleichzeitig kann die Last besser verteilt, und Computeressourcen können besser genutzt werden. Wenn ein Rechenzentrum in einer Notfallsituation ausfällt, können sie die typischen Workloads dieses Rechenzentrums vorübergehend an einen anderen Standort verlagern.
Mit Speicherreplikaten können Sie vorhandene Dateireplikationssysteme wie die DFS-Replikation gegebenenfalls außer Betrieb nehmen, die als Low-End-Notfallwiederherstellungslösungen eingesetzt wurden. Während DIE DFS-Replikation gut über Netzwerke mit geringer Bandbreite funktioniert, ist ihre Latenz hoch - oft in Stunden oder Tagen gemessen. Der Grund dafür ist, dass Dateien geschlossen werden müssen und künstliche Drosselungen implementiert sind, um eine Netzwerküberlastung zu verhindern. Aufgrund dieses Aufbaus werden die neuesten Dateien in einem Replikat der DFS-Replikation mit der geringsten Wahrscheinlichkeit repliziert. Das Speicherreplikatfeature wird unterhalb der Dateiebene ausgeführt, sodass keine dieser Einschränkungen gelten.
Für größere Bereiche und Netzwerke mit höherer Latenz unterstützt das Speicherreplikatfeature zudem die asynchrone Replikation. Da es nicht prüfpunktbasiert ist und stattdessen kontinuierlich repliziert wird, ist das Delta von Änderungen tendenziell weit niedriger als snapshotbasierte Produkte. Das Speicherreplikat wird auf der Partitionsebene ausgeführt und repliziert daher alle VSS-Snapshots, die von Windows Server oder Sicherungssoftware erstellt wurden. Mithilfe von VSS-Momentaufnahmen ermöglicht es die Verwendung anwendungskonserierter Datenmomentaufnahmen für die Zeitwiederherstellung, insbesondere unstrukturierte Benutzerdaten, die asynchron repliziert wurden.
Unterstützte Konfigurationen
Sie können ein Speicherreplikat in einem Stretched Cluster sowie zwischen Cluster-zu-Cluster- und in Server-zu-Server-Konfigurationen implementieren (siehe Abbildungen 1-3).
Ein Stretched Cluster ermöglicht die Konfiguration von Computern und Speicher innerhalb eines einzigen Clusters, wobei einige Knoten asymmetrischen Speicher und andere Knoten sich gegenseitig gemeinsam verwenden. Die Replikation wird anschließend mit Standortinformationen synchron oder asynchron durchgeführt. In diesem Szenario können Speicherplätze mit freigegebenem SAS-Speicher, SAN und an iSCSI-LUNs verwendet werden. Sie wird mit PowerShell und dem grafischen Tool des Failovercluster-Managers verwaltet und ermöglicht das automatische Failover der Arbeitsauslastung.
Abbildung 1: Speicherreplikation in einem Stretched Cluster unter Verwendung von Speicherreplikaten
Eine Cluster-zu-Cluster-Konfiguration ermöglicht die Replikation zwischen zwei separaten Clustern, wobei ein Cluster synchron oder asynchron in den anderen Cluster repliziert wird. In diesem Szenario können Sie „Direkte Speicherplätze“ und Speicherplätze mit freigegebenem SAS-Speicher, SAN und an iSCSI-LUNs verwendet werden. Es wird mit Windows Admin Center und PowerShell verwaltet und erfordert manuelle Interventionen für failover.
Abbildung 2: Cluster-zu-Cluster-Speicherreplikation unter Verwendung von Speicherreplikaten
Eine Server-zu-Server-Konfiguration ermöglicht eine synchrone und asynchrone Replikation zwischen zwei eigenständigen Servern unter Verwendung von Speicherplätzen mit freigegebenem SAS-Speicher, SAN- und iSCSI-LUNs sowie lokalen Laufwerken. Es wird mit Windows Admin Center und PowerShell verwaltet und erfordert manuelle Interventionen für failover.
Abbildung 3: Server-zu-Server-Speicherreplikation unter Verwendung von Speicherreplikaten
Hinweis
Sie können auch eine Server-to-Self-Replikation konfigurieren, bei der vier separate Volumes auf einem einzigen Computer verwendet werden. Dieses Szenario wird in diesem Leitfaden jedoch nicht abgedeckt.
Speicherreplikatfeatures
Replikation auf Blockebene ohne Datenverlust. Bei synchroner Replikation gibt es keine Möglichkeit, Datenverluste zu haben. Bei der Replikation auf Blockebene können keine Dateien gesperrt werden.
Einfache Bereitstellung und Verwaltung. Das Speicherreplikatfeature wurde von Grund auf für eine hohe Benutzerfreundlichkeit entwickelt. Die Erstellung einer Replikationspartnerschaft zwischen zwei Servern kann über Windows Admin Center erfolgen. Zur Bereitstellung von Stretched Clustern wird der intuitive Assistent des vertrauten Failovercluster-Managers verwendet.
Gast und Host. Alle Funktionen des Speicherreplikatfeatures werden sowohl in virtualisierten Gast- als auch in hostbasierten Bereitstellungen offengelegt. Das heißt, dass Gäste ihre Datenvolumes selbst dann replizieren können, wenn sie auf Nicht-Windows-Virtualisierungsplattformen oder in öffentlichen Clouds ausgeführt werden. Die einzige Voraussetzung ist, dass auf dem Gast Windows Server verwendet werden muss.
SMB3-basiert. Das Speicherreplikatfeature verwendet die bewährte und ausgereifte SMB3-Technologie, die erstmalig in Windows Server 2012 veröffentlicht wurde. Das bedeutet, dass alle ausgereiften Merkmale von SMB (z. B. SMB Multichannel- und SMB Direct-Unterstützung für RoCE-, iWARP- und InfiniBand RDMA-Netzwerkkarten) für Speicherreplikate verfügbar sind.
Sicherheit. Im Gegensatz zu den Produkten vieler anderer Anbieter ist branchenführende Sicherheitstechnologie bereits in das Speicherreplikatfeature integriert. Dies umfasst Paketsignatur, vollständige AES-128-GCM-Datenverschlüsselung, Unterstützung für Intel AES-NI-Verschlüsselungsbeschleunigung sowie Vorauthentifizierung zur Verhinderung von Man-in-the-Middle-Angriffen. Das Speicherreplikatfeature nutzt Kerberos AES256 für die gesamte Authentifizierung zwischen Knoten.
Erste Hochleistungssynchronisierung. Das Speicherreplikatfeature unterstützt ein Seeding vor der ersten Synchronisierung, wobei auf einem Ziel bereits eine Untermenge von Daten aus älteren Kopien, Sicherungen oder bereitgestellten Laufwerken vorhanden ist. Bei der ersten Replikation werden lediglich die abweichenden Blöcke kopiert, sodass die Dauer der ersten Synchronisierung verkürzt und eine vollständige Belegung eingeschränkter Bandbreite verhindert wird. Da Speicherreplikate eine Prüfsummenberechnung und Aggregation verhindern, ist die Leistung bei der ersten Synchronisierung lediglich durch die Geschwindigkeit von Speicher und Netzwerk beschränkt.
Konsistenzgruppen. Durch eine Schreibreihenfolge wird sichergestellt, dass Anwendungen wie Microsoft SQL Server in mehrere replizierte Volumes schreiben können und die Daten sequenziell auf den Zielserver geschrieben werden.
Benutzerdelegierung. Benutzern können Berechtigungen zum Verwalten der Replikation zugewiesen werden, ohne dass diese Mitglied der integrierten Administratorengruppe auf den replizierten Knoten sind. Dadurch wird der Zugriff dieser Benutzer auf nicht verknüpfte Bereiche eingeschränkt.
Netzwerkeinschränkung. Das Speicherreplikatfeature kann durch die Angabe von Servern und replizierten Volumes auf einzelne Netzwerke beschränkt werden, um Bandbreite für Anwendungen, Sicherungen und Verwaltungssoftware bereitzustellen.
Schlanke Speicherzuweisung. Die Unterstützung für die dünne Bereitstellung in Speicherplätze- und SAN-Geräten wird unterstützt, um nahezu sofortige Anfängliche Replikationszeiten unter vielen Umständen bereitzustellen. Sobald die anfängliche Replikation initiiert wurde, kann das Volume nicht verkleinern oder kürzen.
Komprimierung. Speicherreplikat bietet Komprimierung für Daten, die über das Netzwerk zwischen dem Quell- und Zielserver übertragen werden. Die Speicherreplikatkomprimierung für die Datenübertragung wird nur in Windows Server Datacenter unterstützt: Azure Edition beginnend mit dem Betriebssystembuild 20348.1070 und höher (KB5017381).
Speicherreplikate enthalten die folgenden Features:
| Funktion | Details |
|---|---|
| type | Hostbasiert |
| Synchron | Ja |
| Asynchron | Ja |
| Speicherhardwareagnostisch | Ja |
| Replikationseinheit | Volume (Partition) |
| Erstellung eines Stretched Clusters mit Windows Server | Ja |
| Server-zu-Server-Replikation | Ja |
| Cluster-zu Cluster-Replikation | Ja |
| Transport | SMB3 |
| Netzwerk | TCP/IP oder RDMA |
| Unterstützung für die Netzwerkeinschränkung | Ja |
| Netzwerkkomprimierung | Ja** |
| RDMA* | iWARP, InfiniBand, RoCE v2 |
| Netzwerkport-Firewallanforderungen für die Replikation | Einzelner IANA-Port (TCP 445 oder 5445) |
| Multipath/Multichannel | Ja (SMB3) |
| Kerberos-Unterstützung | Ja (SMB3) |
| Verschlüsselung und Signatur über das Netzwerk | Ja (SMB3) |
| Volumebasiertes Failover zulässig | Ja |
| Unterstützung für die schlanke Speicherzuweisung | Ja |
| Integrierte Verwaltungsbenutzeroberfläche | PowerShell, Failovercluster-Manager |
*Möglicherweise sind Geräte und Kabel für große Entfernungen erforderlich. **Bei Verwendung von Windows Server Datacenter: Azure Edition beginnend mit betriebssystem build 20348.1070
Voraussetzungen für Speicherreplikate
Active Directory Domain Services-Gesamtstruktur.
Speicherplätze mit SAS JBODs, „Direkte Speicherplätze“, Fibre Channel-SAN, freigegebene VHDX, iSCSI-Ziel oder lokalem SAS/SCSI/SATA-Speicher. Für Replikationsprotokolllaufwerke werden mindestens SSDs empfohlen. Microsoft empfiehlt, dass der Protokollspeicher schneller als der Datenspeicher ist. Protokollvolumes dürfen niemals für andere Workloads verwendet werden.
Mindestens eine Ethernet/TCP-Verbindung auf jedem Server für die synchrone Replikation (vorzugsweise RDMA).
Mindestens 2 GB RAM und zwei Kerne pro Server.
Ein Netzwerk zwischen Servern mit ausreichender Bandbreite, um Ihre IO-Schreibauslastung und einen Durchschnitt von 5 ms Roundtriplatenz oder niedriger für die synchrone Replikation zu enthalten. Für die asynchrone Replikation gelten keine Empfehlungen in Bezug auf die Latenz.
Windows Server, Datacenter Edition oder Windows Server, Standard Edition. Ein unter Windows Server, Standard Edition, ausgeführtes Speicherreplikat hat die folgenden Einschränkungen:
- Sie müssen Windows Server 2019 oder höher verwenden.
- Das Speicherreplikat repliziert ein einzelnes Volume anstelle einer unbegrenzten Anzahl von Volumes.
- Volumes können eine Größe von bis zu 2 TB statt einer unbegrenzten Größe haben.
Hintergrund
Dieser Abschnitt enthält Informationen zu allgemeinen Begriffen aus der Branche, synchroner und asynchroner Replikation und zu Schlüsselverhalten.
Allgemeine Begriffe aus der Branche
Der Begriff Notfallwiederherstellung bezieht sich auf einen Notfallplan für die Wiederherstellung nach einem Katastrophenfall an einem Standort, damit die Geschäftsvorgänge weiter ausgeführt werden können. Zur Notfallwiederherstellung von Daten werden mehrere Kopien von Produktionsdaten an einem separaten physischen Standort erstellt. Ein Beispiel ist ein Stretched Cluster, bei dem sich die Hälfte der Knoten an einem Standort und die andere Hälfte der Knoten an einem anderen Standort befindet. Der Begriff Notfallbereitschaft bezieht sich auf einen Notfallplan, um Workloads präventiv an einen anderen Standort zu verschieben, bevor eine bevorstehende Notallsituation eintritt (z. B. ein Orkan).
Vereinbarungen zum Servicelevel (Service Level Agreement, SLA) definieren die Verfügbarkeit der Anwendungen eines Unternehmens sowie die jeweilige Toleranz von Downtime und Datenverlust während geplanten und ungeplanten Ausfällen. Der RTO-Wert (Recovery Time Objective) definiert den maximalen Zeitraum ohne Datenzugriff, der für ein Unternehmen tolerierbar ist. Der RPO-Wert (Recovery Point Objective) definiert die maximale Menge an Daten, die ein Unternehmen verlieren kann.
Synchrone Replikation
Die synchrone Replikation garantiert, dass die Anwendung Daten gleichzeitig an zwei Speicherorten schreibt, bevor der IO-Vorgang abgeschlossen wurde. Diese Replikation eignet sich besser für unternehmenskritische Daten, da es Netzwerk- und Speicherinvestitionen erfordert und die Leistung der Anwendung beeinträchtigt, indem Schreibvorgänge an zwei Standorten ausgeführt werden müssen.
Wenn Anwendungsschreibvorgänge in der Quelldatenkopie auftreten, erkennt der ursprüngliche Speicher das IO nicht sofort an. Stattdessen replizieren diese Datenänderungen auf die Remotezielkopie und geben eine Bestätigung zurück. Erst dann empfängt die Anwendung die E/A-Bestätigung. Dadurch wird eine konstante Synchronisierung des Remote- und des Quellstandorts sichergestellt, und Speicher-E/A-Vorgänge werden auf das Netzwerk ausgeweitet. Wenn ein Quellwebsitefehler auftritt, können Anwendungen an den Remotestandort fehlschlagen und ihre Vorgänge fortsetzen, indem Sie sicherstellen, dass keine Datenverluste auftreten.
| Mode | Diagramm | Schritte |
|---|---|---|
| Synchron Kein Datenverlust RPO |
 |
1. Anwendung schreibt Daten 2. Protokolldaten werden geschrieben, und die Daten werden an den Remotestandort repliziert. 3. Protokolldaten werden am Remotestandort geschrieben 4. Bestätigung vom Remotestandort 5. Anwendungsschreibzugriff bestätigt t t1 & : Daten, die auf das Volume gespült wurden, protokolle schreiben immer durch |
Asynchrone Replikation
Im Gegensatz zur synchronen Replikation werden die von einer Anwendung geschriebenen Daten bei der asynchronen Replikation ohne umgehende Bestätigung an den Remotestandort repliziert. Dieser Modus ermöglicht eine schnellere Reaktionszeit auf die Anwendung und eine DR-Lösung, die geografisch funktioniert.
Wenn die Anwendung Daten schreibt, erfasst die Replikations-Engine den Schreibvorgang und bestätigt diesen umgehend gegenüber der Anwendung. Die erfassten Daten werden dann am Remotestandort repliziert. Der Remoteknoten verarbeitet die Kopie der Daten und bestätigt den Vorgang mit einer gewissen Verzögerung gegenüber der Quellkopie. Da der Anwendungs-E/A-Pfad nicht länger für die Replikationsleistung ausschlaggebend ist, sind die Reaktionsfähigkeit und Entfernung des Remotestandorts weniger wichtige Faktoren. Es besteht das Risiko eines Datenverlusts, wenn die Quelldaten verloren gehen und die Zielkopie der Daten noch im Puffer war, ohne die Quelle verlassen zu müssen.
Mit seinem höher als null RPO eignet sich die asynchrone Replikation weniger für HA-Lösungen wie Failovercluster, da sie für den kontinuierlichen Betrieb mit Redundanz und ohne Datenverlust konzipiert sind.
| Mode | Diagramm | Schritte |
|---|---|---|
| Asynchron Praktisch keinerlei Datenverlust (von verschiedenen Faktoren abhängig) RPO |
 |
1. Anwendung schreibt Daten 2. Protokolldaten geschrieben 3. Anwendungsschreibzugriff bestätigt 4. Daten, die an den Remotestandort repliziert wurden 5. Protokolldaten, die am Remotestandort geschrieben wurden 6. Bestätigung vom Remotestandort t t1 & : Daten, die auf das Volume gespült wurden, protokolle schreiben immer durch |
Wichtige Evaluierungsaspekte und Verhaltensweisen
Netzwerkbandbreite und Latenz bei Speicher mit maximaler Geschwindigkeit. Bei der synchronen Replikation müssen physische Einschränkungen berücksichtigt werden. Da das Speicherreplikat einen E/A-Filtermechanismus unter Verwendung von Protokollen implementiert und Netzwerkroundtrips erforderlich sind, werden Anwendungsschreibvorgänge durch die synchrone Replikation wahrscheinlich langsamer ausgeführt. Durch Die Verwendung von geringen Latenzen, Netzwerken mit hoher Bandbreite und Hochdurchsatzdatenträger-Subsystemen für die Protokolle minimieren Sie den Leistungsaufwand.
Auf das Zielvolume kann beim Replizieren in Windows Server 2016 nicht zugegriffen werden. Bei der Konfiguration der Replikation wird die Bereitstellung des Zielvolumes aufgehoben, sodass Benutzer keine Daten auf diese Volumes schreiben oder lesen können. Der Treiberbuchstaben kann in typischen Schnittstellen wie Explorer sichtbar sein, aber eine Anwendung kann nicht auf das Volume selbst zugreifen. Replikationstechnologien auf Blockebene sind nicht kompatibel mit dem Zugriff auf das bereitgestellte Dateisystem des Ziels in einem Volume. NTFS und ReFS unterstützen Benutzer nicht beim Schreiben von Daten in das Volume, während sich die Änderungen unter ihnen blockieren.
Das Cmdlet Test-Failover wurde erstmalig in Windows Server, Version 1709, bereitgestellt und war auch in Windows Server 2019 enthalten. Dies unterstützt jetzt die vorübergehende Montage einer Lese-Schreib-Momentaufnahme des Zielvolumes für Sicherungen, Tests usw. Weitere Informationen finden Sie unter Häufig gestellte Fragen zum Speicherreplikat .
Die Microsoft-Implementierung der asynchronen Replikation unterscheidet sich von den meisten anderen Implementierungen. Bei den meisten Implementierungen der asynchronen Repliktion, die innerhalb der Branche verfügbar sind, basiert die Replikation auf Momentaufnahmen. Dabei werden regelmäßig Differenzen an den anderen Knoten übertragen, auf denen die Daten zusammengeführt werden. Bei der asynchronen Replikation mithilfe des Speicherreplikatfeatures wird der Vorgang wie bei der synchronen Replikation ausgeführt. Die beiden Vorgänge unterscheiden sich einzig dadurch, dass die Notwendigkeit einer serialisierten synchronen Bestätigung durch das Ziel entfällt. Das bedeutet, dass für das Speicherreplikat theoretisch ein niedrigerer RPO-Wert gilt, da die Daten kontinuierlich repliziert werden. Es bedeutet jedoch auch, dass der Vorgang von einer internen Absicherung der Anwendungskonsistenz abhängt, da die Konsistenz der Anwendungsdateien nicht mithilfe von Momentaufnahmen sichergestellt wird. Das Speicherreplikat stellt bei einem Absturz in sämtlichen Replikationsmodi Konsistenz sicher
Viele Kunden verwenden DFS-Replikation als Notfallwiederherstellungslösung, obwohl für dieses Szenario häufig unüblich ist – DFS-Replikation kann offene Dateien nicht replizieren und ist so konzipiert, dass die Bandbreitennutzung auf Kosten der Leistung minimiert wird, was zu großen Wiederherstellungspunkt-Deltas führt. Das Speicherreplikat bietet Ihnen die Möglichkeit, die DFS-Replikation gegebenenfalls nicht länger für einige dieser Notfallwiederherstellungsvorgänge einzusetzen.
Speicherreplikat ist keine Sicherungslösung. Da Replikationssysteme einen Datenverlust vollständig verhindern, werden sie in einigen IT-Umgebungen als Sicherungslösungen bereitgestellt und anstelle von täglichen Sicherungen genutzt. Das Speicherreplikat repliziert sämtliche Änderungen an allen Datenblöcken auf dem Volume (unabhängig von der Art der Änderung). Wenn ein Benutzer alle Daten von einem Volume löscht, repliziert das Speicherreplikatvolume den Löschvorgang umgehend auf das andere Volume, sodass die Daten unwiderruflich von beiden Servern entfernt werden. Verwenden Sie das Speicherreplikat nicht als Ersatz für eine Point-in-Time-Sicherungslösung.
Speicherreplikat ist kein Hyper-V-Replikat oder Microsoft SQL AlwaysOn-Verfügbarkeitsgruppen. Das Speicherreplikatfeature ist eine allgemeine speicheragnostische Engine. Durch Definition kann er sein Verhalten nicht so ideal wie die Replikation auf Anwendungsebene anpassen. Dies kann bestimmte Featurelücken mit sich bringen, aufgrund derer Sie sich weiterhin für bestimmte Anwendungsreplikationstechnologien entscheiden.
Hinweis
In diesem Dokument finden Sie eine Liste mit bekannten Problemen und erwarteten Verhaltensweisen sowie einen Abschnitt mit häufig gestellten Fragen.
Terminologie im Zusammenhang mit Speicherreplikaten
In diesem Leitfaden werden folgende Begriffe häufig verwendet:
Die Quelle ist das Volume eines Computers, das lokale Schreibvorgänge ermöglicht und eine ausgehende Replikation durchführt. Es wird auch als „primäres Volume“ bezeichnet.
Das Ziel ist das Volume eines Computers, das lokale Schreibvorgänge nicht erlaubt und eingehende Replikate repliziert. Es wird auch als „sekundäres“ Volume bezeichnet.
Eine Replikationspartnerschaft ist die Synchronisierungsbeziehung zwischen einem Quell- und einem Zielcomputer für mindestens ein Volume, für die ein einziges Protokoll verwendet wird.
Eine Replikationsgruppe ist die Organisation der Volumes sowie der zugehörigen Replikationskonfiguration innerhalb einer Partnerschaft und gilt pro Server. Eine Gruppe kann ein oder mehrere Volumes umfassen.
Neues bei Speicherreplikaten
Eine Liste der neuen Features in Speicherreplikat unter Windows Server 2019 finden Sie unter Neues für Speicher.