記憶域レプリカに関する既知の問題Known issues with Storage Replica

適用先:Windows Server 2019、Windows Server 2016、Windows Server (半期チャネル)Applies to: Windows Server 2019, Windows Server 2016, Windows Server (Semi-Annual Channel)

このトピックでは、Windows Server の記憶域レプリカに関する既知の問題について説明します。This topic discusses known issues with Storage Replica in Windows Server.

レプリケーションの削除後ディスクがオフラインになり、再度レプリケーションを構成することができないAfter removing replication, disks are offline and you cannot configure replication again

Windows Server 2016 では、以前レプリケートされていたボリューム上でレプリケーションをプロビジョニングできないことや、マウントできないボリュームが見つかることがあります。In Windows Server 2016, you may be unable to provision replication on a volume that was previously replicated or may find un-mountable volumes. これは、何らかのエラー状態によりレプリケーションを削除できない場合、または以前データをレプリケートしていたコンピューターにオペレーティング システムを再インストールする場合に発生する可能性があります。This may occur when some error condition prevents removal of replication or when you reinstall the operating system on a computer that was previously replicating data.

この問題を修正するには、Clear-SRMetadata コマンドレットを使用し、非表示の記憶域レプリカのパーティションをディスクから削除して、書き込み可能な状態に戻す必要があります。To fix, you must clear the hidden Storage Replica partition off the disks and return them to a writeable state using the Clear-SRMetadata cmdlet.

  • 孤立したすべての記憶域レプリカ パーティション データベース スロットを削除し、すべてのパーティションを再マウントするには、次のように -AllPartitions パラメーターを使用します。To remove all orphaned Storage Replica partition databases slots and remount all partitions, use the -AllPartitions parameter as follows:

    Clear-SRMetadata -AllPartitions
    
  • 孤立したすべての記憶域レプリカのログ データを削除するには、次のように -AllLogs パラメーターを使用します。To remove all orphaned Storage Replica log data, use the -AllLogs parameter as follows:

    Clear-SRMetadata -AllLogs
    
  • 孤立したすべてのフェールオーバー クラスターの構成データを削除するには、次のように -AllConfiguration パラメーターを使用します。To remove all orphaned failover cluster configuration data, use the -AllConfiguration parameter as follows:

    Clear-SRMetadata -AllConfiguration
    
  • 個々 のレプリケーション グループのメタデータを削除するには、次のように、-Name パラメーターを使用してレプリケーション グループを指定します。To remove individual replication group metadata, use the -Name parameter and specify a replication group as follows:

    Clear-SRMetadata -Name RG01 -Logs -Partition
    

パーティション データベースのクリーンアップ後にサーバーの再起動が必要になる場合があります。これは -NoRestart によって一時的に抑制することができますが、サーバーの再起動がコマンドレットによって要求された場合、スキップすることはできません。The server may need to restart after cleaning the partition database; you can suppress this temporarily with -NoRestart but you should not skip restarting the server if requested by the cmdlet. このコマンドレットは、データ ボリュームやこれらのボリュームに含まれるデータを削除しません。This cmdlet does not remove data volumes nor data contained within those volumes.

初回同期時にイベント ログ 4004 の警告が表示されるDuring initial sync, see event log 4004 warnings

Windows Server 2016 では、レプリケーションを構成するときに、移行元と移行先の両方のサーバーで、最初の同期中に複数の *StorageReplica\Admin log 4004 警告が表示されることがあります。 "API を完了するには、システムリソースが不足しています" という状態になります。In Windows Server 2016, when configuring replication, both the source and destination servers may show multiple *StorageReplica\Admin- event log 4004 warnings each during initial sync, with a status of "insufficient system resources exist to complete the API". 5014 エラーも表示される可能性があります。You are likely to see 5014 errors as well. これは、初回同期とワークロードの実行の両方を行うのに十分なメモリ (RAM) がサーバーにないことを示します。These indicate that the servers do not have enough available memory (RAM) to perform both initial synchronization as well as run workloads. RAM を追加するか、記憶域レプリカ以外の機能とアプリケーションで使用されている RAM を削減してください。Either add RAM or reduce the used RAM from features and applications other than Storage Replica.

共有 VHDX を使用するゲスト クラスターと CSV を使用しないホストを併用すると、仮想マシンがレプリケーションの構成後に応答を停止するWhen using guest clusters with Shared VHDX and a host without a CSV, virtual machines stop responding after configuring replication

