記憶域レプリカに関する FAQ

この記事には、記憶域レプリカに関してよく寄せられる質問に対する回答が含まれています。

ストレージ レプリカは Azure でサポートされていますか?

はい。 Azure では、次のシナリオを使用できます。

• Azure 内のサーバー間レプリケーション (1 つまたは 2 つのデータセンター障害ドメイン内のサービスとしてのインフラストラクチャ (IaaS) 仮想マシン (VM) 間、または 2 つの異なるリージョン間で非同期的に同期的または非同期的に)。
• Azure とオンプレミスの間のサーバー間の非同期レプリケーション (仮想プライベート ネットワーク (VPN) または Azure ExpressRoute を使用)。
• Azure 内のクラスター間レプリケーション (1 つまたは 2 つのデータセンター障害ドメイン内の IaaS VM 間で同期的または非同期的に、または 2 つの異なるリージョン間で非同期的に)。
• Azure とオンプレミスの間のクラスター間の非同期レプリケーション (VPN または Azure ExpressRoute を使用)。
• Azure 共有ディスクを使用したストレッチ クラスタリング (1 つまたは 2 つのデータセンター障害ドメイン内の IaaS VM 間で同期的または非同期的に、または 2 つの異なるリージョン間で非同期的に)。

Azure でのゲスト クラスタリングの詳細については、「Azureでの IaaS VM ゲスト クラスターのデプロイ」を参照してください。

重要なメモ:

• 記憶域スペース ダイレクト ベースの記憶域レプリカ クラスタリング用の Azure Resource Manager テンプレートについては、「記憶域レプリカを使用して記憶域スペース ダイレクト SOFS クラスターを作成し、Azure リージョン間でディザスター リカバリーを行う」を参照してください。
• Azure でのクラスター間 RPC 通信 (クラスター間のアクセスを許可するためにクラスター API で必要) には、クラスター ネットワーク オペレーター (CNO) のネットワーク アクセスを構成する必要があります。 TCP ポート 135 と TCP ポート 49152 より高いダイナミック レンジを許可する必要があります。 詳細については、「Azure IaaS VM での Windows Server フェールオーバー クラスターの構築 - パート 2 ネットワークと作成に関するページを参照してください。
• 2 ノードのゲスト クラスターを使用できます。各ノードは、記憶域レプリカによってレプリケートされる非対称クラスターにループバック iSCSI を使用します。 ただし、この構成はパフォーマンスが低下する可能性があり、限られたワークロードまたはテストにのみ使用する必要があります。

初期同期中のレプリケーションの進行状況を表示するにはどうすればよいですか?

コピー先サーバーの記憶域レプリカ管理者イベント ログのイベント ID 1237 メッセージには、コピーされたバイト数と残りのバイト数が 10 秒ごとに表示されます。

もう 1 つのオプションは、1 つ以上のレプリケートされたボリュームに対して、\Storage Replica Statistics\Total Bytes Received の下にあるターゲット サーバー上の記憶域レプリカ パフォーマンス カウンターを使用することです。

Windows PowerShell を使用してレプリケーション グループのクエリを実行することもできます。 たとえば、次のサンプル コマンドは、宛先のグループの名前を取得し、10 秒ごとに Replication 2 という名前の 1 つのグループにクエリを実行して進行状況を表示します。

Get-SRGroup

do{
    $r=(Get-SRGroup -Name "Replication 2").replicas
    [System.Console]::Write("Number of remaining bytes {0}`n", $r.NumOfBytesRemaining)
    Start-Sleep 10
}until($r.ReplicationStatus -eq 'ContinuouslyReplicating')
Write-Output "Replica Status: "$r.replicationstatus

レプリケーションに使用するネットワーク インターフェイスを指定できますか?

はい。 レプリケーションに使用するネットワーク インターフェイスを指定するには、Set-SRNetworkConstraint コマンドレットを使用します。 このコマンドレットは、インターフェイス レイヤーで動作します。 クラスターシナリオと非クラスターシナリオの両方で使用できます。

たとえば、スタンドアロン サーバー (各ノード上) で、次のコマンドを実行します。

Get-SRPartnership

Get-NetIPConfiguration

ゲートウェイとインターフェイスの情報 (両方のサーバー上) とパートナーシップの指示に注意してください。 次に、次のコマンドを実行します。

Set-SRNetworkConstraint -SourceComputerName sr-srv06 -SourceRGName rg02 -
SourceNWInterface 2 -DestinationComputerName sr-srv05 -DestinationNWInterface 3 -DestinationRGName rg01

Get-SRNetworkConstraint

Update-SmbMultichannelConnection

ストレッチ クラスターでネットワーク制約を構成するには、次のコマンドを実行します。

Set-SRNetworkConstraint -SourceComputerName sr-cluster01 -SourceRGName group1 -SourceNWInterface "Cluster Network 1","Cluster Network 2" -DestinationComputerName sr-cluster02 -DestinationRGName group2 -DestinationNWInterface "Cluster Network 1","Cluster Network 2"

一対多レプリケーションまたは推移的 (A から B から C) のレプリケーションを構成できますか。

いいえ。記憶域レプリカでは、サーバー、クラスター、またはストレッチ クラスター ノードの 1 対 1 のレプリケーションのみがサポートされます。 特定のボリューム ペアのさまざまなサーバー間のレプリケーションは、どちらの方向でも構成できます。 たとえば、サーバー 1 は D ボリュームをサーバー 2 に、E ボリュームはサーバー 3 にレプリケートできます。

記憶域レプリカがレプリケートするレプリケートされたボリュームを拡大または縮小することはできますか?

ボリュームは拡大 (拡張) できますが、縮小することはできません。 既定では、記憶域レプリカにより、管理者はレプリケートされたボリュームを拡張できなくなります。 サイズを変更する前に、ソース グループの Set-SRGroup -AllowVolumeResize $TRUE オプションを使用します。

次に例を示します。

1. ソース コンピューターに対して次のコマンドを実行します: Set-SRGroup -Name YourRG -AllowVolumeResize $TRUE。
2. 好む手法を使用してボリュームを増やします。
3. ソース コンピューターに対して次のコマンドを実行します: Set-SRGroup -Name YourRG -AllowVolumeResize $FALSE。

