Bekannte Probleme mit Speicherreplikaten

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016

In diesem Thema werden bekannte Probleme mit Speicherreplikaten in Windows Server behandelt.

Nach dem Entfernen der Replikation sind Datenträger offline, und Sie können die Replikation nicht erneut konfigurieren

In Windows Server 2016 können Sie auf einem Datenträger, der zuvor repliziert wurde, möglicherweise keine Replikation bereitstellen, oder es sind Volumes vorhanden, die nicht bereitgestellt werden können. Dies kann auftreten, wenn ein bestimmter Fehlerzustand das Entfernen der Replikation verhindert oder wenn Sie das Betriebssystem auf einem Computer neu installieren, der zuvor die Replikation von Daten ausgeführt hat.

Um das Problem zu beheben, müssen Sie die versteckte Speicherreplikatpartition von den Datenträgern löschen und die Datenträger mithilfe des Cmdlets Clear-SRMetadata in einen beschreibbaren Status zurückversetzen.

• Um alle verwaisten Partitionsdatenbankslots Storage Replikatpartitionsdatenbanken zu entfernen und alle Partitionen erneut verfügbar zu machen, -AllPartitions verwenden Sie den Parameter wie folgt:

  Clear-SRMetadata -AllPartitions
  

• Um alle verwaisten Speicherreplikat-Protokolldaten zu entfernen, verwenden Sie den Parameter -AllLogs wie folgt:

  Clear-SRMetadata -AllLogs
  

• Um alle verwaisten Failovercluster-Konfigurationsdaten zu entfernen, verwenden Sie den Parameter -AllConfiguration wie folgt:

  Clear-SRMetadata -AllConfiguration
  

• Um einzelne Replikationsgruppen-Metadaten zu entfernen, verwenden Sie den Parameter -Name wie folgt:

  Clear-SRMetadata -Name RG01 -Logs -Partition
  

Der Server muss nach der Bereinigung der Partitionsdatenbank möglicherweise neu gestartet werden. Sie können den Neustart vorübergehend mit -NoRestart unterdrücken, aber Sie sollten den Neustart des Servers nicht komplett überspringen, wenn er vom Cmdlet angefordert wird. Dieses Cmdlet entfernt weder Datenvolumes noch die auf diesen Volumes enthaltenen Daten.

Während der ersten Synchronisierung werden Ereignisprotokoll 4004-Warnungen angezeigt

In Windows Server 2016 werden beim Konfigurieren der Replikation sowohl der Quell- als auch der Zielserver während der ersten Synchronisierung möglicherweise mehrere **StorageReplica\Admin*- Ereignisprotokollwarnungen 4004 mit dem Status "Es sind nicht genügend Systemressourcen vorhanden, um die API fertig zu stellen" angezeigt. Sie werden wahrscheinlich auch 5014-Fehler angezeigt. Diese Fehler weisen darauf hin, dass die Server nicht über genügend Arbeitsspeicher (RAM) verfügen, um gleichzeitig die erste Synchronisierung und Workloads auszuführen. Fügen Sie RAM hinzu, oder reduzieren Sie den von Features und Anwendungen (mit Ausnahme des Speicherreplikats) verwendeten Arbeitsspeicher.

Werden Gastcluster mit freigegebenem VHDX und ein Host ohne freigegebene Clustervolumes verwendet, reagieren virtuelle Computer nach dem Konfigurieren der Replikation nicht mehr

Werden in Windows Server 2016 Hyper-V-Gastcluster für Speicherreplikat-Tests oder zu Demonstrationszwecken sowie freigegebene VHDX als Gastclusterspeicher verwendet, reagieren die virtuellen Computer nach dem Konfigurieren der Replikation nicht mehr. Wenn Sie den Hyper-V-Host neu starten, reagieren die virtuellen Computer wieder, aber die Replikationskonfiguration wird nicht abgeschlossen, und er erfolgt keine Replikation.

Dieses Verhalten tritt auf, wenn Sie **fltmc.exe svhdxflt*- anfügen, um die Anforderung für den Hyper-V-Host zu umgehen, auf dem eine CSV-Datei ausgeführt wird. Dieser Befehl wird nicht unterstützt und ist ausschließlich für Test- und Demonstrationszwecke bestimmt.

Die Ursache der Verlangsamung ist ein entwurfsbedingtes Interoperabilitätsproblem zwischen dem QoS für Speicher-Feature in Windows Server 2016 und dem manuell angeschlossenen freigegebenen VHDX-Filter. Um dieses Problem zu beheben, deaktivieren Sie den Speicher-QoS-Filtertreiber, und starten Sie den Hyper-V-Host neu:

SC config storqosflt start= disabled

Replikation kann unter Verwendung von „New-Volume“ und unterschiedlichem Speicher nicht konfiguriert werden