Windows Server 2016 では、記憶域レプリカのテストまたはデモのために Hyper-V ゲスト クラスターを使用し、ゲスト クラスターの記憶域として共有 VHDX を使用すると、レプリケーションの構成後に仮想マシンの応答が停止します。In Windows Server 2016, when using Hyper-V guest clusters for Storage Replica testing or demonstration purposes, and using Shared VHDX as the guest cluster storage, the virtual machines stop responding after you configure replication. Hyper-V ホストを再起動すると仮想マシンは応答を開始しますが、レプリケーションの構成が不完全になり、レプリケーションは発生しません。If you restart the Hyper-V host, the virtual machines start responding but replication configuration will not be complete and no replication will occur.

この動作は、CSV を実行している Hyper-v ホストの要件を回避するために、*fltmc.exe attach svhdxflt を使用している場合に発生します。This behavior occurs when you are using *fltmc.exe attach svhdxflt- to bypass the requirement for the Hyper-V host running a CSV. このコマンド使用はサポートされておらず、用途はテストとデモのみに限られています。Use of this command is not supported and is intended only for test and demonstration purposes.

遅延の原因は、Windows Server 2016 の記憶域 QoS 機能と、手動で接続されている共有 VHDX フィルターの間にある、仕様による相互運用性の問題です。The cause of the slowdown is a by-design interoperability issue between the Storage QoS feature in Windows Server 2016 and the manually attached Shared VHDX filter. この問題を解決するには、記憶域 QoS フィルター ドライバーを無効にし、Hyper-V ホストを再起動します。To resolve this issue, disable the Storage QoS filter driver and restart the Hyper-V host:

SC config storqosflt start= disabled

新しいボリュームと別の記憶域を使用するとレプリケーションを構成できないCannot configure replication when using New-Volume and differing storage

2 つの異なる SAN や、異なるディスクを使用する 2 つの JBOD など、レプリケーション元と先で異なる一連の記憶域を New-Volume コマンドレットで使用すると、後で New-SRPartnership を使用してレプリケーションを構成できない可能性があります。When using the New-Volume cmdlet along with differing sets of storage on the source and destination server, such as two different SANs or two JBODs with differing disks, you may not be able to subsequently configure replication using New-SRPartnership. 以下のようなエラーが表示される場合があります。The error shown may include:

Data partition sizes are different in those two groups

ボリュームの作成とフォーマットには、New-Volume ではなく New-Partition** を使用してください。これは、前者のコマンドレットは、異なるストレージ アレイ上のボリューム サイズを丸める場合があるためです。Use the New-Partition** cmdlet to create volumes and format them instead of New-Volume, as the latter cmdlet may round the volume size on differing storage arrays. NTFS ボリュームをすでに作成してある場合、Resize-Partition を使用してボリュームのいずれかを拡大または縮小し、もう片方のボリュームに一致させることができます (これは、ReFS ボリュームでは行うことができません)。If you have already created an NTFS volume, you can use Resize-Partition to grow or shrink one of the volumes to match the other (this cannot be done with ReFS volumes). *Diskmgmt.msc-または サーバーマネージャー を使用する場合、丸め処理は行われません。If using *Diskmgmt- or Server Manager, no rounding will occur.

Test-SRTopology を使用しようとすると、次のエラーのうちいずれかが表示されます。When attempting to use Test-SRTopology, you receive one of the following errors:

エラーの例 1:ERROR EXAMPLE 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

エラーの例 2:ERROR EXAMPLE 2:

WARNING: Invalid value entered for source computer name

エラーの例 3:ERROR EXAMPLE 3:

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

