Freigeben über

Bekannte Probleme mit Speicherreplikaten

  • Artikel

In diesem Artikel werden einige der bekannten Probleme mit dem Speicherreplikat in Windows Server beschrieben.

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

Sie können möglicherweise auf einem Volume, das zuvor repliziert wurde, keine Replikation bereitstellen, oder es sind Volumes vorhanden, die nicht eingebunden werden können. Es kann vorkommen, dass Datenträger offline bleiben, wenn die Replikation nicht entfernt wird oder wenn Sie das Betriebssystem auf einem Computer neu installieren, der zuvor Daten repliziert 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.

  • Verwenden Sie den Parameter -AllPartitions wie folgt, um alle verwaisten Partitionsdatenbankslots des Speicherreplikats zu entfernen und alle Partitionen neu einzubinden:

    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

Nach dem Bereinigen der Partitionsdatenbank muss der Server möglicherweise neu gestartet werden. Mit -NoRestart kann der Neustart des Servers zwar vorübergehend verhindert werden, wenn vom Cmdlet ein Neustart angefordert wird, sollte dieser jedoch nicht übersprungen werden. Dieses Cmdlet entfernt weder Datenvolumes noch die auf diesen Volumes enthaltenen Daten.

Während der ersten Synchronisierung befinden sich Warnungen mit der Ereignis-ID 4004 im Ereignisprotokoll.

Nach dem Konfigurieren der Replikation können während der ersten Synchronisierung sowohl auf dem Quell- als auch auf dem Zielserver mehrere Warnungsereignisse mit der Ereignis-ID 4004 im Ereignisprotokoll StorageReplica\Admin enthalten sein. Die Ereignisbeschreibung enthält einen Status mit dem Hinweis, dass nicht genügend Systemressourcen vorhanden sind, um die API abzuschließen. Wahrscheinlich werden auch Fehler vom Typ „5014“ angezeigt. Diese Ereignisse deuten darauf hin, dass die Server nicht über genügend Arbeitsspeicher (RAM) verfügen, um sowohl die erste Synchronisierung als auch Workloads auszuführen. Fügen Sie RAM hinzu, oder reduzieren Sie den von Features und Anwendungen (mit Ausnahme des Speicherreplikats) verwendeten Arbeitsspeicher.

Virtuelle Computer reagieren nach dem Konfigurieren der Gastreplikation nicht mehr.

Virtuelle Computer reagieren nach dem Konfigurieren der Replikation nicht mehr, wenn Gastcluster und Speicherreplikate in einer freigegebenen VHDX-Datei (kein freigegebenes Clustervolume) verwendet werden. Wenn Sie den Hyper-V-Host neu starten, reagieren die virtuellen Computer wieder, aber die Replikationskonfiguration ist unvollständig, und es wird keine Replikation durchgeführt.

Dieses Verhalten tritt auf, wenn Sie fltmc.exe attach svhdxflt verwenden, um die Voraussetzung zu umgehen, dass auf dem Hyper-V-Host ein freigegebenes Clustervolume ausgeführt werden muss. Dieser Befehl wird nicht unterstützt und ist ausschließlich für Test- und Demonstrationszwecke bestimmt.

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

SC config storqosflt start= disabled

Die Replikation kann bei Verwendung von „New-Volume“ und unterschiedlichem Speicher nicht konfiguriert werden.

Wenn Sie das Cmdlet New-Volume mit unterschiedlichen Gruppen von Speicher auf Quell- und Zielserver verwenden (beispielsweise zwei verschiedene SANs oder zwei JBODs mit unterschiedlichen Datenträgern), können Sie die Replikation möglicherweise 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. Diese Methode kann bei ReFS-Volumes nicht verwendet werden. Wenn Sie Diskmgmt oder den Server-Manager verwenden, erfolgt keine Rundung.

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 und gibt für viele allgemeine 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 ist nicht aktiv oder über das Netzwerk nicht zugänglich.

  • 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 über einen Verwaltungscomputer nicht „CREDSSP“ verwendet.

  • Das angegebene Quell- oder Zielvolume ist kein Clusterdatenträger, sondern ein lokaler Datenträger auf einem Clusterknoten.

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

Dieser Fehler tritt auf, wenn ein Datenvolume ausgewählt wird, das sich auf der gleichen Partition befindet wie das Systemlaufwerk (Laufwerk C: mit dem zugehörigen Windows-Ordner). Beispielsweise auf einem Laufwerk, das die aus der gleichen Partition erstellten Volumes C: und D: enthält. Die Verwendung eines Systemlaufwerks wird für das Speicherreplikat nicht unterstützt. Wählen Sie ein anderes Volume für die Replikation aus.

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

Bei Verwendung des MMC-Snap-Ins „Datenträgerverwaltung“ wird die folgende Fehlermeldung angezeigt:

Element not found