Wenn Sie das Cmdlet New-Volumezusammen mit unterschiedlichen Gruppen von Speicher auf Quell- und Zielserver verwenden, z.B. zwei verschiedene SANs oder zwei JBODs mit unterschiedlichen Datenträgern, können Sie die Replikation möglicherweise anschließend nicht mithilfe von New-SRPartnership konfigurieren. Der angezeigte Fehler kann folgenden Text enthalten:

Data partition sizes are different in those two groups

Verwenden Sie das Cmdlet New-Partition** anstelle von New-Volume, um Volumes zu erstellen und zu formatieren, Weil das zweite Cmdlet die Volumegröße auf unterschiedliche Speicherarrays möglicherweise rundet. Wenn Sie bereits ein NTFS-Volume erstellt haben, können Sie mit Resize-Partition eines der Volumes vergrößern oder verkleinern, um es an die Größe des anderen anzupassen (dies ist bei ReFS-Volumes nicht möglich). Bei Verwendung von **Diskmgmt*- oder Server-Manager wird keine Rundung erfolgen.

Das Ausführen von Test-SRTopology schlägt mit Fehlern im Zusammenhang mit Namen fehl

Bei der Verwendung von Test-SRTopology wird eine der folgenden Fehlermeldungen angezeigt:

FEHLERBEISPIEL 1:

WARNING: Invalid value entered for target computer name: sr-srv03. Test-SrTopology cmdlet does not accept IP address as input for target computer name parameter. NetBIOS names and fully qualified domain names are acceptable inputs
WARNING: System.Exception
WARNING: at Microsoft.FileServices.SR.Powershell.TestSRTopologyCommand.BeginProcessing()
Test-SRTopology : Invalid value entered for target computer name: sr-srv03. Test-SrTopology cmdlet does not accept IP address as input for target computer name parameter. NetBIOS names and fully qualified domain names are acceptable inputs
At line:1 char:1
+ Test-SRTopology -SourceComputerName sr-srv01 -SourceVolumeName d: -So ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidArgument: (:) [Test-SRTopology], Exception
+ FullyQualifiedErrorId : TestSRTopologyFailure,Microsoft.FileServices.SR.Powershell.TestSRTopologyCommand

FEHLERBEISPIEL 2:

WARNING: Invalid value entered for source computer name

FEHLERBEISPIEL 3:

The specified volume cannot be found G: cannot be found on computer SRCLUSTERNODE1

Dieses Cmdlet verfügt über eingeschränkte Fehlerberichterstattung in Windows Server 2016 und gibt für viele häufige Probleme die gleiche Ausgabe zurück. Der Fehler kann aus folgenden Gründen angezeigt werden:

• Sie sind beim Quellcomputer als lokaler Benutzer und nicht als Domänenbenutzer angemeldet.

• Der Zielcomputer wird nicht ausgeführt oder ist über das Netzwerk nicht verfügbar.

• Sie haben einen falschen Namen für den Zielcomputer angegeben.

• Sie haben eine IP-Adresse für den Zielserver angegeben.

• Die Zielcomputerfirewall blockiert den Zugriff auf PowerShell und/oder CIM-Aufrufe.

• Auf dem Zielcomputer wird der WMI-Dienst nicht ausgeführt.

• Sie haben bei der Remoteausführung des Cmdlets Test-SRTopology von einem Verwaltungscomputer aus CREDSSP nicht verwendet.

• Die festgelegten Quell- oder Zielvolumes sind lokale Datenträger auf einem Clusterknoten, keine Clusterdatenträger.

Beim Konfigurieren einer neuen Speicherreplikatpartnerschaft wird ein Fehler zurückgegeben: „Fehler beim Bereitstellen der Partition“

Beim Erstellen einer neuen Replikationspartnerschaft mit New-SRPartnership wird die folgende Fehlermeldung angezeigt:

New-SRPartnership : Unable to create replication group test01, detailed reason: Failed to provision partition ed0dc93f-107c-4ab4-a785-afd687d3e734.
At line: 1 char: 1
+ New-SRPartnership -SourceComputerName srv1 -SourceRGName test01
+ Categorylnfo : ObjectNotFound: (MSFT_WvrAdminTasks : root/ Microsoft/. . s) CNew-SRPartnership], CimException
+ FullyQua1ifiedErrorId : Windows System Error 1168 ,New-SRPartnership

Dies wird durch die Auswahl eines Datenvolumens verursacht, das sich auf derselben Partition wie das Systemlaufwerk befindet (d. h. das Laufwerk **C:- mit dem Windows Ordner). Beispielsweise auf einem Laufwerk, das die Volumes **C:- und **D:*- enthält, die aus derselben Partition erstellt wurden. Dies wird im Speicherreplikatfeature nicht unterstützt. Sie müssen ein anderes Volume zum Replizieren auswählen.