Windows Server 2016 では、このコマンドレットのエラー報告が制限されており、多くの一般的な問題で同じ出力が返されます。This cmdlet has limited error reporting in Windows Server 2016 and will return the same output for many common issues. このエラーは、次の理由で表示されることがあります。The error can appear for the following reasons:

  • ドメイン ユーザーではなくローカル ユーザーとしてレプリケーション元のコンピューターにログオンしている。You are logged on to the source computer as a local user, not a domain user.

  • レプリケーション先のコンピューターが実行されていないか、ネットワーク経由でアクセスできない。The destination computer is not running or is not accessible over the network.

  • レプリケーション先のコンピューターに正しくない名前を指定している。You specified an incorrect name for the destination computer.

  • レプリケーション先サーバーの IP アドレスを指定している。You specified an IP address for the destination server.

  • レプリケーション先コンピューターのファイアウォールで PowerShell や CIM 呼び出しへのアクセスがブロックされている。The destination computer firewall is blocking access to PowerShell and/or CIM calls.

  • レプリケーション先のコンピューターで WMI サービスが実行されていない。The destination computer is not running the WMI service.

  • Test-SRTopology コマンドレットを管理コンピューターからリモートで実行するときに CREDSSP を使用していない。You did not use CREDSSP when running the Test-SRTopology cmdlet remotely from a management computer.

  • 指定されたレプリケーション元またはレプリケーション先のボリュームはクラスター ノード上のローカル ディスクであり、クラスター ディスクではない。The source or destination volume specified are local disks on a cluster node, not clustered disks.

新しい記憶域レプリカのパートナーシップを構成するとエラー "パーティションのプロビジョニングを実行できませんでした" が表示されるConfiguring new Storage Replica partnership returns an error - "Failed to provision partition"

New-SRPartnership を使用して新しいレプリケーション パートナーシップを作成しようとすると、次のエラーが表示されます。When attempting to create a new replication partnership with New-SRPartnership, you receive the following error:

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

これは、システムドライブと同じパーティションにあるデータボリューム (つまり、*C:-ドライブとその Windows フォルダー) を選択することによって発生します。This is caused by selecting a data volume that is on the same partition as the System Drive (i.e. the *C:- drive with its Windows folder). たとえば、同じパーティションから作成された *C:-と *D:-ボリュームの両方が含まれているドライブがあるとします。For instance, on a drive that contains both the *C:- and *D:- volumes created from the same partition. この操作は記憶域レプリカではサポートされていないため、別のボリュームをレプリケート対象として選択する必要があります。This is not supported in Storage Replica; you must pick a different volume to replicate.

レプリケートされたボリュームを拡大しようとすると、更新プログラムがないために失敗するAttempting to grow a replicated volume fails due to missing update

レプリケートされたボリュームを拡大しようとすると、次のようなエラーが表示されます。When attempting to grow or extend a replicated volume, you receive the following error:

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

ディスク管理 MMC スナップインを使用する場合、次のエラーが表示されます。If using the Disk Management MMC snapin, you receive this error:

Element not found

このエラーは、Set-SRGroup -Name rg01 -AllowVolumeResize $TRUE を使用してソース サーバーでボリュームのサイズ変更を正しく有効化した場合にも発生します。This occurs even if you correctly enable volume resizing on the source server using Set-SRGroup -Name rg01 -AllowVolumeResize $TRUE.

この問題は、Windows 10 バージョン 1607 (記念日更新) および Windows Server 2016: 2016 (KB3201845) の累積的な更新プログラムで修正されました。This issue was fixed in Cumulative Update for Windows 10, version 1607 (Anniversary Update) and Windows Server 2016: December 9, 2016 (KB3201845).

レプリケートされたボリュームを拡大しようとすると、ステップがないために失敗するAttempting to grow a replicated volume fails due to missing step

まず -AllowResizeVolume $TRUE を設定せずにソース サーバーでレプリケートされたボリュームをサイズ変更しようとした場合、次のエラーが発生します。If you attempt to resize a replicated volume on the source server without setting -AllowResizeVolume $TRUE first, you will receive the following errors:

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

ソースデータパーティションを拡張する前に、コピー先のデータパーティションに、同じサイズに拡張するための十分な領域があることを確認してください。Before you grow the source data partition, ensure that the destination data partition has enough space to grow to an equal size. 記憶域レプリカによって保護されているデータパーティションの圧縮がブロックされています。Shrinking of data partition protected by Storage Replica is blocked.

ディスク管理スナップイン エラー:Disk Management Snap-in Error:

An unexpected error has occurred

ボリュームをサイズ変更したら、必ず Set-SRGroup -Name rg01 -AllowVolumeResize $FALSE を使ってサイズ変更を無効にしてください。After resizing the volume, remember to disable resizing with Set-SRGroup -Name rg01 -AllowVolumeResize $FALSE. このパラメーターを使うと、管理者はターゲット ボリュームに十分なスペースがあることを確認するまでボリュームのサイズを変更することができません。通常は、記憶域レプリカが存在していることがわからないためです。This parameter prevents admins from attempting to resize volumes prior to ensuring that there is sufficient space on the destination volume, typically because they were unaware of Storage Replica's presence.

