Häufig gestellte Fragen zu Speicherreplikaten

Ja. Sie können die folgenden Szenarien mit Azure verwenden:

• Server-zu-Server-Replikation in Azure (synchron oder asynchron zwischen IaaS-VMs in einer oder zwei Rechenzentrums-Fehlerdomänen oder asynchron zwischen zwei separaten Regionen)
• Asynchrone Server-zu-Server-Replikation zwischen Azure und der lokalen Umgebung (per VPN oder Azure ExpressRoute)
• Cluster-zu-Cluster-Replikation in Azure (synchron oder asynchron zwischen IaaS-VMs in einer oder zwei Rechenzentrums-Fehlerdomänen oder asynchron zwischen zwei separaten Regionen)
• Asynchrone Cluster-zu-Cluster-Replikation zwischen Azure und der lokalen Umgebung (per VPN oder Azure ExpressRoute)
• Stretch Database-Clustering mit freigegebenen Azure-Datenträgern (synchron oder asynchron zwischen IaaS-VMs in einer oder zwei Rechenzentrums-Fehlerdomänen oder asynchron zwischen zwei separaten Regionen)

Weitere Hinweise zum Gastclustering in Azure finden Sie unter Deploying IaaS VM Guest Clusters in Microsoft Azure (Bereitstellen von IaaS-VM-Gastclustern in Microsoft Azure).

Wichtige Hinweise:

• Unter Create a Storage Spaces Direct (S2D) SOFS Clusters with Storage Replica for Disaster Recovery across Azure Regions (Erstellen eines Direkte Speicherplätze-SOFS-Clusters mit Speicherreplikat für die Azure-Regionen übergreifende Notfallwiederherstellung) finden Sie Azure Resource Manager-Vorlagen für Speicherreplikatclustering auf Basis von „Direkte Speicherplätze“.
• Für die RPC-Kommunikation zwischen Clustern in Azure (für die Cluster-APIs zum Gewähren des Zugriffs zwischen Clustern erforderlich) ist die Konfiguration des Netzwerkzugriffs für das CNO erforderlich. Sie müssen TCP-Port 135 und den dynamischen Bereich über TCP-Port 49152 zulassen. Weitere Informationen finden Sie unter Building Windows Server Failover Cluster on Azure IAAS VM – Part 2 (Network and Creation) (Erstellen von Windows Server-Failoverclustern auf Azure IAAS-VM – Teil 2 (Netzwerk und Erstellung)).
• Es ist möglich, Gastcluster mit zwei Knoten zu verwenden, wobei jeder Knoten Loopback-iSCSI für einen asymmetrischen Cluster verwendet, der vom Speicherreplikat repliziert wird. Dies ist jedoch wahrscheinlich mit einer sehr schlechten Leistung verbunden und sollte nur für sehr eingeschränkte Workloads oder Tests verwendet werden.

Die auf dem Zielserver im Ereignisprotokoll für die Speicherreplikatverwaltung angezeigte Ereignismeldung 1237 zeigt alle 10 Sekunden die Anzahl der kopierten Bytes sowie die Anzahl von verbleibenden Bytes an. Sie können auch den Speicherreplikat-Leistungsindikator auf dem Ziel verwenden, der \Speicherreplikatstatistik\Gesamtzahl empfangener Bytes für mindestens ein repliziertes Volume anzeigt. Die Replikationsgruppe kann auch mithilfe von Windows PowerShell abgefragt werden. Beispielsweise ruft dieser Beispielbefehl den Namen der Gruppen am Ziel ab und fragt dann alle 10 Sekunden eine Gruppe mit dem Namen Replikation 2 ab, um den Fortschritt anzuzeigen:

Get-SRGroup

do{
    $r=(Get-SRGroup -Name "Replication 2").replicas
    [System.Console]::Write("Number of remaining bytes {0}`n", $r.NumOfBytesRemaining)
    Start-Sleep 10
}until($r.ReplicationStatus -eq 'ContinuouslyReplicating')
Write-Output "Replica Status: "$r.replicationstatus

