Server-zu-Server-Speicherreplikation

Artikel
03/09/2023

Gilt für: Azure Stack HCI, Windows Server 2022, Windows Server 2019, Windows Server 2016

Mithilfe der Speicherreplikation können Sie zwei Server konfigurieren, um die Daten zu synchronisieren, sodass jeder Server über eine identische Kopie des gleichen Volumes verfügt. Dieses Thema enthält Hintergrundinformationen zu dieser Konfiguration einer Server-zu-Server-Replikation sowie zum Einrichten und Verwalten der Umgebung.

Zum Verwalten von Speicherreplikaten können Sie Windows Admin Center oder PowerShell verwenden.

In diesem Abschnitt finden Sie ein Übersichtsvideo zur Verwendung von Speicherreplikaten in Windows Admin Center.

Voraussetzungen

Active Directory Domain Services-Gesamtstruktur (diese Gesamtstruktur muss nicht auf Windows Server 2016 laufen).
Zwei Server mit Windows Server 2019 oder Windows Server 2016, Datacenter Edition. Wenn Sie Windows Server 2019 benutzen, können Sie stattdessen Standard Edition verwenden, falls Sie nur ein einzelnes Volume mit einer Größe von bis zu 2 TB replizieren möchten.
Zwei Speichergruppen, die SAS-JBODs, Fibre Channel-SANs, iSCSI-Ziele oder lokalen SCSI/SATA-Speicher verwenden. Der Speicher sollte eine Kombination aus HDD- und SSD-Medien umfassen. Die einzelnen Speichergruppen werden nur für jeweils einen Server bereitgestellt, ein gemeinsamer Zugriff wird nicht konfiguriert.
Jede Speichergruppe muss das Erstellen von mindestens zwei virtuellen Datenträgern ermöglichen, einen Datenträger für replizierte Daten und einen Datenträger für Protokolle. Der physische Speicher muss auf allen Datenträgern für Daten dieselben Sektorgrößen aufweisen. Der physische Speicher muss auf allen Datenträgern für Protokolle dieselben Sektorgrößen aufweisen.
Mindestens eine Ethernet/TCP-Verbindung auf jedem Server für die synchrone Replikation (vorzugsweise RDMA).
Geeignete Firewall- und Routerregeln, um bidirektionalen ICMP-Datenverkehr, SMB-Datenverkehr (Port 445 sowie 5445 für SMB Direct) und WS-MAN-Datenverkehr (Port 5985) zwischen allen Knoten zu ermöglichen.
Ein Netzwerk zwischen den Servern mit ausreichender Bandbreite für Ihre E/A-Schreibworkload sowie durchschnittlich 5 ms Roundtriplatenz für die synchrone Replikation. Für die asynchrone Replikation gelten keine Empfehlungen in Bezug auf die Latenz.
Wenn Sie zwischen lokalen Servern und Azure-VMs replizieren, müssen Sie eine Netzwerkverbindung zwischen den lokalen Servern und den Azure-VMs erstellen. Verwenden Sie dazu Express Route, eine Site-to-Site-VPN-Gatewayverbindung, oder installieren Sie VPN-Software auf Ihren Azure-VMs, um sie mit Ihrem lokalen Netzwerk zu verbinden.
Der replizierte Speicher darf sich nicht auf dem Laufwerk mit dem Ordner des Windows-Betriebssystems befinden.

Wichtig

In diesem Szenario sollte sich jeder Server an einem anderen physischen oder logischen Standort befinden. Die Server müssen über das Netzwerk miteinander kommunizieren können.

Viele dieser Voraussetzungen lassen sich mit dem Test-SRTopology cmdlet ermitteln. Sie erhalten Zugang zu diesem Tool, wenn Sie das Speicherreplikatfeature oder die Speicherreplikat-Verwaltungstools auf mindestens einem Server installieren. Das Speicherreplikatfeature muss nicht konfiguriert werden, um dieses Tool verwenden zu können. Es wird lediglich zur Installation des Cmdlets benötigt. Weitere Informationen finden Sie in den nachfolgend beschriebenen Schritten.

Anforderungen für Windows Admin Center

Sie benötigen Folgendes, um Speicherreplikate und Windows Admin Center zusammen zu verwenden:

System	Betriebssystem	Erforderlich für
Zwei Server (beliebige Mischung aus lokaler Hardware, VMs und Cloud-VMs, einschließlich Azure-VMs)	Windows Server 2019, Windows Server 2016, Windows Server (halbjährlicher Kanal)	Speicherreplikat
Ein PC	Windows 10	Windows Admin Center

Hinweis