非同期ストレッチ クラスター上のサイト間で PDR リソースを移動する試みが失敗するAttempting to move a PDR resource between sites on an asynchronous stretch cluster fails

非同期ストレッチ クラスター内の関連する記憶域を移動するために、物理ディスク リソースに接続された役割の移動を試みると (一般的な用途のファイル サーバーなど)、エラーが表示されます。When attempting to move a physical disk resource-attached role - such as a file server for general use - in order to move the associated storage in an asynchronous stretch cluster, you receive an error.

フェールオーバー クラスター マネージャー スナップインを使用する場合:If using the Failover Cluster Manager snap-in:

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

クラスター PowerShell コマンドレットを使用する場合:If using the Cluster powershell cmdlet:

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

このような状況は、Windows Server 2016 の仕様による動作が原因で発生します。This occurs due to a by-design behavior in Windows Server 2016. 非同期ストレッチ クラスター内でこうした PDR ディスクを移動するには、Set-SRPartnership を使用してください。Use Set-SRPartnership to move these PDR disks in an asynchronous stretched cluster.

この動作は、お客様からのフィードバックに基づいて、手動および自動フェールオーバーを非同期レプリケーションで許可するように、Windows Server バージョン1709で変更されています。This behavior has been changed in Windows Server, version 1709 to allow manual and automated failovers with asynchronous replication, based on customer feedback.

非対称の 2 ノード クラスターへのディスクの追加を試みると、"クラスター ディスクに適したディスクが見つかりません" というメッセージが返されるAttempting to add disks to a two-node asymmetric cluster returns "No disks suitable for cluster disks found"

ノードが 2 つのみのクラスターのプロビジョニングを試みる場合は、記憶域レプリカ ストレッチ レプリケーションを追加する前に、使用可能なディスクへの 2 番目のサイトのディスクの追加を試みます。When attempting to provision a cluster with only two nodes, prior to adding Storage Replica stretch replication, you attempt to add the disks in the second site to the Available Disks. 次のエラーが表示されます。You receive the following error:

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.

クラスターに少なくとも 3 つのノードがある場合、このエラーは発生しません。This does not occur if you have at least three nodes in the cluster. この問題は、Windows Server 2016 での非対称記憶域クラスタリング動作に関する設計上のコード変更のために発生します。This issue occurs because of a by-design code change in Windows Server 2016 for asymmetric storage clustering behaviors.

記憶域を追加するには、2 つ目のサイト内のノードで次のコマンドを実行できます。To add the storage, you can run the following command on the node in the second site:

Get-ClusterAvailableDisk -All | Add-ClusterDisk

これは、ノードのローカル ストレージでは機能しません。This will not work with node local storage. 記憶域レプリカを使うと、それぞれ独自の共有ストレージ セットを使う 合計 2 つのノード間でストレッチ クラスターをレプリケートできます。You can use Storage Replica to replicate a stretch cluster between two total nodes, each one using its own set of shared storage.

記憶域レプリカの帯域幅を調整する SMB 帯域幅リミッタが失敗するThe SMB Bandwidth limiter fails to throttle Storage Replica bandwidth

記憶域レプリカに帯域幅の制限を指定する場合、制限は無視され、帯域幅全体を使用します。When specifying a bandwidth limit to Storage Replica, the limit is ignored and full bandwidth used. 次に例を示します。For example:

Set-SmbBandwidthLimit  -Category StorageReplication -BytesPerSecond 32MB

この問題は、記憶域レプリカと SMB 間の相互運用性の問題のために発生します。This issue occurs because of an interoperability issue between Storage Replica and SMB.

初期同期中に イベント 1241 警告が繰り返されるEvent 1241 warning repeated during initial sync

レプリケーション パートナーシップを非同期に指定すると、ソース コンピューターで警告イベント 1241 が記憶域レプリカの管理者チャネルで繰り返し記録されます。When specifying a replication partnership is asynchronous, the source computer repeatedly logs warning event 1241 in the Storage Replica Admin channel. 次に例を示します。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