Ja, mithilfe von Set-SRNetworkConstraint. Dieses Cmdlet wird auf Schnittstellenebene ausgeführt und kann sowohl in Clusterszenarios als auch in Szenarios ohne Cluster verwendet werden. Beispiel mit einem eigenständigen Server (auf jedem Knoten):

Get-SRPartnership

Get-NetIPConfiguration

Beachten Sie die Informationen zu Gateway und Schnittstelle (auf beiden Servern) sowie die Richtungen der Partnerschaften. Führen Sie dann Folgendes aus:

Set-SRNetworkConstraint -SourceComputerName sr-srv06 -SourceRGName rg02 -
SourceNWInterface 2 -DestinationComputerName sr-srv05 -DestinationNWInterface 3 -DestinationRGName rg01

Get-SRNetworkConstraint

Update-SmbMultichannelConnection

So konfigurieren Sie Netzwerkeinschränkungen auf einem Stretched Cluster:

Set-SRNetworkConstraint -SourceComputerName sr-cluster01 -SourceRGName group1 -SourceNWInterface "Cluster Network 1","Cluster Network 2" -DestinationComputerName sr-cluster02 -DestinationRGName group2 -DestinationNWInterface "Cluster Network 1","Cluster Network 2"

Nein, Speicherreplikate unterstützen lediglich die 1:1-Replikation von Servern, Clustern oder Stretched Cluster-Knoten. In einem späteren Release kann sich dies ändern. Sie können natürlich eine Replikation zwischen verschiedenen Servern eines bestimmten Volume-Paars in beide Richtungen konfigurieren. Beispielsweise kann Server 1 sein D-Volume an Server 2, und sein E-Volume von Server 3 replizieren.

Sie können Volumes vergrößern (erweitern), aber nicht verkleinern. Speicherreplikate verhindern standardmäßig, dass Administratoren replizierte Volumes erweitern. Verwenden Sie die Option Set-SRGroup -AllowVolumeResize $TRUE in der Quellgruppe vor dem Ändern der Größe. Zum Beispiel:

1. Verwenden für den Quellcomputer: Set-SRGroup -Name YourRG -AllowVolumeResize $TRUE
2. Vergrößern des Volumes mithilfe Ihres bevorzugten Verfahrens
3. Verwenden für den Quellcomputer: Set-SRGroup -Name YourRG -AllowVolumeResize $FALSE

Nicht in Windows Server 2016. Das Speicherreplikat hebt die Bereitstellung des Zielvolumes bei Beginn der Replikation auf.

In Windows Server 2019 und Windows Server (Halbjährlicher Kanal) ist jedoch ab Version 1709 die Option zum Einbinden des Zielspeichers enthalten. Diese Funktion wird als „Testfailover“ bezeichnet. Dazu benötigen Sie ein nicht verwendetes NTFS- oder ReFS-formatiertes Volume, das derzeit nicht auf dem Zielserver repliziert wird. Sie können dann eine Momentaufnahme des replizierten Speichers vorübergehend zu Test- und Sicherungszwecken bereitstellen.

Geben Sie beispielsweise Folgendes ein, um ein Testfailover zu erstellen, in dem Sie ein Volume „D:“ in der Replikationsgruppe „RG2“ auf dem Zielserver „SRV2“ replizieren und ein Laufwerk „T:“ auf SRV2 haben, das nicht repliziert wird:

Mount-SRDestination -Name RG2 -Computername SRV2 -TemporaryPath T:\

Das replizierte Volume „D:“ ist jetzt auf SRV2 verfügbar. Sie haben darauf ganz normalen Schreib- und Lesezugriff, können Dateien daraus kopieren, oder eine Onlinesicherung durchführen, die Sie an einer anderen Stelle unter dem Pfad „D:“ zur sicheren Verwahrung speichern. Das Volume „T:“ enthält nur Protokolldaten.

So entfernen Sie die Testfailover-Momentaufnahme und verwerfen die Änderungen:

Dismount-SRDestination -Name RG2 -Computername SRV2

Sie sollten die Testfailoverfunktion nur für kurzfristige temporäre Vorgänge verwenden. Sie ist nicht für die langfristige Verwendung vorgesehen. Bei der Durchführung wird die Replikation zum tatsächlichen Zielvolume fortgesetzt.

Obwohl es technisch möglich ist, wird von dieser Konfiguration abgeraten. Der Grund dafür sind die fehlenden Standortinformationen in den Computeknoten, die SOFS kontaktieren. Bei Verwendung von Campusnetzwerken, in denen Wartezeiten typischerweise im Bereich unter Millisekunden liegen, funktioniert diese Konfiguration normalerweise ohne Probleme.

Bei der Konfiguration einer Cluster-zu-Cluster-Replikation bietet das Speicherreplikatfeature bei der Replikation zwischen zwei Clustern volle Unterstützung für Dateiserver mit horizontaler Skalierung (einschließlich Verwendung von direkten Speicherplätzen).

Nein. Sie können die Replikation mit CSV oder einer Reservierung persistenter Datenträger (Persistent Disk Reservation, PDR) durchführen, die sich im Besitz einer Clusterressource befindet, z. B. einer Dateiserverrolle.

Bei der Konfiguration einer Cluster-zu-Cluster-Replikation bietet das Speicherreplikatfeature bei der Replikation zwischen zwei Clustern volle Unterstützung für Dateiserver mit horizontaler Skalierung (einschließlich Verwendung von direkten Speicherplätzen).

Diese Konfiguration wird in Windows Server nicht unterstützt. In einem späteren Release kann sich dies ändern. Bei der Konfiguration einer Cluster-zu-Cluster-Replikation bietet das Speicherreplikatfeature volle Unterstützung für Dateiserver mit horizontaler Skalierung und Hyper-V-Server (einschließlich Verwendung von direkten Speicherplätzen).

Geben Sie New-SRPartnership -ReplicationMode und das Argument Asynchronous an. Standardmäßig wird jede Replikation im Speicherreplikatfeature synchron ausgeführt. Sie können den Modus auch mit Set-SRPartnership -ReplicationMode ändern.

Um ein automatisches Failover zu verhindern, können Sie Get-ClusterNode -Name "NodeName").NodeWeight=0 mithilfe von PowerShell konfigurieren. Dadurch wird die Abstimmung auf den einzelnen Knoten am Notfallwiederherstellungsstandort entfernt. Anschließend können Sie Start-ClusterNode -PreventQuorum auf Knoten am primären Standort und Start-ClusterNode -ForceQuorum auf Knoten am Notfallstandort verwenden, um ein Failover zu erzwingen. Es ist keine grafische Option verfügbar, um ein automatisches Failover zu verhindern, und das Verhindern des automatischen Failovers wird nicht empfohlen.

Um die Ausführung des neuen Hyper-V-VM-Resilienzfeatures zu verhindern und virtuelle Computer anzuhalten, anstatt ein Failover auf den Notfallwiederherstellungs-Standort durchzuführen, führen Sie (Get-Cluster).ResiliencyDefaultPeriod=0 aus.

Eine Möglichkeit, die Dauer der ersten Synchronisierung zu verkürzen, bietet die schlanke Speicherzuweisung. Das Speicherreplikatfeature führt eine Abfrage nach Speicher mit schlanker Zuweisung durch und verwendet diesen Speicher automatisch (einschließlich nicht gruppierter Speicherplätze, dynamischer Hyper-V-Datenträger und SAN-LUNs). Sobald die erste Replikation initiiert wurde, kann das Volume nicht mehr verkleinern oder verkleinern.

Um die Bandbreitennutzung und manchmal die Zeit zu verringern, können Sie auch Datenvolumes verwenden, für die ein Seeding durchgeführt wurde, indem Sie sicherstellen, dass das Zielvolume über eine Untermenge an Daten des primären Standorts verfügt. Anschließend verwenden Sie die Option für ein ausgeführtes Seeding im Failovercluster-Manager oder New-SRPartnership. Wenn das Volume überwiegend leer ist, kann mit einer Seeding-Synchronisierung die Nutzung von Zeit und Bandbreite reduziert werden. Es gibt mehrere Möglichkeiten zum Seeding von Daten mit unterschiedlichen Effizienzgraden:

• Vorherige Replikation: Durch lokale Replikation mit normaler Erstsynchronisierung zwischen Knoten, die die Datenträger und Volumes enthalten, Entfernen der Replikation, Versenden der Zieldatenträger an einen anderen Ort und Hinzufügen der Replikation mit der Option für ein ausgeführtes Seeding. Diese Methode ist am effektivsten, da das Speicherreplikat eine Blockkopierspiegelung garantiert, und das einzige, was repliziert werden muss, sind Deltablöcke.
• Wiederhergestellte Momentaufnahme oder wiederhergestellte momentaufnahmenbasierte Sicherung: Durch Wiederherstellen einer volumebasierten Momentaufnahme auf dem Zielvolume sollten minimale Unterschiede im Blocklayout bestehen. Dies ist die nächsteffektivste Methode, da Blöcke wahrscheinlich übereinstimmen, da Volumemomentaufnahmen Spiegelbilder sind.
• Kopierte Dateien: Wenn Sie ein neues Volume auf dem Ziel erstellen, das noch nie zuvor verwendet wurde, und eine vollständige Robocopy-/MIR-Strukturkopie der Daten ausführen, gibt es wahrscheinlich Blockübereinstimmungen. Wenn Sie den Windows-Datei-Explorer verwenden oder einen Teil der Struktur kopieren, werden nicht viele Blockübereinstimmungen erstellt. Das manuelle Kopieren von Dateien ist die uneffektivste Seedingmethode.

Sie können das Grant-SRDelegation-Cmdlet verwenden. Mit diesem Cmdlet können Sie bestimmte Benutzer in Server-zu-Server-, Cluster-zu-Cluster- und Stretched Cluster-Replikationsszenarien festlegen, die über die Berechtigungen zum Erstellen, Ändern oder Entfernen der Replikation verfügen, ohne Mitglied der lokalen Administratorengruppe zu sein. Zum Beispiel:

Grant-SRDelegation -UserName contso\tonywang

Das Cmdlet weist Sie darauf hin, dass der Benutzer sich beim zu verwaltenden Server ab- und erneut anmelden muss, damit die Änderungen wirksam werden. Diese Konfiguration kann mithilfe von Get-SRDelegation und Revoke-SRDelegation weiter gesteuert werden.

Das Speicherreplikatfeature unterstützt das Sichern und Wiederherstellen des Quellvolumes. Es bietet außerdem Unterstützung für das Erstellen und Wiederherstellen von Momentaufnahmen des Quellvolumes. Sie können das Zielvolume nicht sichern oder wiederherstellen, während es durch das Speicherreplikat geschützt ist, da es weder eingebunden noch zugänglich ist. Wenn ein Notfall auftreten, bei dem das Quellvolume verloren geht, Set-SRPartnership können Sie das vorherige Zielvolume als lese-/beschreibbare Quelle heraufstufen, um dieses Volume zu sichern oder wiederherzustellen. Sie können die Replikation auch mit Remove-SRPartnership und Remove-SRGroup entfernen, um das Volume als lesbares und beschreibbares Volume erneut bereitzustellen.

Für eine regelmäßige Erstellung von anwendungskonsistenten Momentaufnahmen können Sie VSSADMIN.EXE auf dem Quellserver ausführen, um Momentaufnahmen der replizierten Datenvolumes zu erstellen. Beispiel für die Replikation des Volumes F: mit dem Speicherreplikatfeature:

vssadmin create shadow /for=F:

Anschließend können Sie eine beliebige Momentaufnahme wiederherstellen, nachdem Sie die Replikationsrichtung geändert oder die Replikation entfernt haben bzw. wenn Sie weiterhin dasselbe Quellvolume verwenden. Beispiel, wenn Sie weiterhin F: verwenden:

vssadmin list shadows
vssadmin revert shadow /shadow={shadown copy ID GUID listed previously}

Mithilfe eines geplanten Tasks können Sie auch die regelmäßige Ausführung dieses Tools planen. Weitere Informationen zur Verwendung von VSS finden Sie unter Vssadmin. Das Sichern der Protokollvolumes ist nicht notwendig oder sinnvoll. Der Versuch, diesen Vorgang auszuführen, wird von VSS ignoriert.

Das Speicherreplikatfeature unterstützt die Verwendung von Windows Server-Sicherung, Microsoft Azure Backup, Microsoft DPM oder anderen Momentaufnahme-, VSS-, VM- oder dateibasierten Technologien, sofern diese auf Volume-Ebene eingesetzt werden. Das Speicherreplikatfeature bietet keine Unterstützung für blockbasierte Sicherungen und Wiederherstellungen.

Speicherreplikate verwenden SMB und WSMAN für die Replikation und Verwaltung. Dies bedeutet, dass die folgenden Ports erforderlich sind:

• 445 (SMB – Replikationstransportprotokoll, RPC-Verwaltungsprotokoll des Clusters)
• 5445 (iWARP SMB – nur bei Verwendung von iWARP RDMA-Netzwerken erforderlich)
• 5985 (WSManHTTP – Verwaltungsprotokoll für WMI/CIM/PowerShell)

Die optimale Größe des Ereignisprotokolls variiert je nach Umgebung und Workload und wird dadurch bestimmt, wie viel Schreib-E/A-Workload ausgeführt wird.

• Ein kleineres oder größeres Protokoll bestimmt nicht die Schnelligkeit.
• Ein kleineres oder größeres Protokoll wirkt sich beispielsweise nicht auf das Datenvolume von 10 GB im Gegensatz zu 10 TB aus.

Ein größeres Protokoll sammelt nur mehr Schreib-E/A-Vorgänge und behält sie bei, bevor sie ausgeschlossen werden. Deshalb kann eine Unterbrechung des Diensts zwischen dem Quell- und Zielcomputer länger dauern, z. B. ein Netzwerkausfall oder wenn der Zielcomputer offline ist. Wenn das Protokoll 10 Stunden an Schreibvorgängen enthalten kann, und das Netzwerk für 2 Stunden ausfällt, kann der Quellcomputer nach erneutem Verbinden mit dem Netzwerk einfach das Delta der nicht synchronisierten Änderungen schnell zum Ziel zurückgeben, und Sie sind erneut sehr schnell geschützt. Wenn das Protokoll 10 Stunden enthält und der Ausfall 2 Tage beträgt, muss der Quellcomputer Daten aus einem anderen Protokoll zurückgeben, das Bitmap genannt wird – was wahrscheinlich langsamer ist, um zum Synchronisieren zurückzukehren. Wenn die Synchronisierung abgeschlossen ist, wird das Protokoll erneut verwendet.

Speicherreplikate nutzen das Protokoll für die gesamte Schreibleistung. Die Protokollleistung ist für die Replikationsleistung von entscheidender Bedeutung. Sie müssen sicherstellen, dass die Leistung des Protokollvolumens besser als die des Datenvolumens ist, da das Protokoll alle Schreib-E/A-Lasten serialisiert und sequenzialisiert. Sie sollten auf Protokollvolumes immer Flashmedien wie SSD verwenden. Sie dürfen niemals zulassen, dass andere Workloads auf dem Protokollvolume ausgeführt werden, so wie Sie auch niemals zulassen würden, dass andere Workloads auf SQL-Datenbank-Protokollvolumes ausgeführt werden.

Noch einmal: Microsoft empfiehlt dringend, dass die Protokollspeicherung schneller als die Datenspeicherung durchgeführt wird, und dass die Protokollvolumes nie für andere Workloads verwendet werden.

Um Empfehlungen zur Protokolldimensionierung zu erhalten, können Sie das Tool Test-SRTopology ausführen. Alternativ können Sie Leistungsindikatoren auf vorhandenen Servern verwenden, um eine Protokollgröße zu beurteilen. Die Formel ist einfach: Überwachen Sie den Datenträgerdurchsatz (durchschnittliche Schreibbytes/Sek.) unter der Workload, und berechnen Sie damit die Zeit, die zum Auffüllen des Protokolls in unterschiedlicher Größe benötigt wird. Beispielsweise erfasst ein 120 GB-Protokoll bei einem Datenträgerdurchsatz von 50 MB/s 120 GB/50 MB Sekunden, d. h. 2.400 Sekunden oder 40 Minuten. Die Zeitspanne, für die der Zielserver nicht erreichbar sein könnte, bevor das Protokoll geschlossen wird, beträgt also 40 Minuten. Wenn das Protokoll geschlossen wird, aber das Ziel wieder erreichbar ist, gibt die Quelle Blöcke über das Bitmapprotokoll anstelle des Hauptprotokolls wieder. Die Größe des Protokolls wirkt sich nicht auf die Leistung aus.

NUR der Datenträger aus dem Quellcluster sollte gesichert werden. Die Speicherreplikatprotokoll-Datenträger sollten NICHT gesichert werden, da eine Sicherung mit Speicherreplikatvorgängen in Konflikt geraten kann.

Speicherreplikate sind in drei Hauptkonfigurationen verfügbar: Stretched Cluster, Cluster-zu-Cluster und Server-zu-Server. Jede bietet verschiedene Vorteile.

Die Stretched Cluster-Topologie ist ideal für Workloads, die automatisches Failover mit Orchestrierung wie z. B. private Hyper-V-Cloud-Cluster und SQL Server-Failoverclusterinstanzen erfordern. Sie verfügt außerdem über eine integrierte Benutzeroberfläche, die den Failovercluster-Manager verwendet. Sie verwendet die klassische asymmetrische Speicherarchitektur mit gemeinsam genutzten Clustern von Speicherplätzen, SAN, iSCSI und RAID über persistente Reservierung. Sie können dies mit nur 2 Knoten ausführen.

Die Cluster-zu-Cluster-Topologie verwendet zwei separate Cluster und eignet sich besonders für Administratoren, die manuelles Failover wünschen, insbesondere, wenn der zweite Speicherort für die Notfallwiederherstellung und nicht die alltägliche Verwendung konfiguriert ist. Die Orchestrierung erfolgt manuell. Im Gegensatz zu Stretched Clustern können „Direkte Speicherplätze“ in dieser Konfiguration verwendet werden (mit Einschränkungen – siehe häufig gestellte Fragen zu Speicherreplikaten und Cluster-zu-Cluster-Dokumentation). Sie können dies mit nur 4 Knoten ausführen.

Die Server-zu-Server-Topologie ist ideal für Kunden mit Hardware, die nicht in Clustern gruppiert werden kann. Sie erfordert manuelles Failover und Orchestrierung. Sie ist ideal für kostengünstige Bereitstellungen zwischen Zweigstellen und zentralen Rechenzentren, insbesondere bei der Verwendung von asynchroner Replikation. Diese Konfiguration ersetzt häufig Instanzen von DFSR-geschützten Dateiservern, die für Single Master-Notfallwiederherstellungs-Szenarien verwendet werden.

In allen Fällen kann die Topologie sowohl auf physischer Hardware als auch auf virtuellen Computern ausgeführt werden. In virtuellen Computern erfordert der zugrunde liegende Hypervisor nicht Hyper-V und kann stattdessen VMware, KVM, Xen etc. verwenden.

Das Speicherreplikatfeature verfügt außerdem über einen Server-to-Self-Modus, in dem die Replikation auf zwei Volumes auf demselben Computer verweist.

Ja, die Datendeduplizierung wird mit Speicherreplikaten unterstützt. Aktivieren Sie die Datendeduplizierung auf einem Volume des Quellservers, und während der Replikation erhält der Zielserver eine deduplizierte Kopie des Volumes.