Derzeit können Sie Speicherreplikate auf einem Server nicht mit Windows Admin Center verwalten.

Begriffe

Für diese exemplarische Vorgehensweise wird die folgende Beispielumgebung verwendet:

Zwei Server: SR-SRV05 und SR-SRV06
Ein Paar aus logischen „Standorten“, die für zwei unterschiedliche Rechenzentren stehen: Redmond und Bellevue.

Diagramm, das einen Server in Gebäude 5 zeigt, der mit einem Server in Gebäude 9 repliziert wird

Abbildung 1: Server-zu-Server-Replikation

Schritt 1: Installieren und Konfigurieren von Windows Admin Center auf Ihrem PC

Wenn Sie Windows Admin Center zum Verwalten von Speicherreplikaten verwenden, führen Sie die folgenden Schritte aus, um Ihren PC für die Verwaltung der Speicherreplikate vorzubereiten.

Laden Sie Windows Admin Center herunter, und installieren Sie das Programm.
Laden Sie die Remoteserver-Verwaltungstools, herunter und installieren Sie die Datei.
- Wenn Sie ein Windows 10, Version 1809 oder höher verwenden, installieren Sie über Features bei Bedarf das „RSAT: Speicherreplikatmodul für Windows PowerShell“.
Öffnen Sie eine PowerShell-Sitzung als Administrator, indem Sie auf die Schaltfläche Start klicken, PowerShell eingeben, mit der rechten Maustaste auf Windows PowerShell klicken, und dann Als Administrator ausführen auswählen.
Geben Sie den folgenden Befehl ein, um das WS-Managementprotokoll auf dem lokalen Computer zu aktivieren und die Standardkonfiguration für die Remoteverwaltung auf dem Client einzurichten.
```
winrm quickconfig
```
Geben Sie Y ein, um WinRM-Dienste zu aktivieren, und aktivieren Sie die WinRM-Firewallausnahme.

Schritt 2: Bereitstellen von Betriebssystem, Features, Rollen, Speicher und Netzwerk

Installieren Sie Windows Server auf beiden Serverknoten mit dem Installationstyp Windows Server (Desktopdarstellung) .

Informationen zur Verwendung einer Azure-VM, die über ExpressRoute mit Ihrem Netzwerk verbunden ist, finden Sie unter Hinzufügen einer Azure-VM, die über ExpressRoute mit Ihrem Netzwerk verbunden ist.

Hinweis

Ab Windows Admin Center Version 1910 können Sie automatisch einen Zielserver in Azure konfigurieren. Wenn Sie diese Option auswählen, installieren Sie Windows Server auf dem Quellserver, und fahren Sie dann mit Schritt 3: Einrichten der Server-zu-Server-Replikation fort.
Fügen Sie Netzwerkinformationen hinzu, fügen Sie die Server derselben Domäne wie Ihr Windows 10-Verwaltungs-PC hinzu (falls Sie einen verwenden), und starten Sie dann die Server neu.

Hinweis

Melden Sie sich anschließend stets als Domänenbenutzer an, der Mitglied der integrierten Administratorengruppe auf allen Servern ist. Denken Sie anschließend immer daran, erhöhte Rechte für Ihre PowerShell- und Eingabeaufforderungen festzulegen, wenn Sie die Features auf einer graphischen Serverinstallation oder auf einem Windows 10-Computer ausführen.
Verbinden Sie die erste Gruppe aus JBOD-Speicherserver, iSCSI-Ziel, FC-SAN- oder lokalem DAS-Speicher mit dem Server am Standort Redmond.
Verbinden Sie die zweite Speichergruppe mit dem Server am Standort Bellevue.
Installieren Sie gegebenenfalls aktuelle Speicher- und Gehäusefirmware, HBA-Treiber, BIOS/UEFI-Firmware, Netzwerktreiber und Hauptplatinenchipsatz-Treiber der jeweiligen Hersteller auf beiden Knoten. Starten Sie die Knoten gegebenenfalls neu.

Hinweis

Konfigurieren Sie die Hardware für freigegebenen Speicher und Netzwerk gemäß der Dokumentation des jeweiligen Herstellers.
Stellen Sie sicher, dass die BIOS/UEFI-Einstellungen für Server eine hohe Leistung ermöglichen (z.B. Deaktivieren des C-Status, Festlegen der QPI-Geschwindigkeit, Aktivieren von NUMA und Festlegen der höchsten Speicherfrequenz). Stellen Sie sicher, dass die Energieverwaltung in Windows Server auf Hohe Leistung festgelegt ist. Führen Sie bei Bedarf einen Neustart aus.
Konfigurieren Sie folgende Rollen:
- Windows Admin Center – Methode
  1. Navigieren Sie in Windows Admin Center zu Server-Manager, und wählen Sie dann einen der Server aus.
  2. Navigieren Sie zu Rollen/Features.
  3. Wählen Sie Features>Speicherreplikat aus, und klicken Sie dann auf Installieren.
  4. Wiederholen Sie dies auf dem anderen Server.