ガイダンス: 通常、これは次のいずれかの理由で発生します。Guidance: This is typically due to one of the following reasons:

  • 非同期の宛先は、現在切断されています。The asynchronous destination is currently disconnected. 接続が復元した後に、RPO が利用可能になる可能性があります。The RPO may become available after the connection is restored.

  • 非同期の転送先は、ソースログに最新の宛先ログレコードが存在しないように、ソースのペースを維持することができません。The asynchronous destination is unable to keep pace with the source such that the most recent destination log record is no longer present in the source log. コピー先のブロックコピーが開始されます。The destination will start block copying. ブロックのコピーが完了すると、RPO が使用できるようになります。The RPO should become available after block copying completes.

これは初期同期中に予期される動作であり、無視しても問題ありません。This is expected behavior during initial sync and can safely be ignored. この動作は、今後のリリースで変更される可能性があります。This behavior may change in a later release. この動作が、継続的な非同期レプリケーション中に発生する場合、パートナーシップを調査して、構成済みのRPO (既定で 30秒) 以上に遅延する理由を判断します。If you see this behavior during ongoing asynchronous replication, investigate the partnership to determine why replication is delayed beyond your configured RPO (30 seconds, by default).

レプリケート ノードを再起動した後にイベント 4004 警告が繰り返されるEvent 4004 warning repeated after rebooting a replicated node

通常は再現できないまれな状況で、パートナーシップ内のサーバーを再起動すると、レプリケーションが失敗し、再起動されたノードで、アクセス拒否エラーと警告イベント 4004 が記録されます。Under rare and usually unreproducable circumstances, rebooting a server that is in a partnership leads to replication failing and the rebooted node logging warning event 4004 with an access denied error.

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.

というメッセージに注意してください。 Status: "{Access Denied}" A process has requested access to an object, but has not been granted those access rights. これは、ストレージレプリカ内の既知の問題であり、2017年9月12日の品質更新プログラム (OS ビルド 14393.1715) で修正されました。 https://support.microsoft.com/help/4038782/windows-10-update-kb4038782Note the 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) https://support.microsoft.com/help/4038782/windows-10-update-kb4038782

ストレッチ クラスターで「リソース 'クラスター ディスク x' をオンラインにできませんでした」エラーが発生するError "Failed to bring the resource 'Cluster Disk x' online." ストレッチクラスターを使用するwith a stretch cluster

正常なフェールオーバー後にクラスター ディスクをオンラインにしようとするとき、元のソース サイトを再度プライマリにしようとすると、フェールオーバー クラスター マネージャーでエラーが発生します。When attempting to bring a cluster disk online after a successful failover, where you are attempting to make the original source site primary again, you receive an error in Failover Cluster Manager. 次に例を示します。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.

ディスクまたは CSV を手動で移動しようとすると、さらにエラーが表示されます。If you attempt to move the disk or CSV manually, you receive an additional error. 次に例を示します。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

この問題は、1つまたは複数の未初期化ディスクが1つ以上のクラスターノードに接続されていることが原因で発生します。This issue is caused by one or more uninitialized disks being attached to one or more cluster nodes. 問題を解決するには、DiskMgmt.msc、DISKPART.EXE、または Initialize-Disk PowerShell コマンドレットを使って、アタッチされたすべてのストレージを初期化します。To resolve the issue, initialize all attached storage using DiskMgmt.msc, DISKPART.EXE, or the Initialize-Disk PowerShell cmdlet.

Microsoft はこの問題を完全に解決するための更新プログラムの提供に取り組んでいます。We are working on providing an update that permanently resolves this issue. マイクロソフト プレミア サポート契約をお持ちのお客様で、この問題の解決にご協力いただける方は、バックポート要求の提出のため、SRFEED@microsoft.com までメールでご連絡ください。If you are interested in assisting us and you have a Microsoft Premier Support agreement, please email SRFEED@microsoft.com so that we can work with you on filing a backport request.

新しい SR パートナーシップを作成しようとすると GPT エラーが発生するGPT error when attempting to create a new SR partnership

New-SRPartnership の実行中にエラーが発生します。When running New-SRPartnership, it fails with error:

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

フェールオーバー クラスター マネージャーの GUIでは、ディスクのレプリケーションを設定するオプションはありません。In the Failover Cluster Manager GUI, there is no option to setup Replication for the disk.

Test-SRTopology の実行中に、次のように失敗します。When running Test-SRTopology, it fails with:

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

