オンプレミスのディザスター リカバリーのフェールオーバーとフェールバック (最新版) について
この記事では、Azure Site Recovery - Modernized を使用して、オンプレミスのマシンの Azure へのディザスター リカバリー時におけるフェールオーバーとフェールバックの概要について説明します。
Azure Site Recovery クラシック リリースでのフェールオーバーとフェールバックについては、こちらの記事を参照してください。
復旧ステージ
Site Recovery のフェールオーバーとフェールバックには、次の 4 つのステージがあります。
- ステージ 1:オンプレミスからのフェールオーバー:オンプレミスのマシンに Azure へのレプリケーションを設定したら、オンプレミスのサイトがダウンしたときに、これらのマシンを Azure にフェールオーバーします。 フェールオーバー後、レプリケートされたデータから Azure VM が作成されます。
- ステージ 2:Azure VM の再保護:Azure で、Azure VM がオンプレミスのサイトへのレプリケートを開始できるように、Azure VM を再保護します。 再保護中は、データ一貫性を保証できるように、オンプレミス VM は無効にされます (使用可能な場合)。
- ステージ 3:Azure からのフェールオーバー:オンプレミスのサイトが再び正常に実行されるようになったら、別のフェールオーバーを実行します。今回は、Azure VM をオンプレミスのサイトにフェールバックします。 元の場所にフェールバックすることも、別の場所にフェールバックすることもできます。 このアクティビティは、"計画されたフェールオーバー" と呼ばれます。
- ステージ 4:オンプレミスのマシンの再保護:フェールバック後に、オンプレミスのマシンの Azure へのレプリケーションを再び有効にします。
[フェールオーバー]
フェールオーバーは、事業継続とディザスター リカバリー (BCDR) 戦略の一環として実行します。
- BCDR 戦略の最初のステップとして、オンプレミスのマシンを Azure に継続的にレプリケートします。 ユーザーは、オンプレミスのソース マシンで実行されているワークロードとアプリにアクセスします。
- 必要な場合 (たとえばオンプレミスで障害が発生した場合) には、レプリケートしているマシンを Azure にフェールオーバーします。 レプリケートされたデータを使って Azure VM が作成されます。
- 事業継続のために、ユーザーは引き続き Azure VM 上のアプリにアクセスできます。
フェールオーバーは次の 2 フェーズのアクティビティです。
- フェールオーバー:選択した復旧ポイントを使用して Azure VM を作成して起動するフェールオーバー。
- コミット: フェールオーバー後、Azure で VM を確認します。
- 次に、選択した復旧ポイントにフェールオーバーをコミットするか、別のポイントを選択してコミットします。
- フェールオーバーをコミットしたら、復旧ポイントを変更することはできません。
Note
Windows Server 2012 以前のバージョンではクラッシュ整合性復旧ポイントを使用します。アプリケーション整合性復旧ポイントの場合、これらのバージョンではフェールオーバーされた VM の起動時間が長くなる可能性があるためです。
フェールオーバー後の VM への接続
RDP または SSH を使用してフェールオーバー後に作成された Azure VM に接続するには、複数の要件があります。
| [フェールオーバー] | 場所 | アクション |
|---|---|---|
| Windows で実行中の Azure VM | フェールオーバー前のオンプレミスのマシン上 | インターネット経由でのアクセス:RDP を有効にします。 TCP と UDP の規則が [パブリック] に追加されていることを確認し、 [Windows ファイアウォール]>[許可されたアプリ] で、すべてのプロファイルで RDP が許可されていることを確認します。 サイト間 VPN 経由でのアクセス:マシンで RDP を有効にします。 [Windows ファイアウォール] ->[許可されたアプリおよび機能] で、ドメインとプライベート ネットワークで RDP の使用が許可されていることを確認します。 オペレーティング システムの SAN ポリシーが [OnlineAll] に設定されていることを確認します。 詳細については、こちらを参照してください。 フェールオーバーを開始する際は、実行待ちの Windows Update が VM にないことを確認してください。 フェールオーバーの実行時に Windows Update が開始された場合、更新が完了するまで VM にログオンできなくなります。 |
| Windows で実行中の Azure VM | フェールオーバー後の Azure VM 上 | VM のパブリック IP アドレスを追加します。 フェールオーバーされる VM (およびその接続先となる Azure サブネット) は、そのネットワーク セキュリティ グループの規則で、RDP ポートへの着信接続を許可する必要があります。 [ブート診断] をオンにして、VM のスクリーンショットを確認します。 接続できない場合は、VM が実行中であることを確認したうえで、トラブルシューティングのヒントを確認してください。 |
| Linux で実行中の Azure VM | フェールオーバー前のオンプレミスのマシン上 | VM 上の Secure Shell サービスがシステム起動時に自動的に開始されるよう設定されていることを確認します。 ファイアウォール規則で SSH 接続が許可されていることを確認します。 |
| Linux で実行中の Azure VM | フェールオーバー後の Azure VM 上 | フェールオーバーされる VM (および接続先の Azure サブネット) は、そのネットワーク セキュリティ グループの規則で、SSH ポートへの着信接続を許可する必要があります。 VM のパブリック IP アドレスを追加します。 VM のスクリーンショットを得るために、 [ブート診断] をオンにします。 |
フェールオーバーの種類
Site Recovery には、さまざまなフェールオーバー オプションがあります。
| [フェールオーバー] | 詳細 | 回復 | Workflow |
|---|---|---|---|
| テスト フェールオーバー | データの損失やダウンタイムを発生させることなく、BCDR 戦略を検証するドリルを実行するために使用します。 | Azure で VM のコピーを作成します。進行中のレプリケーションや運用環境には影響しません。 | 1.復旧計画で単一の VM、または複数の VM でテスト フェールオーバーを実行します。 2.テスト フェールオーバーで使用する復旧ポイントを選択します。 3.フェールオーバー後に作成される Azure VM が配置される Azure ネットワークを選択します。 このネットワークは、テスト フェールオーバーにのみ使用されます。 4.ドリルが想定どおりに実行されたことを確認します。 ドリル中に Azure で作成された VM は、Site Recovery によって自動的にクリーンアップされます。 |
| 計画されたフェールオーバー (Hyper-V) | 計画的なダウンタイムに使用されます。 ソース VM はシャットダウンされます。 フェールオーバーを開始する前に最新のデータが同期されます。 |
計画されたワークフローではデータ損失は生じません。 | 1.ダウンタイムのメンテナンス期間を計画し、ユーザーに通知します。 2.ユーザー向けのアプリをオフラインにします。 3.最新の復旧ポイントを使用して、計画されたフェールオーバーを開始します。 マシンがシャットダウンされていない場合、またはエラーが発生した場合、フェールオーバーは実行されません。 4.フェールオーバー後、Azure でレプリカの Azure VM がアクティブになっていることを確認します。 5.フェールオーバーをコミットして終了します。 コミット アクションにより、すべての復旧ポイントが削除されます。 |
| フェールオーバー (Hyper-V) | 通常は、計画外の停止が発生した場合や、プライマリ サイトが使用できない場合に実行します。 必要に応じて、VM をシャットダウンし、最終的な変更を同期してからフェールオーバーを開始します。 |
アプリのデータ損失は最小限です。 | 1.BCDR プランを開始します。 2.フェールオーバーを開始します。 フェールオーバーをトリガーする前に、Site Recovery で VM をシャットダウンし、最新の変更を同期またはレプリケートするかどうかを指定します。 3. 多くの復旧ポイント オプションにフェールオーバーできます。復旧ポイント オプションの概要については、こちらを参照してください。 VM をシャットダウンするオプションを有効にしない場合、または Site Recovery でシャットダウンできない場合は、最新の復旧ポイントが使用されます。 マシンをシャットダウンできない場合でも、フェールオーバーは実行されます。 4.フェールオーバー後、Azure でレプリカの Azure VM がアクティブになっていることを確認します。 必要に応じて、24 時間のリテンション期間から別の復旧ポイントを選択できます。 5.フェールオーバーをコミットして終了します。 コミット アクションにより、すべての使用可能な復旧ポイントが削除されます。 |
| フェールオーバー (VMware) | 通常は、計画外の停止が発生した場合や、プライマリ サイトが使用できない場合に実行します。 必要に応じて、フェールオーバーを開始する前に、Site Recovery で VM のシャットダウンをトリガーし、最終的な変更を同期してレプリケートするように指定します。 |
アプリのデータ損失は最小限です。 | 1.BCDR プランを開始します。 2.Site Recovery からフェールオーバーを開始します。 フェールオーバーを実行する前に、Site Recovery で VM のシャットダウンをトリガーして同期するかどうかを指定します。 マシンをシャットダウンできない場合でも、フェールオーバーは実行されます。 3.フェールオーバー後、Azure でレプリカの Azure VM がアクティブになっていることを確認します。 必要であれば、72 時間のリテンション期間から別の復旧ポイントを選択できます。 5.フェールオーバーをコミットして終了します。 コミット アクションにより、すべての復旧ポイントが削除されます。 Windows VM の場合、フェールオーバー時に Site Recovery によって VMware ツールが無効にされます。 |
| 計画されたフェールオーバー (VMware) | Azure からオンプレミスへの計画されたフェールオーバーを実行できます。 | これは計画フェールオーバーのアクティビティであるため、計画フェールオーバーのジョブがトリガーされた後に復旧ポイントが生成されます。 | 計画されたフェールオーバーがトリガーされると、保留中の変更がオンプレミスにコピーされ、VM の最新の復旧ポイントが生成され、Azure VM がシャットダウンされます。 こちらの説明のように、フェールオーバー プロセスに従ってください。 この後、オンプレミスのマシンが有効になります。 計画されたフェールオーバーが成功すると、マシンはオンプレミス環境でアクティブになります。 |
フェールオーバーの処理
一部のシナリオでは、フェールオーバーで追加処理が必要です。これが完了するまで約 8 分から 10 分かかります。 以下の場合は、テスト フェールオーバーの時間が長くなることがあります。
- DHCP サービスが有効になっていない VMware VM。
- 次のブート ドライバーがない VMware VM: storvsc、vmbus、storflt、intelide、atapi。
復旧ポイントのオプション
フェールオーバー時に、多くの復旧ポイント オプションを選択できます。
| オプション | 詳細 |
|---|---|
| 最新 (最低 RPO) | このオプションは、最も低い目標復旧ポイント (RPO) を提供します。 これは、Site Recovery サービスに送信されたすべてのデータを最初に処理して、各 VM の復旧ポイントを作成してから、それにフェールオーバーします。 最初に、ターゲットの場所にある Site Recovery サービスに送信されたすべてのデータを処理して適用し、処理したデータを使用して復旧ポイントを作成しようとします。 ただし、フェールオーバーがトリガーされた時点で、処理を待機している Site Recovery サービスにアップロードされたデータがない場合、Azure Site Recovery はいかなる処理も実行しないため、新しい復旧ポイントは作成されません。 このシナリオでは、代わりに、以前に処理された復旧ポイントのみを使用してフェールオーバーします。 |
| 最後に処理があった時点 | このオプションは、Site Recovery によって処理された最新の復旧ポイントに VM をフェールオーバーします。 特定の VM の最新の復旧ポイントを参照するには、VM 設定の [Latest Recovery Points] (最新の回復ポイント) を確認します。 このオプションを使用すると、未処理のデータの処理に時間がかからないため、RTO (目標復旧時間) を低くできます。 |
| 最新のアプリ整合性 | このオプションは、アプリ整合性復旧ポイントが有効になっている場合に、Site Recovery によって処理された最新のアプリケーション整合性復旧ポイントに VM をフェールオーバーします。 VM の設定で、最新の復旧ポイントを確認します。 |
| 最新のマルチ VM 処理 | このオプションは、マルチ VM 整合性が有効にされている 1 台または複数の VM を含む復旧計画で使用できます。 設定が有効にされている VM は、最新の共通マルチ VM 整合性復旧ポイントにフェールオーバーされます。 計画にある他のすべての VM は、最新の処理済み復旧ポイントにフェールオーバーされます。 |
| 最新のマルチ VM アプリ整合性 | このオプションは、マルチ VM 整合性が有効にされている 1 台または複数の VM を含む復旧計画で使用できます。 レプリケーション グループに含まれる VM は、最新の共通マルチ VM アプリケーション整合性復旧ポイントにフェールオーバーされます。 その他の VM は、最新のアプリケーション整合性復旧ポイントにフェールオーバーされます。 |
| Custom | 特定の VM を特定の時点の復旧ポイントにフェールオーバーする場合は、このオプションを使用します。 このオプションは、復旧計画では使用できません。 |
Note
復旧ポイントは、別の Recovery Services コンテナーに移行できません。
再保護または計画されたフェールオーバー
Azure へのフェールオーバー後、レプリケートされた Azure VM は保護されていない状態になります。
- オンプレミスのサイトにフェールバックするための最初の手順として、オンプレミスへの Azure VM のレプリケートを開始する必要があります。 再保護プロセスは、フェールオーバーしたマシンの種類によって異なります。
- マシンが Azure からオンプレミスにレプリケートされると、Azure からオンプレミスのサイトへのフェールオーバーを実行できます。
- マシンがオンプレミスで再び実行されると、レプリケーションを有効にして、ディザスター リカバリーのためにそれらが Azure にレプリケートされるようにすることができます。
- オンプレミスから Azure にレプリケートされたディスクのみが、再保護操作中に Azure から再びレプリケートされます。 フェールオーバーされた Azure VM に新しく追加されたディスクは、オンプレミスのマシンにレプリケートされません。
- アプライアンスには、最大 60 のディスクを接続できます。 フェールバックされる VM に合計で 60 を超えるディスクが含まれている場合、または大量のトラフィックをフェールバックしている場合は、フェールバック用に別のアプライアンスを作成します。
計画されたフェールオーバーは次のように機能します。
- オンプレミスにフェールバックするには、VM に少なくとも 1 つの復旧ポイントが必要です。 復旧計画では、計画内のすべての VM に少なくとも 1 つの復旧ポイントが必要です。
- これは計画フェールオーバーのアクティビティであるため、フェールバック先の復旧ポイントの種類を選択することができます。 クラッシュ整合ポイントを使用することをお勧めします。
- アプリ整合性復旧ポイントのオプションもあります。 この場合、1 つの VM によって、利用可能な最新のアプリ整合性復旧ポイントに復旧されます。 レプリケーション グループを含む復旧計画の場合、それぞれのレプリケーション グループが、その共通の使用可能な復旧ポイントに復旧されます。
- アプリ整合性の復旧ポイントは時間差を伴うことがあり、データの損失につながる場合があります。
- Azure からオンプレミスのサイトへのフェールオーバー中に、Site Recovery によって Azure VM がシャットダウンされます。 フェールオーバーをコミットすると、Azure でフェールバックされた Azure VM が Site Recovery によって削除されます。
Note
クラッシュ整合性復旧ポイントを使用する場合、Windows Server 2012 以前のバージョンでは、フェールオーバー VM の起動に時間がかかる場合があります。
VMware/物理的な再保護/フェールバック
VMware マシンと物理サーバーを Azure から再保護してオンプレミスにフェールバックするには、確実に正常なアプライアンスを用意します。
アプライアンスの選択
- コンテナーに登録されている任意の Azure Site Recovery レプリケーション アプライアンスを選択して、オンプレミスに再保護することができます。 再保護操作のための Azure の別のプロセス サーバーと、Linux VM 用のスケールアウト マスター ターゲット サーバーは必要ありません。
- レプリケーション アプライアンスでは、フェールバック時に (前方保護と比較して) 別のネットワーク接続やポートは必要ありません。 正常な状態であれば、同じアプライアンスを前方および後方保護に使用できます。 レプリケーションのパフォーマンスには影響しません。
- アプライアンスを選択するときは、ソース マシンが配置されているターゲット データストアにアプライアンスからのアクセスが可能であることを確認します。 ソース マシンのデータストアには、アプライアンスからのアクセスが常に可能である必要があります。 マシンとアプライアンスが異なる ESX サーバーに配置されている場合でも、データストアがそれらの間で共有されている限り、再保護は成功します。
Note
- レプリケートされた項目のストレージ vMotion はサポートされていません。 再保護操作後、レプリケーション アプライアンスのストレージ vMotion はサポートされていません。
- アプライアンスを選択するときは、ソース マシンが配置されているターゲット データストアにアプライアンスからのアクセスが可能であることを確認します。
再保護ジョブ
- これが新しい再保護操作である場合は、既定で、新しいログ ストレージ アカウントが Azure Site Recovery によって自動的にターゲット リージョンに作成されます。 リテンション ディスクは必要ありません。
- 別の場所への復旧と元の場所への復旧の場合は、ソース マシンの元の構成が取得されます。
Note
- 別の場所での再保護 (ALR) または元の場所での再保護 (OLR) の場合、静的 IP アドレスを保持することはできません。
- fstab、LVMconf が変更されます。
障害
- 失敗した再保護ジョブは、すべて再試行できます。 再試行中、任意の正常なレプリケーション アプライアンスを選択できます。
Azure マシンをオンプレミスに再保護すると、元の場所または別の場所にフェールバックしていることが通知されます。
元の場所への復旧:これにより、Azure から同じソースのオンプレミスのマシン (存在する場合) にフェールバックされます。 このシナリオでは、変更部分のみがオンプレミスにレプリケートされます。
- OLR 中のデータ ストアの選択: ソースマシンに接続されているデータ ストアが自動的に選択されます。
別の場所への復旧:オンプレミスのマシンが存在しない場合は、Azure から別の場所にフェールバックできます。 Azure VM からオンプレミスに再保護するときに、オンプレミスのマシンが作成されます。 Azure からオンプレミスへの完全なデータ レプリケーションが行われます。 フェールバックの場所に関する要件と制限事項を確認します。
- ALR 中のデータ ストアの選択: アプライアンスが存在し、そのアプライアンスによってアクセス可能 (読み取りと書き込みのアクセス許可がある) な vCenter によって管理されているすべてのデータ ストアを選択できます (元または新規)。 再保護に使用するキャッシュ ストレージ アカウントを選択できます。
フェールオーバーが完了すると、Azure VM のモビリティ エージェントが Site Recovery サービスに自動的に登録されます。 登録に失敗すると、フェールオーバーされた VM で重大な正常性のイシューが発生します。 イシューが解決されると、登録が自動的にトリガーされます。 エラーを解決した後、手動で登録を完了することができます。
フェールオーバーを取り消す
オンプレミス環境の準備ができていない場合、または問題が発生した場合は、フェールオーバーを取り消すことができます。
計画されたフェールオーバーを開始し、正常に完了したら、オンプレミス環境を使用できるようになります。 ただし、操作が完了した後、別の復旧ポイントにフェールオーバーする場合は、フェールオーバーを取り消すことができます。
取り消しできるのは、計画されたフェールオーバーのみです。
計画されたフェールオーバーは、Recovery Services コンテナーの [レプリケートされたアイテム] ページから取り消すことができます。
フェールオーバーが取り消されると、Azure 内のマシンが再びオンになり、Azure からオンプレミスへのレプリケーションが再び開始されます。