- Server-Manager – Methode
  1. Führen Sie ServerManager.exe aus, und erstellen Sie eine Servergruppe, der Sie alle Serverknoten hinzufügen.
  2. Installieren Sie die Rollen und Features Dateiserver und Speicherreplikat auf allen Knoten, und starten Sie die Knoten neu.
- Windows PowerShell – Methode
  
  Führen Sie auf SR-SRV06 oder einem Remoteverwaltungscomputer den folgenden Befehl in einer Windows PowerShell-Konsole aus, um die erforderlichen Features und Rollen zu installieren und den Knoten neu zu starten:
```
$Servers = 'SR-SRV05','SR-SRV06'

$Servers | ForEach { Install-WindowsFeature -ComputerName $_ -Name Storage-Replica,FS-FileServer -IncludeManagementTools -restart }
```
  Weitere Informationen zu diesen Schritten finden Sie unter Installieren oder Deinstallieren von Rollen, Rollendiensten oder Features.
Konfigurieren Sie den Speicher wie folgt:
Wichtig
- In jedem Speicherserver müssen zwei Volumes erstellt werden: ein Volume für Daten und ein Volume für Protokolle.
- Die Datenträger für Protokolle und Daten müssen als GPT (nicht MBR) initialisiert werden.
- Die beiden Datenvolumes müssen dieselbe Größe aufweisen.
- Die beiden Protokollvolumes sollten dieselbe Größe aufweisen.
- Alle Datenträger für replizierte Daten müssen dieselben Sektorgrößen aufweisen.
- Alle Datenträger für Protokolle müssen dieselben Sektorgrößen aufweisen.
- Die Protokollvolumes sollten Flash-basierten Speicher verwenden (z. B. SSD). Microsoft empfiehlt, dass die Protokollspeicherung schneller als die Datenspeicherung durchgeführt wird. Protokollvolumes dürfen niemals für andere Workloads verwendet werden.
- Die Datenträger für Daten können HDD, SSD oder eine mehrstufige Kombination verwenden. Außerdem kann gespiegelter Speicherplatz oder Paritätsspeicherplatz bzw. RAID 1, RAID 10, RAID 5 oder RAID 50 verwendet werden.
- Das Protokollvolume muss standardmäßig eine Größe von mindestens 9 GB aufweisen und kann basierend auf Protokollanforderungen möglicherweise größer oder kleiner sein.
- Die Rolle „Dateiserver“ ist nur für Test-SRTopology erforderlich, um die erforderlichen Firewallports für die Tests zu öffnen.
- Für JBOD-Gehäuse:
  1. Stellen Sie sicher, dass jedem Server nur die Speichergehäuse des jeweiligen Standorts angezeigt werden und die SAS-Verbindungen ordnungsgemäß konfiguriert sind.
  2. Stellen Sie den Speicher mithilfe von Speicherplätzen bereit. Führen Sie dazu die unter Bereitstellen von Speicherplätzen auf einem eigenständigen Server beschriebenen Schritte 1-3 mithilfe von Windows PowerShell oder über den Server-Manager aus.
- Für iSCSI-Speicher:
  1. Stellen Sie sicher, dass jedem Cluster nur die Speichergehäuse des jeweiligen Standorts angezeigt werden. Bei Verwendung von iSCSI sollten mehrere Netzwerkkarten verwendet werden.
  2. Befolgen Sie die Anweisungen in der Dokumentation des jeweiligen Herstellers, um den Speicher bereitzustellen. Bei Verwendung von Windows-basierten iSCSI-Zielen finden Sie unter iSCSI-Zielblockspeicher: So wird's gemacht weitere Informationen.
- Für FC-SAN-Speicher:
  1. Stellen Sie sicher, dass jedem Cluster nur die Speichergehäuse des jeweiligen Standorts angezeigt werden und die Zonen für die Hosts ordnungsgemäß festgelegt wurden.
  2. Befolgen Sie die Anweisungen in der Dokumentation des jeweiligen Herstellers, um den Speicher bereitzustellen.
- Für lokalen DAS-Speicher:
  - Stellen Sie sicher, dass der Speicher kein Systemvolume, keine Auslagerungsdatei und keine Abbilddateien enthält.
  - Befolgen Sie die Anweisungen in der Dokumentation des jeweiligen Herstellers, um den Speicher bereitzustellen.
Starten Sie Windows PowerShell, und überprüfen Sie mithilfe des Cmdlets Test-SRTopology, ob alle Anforderungen für das Speicherreplikatfeature erfüllt sind. Für einen schnellen Test können Sie das Cmdlet in einem Modus zur ausschließlichen Überprüfung der Anforderungen ausführen, oder Sie wählen einen Modus mit langer Ausführungsdauer, um die Leistung auszuwerten.

Beispiel: So überprüfen Sie, ob die Knoten jeweils über ein Volume F: und G: verfügen (die Ausführungszeit des Tests beträgt 30 Minuten):
```
MD c:\temp

Test-SRTopology -SourceComputerName SR-SRV05 -SourceVolumeName f: -SourceLogVolumeName g: -DestinationComputerName SR-SRV06 -DestinationVolumeName f: -DestinationLogVolumeName g: -DurationInMinutes 30 -ResultPath c:\temp
```
Wichtig

Bei Verwendung eines Testservers ohne Schreib-E/A-Last auf dem angegebenen Quellvolume während des Auswertungszeitraums sollten Sie gegebenenfalls eine Workload hinzufügen, um einen nützlichen Bericht zu erhalten. Um reale Zahlen und empfohlene Protokollgrößen zu erhalten, sollte der Test mit produktionsähnlichen Workloads ausgeführt werden. Alternativ können Sie ganz einfach während des Tests Dateien auf das Quellvolume kopieren oder DISKSPD herunterladen und ausführen, um Schreib-E/A zu generieren. Beispiel mit geringer E/A-Workload innerhalb eines Zeitraums von 5 Minuten auf dem Volume D:

Diskspd.exe -c1g -d600 -W5 -C5 -b8k -t2 -o2 -r -w5 -i100 -j100 d:\test
Stellen Sie anhand des Berichts TestSrTopologyReport.html in Abbildung 2 sicher, dass Sie die Anforderungen für das Speicherreplikatfeature erfüllen.

Abbildung 2: Bericht zur Speicherreplikationstopologie

Schritt 3: Einrichten der Server-zu-Server-Replikation

Verwenden von Windows Admin Center

Fügen Sie den Quellserver hinzu.
1. Wählen Sie die Schaltfläche Hinzufügen aus.
2. Wählen Sie Hinzufügen einer Serververbindung aus.
3. Geben Sie den Namen des Servers ein, und wählen Sie dann Übermitteln aus.
Wählen Sie auf der Seite Alle Verbindungen den Quellserver aus.
Wählen Sie im Bereich „Tools“ die Option Speicherreplikat aus.
Klicken Sie auf Neu, um eine neue Partnerschaft zu erstellen. So erstellen Sie eine neue Azure-VM, die als Ziel für die Partnerschaft verwendet werden soll:
1. Wählen Sie unter Mit einem anderen Server replizieren die Option Neue Azure-VM verwenden und dann Weiter aus. Wenn diese Option nicht verfügbar ist, stellen Sie sicher, dass Sie Windows Admin Center Version 1910 oder höher verwenden.
2. Geben Sie die Quellserverinformationen und den Namen der Replikationsgruppe an, und wählen Sie dann Weiter aus.
  
  Dadurch wird ein Prozess gestartet, bei dem automatisch eine Azure-VM mit Windows Server 2019 oder Windows Server 2016 als Ziel für die Migrationsquelle ausgewählt wird. Storage Migration Service empfiehlt VM-Größen passend zur Ihrer Quelle. Sie können diese Empfehlung jedoch übergehen, indem Sie Alle Größen anzeigen auswählen. Bestandsdaten werden verwendet, um Ihre verwalteten Datenträger und ihre Dateisysteme automatisch zu konfigurieren, und Ihre neue Azure-VM mit Ihrer Active Directory-Domäne zu verbinden.
3. Nachdem Windows Admin Center die Azure-VM erstellt hat, geben Sie einen Namen für die Replikationsgruppe an, und wählen Sie dann Erstellen aus. Windows Admin Center startet dann den normalen Speicherreplikat-Erstsynchronisierungsprozess, um mit dem Schutz Ihrer Daten zu beginnen.
Hier sehen Sie ein Video, das zeigt, wie Sie das Speicherreplikat für die Migration zu Azure-VMs verwenden.
Geben Sie die Details der Partnerschaft an, und wählen Sie dann Erstellen aus (siehe Abbildung 3).

Abbildung 3: Erstellen einer neuen Partnerschaft

Hinweis

Durch das Entfernen der Partnerschaft aus dem Speicherreplikat in Windows Admin Center wird der Name der Replikationsgruppe nicht entfernt.

Verwenden von Windows PowerShell

Als nächsten Schritt konfigurieren Sie die Server-zu-Server-Replikation mit Windows PowerShell. Die unten beschriebenen Schritte müssen unmittelbar auf den Knoten oder direkt über einen Remoteverwaltungscomputer ausgeführt werden, auf dem die Remoteverwaltungstools von Windows Server installiert sind.

Stellen Sie sicher, dass Sie eine erweiterte PowerShell-Konsole als Administrator verwenden.
Konfigurieren Sie die Server-zu-Server-Replikation, und geben Sie dabei die Quell- und Zieldatenträger, die Quell- und Zielprotokolle, die Quell- und Zielknoten sowie die Protokollgröße an.
```
New-SRPartnership -SourceComputerName sr-srv05 -SourceRGName rg01 -SourceVolumeName f: -SourceLogVolumeName g: -DestinationComputerName sr-srv06 -DestinationRGName rg02 -DestinationVolumeName f: -DestinationLogVolumeName g: -LogType Raw
```
Ausgabe:
```
DestinationComputerName : SR-SRV06
DestinationRGName       : rg02
SourceComputerName      : SR-SRV05
PSComputerName          :
```
Wichtig

Die standardmäßige Protokollgröße beträgt 8 GB. Abhängig von den Ergebnissen des Cmdlets Test-SRTopology können Sie -LogSizeInBytes mit einem höheren oder niedrigeren Wert verwenden.

Verwenden Sie Get-SRGroup und Get-SRPartnership wie folgt, um den Quell- und Zielzustand der Replikation abzurufen:

Get-SRGroup
Get-SRPartnership
(Get-SRGroup).replicas

Ausgabe:

CurrentLsn             : 0
DataVolume             : F:\
LastInSyncTime         :
LastKnownPrimaryLsn    : 1
LastOutOfSyncTime      :
NumOfBytesRecovered    : 37731958784
NumOfBytesRemaining    : 30851203072
PartitionId            : c3999f10-dbc9-4a8e-8f9c-dd2ee6ef3e9f
PartitionSize          : 68583161856
ReplicationMode        : synchronous
ReplicationStatus      : InitialBlockCopy
PSComputerName         :

Bestimmen Sie den Fortschritt der Replikation wie folgt:
1. Führen Sie auf dem Quellserver den folgenden Befehl aus, und überprüfen Sie die Ereignisse 5015, 5002, 5004, 1237, 5001 und 2200:
```
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica -max 20
```
2. Führen Sie auf dem Zielserver den folgenden Befehl aus, um die Speicherreplikatereignisse anzuzeigen, die das Erstellen der Partnerschaft belegen. Dieses Ereignis gibt die Anzahl von kopierten Bytes und die dafür benötigte Zeit an. Beispiel:
```
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica | Where-Object {$_.ID -eq "1215"} | fl
```
  Hier ist eine Beispielausgabe angegeben:
```
TimeCreated  : 4/8/2016 4:12:37 PM
ProviderName : Microsoft-Windows-StorageReplica
Id           : 1215
Message      : Block copy completed for replica.

ReplicationGroupName: rg02
ReplicationGroupId: {616F1E00-5A68-4447-830F-B0B0EFBD359C}
ReplicaName: f:\
ReplicaId: {00000000-0000-0000-0000-000000000000}
End LSN in bitmap:
LogGeneration: {00000000-0000-0000-0000-000000000000}
LogFileId: 0
CLSFLsn: 0xFFFFFFFF
Number of Bytes Recovered: 68583161856
Elapsed Time (ms): 117
```
  Hinweis
  
  Das Speicherreplikatfeature hebt die Bereitstellung der Zielvolumes sowie der zugehörigen Laufwerkbuchstaben oder Bereitstellungspunkte auf. Dies ist beabsichtigt.
3. Alternativ gibt die Zielservergruppe für das Replikat jederzeit die Anzahl der noch zu kopierenden Bytes an. Dieser Wert kann auch über PowerShell abgefragt werden. Beispiel:
```
(Get-SRGroup).Replicas | Select-Object numofbytesremaining
```
  Beispiel für den Fortschritt (das nicht beendet wird):