これはクラスター機能レベルが Windows Server 2012 R2 (FL 8 など) に設定されたままであることにより発生します。This is caused by the cluster functional level still being set to Windows Server 2012 R2 (i.e. FL 8). 記憶域レプリカは、固有のエラーを返すべきですが、正しくないエラー マッピングが返されています。Storage Replica is supposed to return a specific error here but instead returns an incorrect error mapping.

Run Get-Cluster | fl - on each node.

の場合 ClusterFunctionalLevel = 9 、これは、このノードに記憶域レプリカを実装するために必要な Windows 2016 ClusterFunctionalLevel バージョンです。If ClusterFunctionalLevel = 9, that is the Windows 2016 ClusterFunctionalLevel version needed to implement Storage Replica on this node. ClusterFunctionalLevel が 9でない場合、このノードで記憶域レプリカを実装するためには、ClusterFunctionalLevel を更新する必要があります。If ClusterFunctionalLevel is not 9, the ClusterFunctionalLevel will need to be updated in order to implement Storage Replica on this node.

この問題を解決するには、PowerShell コマンドレット ClusterFunctionalLevelを実行して、クラスターの機能レベルを上げます。To resolve the issue, raise the cluster functional level by running the PowerShell cmdlet: Update-ClusterFunctionalLevel.

レプリケートされた各ボリュームに対し、DISKMGMT に小さな不明パーティションが表示されるSmall unknown partition listed in DISKMGMT for each replicated volume

ディスク管理スナップイン (DISKMGMT.MSC) を実行すると、ラベルやドライブ文字がない 1 MB のサイズのボリュームが 1 つまたは複数表示されます。When running the Disk Management snap-in (DISKMGMT.MSC), you notice one or more volumes listed with no label or drive letter and 1MB in size. この不明なボリュームは削除できる場合もありますが、できない場合は以下のエラー メッセージが表示されることがあります。You may be able to delete the unknown volume or you may receive:

An Unexpected Error has Occurred

この動作は仕様です。This behavior is by design. これはボリュームではなくパーティションです。This not a volume, but a partition. 記憶域レプリカによって、レプリケーション操作のためのデータベース スロットとして 512 KB のパーティションが作成されます (レガシー DiskMgmt.msc ツールによって、MB 単位で最も近いサイズに丸められます)Storage Replica creates a 512KB partition as a database slot for replication operations (the legacy DiskMgmt.msc tool rounds to the nearest MB). レプリケートされた各ボリュームにこのようなパーティションが作成されることは、正常であり適切です。Having a partition like this for each replicated volume is normal and desirable. この 512 KB のパーティションは、不要になれば削除できますが、使用中は削除できません。When no longer in use, you are free to delete this 512KB partition; in-use ones cannot be deleted. パーティションのサイズは、拡大縮小しません。The partition will never grow or shrink. レプリケーションを再作成する場合は、ストレージ レプリカが未使用のパーティションを要求できるように、パーティションを削除せずにおくことをお勧めします。If you are recreating replication we recommend leaving the partition as Storage Replica will claim unused ones.

詳細を表示するには、DISKPART ツールまたは Get-Partition コマンドレットを使用します。To view details, use the DISKPART tool or Get-Partition cmdlet. これらのパーティションには、558d43c5-a1ac-43c0-aac8-d1472b2923d1 という GPT タイプが割り当てられます。These partitions will have a GPT Type of 558d43c5-a1ac-43c0-aac8-d1472b2923d1.

スナップショットの作成時に記憶域レプリカノードがハングするA Storage Replica node hangs when creating snapshots

VSS スナップショット (バックアップ、VSSADMIN など) を作成する場合、記憶域レプリカノードがハングし、回復するノードを強制的に再起動する必要があります。When creating a VSS snapshot (through backup, VSSADMIN, etc) a Storage Replica node hangs, and you must force a restart of the node to recover. サーバーがハードハングするだけで、エラーは発生しません。There is no error, just a hard hang of the server.

この問題は、ログボリュームの VSS スナップショットを作成するときに発生します。This issue occurs when you create a VSS snapshot of the log volume. 根本的な原因は、記憶域レプリカではなく、VSS の従来の設計側面です。The underlying cause is a legacy design aspect of VSS, not Storage Replica. 記憶域レプリカのログボリュームのスナップショットを作成するときの動作は、VSS i/o キューメカニズムによってサーバーがデッドロックされます。The resulting behavior when you snapshot the Storage Replica log volume is a VSS I/O queing mechanism deadlocks the server.

