Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel werden einige der bekannten Probleme mit dem Speicherreplikat in Windows Server beschrieben.
Datenträger sind offline, nachdem Sie die Replikation entfernt haben, und Sie können die Replikation nicht einrichten.
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, löschen Sie die ausgeblendete Speicherreplikatpartition von den Datenträgern und geben sie mithilfe des Clear-SRMetadata
Cmdlets in einen schreibbaren Zustand zurück.
Verwenden Sie den
-AllPartitions
Parameter, um alle verwaisten Speicherreplikat-Partitionsdatenbankplätze zu entfernen und alle Partitionen erneut zu hosten:Clear-SRMetadata -AllPartitions
Um alle verwaisten Speicherreplikatprotokolldaten zu entfernen, verwenden Sie den
-AllLogs
Parameter:Clear-SRMetadata -AllLogs
Verwenden Sie den
-AllConfiguration
Parameter, um alle verwaisten Failoverclusterkonfigurationsdaten zu entfernen:Clear-SRMetadata -AllConfiguration
Um einzelne Replikationsgruppenmetadaten zu entfernen, verwenden Sie den
-Name
Parameter, und geben Sie eine Replikationsgruppe an:Clear-SRMetadata -Name RG01 -Logs -Partition
Möglicherweise muss der Server neu gestartet werden, nachdem Sie die Partitionsdatenbank bereinigt haben. Sie können vorübergehend verhindern, dass der Server mit dem -NoRestart
Parameter neu gestartet wird, aber Sie sollten den Neustart nicht überspringen, wenn das Cmdlet einen Neustart einfordert. Dieses Cmdlet entfernt keine Datenvolumes oder Daten, die in diesen Volumes enthalten sind.
Während der ersten Synchronisierung werden Warnungen der Ereignis-ID 4004 im Ereignisprotokoll angezeigt.
Während der ersten Synchronisierung nach der Konfiguration der Replikation können sowohl die Quell- als auch die Zielserver mehrere Warnereignisse mit der StorageReplica\Admin
Ereignis-ID 4004 im Ereignisprotokoll anzeigen. Die Ereignisbeschreibung zeigt den Status "Unzureichende Systemressourcen sind vorhanden, um die API abzuschließen.". Wahrscheinlich werden auch Ereignis-ID 5014-Fehler angezeigt. Diese Ereignisse deuten darauf hin, dass die Server nicht über genügend Arbeitsspeicher (RAM) verfügen, um sowohl die anfängliche 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.
Konfigurieren der Gastreplikation: VMs reagieren nicht mehr.
VMs reagieren nach dem Konfigurieren der Replikation nicht mehr, wenn Gastcluster und Speicherreplikate auf einer freigegebenen virtuelle Festplatte v2 (VHDX) und nicht auf einem freigegebenen Clustervolume (CSV) verwendet werden. Wenn Sie den Hyper-V Host neu starten, reagieren die virtuellen Computer, die Replikationskonfiguration ist jedoch nicht abgeschlossen, und es tritt keine Replikation auf.
Dieses Szenario tritt auf, wenn Sie fltmc.exe attach svhdxflt
verwenden, um die Anforderung für den Host Hyper-V zu umgehen, auf dem eine CSV ausgeführt wird. Dieser Befehl wird nicht unterstützt und ist nur für Test- und Demonstrationszwecke vorgesehen.
Die Ursache für die Verlangsamung ist ein Interoperabilitätsproblem zwischen dem Speicherqualitätsdienst (Storage QoS) in Windows Server und dem manuell zugefügten 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
Konfigurieren Sie die Replikation mithilfe von New-Volume und unterschiedlichen Speicheroptionen
Wenn Sie das New-Volume
Cmdlet mit unterschiedlichen Speichergruppen auf dem Quell- und Zielserver verwenden, z. B. zwei verschiedene SANs oder zwei JBODs mit unterschiedlichen Datenträgern, können Sie die Replikation möglicherweise nicht mithilfe des New-SRPartnership
Cmdlets konfigurieren.
Der angezeigte Fehler könnte diese Ausgabe enthalten:
Data partition sizes are different in those two groups
Verwenden Sie das New-Partition
Cmdlet anstelle von New-Volume
zum Erstellen und Formatieren von Volumes. Das New-Volume
Cmdlet kann die Volumengröße auf verschiedenen Speicherarrays runden. Wenn Sie bereits ein NTFS-Volume (New Technology File System) erstellt haben, können Sie mit Resize-Partition
eines der Volumes vergrößern oder verkleinern, um das andere anzupassen. Sie können diese Methode nicht mit Resilienz-Dateisystemvolumes (ReFS) verwenden. Wenn Sie Diskmgmt oder Server-Manager verwenden, tritt keine Rundung auf.
Test-SRTopology löst Fehler im Zusammenhang mit Namen aus.
Wenn Sie versuchen, Test-SRTopology
zu verwenden, tritt einer der folgenden Fehler auf:
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 eine eingeschränkte Fehlerberichterstattung in Windows Server und gibt die gleiche Ausgabe für viele häufige Probleme 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.
Fehler beim Konfigurieren einer neuen Partnerschaft: „Fehler beim Bereitstellen der Partition“
Wenn Sie versuchen, mithilfe der Verwendung New-SRPartnership
eine neue Replikationspartnerschaft zu erstellen, tritt der folgende Fehler auf:
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 Sie ein Datenvolume auswählen, das sich auf derselben Partition wie das Systemlaufwerk befindet (d. h. bei C:
mit dem Windows-Ordner). Beispielsweise auf einem Laufwerk, das sowohl das Volume C:
als auch das Volume D:
enthält, die aus derselben Partition erstellt wurden. Die Verwendung eines Systemlaufwerks wird im Speicherreplikat nicht unterstützt. In diesem Szenario müssen Sie ein anderes Volume für die Replikation auswählen.
Das Erweitern eines replizierten Volumes schlägt aufgrund eines fehlenden Updates fehl.
Sie versuchen, ein repliziertes Volume zu vergrößern oder zu erweitern, und dieser Fehler tritt auf:
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
Sie verwenden das MMC-Snap-In "Datenträgerverwaltung", und dieser Fehler tritt auf:
Element not found
Die Fehlermeldung „Fehler beim Vorgang mit Rückgabecode 8“ wird auch dann angezeigt, wenn Sie ordnungsgemäß die Größenanpassung des Volumes auf dem Quellserver mithilfe des Befehls Set-SRGroup -Name rg01 -AllowVolumeResize $TRUE
aktivieren.
The issue was fixed in Cumulative Update for Windows 10 version 1607 (Anniversary Update) and Windows Server 2016: December 9, 2016 (KB3201845).
Das Erweitern eines replizierten Volumes schlägt aufgrund eines fehlenden Schritts fehl.
Sie versuchen, die Größe eines replizierten Volumes auf dem Quellserver zu ändern, ohne zuerst festzulegen -AllowResizeVolume $TRUE
, und dieser Fehler tritt 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 Größe des Volumes daran, die Größenanpassung durch Ausführen Set-SRGroup -Name rg01 -AllowVolumeResize $FALSE
zu deaktivieren. Dieser Parameter verhindert, dass Administratoren versuchen, die Größe von Volumes zu ändern, bevor sie sicherstellen, dass genügend Speicherplatz auf dem Zielvolume vorhanden ist, normalerweise weil sie nicht wissen, dass das Speicherreplikat verwendet wird.
Verschieben einer physischen Datenträgerressource zwischen Websites in einem asynchronen Stretchcluster
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. Sie haben beispielsweise versucht, eine Dateiserverrolle auf die asynchrone Website zu verschieben.
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
Wenn Sie das Cluster
PowerShell-Cmdlet verwenden:
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
Verwenden Sie das Set-SRPartnership
Cmdlet, um diese PDR-Datenträger in einem asynchronen gestreckten Cluster zu verschieben. Basierend auf Kundenfeedback wurde das Verhalten ab Windows Server 2019 geändert, um manuelle und automatisierte Failover mit asynchroner Replikation zu ermöglichen.
Hinzufügen von Datenträgern zu einem asymmetrischen Cluster mit zwei Knoten: "Es wurden keine Datenträger gefunden, die für Clusterdatenträger geeignet sind"
Um einen Cluster mit nur zwei Knoten bereitzustellen, versuchen Sie zunächst, die Datenträger am zweiten Standort zu den verfügbaren Datenträgern hinzuzufügen, bevor Sie die Storage Replica-Verbundreplikation hinzufügen. Der folgende Fehler tritt auf:
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 funktioniert nicht mit lokalem Knotenspeicher. Sie können das Speicherreplikat verwenden, um einen Stretchcluster zwischen zwei Gesamtknoten zu replizieren, wobei jeder einen eigenen Satz freigegebener Speicher verwendet.
Ereignis-ID 1241-Warnung wiederholt sich während der ersten Synchronisierung
Sie geben an, dass eine Replikationspartnerschaft asynchron ist und der Quellcomputer wiederholt Ereignis-ID 1241-Warnungsereignisse im Speicherreplikat-Administratorkanal protokolliert. For example:
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
Ereignis-ID 1241: "Das RPO (Recovery Point Objective) des asynchronen Ziels ist nicht verfügbar", tritt in der Regel aus einem der folgenden Gründe auf:
Das asynchrone Ziel ist derzeit nicht verbunden. Das RPO wird möglicherweise verfügbar, nachdem die Verbindung wiederhergestellt wurde.
Das asynchrone Ziel kann nicht mit der Quelle schritthalten, sodass der neueste 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 Ereignis erwartet und kann sicher ignoriert werden. Das Ereignisverhalten kann sich in einer späteren Version ändern. Wenn dieses Verhalten während der fortlaufenden asynchronen Replikation angezeigt wird, untersuchen Sie die Partnerschaftsbeziehung, um zu ermitteln, warum die Replikation über das konfigurierte RPO hinaus verzögert wird (standardmäßig 30 Sekunden).
Die Warnung mit der Ereignis-ID 4004 wird wiederholt, nachdem Sie einen replizierten Knoten neu gestartet haben.
Unter seltenen Umständen führt der Neustart eines Servers, der sich in einer Partnerschaft befindet, zu einem Replikationsfehler. Der neu gestartete Knoten protokolliert die Ereignis-ID 4004 als Warnungsereignis mit einem Fehler "Zugriff verweigert".
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.
Note Status: "{Access Denied}"
and the message A process has requested access to an object, but has not been granted those access rights.
This is a known issue within Storage Replica and was fixed in Quality Update September 12, 2017 KB4038782 (OS Build 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 einen Clusterdatenträger nach einem erfolgreichen Failover online schalten möchten, versuchen Sie, den ursprünglichen Quellstandort erneut als primär festzulegen, und im Failovercluster-Manager tritt ein Fehler auf.
For example:
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 die CSV manuell zu verschieben, tritt ein anderer Fehler auf. For example:
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 tritt auf, wenn mindestens eine nicht initialisierte Festplatte an einen oder mehrere Clusterknoten angefügt ist. Um das Problem zu beheben, initialisieren Sie allen angefügten Speicher mithilfe von DiskMgmt.msc
, DiskPart.exe
oder dem Initialize-Disk
-PowerShell-Cmdlet.
Wir arbeiten an einem Update, das dieses Problem dauerhaft behebt. Weitere Informationen erhalten Sie beim Microsoft-Support.
GPT-Fehler beim Versuch, eine neue Speicherreplikatpartnerschaft zu erstellen
Sie führen das New-SRPartnership
Cmdlet aus, schlägt aber fehl und zeigt diesen Fehler an:
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
Sie können die Replikation für den Datenträger nicht mithilfe des Failovercluster-Managers einrichten.
Sie führen das Test-SRTopology
Cmdlet aus, aber es schlägt fehl und zeigt die folgende Ausgabe an:
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
Der Fehler tritt auf, da die Clusterfunktionsebene weiterhin auf Windows Server 2012 R2 (d. h. FL 8) festgelegt ist. Speicherreplikat soll hier einen bestimmten Fehler zurückgeben, stattdessen wird eine falsche Fehlerzuordnung zurückgegeben.
Führen Sie in einer PowerShell-Sitzung mit Administratorberechtigungen den folgenden Befehl auf jedem Knoten aus:
Get-Cluster | fl *
Wenn das ClusterFunctionalLevel
-Attribut 9
oder höher ist, wird der falsche Wert zur Implementierung von Storage Replica festgelegt. Entspricht ClusterFunctionalLevel
nicht 9
Fall, dann muss ClusterFunctionalLevel
aktualisiert werden, um die Speicherreplikation auf diesem Knoten zu implementieren.
To resolve the issue, raise the cluster functional level by running the PowerShell cmdlet Update-ClusterFunctionalLevel.
Das kleine unbekannte Volume ist in DISKMGMT für jedes replizierte Volume aufgeführt
Wenn Sie das Datenträgerverwaltungs-Snap-In (DiskMgmt.msc
) ausführen, stellen Sie fest, dass ein oder mehrere Volumes ohne Bezeichnung oder Laufwerkbuchstaben aufgeführt sind. Die Volumes sind 1 MB groß. Möglicherweise können Sie die unbekannten Volumes löschen, oder es wird folgender Fehler angezeigt:
An Unexpected Error has Occurred
Diese Nachricht wird erwartet und ist beabsichtigt. Die aufgelisteten Elemente sind Partitionen und keine Volumes. Das Speicherreplikat erstellt eine 512-KB-Partition als Datenbankplatz für Replikationsvorgänge (das Legacytool DiskMgmt.msc
rundet auf das nächste Megabyte ab). Es ist typisch, dass für jedes replizierte Volume eine Partition wie diese vorhanden ist. Wenn der Datenträger nicht mehr vom Speicherreplikat verwendet wird, können Sie diese 512-KB-Partition löschen. Sie können eine Partition nicht löschen, wenn sie verwendet wird. Die Partitionsgröße ändert sich nie. Wenn Sie eine Replikation erneut erstellen, empfehlen wir, die Partition zu löschen, da Storage Replica nicht genutzte Partitionen beansprucht.
Verwenden Sie zum Anzeigen von Details das DISKPART-Tool oder das Get-Partition
Cmdlet. Diese Partitionen weisen einen GPT-Typ 558d43c5-a1ac-43c0-aac8-d1472b2923d1
auf.
Ein Speicherreplikatknoten reagiert nicht mehr, wenn Sie Momentaufnahmen erstellen
You create a Volume Shadow Copy Service (VSS) snapshot, such as through backup or by using vssadmin, and a Storage Replica node stops responding, or hangs. Sie müssen einen Neustart des Knotens erzwingen, um die Funktionalität wiederherzustellen.
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 Szenario vorzubeugen. Die Protokolle können nicht wiederhergestellt werden, sodass keine Momentaufnahme der Protokollvolumes erforderlich ist. Außerdem sollte das Protokollvolume niemals andere Workloads enthalten, daher ist im Allgemeinen keine Momentaufnahme erforderlich.
Hohe E/A-Latenz, wenn Sie Storage Spaces Direct mit Speicherreplikat verwenden
Wenn Sie Storage Spaces Direct mit einem nicht flüchtigen Speicherexpressgerät (NVMe) oder einem SSD-Cache (Solid State Drive) verwenden, kommt es bei der Konfiguration der Speicherreplikat-Replikation zwischen Storage Spaces Direct-Clustern zu einer höheren als erwarteten Latenz. 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 Architekturbeschränkungen im Speicherreplikatprotokollmechanismus in Kombination mit der niedrigen Latenz 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. Alle Speicherreplikataktivitäten werden auf Medien mit gleicher Geschwindigkeit ausgeführt. Die Konfiguration wird unterstützt, es wird jedoch nicht empfohlen. Protokollempfehlungen finden Sie unter Häufig gestellte Fragen zum Speicherreplikat.
Wenn Sie Direkte Speicherplätze mit HDDs verwenden, können Sie das Erstellen eines Caches nicht deaktivieren oder vermeiden. Als Problemumgehung können Sie, wenn Sie nur SSD und NVMe verwenden, nur Leistungs- und Kapazitätsstufen konfigurieren. Wenn Sie in diesem Szenario nur die Speicherreplikatprotokolle auf der Leistungsebene platzieren und nur die Datenvolumes platzieren, die sie auf der Kapazitätsebene verwenden, vermeiden Sie ein Szenario mit hoher Latenz. Sie können ein ähnliches Ergebnis erzielen, indem Sie eine Mischung aus schnelleren und langsameren SSDs und keinem NVMe verwenden.
Diese Problemumgehung ist nicht ideal, und einige Kunden können sie möglicherweise nicht verwenden. Das Speicherreplikatteam arbeitet an Optimierungen und einem aktualisierten Protokollmechanismus, um diese künstlichen Engpässe zu reduzieren. Dieses v1.1-Protokoll wurde zuerst in Windows Server 2019 verfügbar. Die verbesserte Leistung wird unter "Storage" bei Microsoft beschrieben.
Fehler "Datei konnte nicht gefunden werden", wenn Sie Test-SRTopology zwischen zwei Clustern ausführen
Sie führen das Test-SRTopology
Cmdlet zwischen zwei Clustern aus, aber ihre CSV-Pfade schlagen fehl, und dieser Fehler wird angezeigt:
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 tritt aufgrund eines bekannten Codefehlers in Windows Server 2016 auf. 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", wenn Sie Test-SRTopology zwischen zwei Clustern ausführen.
Sie führen das Test-SRTopology
Cmdlet zwischen zwei Clustern aus, aber ihre CSV-Pfade schlagen fehl, und dieser Fehler wird angezeigt:
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 den Quellknoten CSV als Quellvolume angeben, müssen Sie den Knoten auswählen, der die CSV besitzt. Sie können die CSV-Datei entweder in den angegebenen Knoten verschieben oder den von Ihnen festgelegten -SourceComputerName
Knotennamen ändern. In Windows Server 2019 wurde eine verbesserte Meldung eingeführt.
Sie können nach einem unerwarteten Neustart nicht auf das Datenlaufwerk im Speicherreplikat zugreifen, wenn BitLocker aktiviert ist.
Wenn BitLocker auf beiden Laufwerken (dem Protokolllaufwerk und dem Datenlaufwerk) aktiviert ist, wird der primäre Server neu gestartet. Nach dem Neustart des Servers können Sie nicht auf das primäre Laufwerk zugreifen, auch nachdem Sie das Protokolllaufwerk in BitLocker entsperrt haben.
Um die Daten wiederherzustellen oder auf das Laufwerk zuzugreifen, entsperren Sie zuerst das Protokolllaufwerk, und öffnen Diskmgmt.msc
Sie dann, um das Datenlaufwerk zu suchen. Markieren Sie das Datenlaufwerk als offline und dann erneut online. Suchen Sie das BitLocker-Symbol auf dem Laufwerk, und entsperren Sie das Laufwerk.
Sie können das Datenlaufwerk auf dem sekundären Server nicht entsperren, nachdem Sie die Speicherreplikatpartnerschaft aufgehoben haben.
Nachdem Sie die Speicherreplikatpartnerschaft deaktiviert und dann die Partnerschaft entfernt haben, können Sie das Datenlaufwerk des sekundären Servers nicht mithilfe des entsprechenden Kennworts oder Schlüssels entsperren.
Um das Datenlaufwerk des sekundären Servers zu entsperren, müssen Sie den Schlüssel oder das Kennwort des Datenlaufwerks des primären Servers verwenden.
Testfailover wird bei Verwendung der asynchronen Replikation nicht eingebunden
Sie führen das Mount-SRDestination
Cmdlet aus, um ein Zielvolume online zu bringen, während ein Testfailover fehlschlägt. Zudem wird folgender Fehler angezeigt:
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
+ FullyQualifiedErrorId : Windows System Error 5823, Mount-SRDestination.
Bei Verwendung eines synchronen Partnerschaftstyps funktioniert das Testfailover normal.
Ein bekannter Codefehler in Windows Server, Version 1709, verursacht diesen Fehler. Installieren Sie das Update vom 18. Oktober 2018, um dieses Problem zu beheben. Das Problem ist in Windows Server 2019 und höheren Versionen nicht vorhanden.
Sie können speicherreplikate nicht mit einer physischen Sektorgröße einrichten, die größer als 4 KB ist.
Derzeit unterstützt das Speicherreplikat keine Datenträger mit einer physischen Sektorgröße, die größer als 4 KB ist. Weitere Informationen und Lösungen finden Sie unter Problembehandlung bei der Größe des 4-KB-Datenträgersektors.