Übersicht über Speicherreplikate

Das Speicherreplikat in Windows Server schützt Ihre kritischen Daten, indem Volumes zwischen Servern oder Clustern für die Notfallwiederherstellung repliziert werden. Unabhängig davon, ob Sie gegen Hardwarefehler, Naturkatastrophen oder geplante Wartungen absichern, stellt Storage Replica sicher, dass kein Datenverlust entsteht und erlaubt das Erstellen von Stretch-Failoverclustern, die mehrere Standorte umfassen, unter Beibehaltung der Synchronisierung aller Knoten.

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 über Standorte außerhalb der Metropolbereiche über Netzwerkverbindungen mit höheren Latenzen hinweg, ohne jedoch zu gewährleisten, dass beide Standorte zum Zeitpunkt eines potenziellen Ausfalls identische Kopien der Daten aufweisen.

Gründe für die Verwendung von Speicherreplikaten

Das Speicherreplikatfeature bietet Funktionen für Notfallwiederherstellung und -bereitschaft in Windows Server. Speicherreplikate in Windows Server bieten die Gewissheit von null Datenverlust mit der Möglichkeit, Daten auf verschiedenen Racks, Etagen, Gebäuden, Campussen, Landkreisen und Städten synchron zu schützen. Da alle Daten an einem weiteren Standort vorhanden sind, schützen Sie sich mit dieser Konfiguration gegen Datenverlust bei einem Notfall. Das gleiche gilt vor einer Katastrophe. Das Speicherreplikat kann Ihnen helfen, Workloads ohne Datenverlust vor einer Katastrophe auf sichere Standorte zu verschieben, wenn Sie eine kurze Vorwarnung haben.

Verwenden Sie Speicherreplikat für eine effizientere Verwendung mehrerer Rechenzentren. Durch Das Strecken oder Replizieren von Clustern können Sie Workloads in mehreren Rechenzentren ausführen, um den Zugriff auf Daten schneller zu ermöglichen, indem Sie Benutzer und Anwendungen in enger Nähe erreichen. Außerdem erhalten Sie eine bessere Auslastungsverteilung und nutzung von Computeressourcen. Wenn ein Notfall ein Rechenzentrum offline nimmt, können Sie die typischen Workloads vorübergehend auf den anderen Standort verschieben.

Wenn Sie die Speicherreplikation implementieren, können Sie möglicherweise vorhandene Dateireplikationssysteme wie DFS-Replikation stilllegen, die notgedrungen als einfache Notfallwiederherstellungslösungen eingesetzt wurden. Obwohl die DFS-Replikation gut über Netzwerke mit geringer Bandbreite funktioniert, ist die Latenz hoch. Die Latenz in diesem Szenario wird häufig in Stunden oder Tagen gemessen. Die hohe Latenz ist auf die Anforderung zurückzuführen, dass Dateien geschlossen werden und an den künstlichen Drosselungen liegt, die darauf abzielen, 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.

Speicherreplikat unterstützt auch die asynchrone Replikation für längere Bereiche und Netzwerke mit höherer Latenz. Da es nicht prüfpunktbasiert ist und stattdessen kontinuierlich repliziert wird, ist das Delta der Änderungen tendenziell weit niedriger als snapshotbasierte Produkte.

Das Speicherreplikatfeature wird auf Partitionsebene ausgeführt, sodass alle von Windows Server oder Sicherungssoftware erstellten Volumeschattenkopie-Dienst (VSS)-Momentaufnahmen repliziert werden. Mithilfe von VSS-Momentaufnahmen können Sie anwendungskonsistente Momentaufnahmen von Daten für die zeitpunktbezogene Wiederherstellung abrufen, besonders geeignet für unstrukturierte Nutzerdaten, die asynchron repliziert werden.

Unterstützte Konfigurationen

Sie können Speicherreplikate in einem Stretchcluster bereitstellen, von Cluster zu Cluster und in einer Server-zu-Server-Konfiguration.

Replikation des Stretched Clusters

Verwenden Sie die Stretchclusterreplikation , um Daten zwischen Computern und Speicher in einem einzigen Cluster zu replizieren. In diesem Szenario teilen einige Knoten einen Satz asymmetrischer Speicher und einige Knoten teilen einen anderen Speichersatz. Anschließend werden sie synchron oder asynchron unter Berücksichtigung des Standorts repliziert.

Bei der Speicherreplikat-Replikation des Stretched Clusters können Sie Speicherplätze mit gemeinsam genutztem Serial Attached SCSI (SAS)-Speicher, Storage Area Network (SAN)-Logical Unit Numbers (LUNs) und iSCSI-verbundenen LUNs verwenden.

Sie verwalten eine Stretchclusterkonfiguration mithilfe von PowerShell und dem grafischen Tool des Failovercluster-Managers. Das Szenario unterstützt automatisiertes Workload-Failover.

Die folgende Abbildung zeigt die Speicherreplikation in einem Stretchcluster mithilfe des Speicherreplikats:

Cluster-zu Cluster-Replikation

In der Cluster-zu-Cluster-Replikation wird ein Cluster synchron oder asynchron mit einem anderen Cluster repliziert.

In der Cluster-zu-Cluster-Replikation des Speicherreplikats können Sie direkte Speicherplätze, Speicherplätze mit freigegebenem SAS-Speicher, SAN-LUNs und mit iSCSI verbundene LUNs verwenden.

Sie verwalten eine Cluster-zu-Cluster-Konfiguration mithilfe von Windows Admin Center und PowerShell. Für die Konfiguration ist ein manueller Eingriff für den Failover-Vorgang erforderlich.

Die folgende Abbildung zeigt die Cluster-zu-Cluster-Speicherreplikation mithilfe des Speicherreplikats:

Server-zu-Server-Replikation

Die Server-zu-Server-Replikation ist synchron und asynchron zwischen zwei eigenständigen Servern.

In diesem Szenario können Sie Speicherplätze mit freigegebenem SAS-Speicher, SAN LUNs, iSCSI-angefügten LUNs und lokalen Laufwerken verwenden.

Sie verwalten eine Server-zu-Server-Konfiguration mithilfe von Windows Admin Center und PowerShell. Für die Konfiguration ist ein manueller Eingriff für den Failover-Vorgang erforderlich.

Die folgende Abbildung zeigt die Server-zu-Server-Speicherreplikation mithilfe des Speicherreplikats:

Features eines Speicherreplikats

Speicherreplikat in Windows Server bietet die folgenden Features:

• Kein Datenverlust und Replikation auf Blockebene. Bei der synchronen Replikation besteht kein Risiko von Datenverlust. 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. Sie können Windows Admin Center verwenden, um eine Replikationspartnerschaft zwischen zwei Servern zu erstellen. Verwenden Sie den intuitiven Assistenten des vertrauten Failovercluster-Manager, um Stretched Cluster bereitzustellen.

• Gast und Host. Alle Funktionen des Speicherreplikatfeatures werden sowohl in virtualisierten Gast- als auch in hostbasierten Bereitstellungen offengelegt. Gäste können ihre Datenvolumes auch dann replizieren, wenn sie auf Nicht-Windows-Virtualisierungsplattformen oder in öffentlichen Clouds ausgeführt werden, wenn Windows Server sich in der Gastumgebung befindet.

• basiert auf SMB 3. Speicherreplikat verwendet die bewährte und ausgereifte Technologie von Server Message Block (SMB) 3, die erstmals in Windows Server 2012 veröffentlicht wurde. Alle erweiterten SMB-Merkmale, einschließlich Multichannel- und SMB Direct-Unterstützung für RoCE-, iWARP- und InfiniBand-RDMA-Netzwerkkarten, sind für Storage Replica verfügbar.

• Sicherheit. Im Gegensatz zu vielen Lieferantenprodukten verfügt Speicherreplikat über branchenführende Sicherheitstechnologien. Das 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. Speicherreplikat verwendet Kerberos AES256 für die gesamte Authentifizierung zwischen Knoten.

• Erste Synchronisierung mit hoher Leistung. 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. Blockprüfsummenberechnung und Aggregation im Speicherreplikat bedeutet, dass die anfängliche Synchronisierungsleistung nur durch die Geschwindigkeit des Speichers und des Netzwerks begrenzt ist.

• Konsistenzgruppen. Die Schreibsortierung garantiert, dass Anwendungen wie SQL Server in mehrere replizierte Volumes schreiben können und die Daten sequenziell auf dem Zielserver geschrieben werden.

• Benutzerdelegierung. Benutzern können Berechtigungen zum Verwalten der Replikation erteilt werden, ohne Mitglied der integrierten Gruppe "Administratoren" auf den replizierten Knoten zu sein. Der Vorteil besteht darin, dass ihr Zugang zu nicht zusammenhängenden Bereichen begrenzt ist.

• Netzwerkeinschränkung. Sie können das Speicherreplikatfeature durch die Angabe von Servern und replizierten Volumes auf einzelne Netzwerke beschränken, um Bandbreite für Anwendungen, Sicherungen und Verwaltungssoftware bereitzustellen.

• Thin Provisioning Um in vielen Situationen eine praktisch unmittelbare erste Replikation zu ermöglichen, wird die schlanke Speicherzuweisung für Speicherplätze und SAN-Geräte unterstützt. Nachdem die erste Replikation gestartet wurde, können Sie das Volume nicht verkleinern oder beschneiden.

• Komprimierung. Speicherreplikat bietet Komprimierung für Daten, die über das Netzwerk zwischen den Quell- und Zielservern übertragen werden. Das Feature "Speicherreplikatkomprimierung für Datenübertragung" wird nur in Windows Server Datacenter unterstützt: Azure Edition ab Betriebssystembuild 20348.1070 und höher (KB5017381).

Speicherreplikate enthalten die folgenden Features:

* Erfordert möglicherweise zusätzliche Langstreckenausrüstung und Kabel.

Bei Verwendung von Windows Server Datacenter: Azure Edition ab Betriebssystem-Version 20348.1070.

Voraussetzungen für Speicherreplikate

• Active Directory Domain Services-Gesamtstruktur.

• Speicherplätze mit Serial Attached SCSI (SAS), „Just a Bunch of Disks“-Speicherserver (JBODs), direkten Speicherplätze, ein Fibre Channel Storage Area Network (FC SAN), eine virtuelle Shared Festplatte V2 (VHDX), ein Internet Small Computer Systems Interface (iSCSI)-Ziel oder lokalen SAS-, SCSI- oder Serial Advanced Technology Attachment (SATA)-Speicher beinhalten können. Wir empfehlen ein SSD oder eine schnellere Option für Laufwerke, die Replikationsprotokolle speichern. Es wird empfohlen, den Protokollspeicher zu verwenden, der schneller als Ihre Datenspeicherung ist. Protokollvolumes dürfen niemals für andere Workloads verwendet werden.

• Mindestens eine Ethernet-/TCP-Verbindung auf jedem Server für die synchrone Replikation, remote Direct Memory Access (RDMA) wird jedoch bevorzugt.

• Mindestens 2 GB RAM und zwei Kerne pro Server.

• Ein Netzwerk zwischen den Servern mit ausreichender Bandbreite für Ihre E/A-Schreibworkload sowie durchschnittlich maximal 5 ms Roundtriplatenz für die synchrone Replikation. Für die asynchrone Replikation gelten keine Empfehlungen in Bezug auf die Latenz.

• Windows Server Datacenter oder Windows Server Standard. Speicherreplikat, das unter Windows Server Standard ausgeführt wird, hat die folgenden Einschränkungen:

  • Sie müssen Windows Server 2019 oder höher verwenden.
  • Speicherreplikate replizieren ein einzelnes Volume statt einer unbegrenzten Anzahl von Volumes.
  • Volumes können eine Größe von bis zu 2 TB anstelle einer unbegrenzten Größe aufweisen.

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

Notfallwiederherstellung bezieht sich auf einen Notfallplan für die Wiederherstellung von Katastrophen vor Ort, damit das Geschäft weiterhin funktioniert. Die Daten-Notfallwiederherstellung bedeutet, dass mehrere Kopien von Produktionsdaten an einem separaten physischen Standort gespeichert werden. Ein Beispiel ist ein Stretchcluster, bei dem sich die Hälfte der Knoten an einem Standort und in einer Hälfte in einem anderen befinden. Die Notfallbereitschaft bezieht sich auf einen Notfallplan für das präventive Verschieben von Arbeitslasten an einen anderen Ort vor dem Auskommen einer Katastrophe, z. B. einem Hurrikan.

Vereinbarungen auf Serviceebene definieren die Verfügbarkeit der Anwendungen einer Organisation sowie die Toleranz von Ausfallzeiten und Datenverlusten während geplanter und ungeplanter Ausfalls. Das Wiederherstellungszeitziel (RTO) definiert, wie lange das Unternehmen die vollständige Unzugänglichkeit von Daten tolerieren kann. Recovery Point Objective (RPO) definiert, wie viele Daten das Unternehmen verlieren kann.

Synchrone Replikation

Die synchrone Replikation garantiert, dass die Anwendung Daten gleichzeitig an zwei Speicherorten schreibt, bevor der E/A-Vorgang abgeschlossen wird. Diese Replikation eignet sich besser für unternehmenskritische Daten, da sie Netzwerk- und Speicherinvestitionen erfordert und die Anwendungsleistung beeinträchtigt, indem Schreibvorgänge an zwei Standorten ausgeführt werden.

Wenn Anwendungsschreibvorgänge in der Quelldatenkopie erfolgen, erkennt der ursprüngliche Speicher die E/A nicht sofort an. Stattdessen werden diese Datenänderungen in die Remotezielkopie repliziert, und es wird eine Bestätigung zurückgegeben. Erst dann empfängt die Anwendung die E/A-Bestätigung. Diese Sequenz stellt eine konstante Synchronisierung des Remotestandorts mit dem Quellstandort sicher, wodurch die Speicher-E/A über das Netzwerk erweitert wird. Wenn ein Ausfall eines Quellstandorts auftritt, können Anwendungen auf den Remotestandort umschalten und ihre Vorgänge mit der Sicherheit fortsetzen, dass kein Datenverlust eintritt.

Modus	Diagramm	Schritte
Synchron Null Datenverlust RPO		1. Die Anwendung schreibt Daten. 2. Protokolldaten werden geschrieben, und die Daten werden an den Remotestandort repliziert. 3. Protokolldaten werden am Remotestandort geschrieben. Es wurde eine Empfangsbestätigung vom Remotestandort erhalten. 5. Anwendungsschreibvorgang wird bestätigt. t & t1: Daten werden auf das Volume geleert, Protokolle werden immer geschrieben.

Asynchrone Replikation

Die asynchrone Replikation bedeutet, dass die Daten, wenn die Anwendung Daten schreibt, ohne sofortige Bestätigungsgarantien auf den Remotestandort repliziert werden. Dieser Modus ermöglicht eine schnellere Reaktionszeit auf die Anwendung und eine Notfallwiederherstellungslösung, die geografisch funktioniert.

Wenn die Anwendung Daten schreibt, erfasst das Replikationsmodul den Schreibvorgang und erkennt ihn sofort an der Anwendung an. Die erfassten Daten werden dann am Remotestandort repliziert. Der Remoteknoten verarbeitet die Kopie der Daten und bestätigt den Empfang mit einer gewissen Verzögerung gegenüber der Quellkopie. Da sich die Replikationsleistung nicht mehr im E/A-Pfad der Anwendung befindet, 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 Puffermodus war, ohne die Quelle zu verlassen.

Die asynchrone Replikation mit einem RPO von mehr als null ist weniger geeignet für Hochverfügbarkeitslösungen wie Failovercluster, da sie für den kontinuierlichen Betrieb mit Redundanz und ohne Datenverlust ausgelegt ist.

Modus	Diagramm	Schritte
Asynchron Praktisch keinerlei Datenverlust (von verschiedenen Faktoren abhängig) RPO		1. Die Anwendung schreibt Daten. 2. Protokolldaten werden geschrieben. 3. Anwendungsschreibvorgang wird bestätigt. 4. Daten werden an den Remotestandort repliziert. 5. Protokolldaten werden am Remotestandort geschrieben. 6. Bestätigung wird vom Remotestandort empfangen. t & t1: Daten werden auf das Volume geleert, Protokolle werden immer geschrieben.

Wichtige Evaluierungsaspekte und Verhaltensweisen

• Netzwerkbandbreite und Latenz bei Speicher mit maximaler Geschwindigkeit. Es gibt physische Einschränkungen bei der synchronen Replikation. Da das Speicherreplikat einen E/A-Filtermechanismus mithilfe von Protokollen implementiert und Netzwerk-Roundtrips erfordert, führt die synchrone Replikation wahrscheinlich zu langsameren Anwendungsschreibvorgängen. Durch die Verwendung von Netzwerken mit geringer Latenz, Netzwerk mit hoher Bandbreite und Datenträgersubsystemen mit hohem Durchsatz für die Protokolle minimieren Sie den Leistungsaufwand.