この動作を回避するには、記憶域レプリカのログボリュームをスナップショットにしないようにします。To prevent this behavior, do not snapshot Storage Replica log volumes. これらのログは復元できないため、記憶域レプリカのログボリュームのスナップショットは必要ありません。There is no need to snapshot Storage Replica log volumes, as these logs cannot be restored. さらに、ログボリュームに他のワークロードを含めることはできないため、一般にスナップショットは必要ありません。Furthermore, the log volume should never contain any other workloads, so no snapshot is needed in general.

記憶域レプリカで記憶域スペースダイレクトを使用した場合の IO 待機時間の増加High IO latency increase when using Storage Spaces Direct with Storage Replica

NVME または SSD キャッシュで記憶域スペースダイレクトを使用すると、記憶域スペースダイレクトクラスター間で記憶域レプリカのレプリケーションを構成するときに予想よりも長い待機時間が増加することがわかります。When using Storage Spaces Direct with an NVME or SSD cache, you see a greater than expected increase in latency when configuring Storage Replica replication between Storage Spaces Direct clusters. 待機時間の変更は、パフォーマンス + 容量の構成で NVME と SSD を使用する場合よりも大幅に高くなります。また、HDD 階層も容量レベルもありません。The change in latency is proportionally much higher than you see when using NVME and SSD in a performance + capacity configuration and no HDD tier nor capacity tier.

この問題は、低速メディアと比べて、記憶域レプリカのログメカニズム内のアーキテクチャの制限により、NVME の待機時間が非常に短いことが原因で発生します。This issue occurs due to architectural limitations within Storage Replica's log mechanism combined with the extremely low latency of NVME when compared to slower media. 記憶域スペースダイレクトキャッシュを使用する場合は、記憶域レプリカログのすべての i/o と、最近のアプリケーションの読み取り/書き込み IO がすべてキャッシュ内に作成され、パフォーマンスレベルまたは容量レベルでは発生しません。When using the Storage Spaces Direct cache, all I/O of Storage Replica logs, along with all recent read/write IO of applications, will occur in the cache and never on the performance or capacity tiers. これは、すべての記憶域レプリカアクティビティが同じ速度メディアで実行されることを意味します。この構成はサポートされていますが、推奨されません ( https://aka.ms/srfaq ログに関する推奨事項を参照)。This means that all Storage Replica activity happens on the same speed media - this configuration is supported but not recommended (see https://aka.ms/srfaq for log recommendations).

Hdd で記憶域スペースダイレクトを使用する場合、キャッシュを無効にしたり回避したりすることはできません。When using Storage Spaces Direct with HDDs, you cannot disable or avoid the cache. 回避策として、SSD と NVME のみを使用する場合は、パフォーマンスレベルと容量レベルのみを構成できます。As a workaround, if using just SSD and NVME, you can configure just performance and capacity tiers. この構成を使用していて、そのサービスがキャパシティレベルのみにあるデータボリュームに対してのみ、パフォーマンスレベルに SR ログを配置した場合は、前述の高待機時間の問題を回避できます。If using that configuration, and by placing the SR logs on the performance tier only with the data volumes they service being on the capacity tier only, you will avoid the high latency issue described above. これは、高速で低速な Ssd と NVME が混在している場合にも実行できます。The same could be done with a mix of faster and slower SSDs and no NVME.

この回避策はもちろん理想的ではなく、一部のお客様はそれを利用できない可能性があります。This workaround is of course not ideal and some customers may not be able to make use of it. ストレージレプリカチームは、今後、これらの人為的なボトルネックを減らすために、最適化および更新されたログメカニズムに取り組んでいます。The Storage Replica team is working on optimizations and an updated log mechanism for the future to reduce these artificial bottlenecks. この v2.0 ログは、Windows Server 2019 で最初に利用可能になり、パフォーマンスが向上したことが、 Server Storage のブログで説明されています。This v1.1 log first became available in Windows Server 2019 and its improved performance is described in on the Server Storage Blog.

2つのクラスター間で Test-SRTopology を実行すると、"ファイルが見つかりませんでした" というエラーが発生するError "Could not find file" when running Test-SRTopology between two clusters

2つのクラスターとその CSV パスの間で Test-SRTopology を実行すると、次のエラーで失敗します。When running Test-SRTopology between two clusters and their CSV paths, it fails with error:

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

