サーバー間の記憶域レプリケーション
記憶域レプリカを使用すると、2 台のサーバーがそれぞれ同じボリュームの同じコピーを持つようにデータの同期を構成できます。 このトピックでは、このようなサーバー間のレプリケーション構成の背景、設定方法、環境の管理方法について説明します。
記憶域レプリカを管理するために、Windows Admin Center または PowerShell を使用できます。
次の概要ビデオは、Windows Admin Center での記憶域レプリカの使い方を示しています。
前提条件
- Active Directory Domain Services フォレスト (Windows Server 2016 を実行する必要はありません)。
- Datacenter Edition の Windows Server 2019 または Windows Server 2016 を実行している 2 台のサーバー。 Windows Server 2019 を実行しようとしている場合は、サイズが 2 TB までの単一ボリュームをレプリケートするだけで問題なければ、代わりに Standard Edition を使用できます。
- SAS JBOD、ファイバー チャネル SAN、iSCSI ターゲット、またはローカル SCSI/SATA ストレージを使用する 2 セットの記憶域。 記憶域では HDD メディアと SSD メディアを混在させる必要があります。 各記憶域セットは、共有アクセスなしで、各サーバーでのみ利用可能となるように設定します。
- 記憶域の各セットでは、2 つ以上 (1 つはレプリケートされたデータ用、1 つはログ用) の仮想ディスクの作成が許可される必要があります。 物理記憶域のセクター サイズは、すべてのデータ ディスクで同じである必要があります。 物理記憶域のセクター サイズは、すべてのログ ディスクで同じである必要があります。
- 同期レプリケーションのために各サーバーで少なくとも 1 つのイーサネット/TCP 接続 (可能であれば RDMA)。
- すべてのノード間で ICMP、SMB (ポート 445、SMB ダイレクト用に 5445)、WS-MAN (ポート 5985) の双方向トラフィックを許可する適切なファイアウォールおよびルーター ルール。
- 書き込みの IO 負荷に十分対応できる帯域幅を持ちラウンド トリップ遅延時間が平均 5 ミリ秒である、同期レプリケーション用のサーバー間ネットワーク。 非同期レプリケーションには待機時間に関する推奨事項はありません。
オンプレミス サーバーと Azure VM の間でレプリケートしようとしている場合は、オンプレミス サーバーと Azure VM の間にネットワーク リンクを作成する必要があります。 そうするには、Express Route または サイト間 VPN ゲートウェイ接続を使用するか、Azure VM に VPN ソフトウェアをインストールして、VM をオンプレミス ネットワークに接続します。 - レプリケート対象の記憶域を、Windows オペレーティング システムのフォルダーが含まれるドライブに配置することはできません。
重要
このシナリオでは、各サーバーが別の物理または論理サイト上に存在する必要があります。 各サーバーは、ネットワーク経由で相互に通信できる必要があります。
これらの要件の多くは、Test-SRTopology cmdlet
を使用して確認できます。 記憶域レプリカまたは記憶域レプリカ管理ツール機能を 1 つ以上のサーバーにインストールすると、このツールにアクセスできるようになります。 このツールを使用するために、記憶域レプリカを構成する必要はありません。記憶域レプリカは、コマンドレットをインストールするためだけに構成します。 詳細は、以下の手順に記載されています。
Windows Admin Center の要件
記憶域レプリカと Windows Admin Center を一緒に使用するには、以下が必要です。
システム | オペレーティング システム | 次のために必須: |
---|---|---|
2 台のサーバー (オンプレミスのハードウェア、VM、および Azure VM を含むクラウドの VM の任意の組み合わせ) |
Windows Server 2019、Windows Server 2016、Windows Server (半期チャネル) | 記憶域レプリカ |
1 台の PC | Windows 10 | Windows Admin Center |
注意
現時点では、サーバーで Windows Admin Center を使用して記憶域レプリカを管理することはできません。
用語
このチュートリアルでは、例として次の環境を使用します。
SR-SRV05 および SR-SRV06 という名前の 2 台のサーバー。
2 つの異なるデータ センターを表す 2 つの論理 "サイト" である Redmond と Bellevue。
図 1: サーバー間のレプリケーション
手順 1: Windows Admin Center を PC にインストールして構成する
Windows Admin Center を使用して記憶域レプリカを管理しようとしている場合は、以下の手順を使用して、記憶域レプリカを管理するための PC の準備を行います。
Windows Admin Center をダウンロードしてインストールします。
リモート サーバー管理ツールをダウンロードしてインストールします。
- Windows 10 バージョン 1809 以降を使用している場合は、オンデマンド機能から "RSAT: Windows PowerShell 用記憶域レプリカ モジュール" をインストールします。
管理者として PowerShell セッションを開きます。それには、[スタート] ボタンを選択し、「PowerShell」と入力して、[Windows PowerShell] を右クリックしてから、[管理者として実行] を選択します。
次のコマンドを入力してローカル コンピューターで WS-Management プロトコルを有効にして、クライアントでのリモート管理についての既定の構成を設定します。
winrm quickconfig
「Y」と入力して WinRM サービスを有効にして、WinRM のファイアウォール例外を有効にします。
手順 2: オペレーティング システム、機能、役割、記憶域、ネットワークをプロビジョニングする
インストールの種類として Windows Server (デスクトップ エクスペリエンス) を指定して、両方のサーバー ノードに Windows Server をインストールします。
ExpressRoute 経由でネットワークに接続された Azure VM を使用するには、「ExpressRoute 経由でネットワークに接続されている Azure VM の追加」を参照してください。
注意
Windows Admin Center バージョン 1910 以降は、Azure で自動的に対象のサーバーを構成できます。 このオプションを選択した場合は、ソース サーバーに Windows Server をインストールしてから、「手順 3: サーバー間のレプリケーションを設定する」に進みます。
ネットワーク情報を追加し、サーバーを Windows 10 管理 PC (使用している場合) と同じドメインに参加させてから、サーバーを再起動します。
注意
この時点以降は、常に、すべてのサーバーでビルトイン Administrator グループのメンバーであるドメイン ユーザーとしてログオンします。 今後、グラフィカルなサーバーのインストールまたは Windows 10 コンピューターで実行するとき、PowerShell および CMD プロンプトを昇格してください。
JBOD ストレージ格納装置、iSCSI ターゲット、FC SAN、またはローカルの固定ディスク (DAS) 記憶域の最初のセットをサイト Redmond 内のサーバーに接続します。
2 つ目の記憶域のセットをサイト Bellevue 内のサーバーに接続します。
必要に応じて、両方のノードに最新のベンダー記憶域、格納装置ファームウェアとドライバー、最新のベンダー HBA ドライバー、最新のベンダー BIOS/UEFI ファームウェア、最新のベンダー ネットワーク ドライバー、および最新のマザーボード チップセット ドライバーをインストールします。 必要に応じてノードを再起動します。
注意
共有記憶域およびネットワーク ハードウェアの構成については、ハードウェア ベンダーのドキュメントを参照してください。
サーバーの BIOS および UEFI の設定が、C 状態の無効化、QPI 速度の設定、NUMA の有効化、最大メモリ動作周波数の設定など、高パフォーマンスを有効にする設定であることを確認します。 Windows Server での電源管理が [高パフォーマンス] に設定されていることを確認します。 必要に応じて再起動します。
役割を次のように構成します。
Windows Admin Center での方法
- Windows Admin Center でサーバー マネージャーに移動してから、いずれかのサーバーを選択します。
- [役割と機能] に移動します。
- [機能>記憶域レプリカ] を選択してから、[インストール] をクリックします。
- 他のサーバーで繰り返します。
サーバー マネージャーでの方法
ServerManager.exe を実行してサーバー グループを作成し、すべてのサーバー ノードを追加します。
ファイル サーバーと記憶域レプリカの役割と機能を各ノードでインストールし、再起動します。
Windows PowerShell による方法
SR-SRV06 またはリモート管理コンピューターの Windows PowerShell コンソールで、次のコマンドを実行して必要な機能と役割をインストールし、再起動します。
$Servers = 'SR-SRV05','SR-SRV06' $Servers | ForEach { Install-WindowsFeature -ComputerName $_ -Name Storage-Replica,FS-FileServer -IncludeManagementTools -restart }
詳細については、「役割、役割サービス、または機能のインストールまたはアンインストール」を参照してください。
記憶域を次のように構成します。
重要
- 各格納装置で、データ用に 1 つとログ用に 1 つの 2 つのボリュームを作成する必要があります。
- ログ ディスクとデータ ディスクは、MBR ではなく GPT として初期化する必要があります。
- 2 つのデータ ボリュームのサイズは同じでなければなりません。
- 2 つのログ ボリュームのサイズは同じでなければなりません。
- すべてのレプリケートされたデータ ディスクには、同一のセクター サイズが必要です。
- すべてのログ ディスクのセクター サイズは、同じである必要があります。
- ログ ボリュームには、SSD など、フラッシュ ベースのストレージを使用する必要があります。 ログ ストレージには、データ ストレージよりも大きな速度を確保することをお勧めします。 ログ ボリュームは、絶対に他のワークロードに使用しないでください。
- データ ディスクには、HDD、SSD、または階層型の組み合わせを使用でき、ミラーまたはパリティ スペースか、RAID 1 または 10 もしくは RAID 5 または RAID 50 のいずれかを使用できます。
- ログ ボリュームは既定で 9 GB 以上である必要があり、ログ要件に応じて拡大または縮小する可能性もあります。
- ファイル サーバーの役割は、テスト用に必須ファイアウォール ポートを開くため、Test-SRTopology の動作にのみ必要です。
JBOD 格納装置の場合:
各サーバーがそのサイトのストレージ格納装置のみを参照できることと、SAS 接続が正しく構成されていることを確認します。
記憶域スペースを使用して記憶域をプロビジョニングします。これには、「スタンドアロン サーバーに記憶域スペースを展開する」の手順 1 - 3 に従い、Windows PowerShell またはサーバー マネージャーを使用します。
iSCSI ストレージの場合:
各クラスターがそのサイトのストレージ格納装置のみを参照できることを確認します。 iSCSI を使用する場合は、複数の単一ネットワーク アダプターを使用する必要があります。
ベンダーのドキュメントを参照して記憶域をプロビジョニングします。 Windows ベースの iSCSI ターゲットを使用する場合は、「iSCSI ターゲット ブロック記憶域: 操作方法」を参照してください。
FC SAN ストレージの場合:
各クラスターがそのサイトのストレージ格納装置のみを参照できることと、ホストのゾーンが正しく設定されていることを確認します。
ベンダーのドキュメントを参照して記憶域をプロビジョニングします。
ローカル固定ディスク記憶域の場合:
記憶域に、システム ボリューム、ページ ファイル、ダンプ ファイルが含まれていないことを確認します。
ベンダーのドキュメントを参照して記憶域をプロビジョニングします。
Windows PowerShell を起動し、Test-SRTopology コマンドレットを使用して、記憶域レプリカのすべての要件を満たしているかどうかを判別します。 このコマンドレットは、簡単なテストのために要件のみモードで使用することも、実行時間の長いパフォーマンス評価モードで使用することもできます。
たとえば、それぞれ F: と G: のボリュームがあるノード候補を検証して、テストを 30 分間実行する場合は次のようになります。
MD c:\temp Test-SRTopology -SourceComputerName SR-SRV05 -SourceVolumeName f: -SourceLogVolumeName g: -DestinationComputerName SR-SRV06 -DestinationVolumeName f: -DestinationLogVolumeName g: -DurationInMinutes 30 -ResultPath c:\temp
重要
評価期間中に指定したソース ボリュームに対する書き込み IO 負荷のないテスト サーバーを使用している場合は、ワークロードの追加を検討してください。負荷がない場合、有用なレポートは生成されません。 実際の数値および推奨されるログのサイズを確認するには、実稼働環境と同様のワークロードでテストする必要があります。 または、単に、テスト中にソース ボリュームにいくつかのファイルをコピーするか、DISKSPD をダウンロードして実行することで書き込み IO を生成します。 たとえば、D: ボリュームに対する 10 分間の低書き込み IO ワークロードによる例を次に示します。
Diskspd.exe -c1g -d600 -W5 -C5 -b8k -t2 -o2 -r -w5 -i100 -j100 d:\test
図 2 に示した TestSrTopologyReport.html レポートを調べて、記憶域レプリカの要件を満たしていることを確認します。
図 2: 記憶域レプリケーション トポロジのレポート
手順 3: サーバー間のレプリケーションを設定する
Windows Admin Center を使用する
ソース サーバーを追加します。
- [追加] ボタンを選びます。
- [サーバー接続の追加] を選択します。
- サーバーの名前を入力してから、[送信] を選択します。
[すべての接続] ページで、ソース サーバーを選択します。
[ツール] パネルから [記憶域レプリカ] を選択します。
[新規] を選択して新しいパートナーシップを作成します。 パートナーシップの対象として使用する新しい Azure VM を作成するには、以下のようにします。
- [別のサーバーとのレプリケーション] で [新しい Azure VM を使用する] を選択してから、[次へ] を選択します。 このオプションが表示されない場合は、Windows Admin Center バージョン 1910 以降を使用していることを確認してください。
- ソース サーバーの情報とレプリケーション グループの名前を指定してから、[次へ] を選択します。
これで、その移行ソースのターゲットとして Windows Server 2019 または Windows Server 2016 の Azure VM が自動的に選択されるプロセスが開始されます。 記憶域移行サービスでは、ソースに合わせた VM サイズが推奨されますが、このサイズは、[すべてのサイズを表示] を選択して上書きすることができます。 マネージド ディスクとそれらのファイル システムを自動的に構成し、新しい Azure VM を Active Directory ドメインに参加させるために、インベントリ データが使用されます。 - Windows Admin Center によって Azure VM が作成されたら、レプリケーション グループ名を指定してから [作成] を選択します。 その後、Windows Admin Center によって、データの保護を開始するために、記憶域レプリカの通常の初期同期プロセスが開始されます。
次に示すのは、記憶域レプリカを使用して Azure VM に移行する方法を示しているビデオです。
パートナーシップの詳細を指定してから、図 3 に示すように、[作成] を選択します。
図 3: 新しいパートナーシップの作成
注意
Windows Admin Center の記憶域レプリカからパートナーシップを削除しても、レプリケーション グループ名は削除されません。
Windows PowerShell を使用する
次に、Windows PowerShell を使用してサーバー間のレプリケーションを構成します。 以下のすべての手順は、ノード上で直接実行するか、Windows Server の Remote Server Administration ツールがインストールされているリモート管理コンピューターから実行する必要があります。
PowerShell コンソールを管理者として使用していることを確認します。
レプリケーション元とレプリケーション先のディスク、ログ、およびノードと、ログのサイズを指定して、サーバー間のレプリケーションを構成します。
New-SRPartnership -SourceComputerName sr-srv05 -SourceRGName rg01 -SourceVolumeName f: -SourceLogVolumeName g: -DestinationComputerName sr-srv06 -DestinationRGName rg02 -DestinationVolumeName f: -DestinationLogVolumeName g: -LogType Raw
出力:
DestinationComputerName : SR-SRV06 DestinationRGName : rg02 SourceComputerName : SR-SRV05 PSComputerName :
重要
既定のログのサイズは 8 GB です。
Test-SRTopology
コマンドレットの結果に応じて、値をより大きく、または小さくして -LogSizeInBytes を使用することを検討してください。レプリケーション元とレプリケーション先の状態の取得するために、
Get-SRGroup
とGet-SRPartnership
を次のとおり使用します。Get-SRGroup Get-SRPartnership (Get-SRGroup).replicas
出力:
CurrentLsn : 0 DataVolume : F:\ LastInSyncTime : LastKnownPrimaryLsn : 1 LastOutOfSyncTime : NumOfBytesRecovered : 37731958784 NumOfBytesRemaining : 30851203072 PartitionId : c3999f10-dbc9-4a8e-8f9c-dd2ee6ef3e9f PartitionSize : 68583161856 ReplicationMode : synchronous ReplicationStatus : InitialBlockCopy PSComputerName :
次のようにレプリケーションの進行状況を確認します。
レプリケーション元サーバーで、次のコマンドを入力し、イベント 5015、5002、5004、1237、5001、2200 を調べます。
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica -max 20
レプリケーション先サーバーで、次のコマンドを実行して、パートナーシップの作成を示す記憶域レプリカ イベントを参照します。 このイベントでは、コピーされたバイト数と所要時間が示されます。 例:
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica | Where-Object {$_.ID -eq "1215"} | fl
出力例を次に示します。
TimeCreated : 4/8/2016 4:12:37 PM ProviderName : Microsoft-Windows-StorageReplica Id : 1215 Message : Block copy completed for replica. ReplicationGroupName: rg02 ReplicationGroupId: {616F1E00-5A68-4447-830F-B0B0EFBD359C} ReplicaName: f:\ ReplicaId: {00000000-0000-0000-0000-000000000000} End LSN in bitmap: LogGeneration: {00000000-0000-0000-0000-000000000000} LogFileId: 0 CLSFLsn: 0xFFFFFFFF Number of Bytes Recovered: 68583161856 Elapsed Time (ms): 117
注意
記憶域レプリカによって、インストール先のボリュームとそのドライブ文字またはマウント ポイントがマウント解除されます。 これは仕様です。
または、レプリカのレプリケーション先サーバー グループでは、コピーの残りのバイト数が常時示されており、PowerShell を使って照会できます。 例:
(Get-SRGroup).Replicas | Select-Object numofbytesremaining
進行状況サンプル (終了しません):
while($true) { $v = (Get-SRGroup -Name "RG02").replicas | Select-Object numofbytesremaining [System.Console]::Write("Number of bytes remaining: {0}`r", $v.numofbytesremaining) Start-Sleep -s 5 }
レプリケーション先サーバーで、次のコマンドを実行し、イベント 5009、1237、5001、5015、5005、2200 を調べて、処理の進行状況を把握します。 このシーケンスでは、エラーの警告は発生しないはずです。 イベント 1237 が多くあります。これは進行状況を示します。
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica | FL
手順 4: レプリケーションを管理する
これで、サーバー間のレプリケートされたインフラストラクチャを管理および運用できるようになります。 以下のすべての手順は、ノード上で直接実行することも、Windows Server の Remote Server Administration ツールがインストールされているリモート管理コンピューターから実行することもできます。
Get-SRPartnership
とGet-SRGroup
を使用して、現在のレプリケーション元とレプリケーション先およびそれらの状態を判別します。レプリケーションのパフォーマンスを測定するには、ソースと宛先の両方のノードで
Get-Counter
コマンドレットを使用します。 カウンター名は次のとおりです。\Storage Replica Partition I/O Statistics(*)\Number of times flush paused
\Storage Replica Partition I/O Statistics(*)\Number of pending flush I/O
\Storage Replica Partition I/O Statistics(*)\Number of requests for last log write
\Storage Replica Partition I/O Statistics(*)\Avg. Flush Queue Length
\Storage Replica Partition I/O Statistics(*)\Current Flush Queue Length
\Storage Replica Partition I/O Statistics(*)\Number of Application Write Requests
\Storage Replica Partition I/O Statistics(*)\Avg. Number of requests per log write
\Storage Replica Partition I/O Statistics(*)\Avg. App Write Latency
\Storage Replica Partition I/O Statistics(*)\Avg. App Read Latency
\Storage Replica Statistics(*)\Target RPO
\Storage Replica Statistics(*)\Current RPO
\Storage Replica Statistics(*)\Avg. Log Queue Length
\Storage Replica Statistics(*)\Current Log Queue Length
\Storage Replica Statistics(*)\Total Bytes Received
\Storage Replica Statistics(*)\Total Bytes Sent
\Storage Replica Statistics(*)\Avg. Network Send Latency
\Storage Replica Statistics(*)\Replication State
\Storage Replica Statistics(*)\Avg. Message Round Trip Latency
\Storage Replica Statistics(*)\Last Recovery Elapsed Time
\Storage Replica Statistics(*)\Number of Flushed Recovery Transactions
\Storage Replica Statistics(*)\Number of Recovery Transactions
\Storage Replica Statistics(*)\Number of Flushed Replication Transactions
\Storage Replica Statistics(*)\Number of Replication Transactions
\Storage Replica Statistics(*)\Max Log Sequence Number
\Storage Replica Statistics(*)\Number of Messages Received
\Storage Replica Statistics(*)\Number of Messages Sent
Windows PowerShell でのパフォーマンス カウンターの詳細については、「Get-Counter」を参照してください。
レプリケーションの方向を片方のサイトから移すには、
Set-SRPartnership
コマンドレットを使用します。Set-SRPartnership -NewSourceComputerName sr-srv06 -SourceRGName rg02 -DestinationComputerName sr-srv05 -DestinationRGName rg01
警告
初期レプリケーションが完了する前に役割を切り替えを試みるとデータの損失につながる可能性があるため、Windows Server では、初期同期の進行中に役割を切り替えることはできません。 最初の同期が完了するまでは、強制的に方向を切り替えないでください。
イベント ログを調べてレプリケーションの方向の変更と回復モードが発生しているかどうかを確認し、調整してください。 調整後、書き込み IO で、新しいレプリケーション元サーバーの所有する記憶域に書き込むことができます。 レプリケーションの方向を変更すると、前のソース コンピューター上で書き込み IO がブロックされます。
レプリケーションを削除するには、各ノードで
Get-SRGroup
、Get-SRPartnership
、Remove-SRGroup
、およびRemove-SRPartnership
を使用します。Remove-SRPartnership
コマンドレットは、レプリケーション先サーバーではなく、現在のレプリケーション ソース上でのみ実行してください。 両方のサーバーでRemove-SRGroup
を実行します。 たとえば、2 台のサーバーからすべてのレプリケーションを削除するには、次の手順に従います。Get-SRPartnership Get-SRPartnership | Remove-SRPartnership Get-SRGroup | Remove-SRGroup
DFS レプリケーションを記憶域レプリカに置き換える
多くの Microsoft ユーザーは、ホーム フォルダーおよび部門別の共有のような非構造化ユーザー データの災害復旧ソリューションとして、DFS レプリケーションを展開しています。 DFS レプリケーションは、Windows Server 2003 R2 以降のすべてのオペレーティング システムに付属しており、帯域幅の狭いネットワークで動作するため、ノードが多数あり、待機時間が長く変更の少ない環境に適しています。 ただし、DFS レプリケーションには、データ レプリケーション ソリューションとして重要な以下の制限があります。
- 使用中のファイルや開いているファイルはレプリケートされません。
- レプリケーションは同期的に行われません。
- 非同期レプリケーションの待機期間は数分、数時間、または数日かかることがあります。
- 電源中断の後に時間のかかる一貫性チェックが必要になるデータベースを使用します。
- これは通常、マルチマスターとして構成されおり、双方向にフローを変更できるため、より新しいデータが上書きされる可能性があります。
記憶域レプリカには、これらの欠点はありません。 ただし、いくつかの制限はあり、環境によっては利点が薄くなる可能性があります。
- ボリューム間で実行できるのは 1 対 1 のレプリケーションのみです。 複数のサーバー間で異なるボリュームをレプリケートできます。
- 非同期レプリケーションはサポートされていますが、低帯域幅で待機時間が長いネットワーク向けには設計されていません。
- レプリケーションの進行中、ユーザーはレプリケーション先の保護されたデータにはアクセスできません
これらの要素が障害とならない場合は、記憶域レプリカを使用し、DFS レプリケーション サーバーをこの新しいテクノロジで置き換えることができます。 このプロセスの概要は次のとおりです。
2 台のサーバーに Windows Server をインストールして記憶域を構成します。 環境によっては、既存の一連のサーバーのアップグレードまたはクリーン インストールを行うことになります。
レプリケートするデータが C ドライブ以外の 1 つ以上のデータ ボリューム上に存在することを確認します。 a. バックアップやファイルのコピー、シン プロビジョニングされた記憶域を使用して片方のサーバー上のデータをシードし、時間を節約することもできます。 DFS レプリケーションとは異なり、メタデータのようなセキュリティを完全に一致させる必要はありません。
ソース サーバーでデータを共有し、DFS 名前空間を介してそれにアクセスできるようにします。 これは、サーバー名が障害の発生しているサイトにあるサーバーの名前に変更された場合でも、ユーザーがサーバーにアクセスできるようにするために重要です。 a. レプリケーション先のサーバーに、通常運用時には利用できなくなる、対応する共有を作成できます。b. レプリケーション先サーバーを [DFS 名前空間] の名前空間に追加しないでください。追加する場合は、そのすべてのフォルダー ターゲットを無効にしてください。
記憶域レプリカのレプリケーションを有効にして、初回の同期を完了します。レプリケーションは、同期的と非同期的のどちらでも実行できます。 a. ただし、レプリケーション先サーバーでの IO データの一貫性を保つために、同期的に実行することをお勧めします。 b. ボリューム シャドウ コピーを有効にして、VSSADMIN またはその他のお好みのツールで定期的にスナップショットを撮ることを強くお勧めします。 これによって、アプリケーションは一貫してデータ ファイルをディスクにフラッシュするようになります。 障害が発生した場合、レプリケーション先サーバー上の部分的に非同期レプリケート済みのスナップショットからファイルを回復できます。 スナップショットは、ファイルと共にレプリケートされます。
障害が発生するまでは正常に動作します。
レプリケーション先サーバーを新しいソース サーバーに切り替えると、このサーバーのレプリケート済みボリュームがユーザーに示されます。
同期レプリケーションを使用している場合、ソース サーバーの損失時にユーザーがトランザクション保護なし (これはレプリケーションには関係ありません) でデータを書き込むアプリケーションを使用していない限り、データの復元は必要ありません。 非同期レプリケーションを使用している場合、VSS スナップショットをマウントする必要性が高くなりますが、アプリケーションのスナップショットの一貫性を保つため、どのような場合でも VSS の使用を検討してください。
[DFS 名前空間] のフォルダー ターゲットとして、サーバーとその共有を追加します。
これによって、ユーザーがデータにアクセスできるようになります。
注意
障害回復の計画は複雑な問題であるため、細心の注意が必要です。 Runbook の作成と、年単位でのライブ フェールオーバー ドリルの実行を強くお勧めします。 実際の障害発生時には混乱の中での対応となり、また経験豊富な担当者は手が空いていない場合もあります。
ExpressRoute 経由でネットワークに接続されている Azure VM を追加する
Azure portal で ExpressRoute を作成します。
ExpressRoute が承認されると、リソース グループがサブスクリプションに追加されます。[リソース グループ] に移動して、この新しいグループを表示します。 仮想ネットワークの名前をメモします。図 4: ExpressRoute に関連付けられているリソース - 仮想ネットワーク名をメモする
ネットワーク セキュリティ グループを追加します。 作成時に、作成した ExpressRoute に関連付けられているサブスクリプション ID を選択し、作成したばかりのリソース グループも選択します。
必要なすべての受信および送信のセキュリティ規則をネットワーク セキュリティ グループに追加します。 たとえば、VM へのリモート デスクトップ アクセスを許可したい場合があります。(図 5 に示されている) 以下の設定を使用して Azure VM を作成します。
- [パブリック IP アドレス名]: なし
- [仮想ネットワーク]: ExpressRoute と共に追加したリソース グループからメモした仮想ネットワークを選択します。
- [ネットワーク セキュリティ グループ (ファイアウォール)]: 前に作成したネットワーク セキュリティ グループを選択します。 図 5: ExpressRoute のネットワーク設定を選択しながらの VM の作成
VM が作成されたら、「手順 2: オペレーティング システム、機能、役割、記憶域、ネットワークをプロビジョニングする」を参照してください。