Beim Versuch, ein repliziertes Volume zu vergrößern, tritt aufgrund eines fehlenden Updates ein Fehler auf.

Wenn Sie versuchen, ein repliziertes Volume zu vergrößern oder zu erweitern, wird die folgende Fehlermeldung angezeigt:

Resize-Partition -DriveLetter d -Size 44GB
Resize-Partition : The operation failed with return code 8
At line:1 char:1
+ Resize-Partition -DriveLetter d -Size 44GB
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (StorageWMI:ROOT/Microsoft/.../MSFT_Partition
[Resize-Partition], CimException
+ FullyQualifiedErrorId : StorageWMI 8,Resize-Partition

Wenn Sie das MMC-Snap-In „Datenträgerverwaltung“ verwenden, wird diese Fehlermeldung angezeigt:

Element not found

Dies geschieht auch, wenn Sie das Ändern der Größe von Volumes auf dem Quellserver mithilfe von Set-SRGroup -Name rg01 -AllowVolumeResize $TRUE korrekt aktivieren.

Dieses Problem wurde im kumulativen Update für Windows 10 Version 1607 (Anniversary Update) und Windows Server 2016: 9. Dezember 2016 (KB3201845) behoben.

Beim Versuch, ein repliziertes Volume zu vergrößern, tritt aufgrund eines fehlenden Schritts ein Fehler auf.

Wenn Sie versuchen, die Größe eines replizierten Volumes auf dem Quellserver zu ändern, ohne zuvor -AllowResizeVolume $TRUE festzulegen, treten die folgenden Fehler auf:

Resize-Partition -DriveLetter I -Size 8GB
Resize-Partition : Failed

Activity ID: {87aebbd6-4f47-4621-8aa4-5328dfa6c3be}
At line:1 char:1
+ Resize-Partition -DriveLetter I -Size 8GB
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (StorageWMI:ROOT/Microsoft/.../MSFT_Partition) [Resize-Partition], CimException
     + FullyQualifiedErrorId : StorageWMI 4,Resize-Partition

Storage Replica Event log error 10307:

Attempted to resize a partition that is protected by Storage Replica.

DeviceName: \Device\Harddisk1\DR1
PartitionNumber: 7
PartitionId: {b71a79ca-0efe-4f9a-a2b9-3ed4084a1822}

Guidance: To grow a source data partition, set the policy on the replication group containing the data partition.

Set-SRGroup -ComputerName [ComputerName] -Name [ReplicationGroupName] -AllowVolumeResize $true

Bevor Sie die Quelldatenpartition vergrößern, stellen Sie sicher, dass die Zieldatenpartition über genügend Speicherplatz verfügt, um eine gleiche Größe zu erreichen. Das Verkleinern der durch das Speicherreplikat geschützten Datenpartition wird blockiert.

Fehler beim Snap-In „Datenträgerverwaltung“:

An unexpected error has occurred

Denken Sie nach dem Ändern der Volumegröße daran, die Größenänderung mit Set-SRGroup -Name rg01 -AllowVolumeResize $FALSE zu deaktivieren. Dieser Parameter verhindert, dass Administratoren versuchen, die Volumegrößen zu ändern, bevor sie sichergestellt haben, dass auf dem Zielvolume ausreichend Speicherplatz verfügbar ist, in der Regel weil sie nicht wussten, dass Speicherreplikate vorhanden sind.

Fehler beim Versuch, eine PDR-Ressource zwischen Standorten in einem asynchronen Stretched Cluster zu verschieben

Beim Versuch, eine mit einer physischen Datenträgerressource verbundene Rolle (z.B. einen zur allgemeinen Verwendung bestimmten Dateiserver) zu verschieben, um den zugehörigen Speicher in einen asynchronen Stretched Cluster zu verschieben, wird eine Fehlermeldung angezeigt.

Bei Verwendung des Failovercluster-Manager-Snap-Ins:

Error
The operation has failed.
The action 'Move' did not complete.
Error Code: 0x80071398
The operation failed because either the specified cluster node is not the owner of the group, or the node is not a possible owner of the group

Bei Verwendung des PowerShell-Cmdlets „Cluster“:

Move-ClusterGroup -Name sr-fs-006 -Node sr-srv07
Move-ClusterGroup : An error occurred while moving the clustered role 'sr-fs-006'.
The operation failed because either the specified cluster node is not the owner of the group, or the node is not a possible owner of the group
At line:1 char:1
+ Move-ClusterGroup -Name sr-fs-006 -Node sr-srv07
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Move-ClusterGroup], ClusterCmdletException
+ FullyQualifiedErrorId : Move-ClusterGroup,Microsoft.FailoverClusters.PowerShell.MoveClusterGroupCommand