これは、Windows Server 2016 の既知のコードの不具合が原因で発生します。This is caused by a known code defect in Windows Server 2016. この問題は、Windows Server、バージョン1709、および関連する RSAT ツールで最初に修正されました。This issue was first fixed in Windows Server, version 1709 and the associated RSAT tools. ダウンレベルの解決方法については、Microsoft サポートに連絡し、バックポートの更新を依頼してください。For a downlevel resolution, please contact Microsoft Support and request a backport update. 対応策はありません。There is no workaround.

2つのクラスター間で Test-SRTopology を実行すると、"指定されたボリュームが見つかりませんでした" というエラーが発生するError "specified volume could not be found" when running Test-SRTopology between two clusters

2つのクラスターとその CSV パスの間で Test-SRTopology を実行すると、次のエラーで失敗します。When running Test-SRTopology between two clusters and their CSV paths, it fails with error:

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

ソースノード CSV をソースボリュームとして指定する場合は、CSV を所有するノードを選択する必要があります。When specifying the source node CSV as the source volume, you must select the node that owns the CSV. CSV を指定したノードに移動するか、で指定したノード名を変更することができ -SourceComputerName ます。You can either move the CSV to the specified node or change the node name you specified in -SourceComputerName. このエラーは、Windows Server 2019 で改善されたメッセージを受信しました。This error received an improved message in Windows Server 2019.

BitLocker が有効になっているときに、予期しない再起動後に記憶域レプリカのデータドライブにアクセスできないUnable to access the data drive in Storage Replica after unexpected reboot when BitLocker is enabled

BitLocker が両方のドライブ (ログドライブとデータドライブ) と両方の記憶域レプリカドライブで有効になっている場合、プライマリサーバーが再起動すると、BitLocker からログドライブをロック解除した後でも、プライマリドライブにアクセスできなくなります。If BitLocker is enabled on both drives (Log Drive and Data Drive) and in both Storage replica drives, if the Primary Server reboots then you are unable to access the Primary Drive even after unlocking the Log Drive from BitLocker.

これは予想される現象です。This is an expected behavior. データを回復するか、ドライブにアクセスするには、まずログドライブのロックを解除してから、Diskmgmt.msc を開いてデータドライブを特定する必要があります。To recover the data or access the drive, you need to unlock the log drive first and then open Diskmgmt.msc to locate the data drive. データドライブをオフラインにしてからオンラインにします。Turn the data drive offline and online again. ドライブの BitLocker アイコンを見つけて、ドライブのロックを解除します。Locate the BitLocker icon on the drive and unlock the drive.

記憶域レプリカのパートナーシップを解除した後にセカンダリサーバーのデータドライブのロックを解除する問題Issue unlocking the Data drive on secondary server after breaking the Storage Replica partnership

SR パートナーシップを無効にして記憶域レプリカを削除した後、セカンダリサーバーのデータドライブをそれぞれのパスワードまたはキーを使用してロック解除できない場合は、そのことが想定されます。After Disabling the SR Partnership and removing the Storage Replica, it is expected if you are unable to unlock the Secondary Server's Data drive with its respective password or key.

セカンダリサーバーのデータドライブのロックを解除するには、プライマリサーバーのデータドライブのキーまたはパスワードを使用する必要があります。You need to use Key or Password of Primary Server's Data drive to unlock the Secondary Server's data drive.

非同期レプリケーションを使用する場合、テストフェールオーバーがマウントされないTest Failover doesn't mount when using asynchronous replication

テストフェールオーバー機能の一部として移行先ボリュームをオンラインにするために Mount-SRDestination を実行すると、次のエラーで失敗します。When running Mount-SRDestination to bring a destination volume online as part of the Test Failover feature, it fails with error:

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.

同期パートナーシップの種類を使用する場合、テストフェールオーバーは正常に動作します。If using a synchronous partnership type, test failover works normally.

これは、Windows Server バージョン1709の既知のコードの不具合が原因で発生します。This is caused by a known code defect in Windows Server, version 1709. この問題を解決するには、 2018 年10月18日の更新プログラムをインストールします。To resolve this issue, install the October 18, 2018 update. この問題は、Windows Server 2019 および Windows Server バージョン1809以降には存在しません。This issue isn't present in Windows Server 2019 and Windows Server, version 1809 and newer.

その他のリファレンスAdditional References