The operation failed with return code 8 tritt auch auf, wenn Sie das Ändern der Größe von Volumes auf dem Quellserver mithilfe des Befehls Set-SRGroup -Name rg01 -AllowVolumeResize $TRUE ordnungsgemäß aktivieren.

Dieses Problem wurde im kumulativen Update für Windows 10, Version 1607 (Anniversary Update), und für Windows Server 2016 vom 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, Volumegrößen zu ändern, bevor sie sichergestellt haben, dass auf dem Zielvolume ausreichend Speicherplatz verfügbar ist (weil sie wahrscheinlich nicht wussten, dass Speicherreplikate vorhanden sind).

Fehler beim Versuch, eine physische Datenträgerressource in einem asynchronen Stretched Cluster an einen anderen Standort umzuziehen

Beim Versuch, eine mit einer physischen Datenträgerressource verbundene Rolle zu verschieben, um den zugehörigen Speicher in einem asynchronen Stretched Cluster zu verschieben, wird eine Fehlermeldung angezeigt. Beispiel: Verschieben einer Dateiserverrolle an den asynchronen Standort.

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

Verschieben Sie diese PDR-Datenträger mit Set-SRPartnership in einen asynchronen Stretched Cluster. Dieses Verschiebungsverhalten wurde in Windows Server 2019 aufgrund von Kundenfeedback geändert, um 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.

Wenn der Cluster mindestens drei Knoten enthält, tritt der Fehler nicht 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

Der Befehl kann nicht mit lokalem Knotenspeicher verwendet werden. Sie können das Feature „Speicherreplikat“ zum Replizieren eines Stretched Clusters zwischen insgesamt zwei Knoten verwenden, wobei jeder Knoten seinen eigenen freigegebenen Speicher verwendet.

Wiederholung der Warnung mit der Ereignis-ID 1241 während der ersten Synchronisierung

Beim Angeben einer asynchronen Replikationspartnerschaft protokolliert der Quellcomputer wiederholt die Ereignis-ID 1241 im Kanal für die Speicherreplikatverwaltung. Zum 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

Die Ereignis-ID 1241 mit dem Hinweis, dass die Wiederherstellungspunktvorgabe (Recovery Point Objective, RPO) des asynchronen Ziels nicht verfügbar ist, ist in der Regel auf eine der folgenden Ursachen zurückzuführen:

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

Während der ersten Synchronisierung wird dieses Verhalten erwartet und kann ignoriert werden. In einer späteren Version wird das Ereignisverhalten ggf. 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.

Wiederholte Warnung mit der Ereignis-ID 4004 nach Neustart eines replizierten Knotens

In seltenen Fällen führt ein Neustart eines Servers, der Teil einer Partnerschaft ist, zu Replikationsfehlern, und der neu gestartete Zielknoten protokolliert Warnungsereignisse mit der Ereignis-ID 4004 und einem Zugriffsverweigerungsfehler.

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 behoben: KB4038782 (Betriebssystembuild 14393.1715).

Fehler mit dem Hinweis, dass die Ressource „Clusterdatenträger X“ nicht in den Onlinemodus versetzt werden konnte (bei Verwendung eines Stretched Clusters)

Wenn Sie versuchen, einen Clusterdatenträger nach einem erfolgreichen Failover in den Onlinemodus zu versetzen, und dabei den ursprünglichen Quellstandort wieder zum primären Standort machen möchten, erhalten Sie eine Fehlermeldung im Failovercluster-Manager. Zum 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 das freigegebene Clustervolume manuell zu verschieben, erhalten Sie eine weitere 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. Initialisieren Sie zur Behebung des Problems alle Speichermedien mithilfe von „DiskMgmt.msc“ oder „DISKPART.EXE” oder mithilfe des PowerShell-Cmdlets Initialize-Disk.

Wir arbeiten an einem Update, das dieses Problem dauerhaft behebt. Wenden Sie sich an den Microsoft-Support, um weitere Informationen zu erhalten.

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

Beim Ausführen von New-SRPartnership 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

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

Beim Ausführen von Test-SRTopology wird Folgendes ausgegeben:

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

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

Führen Sie in einer PowerShell-Sitzung mit erhöhten Rechten für jeden Knoten den folgenden Befehl aus:

Get-Cluster | fl *

Wenn das Attribut ClusterFunctionalLevel mindestens den Wert 9 hat, ist das die Version, die zum Implementieren des Speicherreplikats erforderlich ist. Wenn ClusterFunctionalLevel nicht den Wert 9 hat, muss ClusterFunctionalLevel aktualisiert werden, damit das Speicherreplikat auf diesem Knoten implementiert werden kann.

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

Kleines unbekanntes Volume in DISKMGMT für jedes replizierte Volume

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

Die obige Meldung ist ein erwartetes Verhalten und beabsichtigt. Die aufgelisteten Elemente sind keine Volumes, sondern Partitionen. 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. Sobald der Datenträger nicht mehr vom Speicherreplikat verwendet wird, können Sie diese 512-KB-Partition löschen. Verwendete Partitionen können nicht gelöscht werden. Die Partition vergrößert oder verkleinert sich nicht. Bei der Neuerstellung einer Replikation empfiehlt es sich, die Partition beizubehalten, da nicht verwendete Partitionen vom Speicherreplikat beansprucht werden.

