記憶域レプリカについてよく寄せられる質問

はい。 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 でのゲスト クラスタリングに関するその他の注意事項については、「Microsoft Azure での IaaS VM ゲスト クラスターのデプロイ」をご覧ください。

重要なメモ:

• 「Create a Storage Spaces Direct SOFS Clusters with Storage Replica for Disaster Recovery across Azure Regions (Azure リージョン間でのディザスター リカバリー用に記憶域レプリカを使用して記憶域スペース ダイレクト SOFS クラスターを作成する)」に、記憶域スペース ダイレクト ベースの記憶域レプリカ クラスタリング用の Azure Resource Manager テンプレートがあります。
• Azure 内でのクラスター間 RPC 通信 (クラスター間でアクセスを許可するためにクラスター API によって必要) では、CNO へのネットワーク アクセスを構成する必要があります。 TCP ポート 135 と、TCP ポート 49152 より上の動的範囲を許可する必要があります。 Azure IAAS VM での Windows Server フェールオーバー クラスターの構築 – パート 2 ネットワークと作成に関する記事をご覧ください。
• 2 ノードのゲスト クラスターを使用できます。その場合、各ノードにより、記憶域レプリカによってレプリケートされる非対称クラスター用にループバック iSCSI が使われます。 ただし、この方法はパフォーマンスが非常に低く、非常に限られたワークロードやテストのみに使用する必要があります。

レプリケーション先のサーバーの記憶域レプリカの管理者イベント ログに表示される Event 1237 メッセージに、コピーされたバイト数および残りのバイト数が 10 秒間隔で表示されます。 1 つまたは複数のレプリケートされたボリュームに対して \Storage Replica Statistics\Total Bytes Received が表示されるレプリケーション先で、記憶域レプリカのパフォーマンス カウンターを使用することもできます。 Windows PowerShell を使用して、レプリケーション グループをクエリすることもできます。 たとえば、このサンプル コマンドはレプリケーション先にあるグループの名前を取得し、Replication 2 という名前の 1 つのグループをクエリして、10 秒間隔で進行状況を表示します。

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 2019 およびバージョン 1709 以降の Windows Server Semi-Annual Channel では、レプリケーション先記憶域をマウントするオプションを使用できます。この機能は "テスト フェールオーバー" と呼ばれます。 これを実行するには、現在、宛先でレプリケートされていない、未使用の、NTFS または ReFS でフォーマットされたボリュームが必要です。 次に、レプリケートされた記憶域のスナップショットを、テストやバックアップの目的で、一時的にマウントすることができます。

たとえば、宛先サーバー "SRV2" のレプリケーション グループ "RG2" 内にボリューム "D:" をレプリケートしており、SRV2 にレプリケートされていない "T:" ドライブがある場合に、テスト フェールオーバーを作成するには、次の操作を実行します。

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

レプリケートされたボリューム D: は SRV2 でアクセスできるようになります。 D: の下で、普通に読み書きを行ったり、ファイルをそこにコピーしたり、安全のために別の場所に保存するオンライン バックアップを実行したりできます。 T: ボリュームにはログ データのみが含まれます。

テスト フェールオーバーのスナップショットを削除してその変更を破棄するには:

Dismount-SRDestination -Name RG2 -Computername SRV2

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

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

クラスター間のレプリケーションを構成している場合、記憶域レプリカは、2 つの記憶域クラスター間でのレプリケート中の記憶域スペース ダイレクトの使用も含め、スケールアウト ファイル サーバーを完全にサポートします。

いいえ。 ファイル サーバーの役割などのクラスター リソースによって所有されている CSV または永続ディスク予約 (PDR) を使用してレプリケートできます。

クラスター間のレプリケーションを構成している場合、記憶域レプリカは、2 つの記憶域クラスター間でのレプリケート中の記憶域スペース ダイレクトの使用も含め、スケールアウト ファイル サーバーを完全にサポートします。

これは、Windows Server ではサポートされていない構成です。 これは、今後のリリースで変更される可能性があります。 クラスター間のレプリケーションを構成している場合、記憶域レプリカは、記憶域スペース ダイレクトの使用も含め、スケールアウト ファイル サーバーと Hyper-V Server を完全にサポートします。

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

自動フェールオーバーを回避するには、PowerShell を使用して Get-ClusterNode -Name "NodeName").NodeWeight=0 を構成します。 これにより、障害復旧サイト内の各ノードの票が削除されます。 その後、プライマリ サイト内のノードの Start-ClusterNode -PreventQuorum および障害サイト内のノードの Start-ClusterNode -ForceQuorum を使用して、フェールオーバーを強制することができます。 自動フェールオーバーを防止するためのグラフィカルなオプションはなく、自動フェールオーバーの防止は推奨されません。

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

初期同期の間を短縮する 1 つの方法として、仮想プロビジョニングされた記憶域を使用できます。 記憶域レプリカは、クエリを実行し、非クラスター化記憶域スペース、Hyper-V の動的ディスク、SAN LUN を含む、仮想プロビジョニングされたストレージを自動的に使用します。 初期レプリケーションが開始されると、ボリュームは縮小やトリミングをできなくなります。

また、シードされたデータ ボリュームを使用することで、使用帯域幅の低減や、場合によっては時間の短縮ができます。レプリケーション先のボリュームにプライマリからのデータのサブセットがあることを確認した後、シード オプションをフェールオーバー クラスター マネージャーまたは New-SRPartnership で使用します。 ボリュームがほぼ空の場合は、シード同期を使用すると、時間と使用帯域幅を低減できます。 データをシードするには、有効性が異なる複数の方法があります。

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

Grant-SRDelegation コマンドレットを使用できます。 これにより、サーバー間、クラスター間で特定のユーザーを設定して、クラスターのレプリケーション シナリオを、ローカルの管理者グループのメンバーにならずにレプリケーションを作成、変更、削除する権限が付与されているとして拡張することができます。 例:

Grant-SRDelegation -UserName contso\tonywang

このコマンドレットは、変更が有効になるように、管理しようと計画しているサーバーからユーザーがログオフおよびログオンする必要があることを通知します。 Get-SRDelegation と Revoke-SRDelegation を使用して、さらにこれを制御できます。

記憶域レプリカは、ソース ボリュームのバックアップと復元をサポートします。 さらに、ソース ボリュームのスナップショットの作成と復元もサポートします。 記憶域レプリカによって保護されている間はマウントもアクセスもできないため、レプリケーション先のボリュームをバックアップまたは復元することはできません。 ソース ボリュームが失われる障害が発生した場合、Set-SRPartnership を使用して以前のレプリケーション先ボリュームを昇格します。読み取りと書き込みが可能になったソースによって、失われたソース ボリュームをバックアップまたは復元できるようになります。 Remove-SRPartnership と Remove-SRGroup を使用して、このボリュームを読み取りと書き込みが可能なボリュームとして再マウントすることもできます。

アプリケーション整合性のスナップショットを定期的に作成するために、ソース サーバーで VSSADMIN.EXE を使用して、レプリケートされたデータ ボリュームのスナップショットを作成できます。 たとえば、F: ボリュームを記憶域レプリカでレプリケートしている場合は次のようになります。

vssadmin create shadow /for=F:

その後、レプリケーションの方向を切り替えた後、レプリケーションを削除した後、または同じソース ボリューム上にいる場合、任意のスナップショットをその時点に復元できます。 たとえば、依然として F: を使用している場合は次のようになります。

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

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

Windows Server バックアップ、Microsoft Azure Backup、Microsoft DPM、またはその他のスナップショット、VSS、仮想マシン、またはファイルベースのテクノロジの使用は、ボリューム層内で動作する限り、記憶域レプリカでサポートされます。 記憶域レプリカは、ブロックベースのバックアップと復元はサポートしません。

記憶域レプリカは、レプリケーションと管理において SMB と WSMAN を利用します。 つまり、次のポートが必要です。

• 445 (SMB - レプリケーション トランスポート プロトコル、クラスター RPC 管理プロトコル)
• 5445 (iWARP SMB - iWARP RDMA ネットワークを使用する場合にのみ必要)
• 5985 (WSManHTTP - WMI/CIM/PowerShell 用の管理プロトコル)

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

• ログの大きさは、処理速度には影響を与えません
• ログのサイズ、またデータ ボリュームが、たとえば、10 GB か 10 TB かは、パフォーマンスに影響を及ぼしません