```
while($true) {

 $v = (Get-SRGroup -Name "RG02").replicas | Select-Object numofbytesremaining
 [System.Console]::Write("Number of bytes remaining: {0}`r", $v.numofbytesremaining)
 Start-Sleep -s 5
}
```
4. Führen Sie auf dem Zielserver den folgenden Befehl aus, und überprüfen Sie die Ereignisse 5009, 1237, 5001, 5015, 5005 und 2200, um Informationen zum Verarbeitungsfortschritt zu erhalten. In dieser Sequenz sollten keine Warnungen oder Fehler vorliegen. Es werden eine Vielzahl von Ereignissen des Typs 1237 angezeigt, die für den Fortschritt stehen.
```
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica | FL
```

Schritt 4: Verwalten der Replikation

Nachfolgend sind die Schritte zur Verwaltung Ihrer Server-zu-Server-Replikationsinfrastruktur beschrieben. Die unten beschriebenen Schritte können unmittelbar auf den Knoten oder über einen Remoteverwaltungscomputer ausgeführt werden, auf dem die Remoteverwaltungstools von Windows Server installiert sind.

Verwenden Sie Get-SRPartnership und Get-SRGroup, um die aktuelle Quelle und das aktuelle Ziel der Replikation sowie den zugehörigen Status zu ermitteln.
Zum Ermitteln der Replikationsleistung verwenden Sie das Cmdlet Get-Counter sowohl auf dem Quell- als auch auf dem Zielknoten. Es werden folgende Leistungsindikatoren verwendet:
- \Statistik zur Partitions-E/A des Speicherreplikats(*)\Häufigkeit, mit der die Leerung angehalten wurde
- \Statistik zur Partitions-E/A des Speicherreplikats(*)\Anzahl ausstehender Leerungs-E/As
- \Statistik zur Partitions-E/A des Speicherreplikats(*)\Anzahl von Anforderungen für letzten Schreibvorgang im Protokoll
- \Statistik zur Partitions-E/A des Speicherreplikats(*)\Durchschnittl. Länge der Warteschlange zum Leeren
- \Statistik zur Partitions-E/A des Speicherreplikats(*)\Aktuelle Länge der Warteschlange zum Leeren
- \Statistik zur Partitions-E/A des Speicherreplikats(*)\Anzahl von Anwendungsschreibanforderungen
- \Statistik zur Partitions-E/A des Speicherreplikats(*)\Anzahl durchschnittl. Anforderungen pro Schreibvorgang im Protokoll
- \Statistik zur Partitions-E/A des Speicherreplikats(*)\Durchschnittl. Wartezeit für App-Schreibvorgang
- \Statistik zur Partitions-E/A des Speicherreplikats(*)\Durchschnittl. Wartezeit für App-Lesevorgang
- \Speicherreplikatstatistik(*)\Ziel-RPO
- \Speicherreplikatstatistik(*)\Aktuelle RPO
- \Speicherreplikatstatistik(*)\Durchschnittl. Länge der Protokollwarteschlange
- \Speicherreplikatstatistik(*)\Aktuelle Länge der Protokollwarteschlange
- \Speicherreplikatstatistik(*)\Gesamtanzahl empfangener Bytes
- \Speicherreplikatstatistik(*)\Gesamtanzahl gesendeter Bytes
- \Speicherreplikatstatistik(*)\Durchschnittl. Wartezeit beim Senden über das Netzwerk
- \Speicherreplikatstatistik(*)\Replikationszustand
- \Speicherreplikatstatistik(*)\Durchschnittl. Wartezeit bei Nachrichtenroundtrip
- \Speicherreplikatstatistik(*)\Verstrichene Zeit bei letzter Wiederherstellung
- \Speicherreplikatstatistik(*)\Anzahl geleerter Wiederherstellungstransaktionen
- \Speicherreplikatstatistik(*)\Anzahl von Wiederherstellungstransaktionen
- \Speicherreplikatstatistik(*)\Anzahl geleerter Replikationstransaktionen
- \Speicherreplikatstatistik(*)\Anzahl von Replikationstransaktionen
- \Speicherreplikatstatistik(*)\Max. Protokollfolgenummer
- \Speicherreplikatstatistik(*)\Anzahl empfangener Nachrichten
- \Speicherreplikatstatistik(*)\Anzahl gesendeter Nachrichten
Weitere Informationen zu Leistungsindikatoren in Windows PowerShell finden Sie unter Get-Counter.
Zum Ändern der Replikationsrichtung eines Standorts verwenden Sie das Cmdlet Set-SRPartnership.
```
Set-SRPartnership -NewSourceComputerName sr-srv06 -SourceRGName rg02 -DestinationComputerName sr-srv05 -DestinationRGName rg01
```
Warnung

Windows Server verhindert einen Rollenwechsel während der ersten Synchronisierung. Es kann zu Datenverlust führen, wenn Sie vor Abschluss der ersten Replikation versuchen, einen Wechsel vorzunehmen. Erzwingen Sie keinen Richtungswechsel, bevor die erste Synchronisierung abgeschlossen ist.

Überprüfen Sie die Ereignisprotokolle auf eine Richtungsänderung bei der Replikation und einen Wiederherstellungsmodus, und bringen Sie die Konfiguration in Einklang. Schreib-E/As können anschließend in den Speicher schreiben, der sich im Besitz des neuen Quellservers befindet. Durch das Ändern der Replikationsrichtung werden Schreib-E/As auf dem vorherigen Quellcomputer verhindert.
Zum Entfernen der Replikation verwenden Sie Get-SRGroup, Get-SRPartnership, Remove-SRGroup und Remove-SRPartnership auf jedem Knoten. Führen Sie das Cmdlet Remove-SRPartnership keinesfalls auf dem Zielserver, sondern lediglich auf der aktuellen Replikationsquelle aus. Führen Sie Remove-SRGroup auf beiden Servern aus. So entfernen Sie die Replikation z. B. vollständig von zwei Servern:
```
Get-SRPartnership
Get-SRPartnership | Remove-SRPartnership
Get-SRGroup | Remove-SRGroup
```

Ersetzen der DFS-Replikation durch Speicherreplikate

Viele Microsoft-Kunden stellen die DFS-Replikation als Notfallwiederherstellungslösung für unstrukturierte Benutzerdaten wie Basisordner und Abteilungsfreigaben bereit. DFS-Replikation wurde in Windows Server 2003 R2 und allen späteren Betriebssystemen bereitgestellt und kann in Netzwerken mit geringer Bandbreite eingesetzt werden. Daher eignet sich diese Replikation für Umgebungen mit einer Vielzahl von Knoten, die durch eine hohe Latenz und wenige Änderungen gekennzeichnet sind. DFS-Replikation hat jedoch deutliche Einschränkungen als Lösung zur Replikation von Daten:

Dateien, die aktuell verwendet werden oder geöffnet sind, werden nicht repliziert.
Es wird keine synchrone Replikation durchgeführt.
Bei der asynchronen Replikation kann eine Wartezeit von mehreren Minuten, Stunden oder sogar Tagen auftreten.
DFSR ist von einer Datenbank abhängig, für die nach einer Unterbrechung der Stromversorgung lange Konsistenzprüfungen erforderlich sein können.
Diese Lösung ist üblicherweise als Multimaster konfiguriert, sodass Änderungen in beide Richtungen übermittelt werden können (wodurch neuere Daten überschrieben werden können).

Bei Speicherreplikaten gelten keine dieser Einschränkungen. Allerdings müssen auch hier eine Reihe von Einschränkungen berücksichtigt werden, aufgrund derer sich diese Art der Replikation für einige Umgebungen weniger gut eignet:

Lediglich eine 1:1-Replikation zwischen Volumes ist möglich. Unterschiedliche Volumes können zwischen mehreren Servern repliziert werden.
Wenngleich eine asynchrone Replikation unterstützt wird, ist dieses Feature nicht für Netzwerke mit niedriger Bandbreite und hoher Latenz ausgelegt.
Während der Replikation ist kein Benutzerzugriff auf die geschützten Daten auf dem Ziel möglich.

Wenn diese Faktoren nicht entscheidend sind, kann das Speicherreplikatfeature eingesetzt werden, um DFS-Replikatserver durch diese neuere Technologie zu ersetzen. Nachfolgend finden Sie einen groben Überblick über die erforderlichen Schritte:

Installieren Sie Windows Server auf zwei Servern, und konfigurieren Sie Ihren Speicher. Sie können entweder zwei vorhandene Server upgraden oder eine Neuinstallation durchführen.
Stellen Sie sicher, dass die Daten, die repliziert werden sollen, sich auf mindestens einem Datenvolume und nicht Laufwerk C: befinden. a. Sie können auch ein Seeding für die Daten auf dem anderen Server durchführen, um den Zeitaufwand zu reduzieren. Dabei werden eine Sicherung oder Dateikopien verwendet. Außerdem ist eine schlanke Speicherzuweisung möglich. Im Gegensatz zu DFS-Replikation ist eine exakte Übereinstimmung mit der metadatenähnlichen Sicherheit nicht erforderlich.
Geben Sie die Daten auf Ihrem Quellserver frei, und machen Sie sie über einen DFS-Namespace verfügbar. Dies ist wichtig, um sicherzustellen, dass Benutzer weiterhin auf die Daten zugreifen können, wenn der Servername in einen Namen an einem Notfallstandort geändert wird. a. Sie können übereinstimmende Freigaben auf dem Zielserver erstellen, die im normalen Betrieb nicht verfügbar sind. Fügen Sie den Zielserver nicht dem DFS-Namespace hinzu. Falls doch, stellen Sie sicher, dass sämtliche Ordnerziele deaktiviert sind.
Aktivieren Sie die Speicherreplikatreplikation schließen Sie die Erstsynchronisierungsreplikation ab. Die Replikation kann entweder synchron oder asynchron durchgeführt werden. a. Um E/A-Datenkonsistenz auf dem Zielserver sicherzustellen, wird jedoch eine synchrone Replikation empfohlen. b. Es wird dringend empfohlen, Volumeschattenkopien zu aktivieren und regelmäßig Momentaufnahmen mit VSSADMIN oder einem anderen Tool Ihrer Wahl zu erstellen. Dadurch wird sichergestellt, dass Anwendungen ihre Daten konsistent auf den Datenträgern speichern. Bei einem Notfall können Sie Dateien anhand von Momentaufnahmen auf dem Zielserver wiederherstellen, die möglicherweise teilweise asynchron repliziert wurden. Momentaufnahmen werden gemeinsam mit den Dateien repliziert.
Nehmen Sie den normalen Betrieb auf, bis eine Notfallsituation eintritt.
Ändern Sie den Zielserver in den neuen Quellserver, sodass die replizierten Volumes für die Benutzer angezeigt werden.
Bei Verwendung der synchronen Replikation ist nur dann eine Datenwiederherstellung erforderlich, wenn der Benutzer eine Anwendung verwendet hat, die beim Ausfall des Quellservers Daten ohne Transaktionsschutz (unabhängig von der Replikation) geschrieben hat. Bei Verwendung der asynchronen Replikation sollte eine VSS-Momentaufnahmenbereitstellung verwendet werden. Sie sollten die Verwendung von VSS jedoch in allen Situationen in Betracht ziehen, um anwendungskonsistente Momentaufnahmen bereitzustellen.
Fügen Sie den Server und seine Freigaben als DFS-Namespaces-Ordnerziel hinzu.
Die Benutzer können anschließend auf ihre Daten zugreifen.

Hinweis

Die Notfallwiederherstellungsplanung ist ein komplexes Thema, das mit größter Sorgfalt behandelt werden muss. Es wird dringend empfohlen, Runbooks zu erstellen und jährliche Livefailoverdrills durchzuführen. Wenn tatsächlich eine Notfallsituation eintritt, können die Abläufe chaotisch sein, und erfahrene Mitarbeiter sind möglicherweise nicht verfügbar.

Hinzufügen einer Azure-VM, die über ExpressRoute mit Ihrem Netzwerk verbunden ist

Erstellen Sie einen Schlüssel im Azure-Portal.
Nachdem ExpressRoute genehmigt wurde, wird dem Abonnement eine Ressourcengruppe hinzugefügt. Navigieren Sie zu Ressourcengruppen, um diese neue Gruppe anzuzeigen. Notieren Sie sich den Namen des virtuellen Netzwerks.

Abbildung 4: Die einer ExpressRoute zugeordneten Ressourcen. Notieren Sie sich den Namen des virtuellen Netzwerks.
Erstellen Sie eine neue Ressourcengruppe.
Fügen Sie eine Netzwerksicherheitsgruppe hinzu. Wählen Sie beim Erstellen die Abonnement-ID aus, die der von Ihnen erstellten ExpressRoutee zugeordnet ist, und wählen Sie auch die Ressourcengruppe aus, die Sie soeben erstellt haben.

Fügen Sie der Netzwerksicherheitsgruppe alle Eingangs- und Ausgangssicherheitsregeln hinzu, die Sie benötigen. Beispielsweise können Sie Remotedesktop Zugriff auf den virtuellen Computer gestatten.
Erstellen Sie eine Azure-VM mit den folgenden Einstellungen (siehe Abbildung 5):
- Öffentliche IP-Adresse: Keine
- Virtuelles Netzwerk: Wählen Sie das virtuelle Netzwerk aus, das Sie sich notiert haben, aus der Ressourcengruppe, die mit ExpressRoute hinzugefügt wurde.
- Netzwerksicherheitsgruppe (Firewall) : Wählen Sie die Netzwerksicherheitsgruppe aus, die Sie zuvor erstellt haben. Abbildung 5: Erstellen eines virtuellen Computers beim Auswählen von ExpressRoute-Netzwerkeinstellungen
Nachdem der virtuelle Computer erstellt wurde, finden Sie weitere Informationen unter Schritt 2: Bereitstellen von Betriebssystem, Features, Rollen, Speicher und Netzwerk.