Verwenden Sie zum Anzeigen von Details das DISKPART-Tool oder das Cmdlet Get-Partition. 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.) bleibt ein Speicherreplikatknoten hängen, und Sie müssen einen Neustart des Knotens erzwingen. Hier liegt kein Fehler vor. Es handelt sich lediglich um einen nicht mehr reagierenden Server.

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.

Erstellen Sie keine Momentaufnahmen von Speicherreplikat-Protokollvolumes, um diesem Verhalten vorzubeugen. 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 E/A-Wartezeit bei Verwendung von „Direkte Speicherplätze“ mit dem Speicherreplikat

Wenn Sie „Direkte Speicherplätze“ mit einem NVMe-Gerät (non-volatile memory express) oder mit SSD-Cache (solid-state drive) verwenden und zwischen Clustern vom Typ „Direkte Speicherplätze“ die Speicherreplikatreplikation konfigurieren, nimmt die Wartezeit stärker zu als erwartet. Die Änderung der Wartezeit 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 geringen Wartezeit von NVMe im Vergleich zu langsameren Medien auf. Wenn Sie einen Cache vom Typ „Direkte Speicherplätze“ verwenden, erfolgen die gesamte Lese-/Schreib-E/A der Speicherreplikatprotokolle sowie alle zuletzt durchgeführten Lese-/Schreibvorgänge von Anwendungen im Cache und nicht auf der Leistungs- oder Kapazitätsebene. Das bedeutet, dass alle Speicherreplikataktivitäten auf dem gleichen schnellen Medium ausgeführt werden. Diese Konfiguration wird nicht unterstützt und nicht empfohlen. (Protokollbezogene Empfehlungen finden Sie in den häufig gestellten Fragen zum Speicherreplikat.)

Wenn Sie „Direkte Speicherplätze“ mit Festplatten verwenden, können Sie den Cache nicht deaktivieren oder umgehen. Wenn Sie nur SSD und NVMe verwenden, können Sie lediglich 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 hohen Wartezeit. Auf die gleiche Weise können Sie bei einer Mischung aus schnelleren und langsameren SSDs ohne NVMe vorgehen.

Diese Problemumgehung ist 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 deren CSV-Pfaden tritt der folgende Fehler auf:

Validating data and log volumes...
Measuring Storage Replica recovery and initial synchronization performance...
WARNING: Could not find file '\\SERVER01\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 '\\SERVER01\C$\CLUSTERSTORAGE\VOLUME1TestSRTopologyRecoveryTest\SRRecoveryTestFile01.txt'.
At line:1 char:1
+ Test-SRTopology -SourceComputerName ClusterA -SourceVolumeName  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (:) [Test-SRTopology], FileNotFoundException
+ FullyQualifiedErrorId : TestSRTopologyFailure,Microsoft.FileServices.SR.Powershell.TestSRTopologyCommand

Der im Beispiel gezeigte Fehler wird durch einen bekannten Codefehler in Windows Server 2016 verursacht. Dieses Problem wurde in Windows Server 2019 und den zugehörigen Remoteserver-Verwaltungstools behoben. Wenden Sie sich an den Microsoft-Support, um eine Lösung für eine niedrigere Version zu erhalten. 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 deren CSV-Pfaden tritt folgender Fehler auf:

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. In Windows Server 2019 wurde eine verbesserte Meldung eingeführt.

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

Wenn BitLocker auf beiden Laufwerken (Protokolllaufwerk und Datenlaufwerk) aktiviert ist und der primäre Server neu gestartet wird, können Sie auch nach dem Aufheben der BitLocker-Sperre für das Protokolllaufwerk nicht auf das primäre Laufwerk zugreifen.

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. Markieren Sie das Datenlaufwerk als offline und anschließend wieder als 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 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 schalten, 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.

Es gibt einen bekannten Codefehler in der Windows Server-Version 1709, der diesen Fehler verursacht. Installieren Sie das Update vom 18. Oktober 2018, um dieses Problem zu beheben. Dieses Problem tritt ab Windows Server 2019 nicht mehr auf.

Einrichten von Speicherreplikaten mit physischen Sektorgrößen größer als 4K nicht möglich

Das Speicherreplikat unterstützt aktuell keine Datenträger mit einer physischen Sektorgröße von mehr als 4K. Wir prüfen derzeit die Implementierung dieser Funktion in zukünftigen Versionen.

Weitere Informationen und Problemumgehungen finden Sie in diesem Dokument.

Nächste Schritte

Nun kennen Sie einige der bekannten Probleme mit dem Speicherreplikat in Windows Server. Hier finden Sie einige Artikel, die Ihnen bei der Verwendung helfen können: