Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Sie können Speicherreplikate in Windows Server verwenden, um Volumes zwischen Servern oder Clustern für die Notfallwiederherstellung zu replizieren. Sie können es auch verwenden, um Stretch-Failovercluster zu erstellen, die sich über zwei Standorte erstrecken, und alle Knoten bleiben synchron.
Das Speicherreplikat unterstützt sowohl die synchrone als auch die asynchrone Replikation.
- Synchronous replication mirrors data within a low-latency network site with crash-consistent volumes to ensure zero data loss at the file system level during a failure.
- Asynchronous replication mirrors data across sites beyond metropolitan ranges over network links with higher latencies, but without a guarantee that both sites have identical copies of the data at the time of a potential failure.
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. The same applies before a disaster. 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.
Supported configurations
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-to-cluster replication
In cluster-to-cluster replication, one cluster synchronously or asynchronously replicates with another cluster.
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-to-server replication
Server-to-server replication is synchronous and asynchronous replication between two standalone servers.
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:
Note
Sie können auch die Server-zu-Self-Replikation konfigurieren, indem Sie vier separate Volumes auf einem Computer verwenden. In diesem Artikel wird dieses Szenario jedoch nicht behandelt.
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.
SMB 3-based. 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.
Security. 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.
Consistency groups. Die Schreibsortierung garantiert, dass Anwendungen wie SQL Server in mehrere replizierte Volumes schreiben können und die Daten sequenziell auf dem Zielserver geschrieben werden.
User delegation. 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.
Network constraint. 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.
Compression. Speicherreplikat bietet Komprimierung für Daten, die über das Netzwerk zwischen den Quell- und Zielservern übertragen werden. The Storage Replica Compression for Data Transfer feature is supported only in Windows Server Datacenter: Azure Edition beginning with OS build 20348.1070 and later (KB5017381).
Speicherreplikate enthalten die folgenden Features:
| Feature | Details |
|---|---|
| Type | Host-based |
| Synchronous | Yes |
| Asynchronous | Yes |
| Storage hardware-agnostic | Yes |
| Replication unit | Volume (Partition) |
| Erstellung eines Stretched Clusters mit Windows Server | Yes |
| Server-zu-Server-Replikation | Yes |
| Cluster-zu Cluster-Replikation | Yes |
| Transport | SMB3 |
| Network | TCP/IP oder RDMA |
| Unterstützung für die Netzwerkeinschränkung | Yes |
| Network compression | Yes** |
| RDMA* | iWARP, InfiniBand, RoCE v2 |
| Netzwerkport-Firewallanforderungen für die Replikation | Einzelner IANA-Port (TCP 445 oder 5445) |
| Multipath/Multichannel | Ja (SMB 3) |
| Kerberos support | Ja (SMB 3) |
| Verschlüsselung und Signatur über das Netzwerk | Ja (SMB 3) |
| Volumebasiertes Failover zulässig | Yes |
| Unterstützung für die schlanke Speicherzuweisung | Yes |
| Integrierte Verwaltungsbenutzeroberfläche | PowerShell, Failovercluster-Manager |
* 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.
- Das Speicherreplikat repliziert ein einzelnes Volume anstelle einer unbegrenzten Anzahl von Volumes.
- Volumes können eine Größe von bis zu 2 TB anstelle einer unbegrenzten Größe aufweisen.
Background
Dieser Abschnitt enthält Informationen zu allgemeinen Begriffen aus der Branche, synchroner und asynchroner Replikation und zu Schlüsselverhalten.
Allgemeine Begriffe aus der Branche
Disaster recovery refers to a contingency plan for recovering from site catastrophes so that the business continues to operate. 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 (Service Level Agreements, SLAs) definieren die Verfügbarkeit von Anwendungen einer Organisation und deren Toleranz gegenüber Ausfallzeiten und Datenverlusten während geplanter und ungeplanter Ausfälle. 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.
Synchronous replication
Synchronous replication guarantees that the application writes data to two locations at once before it completes the I/O operation. 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.
| Mode | Diagram | Steps |
|---|---|---|
|
Synchronous 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 |
Asynchronous replication
Asynchronous replication means that when the application writes data, the data replicates to the remote site without immediate acknowledgment guarantees. 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.
| Mode | Diagram | Steps |
|---|---|---|
|
Asynchronous 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. Die Laufwerkbuchstaben werden möglicherweise auf typischen Benutzeroberflächen wie dem Datei-Explorer angezeigt, aber eine Anwendung kann nicht 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-FailoverCmdlet 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.
Note
You can view a list of known issues and expected behaviors and review the Storage Replica FAQ.
Terminologie im Zusammenhang mit Speicherreplikaten
In Artikeln über Speicherreplikate werden häufig die folgenden Begriffe verwendet:
The source is a computer's volume that allows local writes and replicates outbound. Also known as primary.
The destination is a computer's volume that doesn't allow local writes and replicates inbound. Also known as secondary.
A replication partnership is the synchronization relationship between a source and destination computer for one or more volumes and uses a single log.
A replication group is the organization of volumes and their replication configuration within a partnership, on a per-server basis. Eine Gruppe kann ein oder mehrere Volumes enthalten.
Neuigkeiten für Speicherreplikate
Eine Liste der neuen Features im Speicherreplikat in Windows Server 2019 finden Sie unter Neuigkeiten im Speicher.