• Auf das Zielvolume kann während der Replikation 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 Laufwerkbuchstaben ist möglicherweise in allgemeinen Benutzeroberflächen wie dem Datei-Explorer sichtbar, aber eine Anwendung kann nicht tatsächlich auf das Volume zugreifen. Replikationstechnologien auf Blockebene lassen keinen Zugriff auf das bereitgestellte Dateisystem eines Volumes auf dem Ziel zu. New Technology File System (NTFS) und Resilient File System (ReFS) ermöglichen es den Benutzern nicht, Daten auf das Volume zu schreiben, während sich die Blöcke darunter ändern.

  Das Test-Failover Cmdlet wurde in Windows Server, Version 1709, debütiert und war auch in Windows Server 2019 enthalten. Das Cmdlet unterstützt jetzt die vorübergehende Einbindung einer beschreibbaren Momentaufnahme des Zielvolumes für Sicherungen, Tests usw. Weitere Informationen finden Sie in den FAQ zu Storage Replica.

• 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. Speicherreplikat verfügt theoretisch über ein niedrigeres RPO, da es kontinuierlich repliziert wird. Es bedeutet jedoch auch, dass es auf internen Anwendungskonsistenzgarantien basiert, anstatt Momentaufnahmen zu verwenden, um die Konsistenz in Anwendungsdateien zu erzwingen. Das Speicherreplikat stellt bei einem Absturz in sämtlichen Replikationsmodi Konsistenz sicher.

• Viele Kunden verwenden DFS-Replikation als Notfallwiederherstellungslösung, obwohl sie für dieses Szenario häufig unpraktisch ist. Die DFS-Replikation kann keine geöffneten Dateien replizieren und ist so konzipiert, dass die Bandbreitennutzung auf Kosten der Leistung minimiert wird, was zu großen Wiederherstellungspunktdelta führt. Das Speicherreplikat bietet Ihnen die Möglichkeit, die DFS-Replikation gegebenenfalls nicht länger für einige dieser Notfallwiederherstellungsvorgänge einzusetzen.

• Ein Speicherreplikat ist sind keine Sicherungslösung. In einigen IT-Umgebungen werden Replikationssysteme als Sicherungslösungen bereitgestellt, da sie im Vergleich zu täglichen Sicherungen keine Datenverlustoptionen haben. 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 Zeitpunktsicherungslösung.

• Das Speicherreplikatfeature darf nicht mit Hyper-V-Replikaten oder SQL Server AlwaysOn-Verfügbarkeitsgruppen verwechselt werden. Das Speicherreplikatfeature ist eine allgemeine speicheragnostische Engine. Sein Verhalten kann nicht so optimal angepasst werden wie bei der Replikation auf Anwendungsebene. Der Entwurf und Zweck des Speicherreplikats kann zu bestimmten Featurelücken führen, die Sie ermutigen, bestimmte Anwendungsreplikationstechnologien bereitzustellen oder weiterhin zu verwenden.

Terminologie im Zusammenhang mit Speicherreplikaten

In Artikeln über Speicherreplikate werden häufig die folgenden Begriffe verwendet:

• Die Quelle ist ein Computervolume, das lokale Schreibvorgänge zulässt und ausgehend repliziert. Auch als primär bezeichnet.

• Das Ziel ist das Volume eines Computers, das keine lokalen Schreibvorgänge ermöglicht und eine eingehende Replikation durchführt. Auch als sekundär bezeichnet.

• Eine Replikationspartnerschaft ist die Synchronisierungsbeziehung zwischen einem Quell- und Zielcomputer für ein oder mehrere Volumes und verwendet ein einzelnes Protokoll.

• 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 enthalten.

Verwandte Inhalte

• Replikation eines Stretched Clusters mithilfe von freigegebenem Speicher
• Server-zu-Server-Speicherreplikation
• Cluster-zu-Cluster-Speicherreplikation
• Speicherreplikate: Bekannte Probleme
• Speicherreplikat: Häufig gestellte Fragen (FAQ)
• Direkte Speicherplätze
• Windows IT Pro-Support