Azure へのディザスター リカバリー後の VMware VM のフェールバック
ディザスター リカバリー プロセスの一部として Azure にフェールオーバーした後、オンプレミス サイトにフェールバックすることができます。 Azure Site Recovery で可能なフェールバックには 2 種類あります。
- 元の場所にフェールバックする
- 別の場所にフェールバックする
オンプレミスにソース仮想マシンが残っているようであれば、VMware 仮想マシンをフェールオーバーする際に、元の仮想マシンにフェールバックできます。 このシナリオでは、変更部分のみがレプリケートされます。 このシナリオは、元の場所への復旧と呼ばれます。 オンプレミスの仮想マシンが存在しない場合、シナリオは別の場所への復旧となります。
Note
元の vCenter および構成サーバーのみにフェールバックすることができます。 新しい構成サーバーをデプロイし、それを使ってフェールバックすることはできません。 また、新しい vCenter を既存の構成サーバーに追加し、新しい vCenter にフェールバックすることもできません。
元の場所への復旧 (OLR)
元の仮想マシンへのフェールバックを選択する場合は、次の条件を満たしている必要があります。
- vCenter サーバーで仮想マシンが管理されている場合は、マスター ターゲットの ESX ホストが仮想マシンのデータストアにアクセスできる必要があります。
- 仮想マシンが ESX ホスト上にあるものの、vCenter で管理されていない場合、仮想マシンのハード ディスクは、マスター ターゲットのホストがアクセスできるデータストア内にある必要があります。
- 仮想マシンが ESX ホスト上にあり、vCenter が使用されない場合、再保護する前に、マスター ターゲットの ESX ホストの検出を完了する必要があります。 これは、物理サーバーにフェールバックする場合も同様です。
- 仮想記憶域ネットワーク (vSAN) のほか、RAW デバイス マッピング (RDM) ベースのディスクにもフェールバックできますが、事前にそのディスクが存在し、オンプレミスの仮想マシンに接続されている場合に限られます。
重要
重要なのは、フェールバック時に Azure Site Recovery サービスが保留中の変更の書き込み先となる仮想マシン上の元の VMDK を識別できるように、disk.enableUUID= TRUE を有効にすることです。 この値が TRUE に設定されていない場合、サービスはベスト エフォートの原則で対応するオンプレミス VMDK を識別しようとします。 正しい VMDK が見つからない場合は、余分なディスクが作成され、そこにデータが書き込まれます。
別の場所への復旧 (ALR)
仮想マシンを再保護する前にオンプレミスの仮想マシンが存在しない場合のシナリオは、別の場所への復旧と呼ばれます。 再保護のワークフローでオンプレミスの仮想マシンをもう一度作成します。 また、データはすべてダウンロードされます。
- 別の場所にフェールバックすると、仮想マシンは、マスター ターゲット サーバーがデプロイされたのと同じ ESX ホストに復旧されます。 ディスクを作成するために使用したデータストアは、仮想マシンの再保護時に選択したのと同じデータストアになります。
- フェールバック先として使用できるのは、仮想マシン ファイル システム (VMFS) または vSAN データストアのみです。 RDM の場合、再保護とフェールバックは機能しません。
- 再保護には、大規模な初期データ転送と、その後の変更が必要になります。 このプロセスが行われるのは、オンプレミスに仮想マシンがないためです。 全データをレプリケートする必要があります。 さらに、この再保護は元の場所への復旧よりも時間がかかります。
- RDM ベースのディスクにフェールバックすることはできません。 VMFS/vSAN データストアに作成できるのは新しい仮想マシン ディスク (VMDK) のみです。
Note
物理マシンは、Azure にフェールオーバーした場合、VMware 仮想マシンとしてのみフェールバックできます。 これは、別の場所への復旧と同じワークフローに従います。 1 つ以上のマスター ターゲット サーバーと、フェールバック先として必要な ESX/ESXi ホストを必ず検出します。
次のステップ
手順に従ってフェールバック操作を実行します。