読み取り専用アクセスのために宛先ボリュームをオンラインにすることはできますか?

Windows Server 2016: いいえ。 記憶域レプリカは、Windows Server 2016 でレプリケーションが開始されると、移行先ボリュームのマウントを解除します。

Windows Server 2019: はい。 テスト フェールオーバー 機能を使用して、移行先ストレージをマウントできます。 テスト フェールオーバーを実行するには、現在宛先でレプリケートされていない未使用の NTFS または ReFS 形式のボリュームが必要です。 次に、テストまたはバックアップの目的で、レプリケートされたストレージのスナップショットを一時的にマウントします。

レプリケーション先サーバー RG2でレプリケーション グループ SRV2 のテスト フェールオーバーを作成するには、レプリケートされていない一時ドライブとして T: を使用して、次のコマンドを実行します。

Mount-SRDestination -Name RG2 -Computername SRV2 -TemporaryPath T:\

レプリケートされたボリュームは、SRV2でアクセスできるようになりました。 通常どおりに読み書きしたり、ファイルをコピーしたり、保管のために他の場所に保存したオンライン バックアップを実行したりできます。 T: ボリュームにはログ データが含まれています。

テスト フェールオーバー スナップショットを削除し、その変更を破棄するには、次を実行します。

Dismount-SRDestination -Name RG2 -Computername SRV2

テスト フェールオーバー機能は、短期的な一時的な操作にのみ使用する必要があります。 これは、長期的な使用を目的としたものではありません。 使用中は、レプリケーションは実際の宛先ボリュームに続行されます。

ストレッチ クラスター Scale-Out ファイル サーバー (SOFS) を構成できますか?

技術的には可能ですが、SOFS インスタンスに接続するコンピューティング ノードのサイト認識が不足しているため、この構成はお勧めしません。 通常、待機時間が 1 ミリ秒未満のキャンパス距離ネットワークを使用する場合、通常、この構成は問題なく機能します。

クラスター間レプリケーションでは、記憶域レプリカは、2 つのクラスター間でレプリケートするときに、記憶域スペース ダイレクトの使用を含む SOFS を完全にサポートします。

クラスター共有ボリュームは、ストレッチ クラスター内またはクラスター間でレプリケートする必要がありますか?

いいえ。 クラスター共有ボリュームまたはファイル サーバー ロールなどのクラスター リソースが所有する永続ディスク予約 (PDR) を使用してレプリケートできます。

クラスター間レプリケーションでは、記憶域レプリカは、2 つのクラスター間でレプリケートするときに、記憶域スペース ダイレクトの使用を含む SOFS を完全にサポートします。

記憶域レプリカを使用してストレッチ クラスターで記憶域スペース ダイレクトを構成できますか?

いいえ。 この構成は、Windows Server ではサポートされていません。

クラスター間レプリケーションでは、記憶域レプリカは記憶域スペース ダイレクトの使用を含め、SOFS および Hyper-V サーバーを完全にサポートします。

非同期レプリケーションを構成する方法

New-SRPartnership -ReplicationMode を実行し、引数 Asynchronous指定します。 既定では、記憶域レプリカ内のすべてのレプリケーションは同期です。 Set-SRPartnership -ReplicationModeを実行してモードを変更することもできます。

ストレッチ クラスターの自動フェールオーバーを防ぐにはどうすればよいですか?

自動フェールオーバーを防ぐために、PowerShell を使用して Get-ClusterNode -Name "NodeName").NodeWeight=0を構成できます。 このコマンドは、ディザスター リカバリー サイト内の各ノードの投票を削除します。 その後、プライマリ サイトのノードで Start-ClusterNode -PreventQuorum を実行し、ディザスター サイト内のノードで Start-ClusterNode -ForceQuorum してフェールオーバーを強制できます。 自動フェールオーバーの防止は、UI 構成オプションとして使用できないため、自動フェールオーバーを防止しないことをお勧めします。

仮想マシンの回復性を無効にする方法

新しい Hyper-V 仮想マシンの回復機能が実行されないようにし、代わりに VM をディザスター リカバリー サイトにフェールオーバーするのではなく一時停止するには、(Get-Cluster).ResiliencyDefaultPeriod=0実行します。

初期同期の時間を短縮するにはどうすればよいですか?

シン プロビジョニング ストレージを使用すると、初期同期時間を短縮できます。 記憶域レプリカは、非クラスター化記憶域スペース、Hyper-V ダイナミック ディスク、記憶域ネットワーク (SAN) 論理ユニット番号 (LUN) など、シン プロビジョニングされた記憶域に対してクエリを実行し、自動的に使用します。 初期レプリケーションが開始された後は、ボリュームを縮小またはトリミングすることはできません。

シード処理されたデータ ボリュームを使用して、帯域幅の使用量を減らし、一部のシナリオでは同期時間を短縮することもできます。 フェールオーバー クラスター マネージャーでシードオプションを使用するか、New-SRPartnership コマンドレットを使用して、移行先ボリュームにプライマリ サイトからのデータのサブセットがあることを確認します。 ボリュームがほとんど空の場合、シード同期を使用すると、時間と帯域幅の使用量が削減される可能性があります。

データをシード処理するには、さまざまな程度の有効性を提供するオプションから選択できます。

• 以前のレプリケーション。 ディスクとボリュームを含むノード間で通常の初期同期を使用してローカルにレプリケートし、レプリケーションを削除し、宛先ディスクを別の場所に発送してから、シード処理されたオプションを使用してレプリケーションを追加します。 記憶域レプリカはブロック コピー ミラーを保証し、レプリケートする唯一の処理は差分ブロックであるため、この方法が最も効果的です。
• 復元されたスナップショットまたは復元されたスナップショット ベースのバックアップ をします。 ボリューム ベースのスナップショットをコピー先ボリュームに復元することで、ブロック レイアウトの違いは最小限に抑えられます。 この方法は、次に最も効果的です。 ボリューム スナップショットはミラー イメージであるため、ブロックが一致する可能性があります。
• コピーしたファイル します。 使用されなかった新しいボリュームを宛先に作成し、データの完全な robocopy /MIR ツリー コピーを実行します。 ブロックの一致が発生する可能性があります。 Windows エクスプローラーを使用するか、ツリーの一部をコピーしても、多くのブロック一致は作成されません。 ファイルを手動でコピーすることは、シード処理の最も効果的な方法です。