Sie sollten die Datendeduplizierung zwar sowohl auf dem Quell- als auch auf dem Zielserver installieren (siehe Installieren und Aktivieren der Datendeduplizierung), doch ist es wichtig, die Datendeduplizierung nicht auf dem Zielserver zu aktivieren. Das Speicherreplikat lässt Schreibvorgänge nur auf dem Quellserver zu. Da die Datendeduplizierung Schreibvorgänge auf dem Volume vornimmt, sollte sie nur auf dem Quellserver ausgeführt werden.

Leider wird das Erstellen einer neuen Partnerschaft zwischen Windows Server 2019 und Windows Server 2016 nicht unterstützt. Sie können ein sicheres Upgrade eines Servers oder Clusters unter Windows Server 2016 auf Windows Server 2019 durchführen, und alle vorhandenen Partnerschaften funktionieren weiterhin.

Um jedoch die verbesserte Replikationsleistung von Windows Server 2019 zu erzielen, müssen alle Mitglieder der Partnerschaft Windows Server 2019 ausführen, und Sie müssen vorhandene Partnerschaften und zugeordnete Replikationsgruppen löschen und sie dann mit Daten, für die ein Seeding durchgeführt wurde, neu erstellen (entweder beim Erstellen der Partnerschaft in Windows Admin Center oder mit dem Cmdlet New-SRPartnership).

Falls Sie technische Unterstützung für Speicherreplikate benötigen, können Sie Ihre Fragen in den Microsoft-Foren stellen. Sie können auch eine E-Mail srfeed@microsoft.com bei Fragen zum Speicherreplikat senden. Informationen zu Problemen mit dieser Dokumentation finden Sie im Abschnitt Feedback unten auf dieser Seite, und wählen Sie Diese Seite aus.

Das Speicherreplikat ist eine Technologie zur Replikation in einer Richtung. Es wird nur pro Volume von der Quelle zum Ziel repliziert. Diese Richtung kann jederzeit umgekehrt werden, aber es ist jeweils immer nur eine Richtung möglich. Dies bedeutet jedoch nicht, dass nicht eine Gruppe von Volumes (Quelle und Ziel) in eine Richtung repliziert und eine andere Gruppe von Laufwerken (Quelle und Ziel) in umgekehrter Richtung repliziert werden kann. Beispielsweise möchten Sie die Server-zu-Server-Replikation konfigurieren. Server1 und Server2 verfügen jeweils über die Laufwerkbuchstaben L:, M:, N: und O:, und Sie möchten Laufwerk M: von Server1 zu Server2, aber Laufwerk O: von Server2 zu Server1 replizieren. Dies kann erfolgen, solange für jede Gruppe separate Protokolllaufwerke vorhanden sind. Das heißt,

• Server1-Quelllaufwerk M: mit Quellprotokolllaufwerk L: replizierend zu Server2-Ziellaufwerk M: mit Zielprotokolllaufwerk L:
• Server2-Quelllaufwerk O: mit Quellprotokolllaufwerk N: replizierend zu Server1-Ziellaufwerk O: mit Zielprotokolllaufwerk N:

Das Speicherreplikat verhindert grundsätzlich die Versetzung von Clusterdatenträgern in den Wartungsmodus. Für Aufgaben wie das Aktivieren oder Deaktivieren von BitLocker müssen sich die Datenträger aber im Wartungsmodus befinden. Zum Durchführen von Aufgaben, die den Wartungsmodus für die Datenträger erfordern, muss die Partnerschaft zuerst aufgehoben und nach Abschluss des Vorgangs neu erstellt werden.

• Übersicht über Speicherreplikate
• Replikation eines Stretched Clusters mithilfe von freigegebenem Speicher
• Server-zu-Server-Speicherreplikation
• Cluster-zu-Cluster-Speicherreplikation
• Speicherreplikate: Bekannte Probleme

• Übersicht über das erweiterte Speichern
• Direkte Speicherplätze