Die Ursache für das Auftreten ist ein beabsichtigtes Verhalten in Windows Server 2016. Verschieben Sie diese PDR-Datenträger mit Set-SRPartnership in einen asynchronen Stretched Cluster.

Dieses Verhalten wurde in Windows Server Version 1709 geändert, um basierend auf Kundenfeedback manuelle und automatisierte Failover mit asynchroner Replikation zu ermöglichen.

Beim Versuch, Datenträger zu einem asymmetrischen Cluster mit zwei Knoten hinzuzufügen, wird „Keine geeigneten Datenträger für den Cluster gefunden“ angezeigt

Wenn Sie vor dem Hinzufügen einer Speicherreplikat-Stretchreplikation versuchen, einen Cluster mit nur zwei Knoten bereitzustellen, wird versucht, die Datenträger am zweiten Standort zu „Verfügbare Datenträger“ hinzuzufügen. Sie erhalten die folgende Fehlermeldung:

No disks suitable for cluster disks found. For diagnostic information about disks available to the cluster, use the Validate a Configuration Wizard to run Storage tests.

Dieser Fehler tritt nicht auf, wenn im Cluster mindestens drei Knoten vorhanden sind. Dieses Problem tritt aufgrund einer beabsichtigten Codeänderung in Windows Server 2016 für das Clusteringverhalten bei asymmetrischem Speicher auf.

Um den Speicher hinzuzufügen, können Sie den folgenden Befehl auf dem Knoten am zweiten Standort ausführen:

Get-ClusterAvailableDisk -All | Add-ClusterDisk

Dies funktioniert nicht mit lokalem Speicher auf einem Knoten. Sie können das Feature „Speicherreplikat“ zum Replizieren eines Stretched Clusters zwischen insgesamt zwei Knoten verwenden, wobei jeder Knoten seinen eigenen freigegebenen Speicher verwendet.

Die SMB-Bandbreiteneinschränkung drosselt die Speicherreplikat-Bandbreite nicht

Wenn Sie dem Speicherreplikat eine Bandbreiteneinschränkung hinzufügen, wird das Limit ignoriert und die volle Bandbreite verwendet. Beispiel:

Set-SmbBandwidthLimit  -Category StorageReplication -BytesPerSecond 32MB

Dieses Problem tritt aufgrund eines Kompatibilitätsproblems zwischen Speicherreplikat und SMB auf.

Warnung 1241 im Zuge der ersten Synchronisierung wiederholt

Beim Angeben einer asynchronen Replikationspartnerschaft meldet der Quellcomputer Warnung 1241 wiederholt im Speicherreplikatverwaltungs-Kanal. Beispiel:

Log Name:      Microsoft-Windows-StorageReplica/Admin
Source:        Microsoft-Windows-StorageReplica
Date:          3/21/2017 3:10:41 PM
Event ID:      1241
Task Category: (1)
Level:         Warning
Keywords:      (1)
User:          SYSTEM
Computer:      sr-srv05.corp.contoso.com
Description:
The Recovery Point Objective (RPO) of the asynchronous destination is unavailable.

LocalReplicationGroupName: rg01
LocalReplicationGroupId: {e20b6c68-1758-4ce4-bd3b-84a5b5ef2a87}
LocalReplicaName: f:\
LocalPartitionId: {27484a49-0f62-4515-8588-3755a292657f}
ReplicaSetId: {1f6446b5-d5fd-4776-b29b-f235d97d8c63}
RemoteReplicationGroupName: rg02
RemoteReplicationGroupId: {7f18e5ea-53ca-4b50-989c-9ac6afb3cc81}
TargetRPO: 30

Anleitung: Dies hat in der Regel einen oder mehrere der folgenden Gründe:

• Das asynchrone Ziel ist derzeit nicht verbunden. Die RPO ist eventuell verfügbar, nachdem die Verbindung wiederhergestellt wurde.

• Das asynchrone Ziel kann nicht mit der Quelle Schritt halten, sodass der letzte Zielprotokolldatensatz nicht mehr im Quellprotokoll vorhanden ist. Das Ziel beginnt, das Kopieren zu blockieren. Der RPO sollte verfügbar werden, nachdem das Kopieren von Blöcken abgeschlossen ist.

Dieses Verhalten wird während der ersten Synchronisierung erwartet und kann ignoriert werden. In einer späteren Version wird dieses Verhalten möglicherweise geändert. Wenn dieses Verhalten während der asynchronen Replikation auftritt, überprüfen Sie die Partnerschaft, um zu ermitteln, warum die Replikation außerhalb der konfigurierten RPO (standardmäßig 30 Sekunden) verzögert wird.