レプリケーションを管理するユーザーを委任できますか?

はい。 Grant-SRDelegation コマンドレットを使用して、ユーザーを委任します。 このコマンドを使用して、サーバー間、クラスター間、およびストレッチ クラスター レプリケーション シナリオで特定のユーザーを設定できます。 このコマンドは、ローカル管理者グループのメンバーにならずに、レプリケーションを作成、変更、または削除するためのアクセス許可を委任します。

次に例を示します。

Grant-SRDelegation -UserName contoso\tonywang

このコマンドレットは、ユーザーがサインアウトしてから、変更を有効にするために管理する予定のサーバーにサインインする必要があることを通知します。 Get-SRDelegation コマンドレットと Revoke-SRDelegation コマンドレットを使用して、委任をさらに制御できます。

レプリケートされたボリュームのバックアップと復元のオプションは何ですか?

記憶域レプリカでは、ソース ボリュームのバックアップと復元がサポートされています。 また、ソース ボリュームのスナップショットの作成と復元もサポートしています。 ストレージ レプリカによって保護されている間は、マウントまたはアクセスできないため、コピー先ボリュームをバックアップまたは復元することはできません。

障害が発生し、ソース ボリュームが失われた場合は、Set-SRPartnership コマンドレットを使用して、移行先を新しいソース ボリュームとして昇格できます。 新しく昇格したソースでは、そのボリュームをバックアップまたは復元できます。 Remove-SRPartnership コマンドレットと Remove-SRGroup コマンドレットを使用してレプリケーションを削除し、ボリュームを読み取り/書き込み可能として再マウントすることもできます。

アプリケーション整合性スナップショットを定期的に作成するには、ソース サーバーで VSSAdmin.exe を実行してレプリケートされたデータ ボリュームのスナップショットを作成することで、ボリューム シャドウ コピー サービス (VSS) を使用できます。

たとえば、記憶域レプリカを使用して F: ボリュームをレプリケートする場合は、次のコマンドを実行します。

vssadmin create shadow /for=F:

次に、レプリケーションの方向を切り替えた後、レプリケーションを削除した後、または単に同じソース ボリューム上にある場合は、任意のスナップショットをその時点に復元できます。

たとえば、F:を引き続き使用して、次を実行します。

vssadmin list shadows
vssadmin revert shadow /shadow={shadown copy ID GUID listed previously}

スケジュールされたタスクを使用して、このツールを定期的に実行するようにスケジュールすることもできます。 VSS の使用方法の詳細については、vssadmin を参照してください。 VSS はログ ボリュームを無視するため、ログ ボリュームをバックアップする必要はありません。

記憶域レプリカでは、ファイル ベースのバックアップがサポートされます。 記憶域レプリカでは、ブロック ベースのバックアップと復元はサポートされていません。

記憶域レプリカに必要なネットワーク ポート

記憶域レプリカは、レプリケーションと管理のためにサーバー メッセージ ブロック (SMB) と Web サービス管理 (WSMan) に依存しているため、次のポートが必要です。

• 445 (SMB、レプリケーション トランスポート プロトコル、クラスター RPC 管理プロトコル)
• 5445 (iWARP SMB。iWARP リモート ダイレクト メモリ アクセス (RDMA) ネットワークを使用する場合にのみ必要)
• 5985 (WSManHTTP; Windows Management Instrumentation (WMI)/Common Information Model (CIM)/PowerShell の管理プロトコル)

注

Test-SRTopology コマンドレットには ICMPv4/ICMPv6 が必要ですが、レプリケーションや管理には必要ありません。

ログ ボリュームのベスト プラクティスとは

ログの最適なサイズは、環境とワークロード、およびワークロードが実行する書き込み I/O の量によって大きく異なります。

• ログが大きくなったり小さくなったりしても、レプリケーションの速度が速くなったり遅くなったりすることはありません。
• 大きいログまたは小さいログでは、10 GB のデータ ボリュームと 10 TB のデータ ボリューム (たとえば) には影響しません。

大きなログでは、ラップされる前に、より多くの書き込み I/O が収集されて保持されます。ログを大きくすると、ネットワークの停止やオフラインの宛先など、移行元と移行先のコンピューター間のサービスの中断が長くなります。 たとえば、ログは最大 10 時間の書き込みを保持するように構成されており、ネットワークは 2 時間ダウンします。 ネットワークが戻ると、ソースは同期されていない変更の差分のみを宛先に再生できます。 ログが 10 時間保持され、停止が 2 日の場合、ソースはビットマップと呼ばれる別のログから再生する必要があります。通常、同期に戻るには時間がかかります。同期されると、ログの使用に戻ります。

記憶域レプリカは、すべての書き込みパフォーマンスのためにログに依存します。 ログのパフォーマンスは、レプリケーションのパフォーマンスにとって重要です。 ログがすべての書き込み I/O をシリアル化および順次化するため、ログ ボリュームのパフォーマンスがデータ ボリュームよりも優れていることを確認する必要があります。 ログ ボリュームでは、ソリッド ステート ドライブ (SSD) のようなフラッシュ メディアを常に使用する必要があります。 他のワークロードをログ ボリューム上で実行することは許可しないでください。他のワークロードを SQL データベース ログ ボリュームで実行することを許可しないのと同じ方法です。

重要

ログ ストレージはデータ ストレージよりも高速であり、ログ ボリュームは他のワークロードに使用されないようにすることをお勧めします。

Test-SRTopology コマンドレットを実行すると、ログのサイズ設定に関する推奨事項を取得できます。 または、既存のサーバーのパフォーマンス カウンターを使用して、ログ サイズを判断することもできます。 数式は単純です。ワークロードの下でデータ ディスクのスループット (Avg Write Bytes/Sec) を監視し、それを使用して、さまざまなサイズのログを埋めるのにかかる時間を計算します。 たとえば、データ ディスクのスループットが 50 MB/秒の場合、120 GB のログが 120 GB で 50 MB/秒 (2,400 秒または 40 分) で分割されます。 そのため、ラップされたログが 40 分になるまでに宛先サーバーに到達できない可能性がある時間。 ログがラップされても宛先に再び到達可能になった場合、ソースはメイン ログではなくビットマップ ログを介してブロックを再生します。 ログのサイズはパフォーマンスに影響しません。

ソース クラスターのデータ ディスク のみをバックアップする必要があります。 記憶域レプリカのログ ディスク バックアップ しないでください。これは、バックアップが記憶域レプリカの操作と競合する可能性があるためです。

ストレッチ クラスター、クラスター間、サーバー間のどちらのトポロジを選択する必要がありますか?

記憶域レプリカには、ストレッチ クラスター、クラスター間、サーバー間の 3 つの主要な構成があります。 各トポロジには異なる利点があります。

ストレッチ クラスター トポロジは、Hyper-V プライベート クラウド クラスターや SQL Server FCI など、ワークロードでオーケストレーションによる自動フェールオーバーが必要な場合に最適です。 また、使いやすさのために、組み込みのグラフィカル インターフェイスであるフェールオーバー クラスター マネージャーも備えています。 永続的な予約を介して記憶域スペース、SAN、iSCSI、RAID の従来の非対称クラスター共有記憶域アーキテクチャを使用します。 このトポロジは、わずか 2 つのノードで実行できます。

クラスター間トポロジでは、2 つの異なるクラスターが使用されます。 このトポロジは、手動フェールオーバーが必要な場合や、2 番目のサイトがディザスター リカバリー用にプロビジョニングされていて、日常的な使用には必要ない場合に最適です。 オーケストレーションは手動です。 ストレッチ クラスター トポロジとは異なり、この構成では記憶域スペース ダイレクトを使用できます (注意事項については、記憶域レプリカに関する FAQ とクラスター間のドキュメントを参照してください)。 このトポロジは、わずか 4 つのノードで実行できます。

サーバー間トポロジは、クラスター化できないハードウェアを実行している場合に最適です。 手動フェールオーバーとオーケストレーションが必要です。 特に非同期レプリケーションを使用する場合は、ブランチ オフィスと中央データセンター間の低コストのデプロイに最適です。 この構成は、多くの場合、シングルマスターディザスター リカバリー シナリオに使用する分散ファイル システム レプリケーション (DFS レプリケーション) で保護されたファイル サーバーのインスタンスを置き換えることができます。

いずれの場合も、トポロジは物理ハードウェアでの実行と仮想マシンでの実行の両方をサポートします。 仮想マシンでは、基になるハイパーバイザーに Hyper-V は必要ありません。 VMware、KVM、Xen などを使用できます。

記憶域レプリカにはサーバー間モードもあります。このモードでは、同じコンピューター上の 2 つの異なるボリュームへのレプリケーションをポイントします。

記憶域レプリカでデータ重複除去はサポートされていますか?

はい。 ソース サーバー上のボリュームでデータ重複除去を有効にし、レプリケーション中に、レプリケーション先サーバーは重複除去されたボリュームのコピーを受け取ります。

データ重複除去を移行元サーバーと移行先サーバーの両方にインストール 必要がありますが (「データ重複除去をインストールして有効にする」を参照)、移行先サーバーで データ重複除去を有効に しないことが重要です。 記憶域レプリカでは、ソース サーバーでのみ書き込みが許可されます。 データ重複除去はボリュームへの書き込みを行うため、ソース サーバーでのみ実行する必要があります。

Windows Server 2019 と Windows Server 2016 の間でレプリケートできますか?

残念ながら、Windows Server 2019 と Windows Server 2016 の 新しい パートナーシップの作成はサポートされていません。 Windows Server 2016 を実行しているサーバーまたはクラスターを Windows Server 2019 に安全にアップグレードでき、既存の パートナーシップ 引き続き機能します。

Windows Server 2019 のレプリケーション パフォーマンスを向上させるには、パートナーシップのすべてのメンバーが Windows Server 2019 を実行する必要があります。 また、既存のパートナーシップと関連するレプリケーション グループを削除してから、シードデータを使用して再作成する必要があります (Windows Admin Center でパートナーシップを作成するとき、または New-SRPartnership コマンドレットを使用する場合)。

記憶域レプリカまたはドキュメントに関する問題を報告するにはどうすればよいですか?

記憶域レプリカに関する技術的なサポートについては、Microsoft Q & A に投稿するか、Microsoft Business サポート にお問い合わせください。

このドキュメントに関する問題については、このページの下部にある「フィードバック」セクションを参照し、このページ 選択します。

両方向にレプリケートするように記憶域レプリカを構成できますか?

記憶域レプリカは一方向レプリケーション テクノロジです。 ボリュームごとにソースから宛先にのみレプリケートされます。 方向はいつでも逆にできますが、1 方向にのみレプリケートされます。

一連のボリューム (ソースと宛先) を一方向にレプリケートし、異なる一連のドライブ (ソースと宛先) を逆方向にレプリケートすることができます。

たとえば、サーバー間レプリケーションを構成するとします。 Server1 と Server2 には、それぞれドライブ文字 L:、M:、N:、および O:があります。 ドライブ M: を Server1 から Server2にレプリケートし、ドライブ O: を Server2 から Server1にレプリケートします。 グループごとに個別のログ ドライブがある限り、次の構成を使用できます。

• ソース ログ ドライブ Server1M:、移行先ログ ドライブ L:Server2drive M: 宛先 L: にレプリケートされます。
• ソース ログ ドライブ Server2 を O:N:、移行先のログ ドライブが Server1drive O: 宛先 N: にレプリケートされます。

クラスター ディスクをメンテナンス モードにすることはできますか?

記憶域レプリカは、クラスター ディスクがメンテナンス モードに移行するのをブロックします。 BitLocker の有効化や無効化などの一部のタスクでは、ディスクがメンテナンス モードである必要があります。 ディスクをメンテナンス モードにする必要があるタスクの場合、最初にパートナーシップを解除してから、タスクの完了時に再度作成する必要があります。

異なるオペレーティング システム バージョン間で記憶域レプリカを構成できますか?

レプリケーション ログのバージョンが一致しない場合、または両方のサーバーで機能がサポートされていない場合、記憶域レプリカは新しいパートナーシップをブロックします。 記憶域レプリカの圧縮は、Windows Server 2022 で最初に追加されたため、オペレーティング システムのバージョン間で一致しない機能の例です。 機能をサポートしていないサーバーとのパートナーシップを構成しようとすると、"要求された操作がサポートされていません" というエラーが返されます。

次の表は、現在のログ バージョンの相互運用性マトリックスを示しています。

レプリケーションの開始/開始	Windows Server 2016	Windows Server 2019	Windows Server 2022
Windows Server 2016
Windows Server 2019
Windows Server 2022

関連コンテンツ

• 記憶域レプリカの概要
• 共有ストレージ を使用した Stretch クラスター レプリケーションの
• サーバー間ストレージ レプリケーション
• クラスター間ストレージ レプリケーション の
• 記憶域レプリカ: 既知の問題
• Storage の概要
• 記憶域スペース ダイレクト

この記事には、記憶域レプリカに関してよく寄せられる質問に対する回答が含まれています。

はい。 Azure では、次のシナリオを使用できます。

• Azure 内のサーバー間レプリケーション (1 つまたは 2 つのデータセンター障害ドメイン内のサービスとしてのインフラストラクチャ (IaaS) 仮想マシン (VM) 間、または 2 つの異なるリージョン間で非同期的に同期的または非同期的に)。
• Azure とオンプレミスの間のサーバー間の非同期レプリケーション (仮想プライベート ネットワーク (VPN) または Azure ExpressRoute を使用)。
• Azure 内のクラスター間レプリケーション (1 つまたは 2 つのデータセンター障害ドメイン内の IaaS VM 間で同期的または非同期的に、または 2 つの異なるリージョン間で非同期的に)。
• Azure とオンプレミスの間のクラスター間の非同期レプリケーション (VPN または Azure ExpressRoute を使用)。
• Azure 共有ディスクを使用したストレッチ クラスタリング (1 つまたは 2 つのデータセンター障害ドメイン内の IaaS VM 間で同期的または非同期的に、または 2 つの異なるリージョン間で非同期的に)。

Azure でのゲスト クラスタリングの詳細については、「Azureでの IaaS VM ゲスト クラスターのデプロイ」を参照してください。

重要なメモ:

• 記憶域スペース ダイレクト ベースの記憶域レプリカ クラスタリング用の Azure Resource Manager テンプレートについては、「記憶域レプリカを使用して記憶域スペース ダイレクト SOFS クラスターを作成し、Azure リージョン間でディザスター リカバリーを行う」を参照してください。
• Azure でのクラスター間 RPC 通信 (クラスター間のアクセスを許可するためにクラスター API で必要) には、クラスター ネットワーク オペレーター (CNO) のネットワーク アクセスを構成する必要があります。 TCP ポート 135 と TCP ポート 49152 より高いダイナミック レンジを許可する必要があります。 詳細については、「Azure IaaS VM での Windows Server フェールオーバー クラスターの構築 - パート 2 ネットワークと作成に関するページを参照してください。
• 2 ノードのゲスト クラスターを使用できます。各ノードは、記憶域レプリカによってレプリケートされる非対称クラスターにループバック iSCSI を使用します。 ただし、この構成はパフォーマンスが低下する可能性があり、限られたワークロードまたはテストにのみ使用する必要があります。

コピー先サーバーの記憶域レプリカ管理者イベント ログのイベント ID 1237 メッセージには、コピーされたバイト数と残りのバイト数が 10 秒ごとに表示されます。

もう 1 つのオプションは、1 つ以上のレプリケートされたボリュームに対して、\Storage Replica Statistics\Total Bytes Received の下にあるターゲット サーバー上の記憶域レプリカ パフォーマンス カウンターを使用することです。

Windows PowerShell を使用してレプリケーション グループのクエリを実行することもできます。 たとえば、次のサンプル コマンドは、宛先のグループの名前を取得し、10 秒ごとに Replication 2 という名前の 1 つのグループにクエリを実行して進行状況を表示します。

Get-SRGroup

do{
    $r=(Get-SRGroup -Name "Replication 2").replicas
    [System.Console]::Write("Number of remaining bytes {0}`n", $r.NumOfBytesRemaining)
    Start-Sleep 10
}until($r.ReplicationStatus -eq 'ContinuouslyReplicating')
Write-Output "Replica Status: "$r.replicationstatus

はい。 レプリケーションに使用するネットワーク インターフェイスを指定するには、Set-SRNetworkConstraint コマンドレットを使用します。 このコマンドレットは、インターフェイス レイヤーで動作します。 クラスターシナリオと非クラスターシナリオの両方で使用できます。

たとえば、スタンドアロン サーバー (各ノード上) で、次のコマンドを実行します。

Get-SRPartnership

Get-NetIPConfiguration

ゲートウェイとインターフェイスの情報 (両方のサーバー上) とパートナーシップの指示に注意してください。 次に、次のコマンドを実行します。

Set-SRNetworkConstraint -SourceComputerName sr-srv06 -SourceRGName rg02 -
SourceNWInterface 2 -DestinationComputerName sr-srv05 -DestinationNWInterface 3 -DestinationRGName rg01

Get-SRNetworkConstraint

Update-SmbMultichannelConnection

ストレッチ クラスターでネットワーク制約を構成するには、次のコマンドを実行します。

Set-SRNetworkConstraint -SourceComputerName sr-cluster01 -SourceRGName group1 -SourceNWInterface "Cluster Network 1","Cluster Network 2" -DestinationComputerName sr-cluster02 -DestinationRGName group2 -DestinationNWInterface "Cluster Network 1","Cluster Network 2"

いいえ。記憶域レプリカでは、サーバー、クラスター、またはストレッチ クラスター ノードの 1 対 1 のレプリケーションのみがサポートされます。 特定のボリューム ペアのさまざまなサーバー間のレプリケーションは、どちらの方向でも構成できます。 たとえば、サーバー 1 は D ボリュームをサーバー 2 に、E ボリュームはサーバー 3 にレプリケートできます。

ボリュームは拡大 (拡張) できますが、縮小することはできません。 既定では、記憶域レプリカにより、管理者はレプリケートされたボリュームを拡張できなくなります。 サイズを変更する前に、ソース グループの Set-SRGroup -AllowVolumeResize $TRUE オプションを使用します。

次に例を示します。

1. ソース コンピューターに対して次のコマンドを実行します: Set-SRGroup -Name YourRG -AllowVolumeResize $TRUE。
2. 好む手法を使用してボリュームを増やします。
3. ソース コンピューターに対して次のコマンドを実行します: Set-SRGroup -Name YourRG -AllowVolumeResize $FALSE。

Windows Server 2016: いいえ。 記憶域レプリカは、Windows Server 2016 でレプリケーションが開始されると、移行先ボリュームのマウントを解除します。

Windows Server 2019: はい。 テスト フェールオーバー 機能を使用して、移行先ストレージをマウントできます。 テスト フェールオーバーを実行するには、現在宛先でレプリケートされていない未使用の NTFS または ReFS 形式のボリュームが必要です。 次に、テストまたはバックアップの目的で、レプリケートされたストレージのスナップショットを一時的にマウントします。

レプリケーション先サーバー RG2でレプリケーション グループ SRV2 のテスト フェールオーバーを作成するには、レプリケートされていない一時ドライブとして T: を使用して、次のコマンドを実行します。

Mount-SRDestination -Name RG2 -Computername SRV2 -TemporaryPath T:\

レプリケートされたボリュームは、SRV2でアクセスできるようになりました。 通常どおりに読み書きしたり、ファイルをコピーしたり、保管のために他の場所に保存したオンライン バックアップを実行したりできます。 T: ボリュームにはログ データが含まれています。

テスト フェールオーバー スナップショットを削除し、その変更を破棄するには、次を実行します。

Dismount-SRDestination -Name RG2 -Computername SRV2

テスト フェールオーバー機能は、短期的な一時的な操作にのみ使用する必要があります。 これは、長期的な使用を目的としたものではありません。 使用中は、レプリケーションは実際の宛先ボリュームに続行されます。

技術的には可能ですが、SOFS インスタンスに接続するコンピューティング ノードのサイト認識が不足しているため、この構成はお勧めしません。 通常、待機時間が 1 ミリ秒未満のキャンパス距離ネットワークを使用する場合、通常、この構成は問題なく機能します。

クラスター間レプリケーションでは、記憶域レプリカは、2 つのクラスター間でレプリケートするときに、記憶域スペース ダイレクトの使用を含む SOFS を完全にサポートします。

いいえ。 クラスター共有ボリュームまたはファイル サーバー ロールなどのクラスター リソースが所有する永続ディスク予約 (PDR) を使用してレプリケートできます。

クラスター間レプリケーションでは、記憶域レプリカは、2 つのクラスター間でレプリケートするときに、記憶域スペース ダイレクトの使用を含む SOFS を完全にサポートします。

いいえ。 この構成は、Windows Server ではサポートされていません。

クラスター間レプリケーションでは、記憶域レプリカは記憶域スペース ダイレクトの使用を含め、SOFS および Hyper-V サーバーを完全にサポートします。

New-SRPartnership -ReplicationMode を実行し、引数 Asynchronous指定します。 既定では、記憶域レプリカ内のすべてのレプリケーションは同期です。 Set-SRPartnership -ReplicationModeを実行してモードを変更することもできます。

自動フェールオーバーを防ぐために、PowerShell を使用して Get-ClusterNode -Name "NodeName").NodeWeight=0を構成できます。 このコマンドは、ディザスター リカバリー サイト内の各ノードの投票を削除します。 その後、プライマリ サイトのノードで Start-ClusterNode -PreventQuorum を実行し、ディザスター サイト内のノードで Start-ClusterNode -ForceQuorum してフェールオーバーを強制できます。 自動フェールオーバーの防止は、UI 構成オプションとして使用できないため、自動フェールオーバーを防止しないことをお勧めします。

新しい Hyper-V 仮想マシンの回復機能が実行されないようにし、代わりに VM をディザスター リカバリー サイトにフェールオーバーするのではなく一時停止するには、(Get-Cluster).ResiliencyDefaultPeriod=0実行します。

シン プロビジョニング ストレージを使用すると、初期同期時間を短縮できます。 記憶域レプリカは、非クラスター化記憶域スペース、Hyper-V ダイナミック ディスク、記憶域ネットワーク (SAN) 論理ユニット番号 (LUN) など、シン プロビジョニングされた記憶域に対してクエリを実行し、自動的に使用します。 初期レプリケーションが開始された後は、ボリュームを縮小またはトリミングすることはできません。

シード処理されたデータ ボリュームを使用して、帯域幅の使用量を減らし、一部のシナリオでは同期時間を短縮することもできます。 フェールオーバー クラスター マネージャーでシードオプションを使用するか、New-SRPartnership コマンドレットを使用して、移行先ボリュームにプライマリ サイトからのデータのサブセットがあることを確認します。 ボリュームがほとんど空の場合、シード同期を使用すると、時間と帯域幅の使用量が削減される可能性があります。

データをシード処理するには、さまざまな程度の有効性を提供するオプションから選択できます。

• 以前のレプリケーション。 ディスクとボリュームを含むノード間で通常の初期同期を使用してローカルにレプリケートし、レプリケーションを削除し、宛先ディスクを別の場所に発送してから、シード処理されたオプションを使用してレプリケーションを追加します。 記憶域レプリカはブロック コピー ミラーを保証し、レプリケートする唯一の処理は差分ブロックであるため、この方法が最も効果的です。
• 復元されたスナップショットまたは復元されたスナップショット ベースのバックアップ をします。 ボリューム ベースのスナップショットをコピー先ボリュームに復元することで、ブロック レイアウトの違いは最小限に抑えられます。 この方法は、次に最も効果的です。 ボリューム スナップショットはミラー イメージであるため、ブロックが一致する可能性があります。
• コピーしたファイル します。 使用されなかった新しいボリュームを宛先に作成し、データの完全な robocopy /MIR ツリー コピーを実行します。 ブロックの一致が発生する可能性があります。 Windows エクスプローラーを使用するか、ツリーの一部をコピーしても、多くのブロック一致は作成されません。 ファイルを手動でコピーすることは、シード処理の最も効果的な方法です。

はい。 Grant-SRDelegation コマンドレットを使用して、ユーザーを委任します。 このコマンドを使用して、サーバー間、クラスター間、およびストレッチ クラスター レプリケーション シナリオで特定のユーザーを設定できます。 このコマンドは、ローカル管理者グループのメンバーにならずに、レプリケーションを作成、変更、または削除するためのアクセス許可を委任します。

次に例を示します。

Grant-SRDelegation -UserName contoso\tonywang

このコマンドレットは、ユーザーがサインアウトしてから、変更を有効にするために管理する予定のサーバーにサインインする必要があることを通知します。 Get-SRDelegation コマンドレットと Revoke-SRDelegation コマンドレットを使用して、委任をさらに制御できます。

記憶域レプリカでは、ソース ボリュームのバックアップと復元がサポートされています。 また、ソース ボリュームのスナップショットの作成と復元もサポートしています。 ストレージ レプリカによって保護されている間は、マウントまたはアクセスできないため、コピー先ボリュームをバックアップまたは復元することはできません。

障害が発生し、ソース ボリュームが失われた場合は、Set-SRPartnership コマンドレットを使用して、移行先を新しいソース ボリュームとして昇格できます。 新しく昇格したソースでは、そのボリュームをバックアップまたは復元できます。 Remove-SRPartnership コマンドレットと Remove-SRGroup コマンドレットを使用してレプリケーションを削除し、ボリュームを読み取り/書き込み可能として再マウントすることもできます。

アプリケーション整合性スナップショットを定期的に作成するには、ソース サーバーで VSSAdmin.exe を実行してレプリケートされたデータ ボリュームのスナップショットを作成することで、ボリューム シャドウ コピー サービス (VSS) を使用できます。

たとえば、記憶域レプリカを使用して F: ボリュームをレプリケートする場合は、次のコマンドを実行します。

vssadmin create shadow /for=F:

次に、レプリケーションの方向を切り替えた後、レプリケーションを削除した後、または単に同じソース ボリューム上にある場合は、任意のスナップショットをその時点に復元できます。

たとえば、F:を引き続き使用して、次を実行します。

vssadmin list shadows
vssadmin revert shadow /shadow={shadown copy ID GUID listed previously}

スケジュールされたタスクを使用して、このツールを定期的に実行するようにスケジュールすることもできます。 VSS の使用方法の詳細については、vssadmin を参照してください。 VSS はログ ボリュームを無視するため、ログ ボリュームをバックアップする必要はありません。

記憶域レプリカでは、ファイル ベースのバックアップがサポートされます。 記憶域レプリカでは、ブロック ベースのバックアップと復元はサポートされていません。

記憶域レプリカは、レプリケーションと管理のためにサーバー メッセージ ブロック (SMB) と Web サービス管理 (WSMan) に依存しているため、次のポートが必要です。

• 445 (SMB、レプリケーション トランスポート プロトコル、クラスター RPC 管理プロトコル)
• 5445 (iWARP SMB。iWARP リモート ダイレクト メモリ アクセス (RDMA) ネットワークを使用する場合にのみ必要)
• 5985 (WSManHTTP; Windows Management Instrumentation (WMI)/Common Information Model (CIM)/PowerShell の管理プロトコル)

注

Test-SRTopology コマンドレットには ICMPv4/ICMPv6 が必要ですが、レプリケーションや管理には必要ありません。

ログの最適なサイズは、環境とワークロード、およびワークロードが実行する書き込み I/O の量によって大きく異なります。

• ログが大きくなったり小さくなったりしても、レプリケーションの速度が速くなったり遅くなったりすることはありません。
• 大きいログまたは小さいログでは、10 GB のデータ ボリュームと 10 TB のデータ ボリューム (たとえば) には影響しません。

大きなログでは、ラップされる前に、より多くの書き込み I/O が収集されて保持されます。ログを大きくすると、ネットワークの停止やオフラインの宛先など、移行元と移行先のコンピューター間のサービスの中断が長くなります。 たとえば、ログは最大 10 時間の書き込みを保持するように構成されており、ネットワークは 2 時間ダウンします。 ネットワークが戻ると、ソースは同期されていない変更の差分のみを宛先に再生できます。 ログが 10 時間保持され、停止が 2 日の場合、ソースはビットマップと呼ばれる別のログから再生する必要があります。通常、同期に戻るには時間がかかります。同期されると、ログの使用に戻ります。

記憶域レプリカは、すべての書き込みパフォーマンスのためにログに依存します。 ログのパフォーマンスは、レプリケーションのパフォーマンスにとって重要です。 ログがすべての書き込み I/O をシリアル化および順次化するため、ログ ボリュームのパフォーマンスがデータ ボリュームよりも優れていることを確認する必要があります。 ログ ボリュームでは、ソリッド ステート ドライブ (SSD) のようなフラッシュ メディアを常に使用する必要があります。 他のワークロードをログ ボリューム上で実行することは許可しないでください。他のワークロードを SQL データベース ログ ボリュームで実行することを許可しないのと同じ方法です。

重要

ログ ストレージはデータ ストレージよりも高速であり、ログ ボリュームは他のワークロードに使用されないようにすることをお勧めします。

Test-SRTopology コマンドレットを実行すると、ログのサイズ設定に関する推奨事項を取得できます。 または、既存のサーバーのパフォーマンス カウンターを使用して、ログ サイズを判断することもできます。 数式は単純です。ワークロードの下でデータ ディスクのスループット (Avg Write Bytes/Sec) を監視し、それを使用して、さまざまなサイズのログを埋めるのにかかる時間を計算します。 たとえば、データ ディスクのスループットが 50 MB/秒の場合、120 GB のログが 120 GB で 50 MB/秒 (2,400 秒または 40 分) で分割されます。 そのため、ラップされたログが 40 分になるまでに宛先サーバーに到達できない可能性がある時間。 ログがラップされても宛先に再び到達可能になった場合、ソースはメイン ログではなくビットマップ ログを介してブロックを再生します。 ログのサイズはパフォーマンスに影響しません。

ソース クラスターのデータ ディスク のみをバックアップする必要があります。 記憶域レプリカのログ ディスク バックアップ しないでください。これは、バックアップが記憶域レプリカの操作と競合する可能性があるためです。

記憶域レプリカには、ストレッチ クラスター、クラスター間、サーバー間の 3 つの主要な構成があります。 各トポロジには異なる利点があります。

ストレッチ クラスター トポロジは、Hyper-V プライベート クラウド クラスターや SQL Server FCI など、ワークロードでオーケストレーションによる自動フェールオーバーが必要な場合に最適です。 また、使いやすさのために、組み込みのグラフィカル インターフェイスであるフェールオーバー クラスター マネージャーも備えています。 永続的な予約を介して記憶域スペース、SAN、iSCSI、RAID の従来の非対称クラスター共有記憶域アーキテクチャを使用します。 このトポロジは、わずか 2 つのノードで実行できます。

クラスター間トポロジでは、2 つの異なるクラスターが使用されます。 このトポロジは、手動フェールオーバーが必要な場合や、2 番目のサイトがディザスター リカバリー用にプロビジョニングされていて、日常的な使用には必要ない場合に最適です。 オーケストレーションは手動です。 ストレッチ クラスター トポロジとは異なり、この構成では記憶域スペース ダイレクトを使用できます (注意事項については、記憶域レプリカに関する FAQ とクラスター間のドキュメントを参照してください)。 このトポロジは、わずか 4 つのノードで実行できます。

サーバー間トポロジは、クラスター化できないハードウェアを実行している場合に最適です。 手動フェールオーバーとオーケストレーションが必要です。 特に非同期レプリケーションを使用する場合は、ブランチ オフィスと中央データセンター間の低コストのデプロイに最適です。 この構成は、多くの場合、シングルマスターディザスター リカバリー シナリオに使用する分散ファイル システム レプリケーション (DFS レプリケーション) で保護されたファイル サーバーのインスタンスを置き換えることができます。

いずれの場合も、トポロジは物理ハードウェアでの実行と仮想マシンでの実行の両方をサポートします。 仮想マシンでは、基になるハイパーバイザーに Hyper-V は必要ありません。 VMware、KVM、Xen などを使用できます。

記憶域レプリカにはサーバー間モードもあります。このモードでは、同じコンピューター上の 2 つの異なるボリュームへのレプリケーションをポイントします。

はい。 ソース サーバー上のボリュームでデータ重複除去を有効にし、レプリケーション中に、レプリケーション先サーバーは重複除去されたボリュームのコピーを受け取ります。

データ重複除去を移行元サーバーと移行先サーバーの両方にインストール 必要がありますが (「データ重複除去をインストールして有効にする」を参照)、移行先サーバーで データ重複除去を有効に しないことが重要です。 記憶域レプリカでは、ソース サーバーでのみ書き込みが許可されます。 データ重複除去はボリュームへの書き込みを行うため、ソース サーバーでのみ実行する必要があります。

残念ながら、Windows Server 2019 と Windows Server 2016 の 新しい パートナーシップの作成はサポートされていません。 Windows Server 2016 を実行しているサーバーまたはクラスターを Windows Server 2019 に安全にアップグレードでき、既存の パートナーシップ 引き続き機能します。

Windows Server 2019 のレプリケーション パフォーマンスを向上させるには、パートナーシップのすべてのメンバーが Windows Server 2019 を実行する必要があります。 また、既存のパートナーシップと関連するレプリケーション グループを削除してから、シードデータを使用して再作成する必要があります (Windows Admin Center でパートナーシップを作成するとき、または New-SRPartnership コマンドレットを使用する場合)。

記憶域レプリカに関する技術的なサポートについては、Microsoft Q & A に投稿するか、Microsoft Business サポート にお問い合わせください。

このドキュメントに関する問題については、このページの下部にある「フィードバック」セクションを参照し、このページ 選択します。

記憶域レプリカは一方向レプリケーション テクノロジです。 ボリュームごとにソースから宛先にのみレプリケートされます。 方向はいつでも逆にできますが、1 方向にのみレプリケートされます。

一連のボリューム (ソースと宛先) を一方向にレプリケートし、異なる一連のドライブ (ソースと宛先) を逆方向にレプリケートすることができます。

たとえば、サーバー間レプリケーションを構成するとします。 Server1 と Server2 には、それぞれドライブ文字 L:、M:、N:、および O:があります。 ドライブ M: を Server1 から Server2にレプリケートし、ドライブ O: を Server2 から Server1にレプリケートします。 グループごとに個別のログ ドライブがある限り、次の構成を使用できます。

• ソース ログ ドライブ Server1M:、移行先ログ ドライブ L:Server2drive M: 宛先 L: にレプリケートされます。
• ソース ログ ドライブ Server2 を O:N:、移行先のログ ドライブが Server1drive O: 宛先 N: にレプリケートされます。

記憶域レプリカは、クラスター ディスクがメンテナンス モードに移行するのをブロックします。 BitLocker の有効化や無効化などの一部のタスクでは、ディスクがメンテナンス モードである必要があります。 ディスクをメンテナンス モードにする必要があるタスクの場合、最初にパートナーシップを解除してから、タスクの完了時に再度作成する必要があります。

レプリケーション ログのバージョンが一致しない場合、または両方のサーバーで機能がサポートされていない場合、記憶域レプリカは新しいパートナーシップをブロックします。 記憶域レプリカの圧縮は、Windows Server 2022 で最初に追加されたため、オペレーティング システムのバージョン間で一致しない機能の例です。 機能をサポートしていないサーバーとのパートナーシップを構成しようとすると、"要求された操作がサポートされていません" というエラーが返されます。

次の表は、現在のログ バージョンの相互運用性マトリックスを示しています。

レプリケーションの開始/開始	Windows Server 2016	Windows Server 2019	Windows Server 2022
Windows Server 2016
Windows Server 2019
Windows Server 2022

• 記憶域レプリカの概要
• 共有ストレージ を使用した Stretch クラスター レプリケーションの
• サーバー間ストレージ レプリケーション
• クラスター間ストレージ レプリケーション の
• 記憶域レプリカ: 既知の問題
• Storage の概要
• 記憶域スペース ダイレクト