サイズの大きいログは、単純に、一杯になるまでに多くの書き込み IO を収集して保持できます。これにより、ログのソースと保存先コンピューターの間での、長時間にわたるサービス中断に対処できます (ネットワークの切断や保存先コンピューターのオフラインなど)。 ログが 10 時間分の書き込みを保持できる場合、ネットワークが 2 時間ダウンしても、ネットワークの復旧時にソース側から保存先に対して同期されていない変更の差分を素早く同期すれば、短時間で保護された状態に回復します。 しかし保持されるログが 10 時間分である場合に、ネットワークが 2 日間ダウンすると、ソース側はビットマップと呼ばれる別のログから再生する必要があるため、同期状態への回復に時間がかかります。同期された後は、元どおりログを使用できます。

記憶域レプリカのすべての書き込みパフォーマンスはログに依存します。 ログのパフォーマンスは、レプリケーションのパフォーマンスにとって重要です。 ログ ボリュームには、ログではすべての書き込み IO がシリアル化、シーケンス化されるため、ログ ボリュームはデータ ボリュームよりも高速に動作するデバイスを使用する必要があります。 ログ ボリュームでは、常に SSD などのフラッシュ メディアを使う必要があります。 ログ ボリューム上では、他のワークロードの実行を絶対に許可しないでください。同様に、SQL データベースのログ ボリューム上で他のワークロードの実行を許可しないでください。

繰り返しますが、ログ ストレージには、データ ストレージよりも高速に動作するデバイスを使用することをお勧めします。またログ ボリュームは、絶対に他のワークロードに使用しないでください

Test-SRTopology ツールを実行することにより、ログ サイズに関する推奨事項を取得できます。 または、既存のサーバーでパフォーマンス カウンターを使用して、ログ サイズを判断することもできます。 式は簡単です。ワークロードの下でデータ ディスクのスループット (平均書き込みバイト数/秒) を監視し、それを使用して、さまざまなサイズのログがいっぱいになるまでの時間を計算します。 たとえば、データ ディスクのスループットが 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 ノード以上の構成で実行できます。

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

このトポロジは、すべての場合において、物理ハードウェアでの実行と仮想マシンでの実行の両方をサポートします。 仮想マシンで使用する場合、基盤のハイパーバイザーは 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 フォーラムで投稿できます。 記憶域レプリカに関する質問のメールを srfeed@microsoft.com に送信することもできます。 このドキュメントに関する問題については、このページの下部にある「フィードバック」セクションを参照し、[このページ] を選択してください。

記憶域レプリカは、一方向のレプリケーション テクノロジです。 レプリケーションは、ボリューム単位で、ソースからレプリケーション先に対してのみ行われます。 この方向はいつでも反転できますが、それでも 1 方向のみです。 ただし、それは、ボリュームのセット (ソースとレプリケーション先) をある方向でレプリケートし、別のドライブのセット (ソースとレプリケーション先) を逆方向でレプリケートすることはできない、という意味ではありません。 たとえば、サーバー間レプリケーションを構成する必要があるとします。 Server1 と Server2 のそれぞれにドライブ文字 L:、M:、N:、O: があり、ドライブ M: は Server1 から Server2 にレプリケートしますが、ドライブ O: は Server2 から Server1 にレプリケートする必要があります。 これは、グループごとに個別のログ ドライブがある限り実行できます。 つまり、

• Server1 のソース ドライブ M: とソース ログ ドライブ L: から、Server2 のレプリケーション先ドライブ M: とレプリケーション先ログ ドライブ L: へのレプリケート
• Server2 のソース ドライブ O: とソース ログ ドライブ N: から、Server1 のレプリケーション先ドライブ O: とレプリケーション先ログ ドライブ N: へのレプリケート

記憶域レプリカは、クラスター ディスクがメンテナンス モードに入るのをブロックします。 Bitlocker の有効化や無効化のようなタスクでは、ディスクをメンテナンス モードにする必要があります。 ディスクをメンテナンス モードにする必要があるタスクを実行するには、最初にパートナーシップを解除し、完了したらもう一度作成する必要があります。

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

• 記憶域の概要
• 記憶域スペース ダイレクト