Nach dem Neustart eines replizierten Knotens wiederholte Warnung 4004

Unter sehr seltenen Umständen, die in der Regel nicht reproduziert werden können, führt ein Neustart des Servers, der in einer Partnerschaft ist, zu Replikationsfehlern, und der neu gestartete Zielknoten zeigt Warnung 4004 mit einem „Zugriff verweigert”-Fehler an.

Log Name:      Microsoft-Windows-StorageReplica/Admin
Source:        Microsoft-Windows-StorageReplica
Date:          3/21/2017 11:43:25 AM
Event ID:      4004
Task Category: (7)
Level:         Warning
Keywords:      (256)
User:          SYSTEM
Computer:      server.contoso.com
Description:
Failed to establish a connection to a remote computer.

RemoteComputerName: server
LocalReplicationGroupName: rg01
LocalReplicationGroupId: {a386f747-bcae-40ac-9f4b-1942eb4498a0}
RemoteReplicationGroupName: rg02
RemoteReplicationGroupId: {a386f747-bcae-40ac-9f4b-1942eb4498a0}
ReplicaSetId: {00000000-0000-0000-0000-000000000000}
RemoteShareName:{a386f747-bcae-40ac-9f4b-1942eb4498a0}.{00000000-0000-0000-0000-000000000000}
Status: {Access Denied}
A process has requested access to an object, but has not been granted those access rights.

Guidance: Possible causes include network failures, share creation failures for the remote replication group, or firewall settings. Make sure SMB traffic is allowed and there are no connectivity issues between the local computer and the remote computer. You should expect this event when suspending replication or removing a replication partnership.

Beachten Sie Status: "{Access Denied}" und die Meldung A process has requested access to an object, but has not been granted those access rights. Dies ist ein bekanntes Problem innerhalb des Speicherreplikats und wurde im Qualitätsupdate vom 12. September 2017 – KB4038782 (Betriebssystembuild 14393.1715) behoben. https://support.microsoft.com/help/4038782/windows-10-update-kb4038782

Fehler "Fehler beim Online stellen der Ressource 'Cluster Disk x'." mit einem Stretchingcluster

Wenn Sie versuchen, einen Clusterdatenträger nach einem erfolgreichen Failover in den Onlinemodus zu versetzen, indem Sie die ursprüngliche Quellwebsite erneut als primären Site festlegen möchten, erhalten Sie eine Fehlermeldung im Failovercluster-Manager. Beispiel:

Error
The operation has failed.
Failed to bring the resource 'Cluster Disk 2' online.

Error Code: 0x80071397
The operation failed because either the specified cluster node is not the owner of the resource, or the node is not a possible owner of the resource.

Wenn Sie versuchen, den Datenträger oder CSV manuell zu verschieben, erhalten Sie eine zusätzliche Fehlermeldung. Beispiel:

Error
The operation has failed.
The action 'Move' did not complete.

Error Code: 0x8007138d
A cluster node is not available for this operation

Dieses Problem wird durch mindestens einen nicht initialisierten, mindestens einem Clusterknoten angefügten Datenträger verursacht. Um das Problem zu beheben, initialisieren Sie alle Speichermedien mithilfe von „DiskMgmt.msc“, „DISKPART.EXE” oder des Initialize-Disk-PowerShell-Cmdlets.

Wir arbeiten an einem Update, das dieses Problem dauerhaft behebt. Wenn Sie an einer Unterstützung interessiert sind und über einen Microsoft Premier Support-Vertrag verfügen, senden Sie eine E-Mail an SRFEED@microsoft.com, damit wir mit Ihnen an einer Backport-Unterstützung arbeiten können.

GPT-Fehler beim Versuch, eine neue SR-Partnerschaft zu erstellen

Wenn eine neue SR-Partnership ausgeführt wird, tritt folgender Fehler auf:

Disk layout type for volume \\?\Volume{GUID}\ is not a valid GPT style layout.
New-SRPartnership : Unable to create replication group SRG01, detailed reason: Disk layout type for volume
\\?\Volume{GUID}\ is not a valid GPT style layout.
At line:1 char:1
+ New-SRPartnership -SourceComputerName nodesrc01 -SourceRGName SRG01 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (MSFT_WvrAdminTasks:root/Microsoft/...T_WvrAdminTasks) [New-SRPartnership], CimException
+ FullyQualifiedErrorId : Windows System Error 5078,New-SRPartnership

In der grafischen Benutzeroberfläche des Failovercluster-Managers ist keine Option zum Einrichten von Replikationen für das Laufwerk vorhanden.

Wenn „Test-SRTopology” ausgeführt wird, tritt folgender Fehler auf:

WARNING: Object reference not set to an instance of an object.
WARNING: System.NullReferenceException
WARNING:    at Microsoft.FileServices.SR.Powershell.MSFTPartition.GetPartitionInStorageNodeByAccessPath(String AccessPath, String ComputerName, MIObject StorageNode)
    at Microsoft.FileServices.SR.Powershell.Volume.GetVolume(String Path, String ComputerName)
    at Microsoft.FileServices.SR.Powershell.TestSRTopologyCommand.BeginProcessing()
Test-SRTopology : Object reference not set to an instance of an object.
At line:1 char:1
+ Test-SRTopology -SourceComputerName nodesrc01 -SourceVolumeName U: - ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Test-SRTopology], NullReferenceException
+ FullyQualifiedErrorId : TestSRTopologyFailure,Microsoft.FileServices.SR.Powershell.TestSRTopologyCommand

Dies wird durch die noch auf Windows Server 2012 R2 (d. h. FL 8) festgelegte Cluster-Funktionsebene verursacht. Speicherreplikat sollte einen bestimmten Fehler zurückgeben, gibt jedoch stattdessen eine falsche Fehlerzuordnung zurück.

Run Get-Cluster | fl - on each node.

Wenn ClusterFunctionalLevel = 9 ist, muss die Windows 2016 ClusterFunctionalLevel Version das Speicherreplikat auf diesem Knoten installieren. Wenn ClusterFunctionalLevel nicht 9 ist, muss ClusterFunctionalLevel aktualisiert werden, um das Speicherreplikat auf diesen Knoten zu implementieren.

Um das Problem zu beheben, erhöhen Sie die Clusterfunktionsebene, indem Sie das PowerShell-Cmdlet Update-ClusterFunctionalLevel ausführen.

Kleine unbekannte Partition in DISKMGMT ist für jedes replizierte Volume aufgelistet

Beim Ausführen des Snap-Ins „Datenträgerverwaltung“ (DISKMGMT.MSC) bemerken Sie, dass mindestens ein Volume ohne Bezeichnung oder Laufwerkbuchstabe und mit einer Größe von 1 MB aufgelistet ist. Unter Umständen können Sie das unbekannte Volume löschen, oder Sie erhalten Folgendes:

An Unexpected Error has Occurred

Dieses Verhalten ist beabsichtigt. Dies ist kein Volume, sondern eine Partition. Das Speicherreplikat erstellt eine Partition mit 512 KB als Datenbankslot für Replikationsvorgänge (das Legacytool „DiskMgmt.msc“ rundet auf den nächsten MB-Wert auf). Die Nutzung einer Partition für jedes replizierte Volume ist normal und wünschenswert. Wenn sie nicht mehr verwendet wird, können Sie diese Partition mit 512 KB löschen. Sie können keine Partitionen löschen, die noch verwendet werden. Die Partition vergrößert oder verkleinert sich nicht. Beim Neuerstellen einer Replikation empfehlen wir Ihnen, die Partition beizubehalten, da nicht verwendete Partitionen vom Speicherreplikat beansprucht werden.

Verwenden Sie zum Anzeigen der Details das DISKPART-Tool oder das Get-Partition-Cmdlet. Diese Partitionen müssen den GPT-Typ 558d43c5-a1ac-43c0-aac8-d1472b2923d1 aufweisen.

Ein Speicherreplikat-Knoten hängt beim Erstellen von Momentaufnahmen

Beim Erstellen einer VSS-Momentaufnahme (durch Sicherung, VSSADMIN usw.) hängt ein Speicherreplikat-Knoten, und Sie müssen einen Neustart des Knotens erzwingen, um die Wiederherstellung durchzuführen. Hier liegt kein Fehler vor, es ist nur ein hartes Hängen des Servers.

Dieses Problem tritt auf, wenn Sie eine VSS-Momentaufnahme des Protokollvolumes erstellen. Die zugrunde liegende Ursache ist ein Legacyentwurfsaspekt von VSS, nicht das Speicherreplikat. Beim Erstellen einer Momentaufnahme des Speicherreplikat-Protokollvolumes resultiert daraus ein VSS-E/A-Warteschlangenmechanismus, der auf dem Server zu einem Deadlock führt.

Um dieses Verhalten zu verhindern, erstellen Sie keine Momentaufnahmen von Speicherreplikat-Protokollvolumes. Es ist nicht notwendig, Momentaufnahmen von Speicherreplikat-Protokollvolumes zu erstellen, da diese Protokolle nicht wiederhergestellt werden können. Darüber hinaus sollte das Protokollvolume nie andere Workloads enthalten, sodass generell keine Momentaufnahme erforderlich ist.

Hohe Zunahme der E/A-Latenz bei Verwendung von „Direkte Speicherplätze“ mit Speicherreplikaten

Wenn Sie „Direkte Speicherplätze“ mit einem NVME- oder SSD-Cache verwenden und zwischen „Direkte Speicherplätze“-Clustern die Speicherreplikatreplikation konfigurieren, nimmt die Latenz stärker als erwartet zu. Die Änderung der Latenz ist proportional viel größer als bei Verwendung von NVME und SSD in einer Leistungs- und Kapazitätskonfiguration und ohne HDD- bzw. Kapazitätsebene.

Dieses Problem tritt aufgrund von Architektureinschränkungen innerhalb des Protokollmechanismus des Speicherreplikats in Kombination mit der extrem geringen Latenz von NVME im Vergleich zu langsameren Medien auf. Wenn Sie einen „Direkte Speicherplätze“-Cache verwenden, erfolgen die gesamte Lese-/Schreib-E/A der Speicherreplikatprotokolle sowie alle zuletzt durchgeführten Lese-/Schreibvorgänge von Anwendungen im Cache und nicht in der Leistungs- oder Kapazitätsebene. Das bedeutet, dass alle Speicherreplikataktivitäten auf dem einen schnellen Medium ausgeführt werden. Diese Konfiguration wird nicht unterstützt und nicht empfohlen (protokollbezogene Empfehlungen finden Sie unter https://aka.ms/srfaq ).

Wenn Sie „Direkte Speicherplätze“-HDDs verwenden, können Sie den Cache nicht deaktivieren oder umgehen. Wenn Sie nur SSD und NVME verwenden, können Sie nur Leistungs- und Kapazitätsebenen konfigurieren, um dieses Problem zu umgehen. Wenn Sie diese Konfiguration verwenden und die Speicherreplikatprotokolle auf der Leistungsebene nur für die Datenvolumes festlegen, während sich die von ihnen bedienten Datenvolumes nur auf der Kapazitätsebene befinden, vermeiden Sie das oben beschriebene Problem mit der hoher Latenz. Auf dieselbe Weise können Sie bei einer Mischung aus schnelleren und langsameren SSDs ohne NVME vorgehen.

Diese Problemumgehung ist natürlich nicht ideal und kann möglicherweise nicht von allen Kunden genutzt werden. Das für Speicherreplikate zuständige Team arbeitet an einer entsprechenden Optimierung und an einem aktualisierten Protokollmechanismus für die Zukunft, um diese künstlichen Engpässe zu minimieren. Dieses v1.1-Protokoll war erstmals in Windows Server 2019 verfügbar, und seine verbesserte Leistung wird im Serverspeicherblog beschrieben.

Fehler „Datei konnte nicht gefunden werden“ bei Ausführung von Test-SRTopology zwischen zwei Clustern

Beim Ausführen von Test-SRTopology zwischen zwei Clustern und ihren CSV-Pfaden tritt folgender Fehler auf:

PS C:\Windows\system32> Test-SRTopology -SourceComputerName NedClusterA -SourceVolumeName C:\ClusterStorage\Volume1 -SourceLogVolumeName L: -DestinationComputerName NedClusterB -DestinationVolumeName C:\ClusterStorage\Volume1 -DestinationLogVolumeName L: -DurationInMinutes 1 -ResultPath C:\Temp

Validating data and log volumes...
Measuring Storage Replica recovery and initial synchronization performance...
WARNING: Could not find file '\\NedNode1\C$\CLUSTERSTORAGE\VOLUME1TestSRTopologyRecoveryTest\SRRecoveryTestFile01.txt'.
WARNING: System.IO.FileNotFoundException
WARNING:    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options) at Microsoft.FileServices.SR.Powershell.TestSRTopologyCommand.GenerateWriteIOWorkload(String Path, UInt32 IoSizeInBytes, UInt32 Parallel IoCount, UInt32 Duration)at Microsoft.FileServices.SR.Powershell.TestSRTopologyCommand.<>c__DisplayClass75_0.<PerformRecoveryTest>b__0()at System.Threading.Tasks.Task.Execute()
Test-SRTopology : Could not find file '\\NedNode1\C$\CLUSTERSTORAGE\VOLUME1TestSRTopologyRecoveryTest\SRRecoveryTestFile01.txt'.
At line:1 char:1
+ Test-SRTopology -SourceComputerName NedClusterA -SourceVolumeName  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (:) [Test-SRTopology], FileNotFoundException
+ FullyQualifiedErrorId : TestSRTopologyFailure,Microsoft.FileServices.SR.Powershell.TestSRTopologyCommand

Dies wird durch einen bekannten Codefehler in Windows Server 2016 verursacht. Dieses Problem wurde erstmals in Windows Server Version 1709 und den zugehörigen RSAT-Tools behoben. Um eine Lösung für eine niedrigere Version zu erhalten, wenden Sie sich an den Microsoft-Support, und fordern Sie ein Backportupdate an. Es gibt keine Problemumgehung.

Fehler „Angegebenes Volume konnte nicht gefunden werden“ bei Ausführung von Test-SRTopology zwischen zwei Clustern

Beim Ausführen von Test-SRTopology zwischen zwei Clustern und ihren CSV-Pfaden tritt folgender Fehler auf:

PS C:\> Test-SRTopology -SourceComputerName RRN44-14-09 -SourceVolumeName C:\ClusterStorage\Volume1 -SourceLogVolumeName L: -DestinationComputerName RRN44-14-13 -DestinationVolumeName C:\ClusterStorage\Volume1 -DestinationLogVolumeName L: -DurationInMinutes 30 -ResultPath c:\report

Test-SRTopology : The specified volume C:\ClusterStorage\Volume1 cannot be found on computer RRN44-14-09. If this is a cluster node, the volume must be part of a role or CSV; volumes in Available Storage are not accessible
At line:1 char:1
+ Test-SRTopology -SourceComputerName RRN44-14-09 -SourceVolumeName C:\ ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (:) [Test-SRTopology], Exception
    + FullyQualifiedErrorId : TestSRTopologyFailure,Microsoft.FileServices.SR.Powershell.TestSRTopologyCommand

Wenn Sie die CSV-Datei des Quellknotens als Quellvolume angeben, müssen Sie den Knoten auswählen, der die CSV-Datei besitzt. Sie können entweder die CSV-Datei auf den angegebenen Knoten verschieben oder den Knotennamen ändern, den Sie in -SourceComputerName angegeben haben. Dieser Fehler hat in Windows Server 2019 eine verbesserte Meldung erhalten.

Nach einem unerwarteten Neustart mit aktiviertem BitLocker kann nicht auf das Datenlaufwerk im Speicherreplikat zugegriffen werden

Wenn BitLocker auf beiden Laufwerken (Protokolllaufwerk und Datenlaufwerk) und auf beiden Speicherreplikatlaufwerken aktiviert ist, können Sie beim Neustart des primären Servers auch nach dem Aufheben der BitLocker-Sperre auf dem Protokolllaufwerk nicht auf das primäre Laufwerk zugreifen.

Dies entspricht dem erwarteten Verhalten. Um die Daten wiederherzustellen oder auf das Laufwerk zuzugreifen, müssen Sie zuerst das Protokolllaufwerk entsperren und dann „Diskmgmt.msc“ öffnen, um das Datenlaufwerk zu suchen. Schalten Sie das Datenlaufwerk offline und wieder online. Suchen Sie das BitLocker-Symbol auf dem Laufwerk, und entsperren Sie das Laufwerk.

Problem beim Entsperren des Datenlaufwerks auf dem sekundären Server nach dem Abbruch der Speicherreplikatpartnerschaft

Nachdem Sie die SR-Partnerschaft deaktiviert und das Speicherreplikat entfernt haben, ist zu erwarten, dass Sie das Datenlaufwerk des sekundären Servers nicht mit dem entsprechenden Kennwort oder Schlüssel entsperren können.

Sie müssen den Schlüssel oder das Kennwort des Datenlaufwerks des primären Servers verwenden, um das Datenlaufwerk des sekundären Servers zu entsperren.

Testfailover wird bei Verwendung der asynchronen Replikation nicht eingebunden

Beim Ausführen von Mount-SRDestination, um ein Zielvolume als Teil der Testfailoverfunktion online zu stellen, tritt folgender Fehler auf:

Mount-SRDestination: Unable to mount SR group <TEST>, detailed reason: The group or resource is not in the correct state to perform the supported operation.
    At line:1 char:1
    + Mount-SRDestination -ComputerName SRV1 -Name TEST -TemporaryP . . .
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: (MSFT WvrAdminTasks : root/Microsoft/...(MSFT WvrAdminTasks : root/Microsoft/. T_WvrAdminTasks) (Mount-SRDestination], CimException
        + FullyQua1ifiedErrorId : Windows System Error 5823, Mount-SRDestination.

Bei Verwendung eines synchronen Partnerschaftstyps funktioniert das Testfailover normal.

Dies wird durch einen bekannten Codefehler in Windows Server Version 1709 verursacht. Installieren Sie das Update vom 18. Oktober 2018, um dieses Problem zu beheben. Dieses Problem tritt in Windows Server 2019 und Windows Server Version 1809 und höher nicht auf.

Zusätzliche Referenzen

• Speicherreplikat
• Replikation eines Stretched Clusters mithilfe von freigegebenem Speicher
• Server-zu-Server-Speicherreplikation
• Cluster-zu-Cluster-Speicherreplikation
• Speicherreplikat: Häufig gestellte Fragen
• Direkte Speicherplätze