フェールオーバーとフェールバック

完了

Azure Site Recovery を使用すると、障害が発生した場合の Azure へのフェールオーバーと、イベントが終わった後で、オンプレミス マシンへのフェールバックを柔軟に行うことができます。

今あなたは、保護された環境の残りの部分を Azure に完全にフェールオーバーしようと考えています。 単一のテスト仮想マシンでフェールオーバー訓練を問題なく実行した後、完全なフェールオーバーを実行します。 その後、フェールオーバーが正常に完了した後、フェールバックを実行します。

このユニットでは、フェールオーバーとフェールバックの違いについて説明します。 また、Azure へのレプリケーション ポリシーをセットアップした後、フェールバック ポリシーを自動的に作成する方法についても学習します。

フェールオーバーとフェールバック

フェールオーバーとは、ビジネスの BCDR 計画を実行することが決定されたときに行われるプロセスです。 フェールオーバーは、Site Recovery を使用して保護されている現在のライブ環境が、レプリカ環境に移動されるときに発生します。 このターゲット レプリカ環境は、ライブ環境の代わりに、プライマリ インフラストラクチャになります。

フェールバックとは、フェールオーバーの逆のことです。 前のライブ環境 (フェールオーバーが行われたため、今はレプリカ環境になっています) が元の役割を取り戻して、再びライブ環境になります。 最初のインスタンスでフェールオーバーが行われた後、再保護フェーズを実行する必要があります。 このフェーズでは、元の環境を新しいライブ環境と再び同期した状態に戻します。 このプロセスにより、データを失うことなく、フェールオーバーとフェールバックを行うことが可能になります。 再保護フェーズは、障害発生後に古いライブ環境を正しく動作させる必要があるため、時間がかかる可能性があります。

Diagram showing the cyclical nature of failing over, and then failing back, and how the replication to reprotect VM works.

フェールオーバーとフェールバックのアクションには、次の 4 つのステージがあります。

  • Azure にフェールオーバーする: オンプレミスのプライマリ サイトがダウンした場合は、Azure (またはセカンダリ サイト) へのフェールオーバーが決定され、レプリケートされたプライマリ データから仮想マシンが作成されます。
  • Azure 仮想マシンを再保護する: フェールオーバーが行われた後は、障害が復旧された後でオンプレミス環境に変更をレプリケートして戻すことができるように、Azure 仮想マシンを再保護する必要があります。 データの整合性を確保するため、仮想マシンの電源が切られます。
  • オンプレミスにフェールバックする: オンプレミス サイトが再び稼働状態になったら、その環境にフェールオーバーすることができます。 その後、それが再びライブ環境になります。 物理サーバーにはフェールバックできません。 すべてのシステムを仮想マシンにフェールバックする必要があります。
  • オンプレミスの仮想マシンを再保護する: フェールバックが正常に行われた後に、オンプレミスの仮想マシンの再保護が行われ、Azure へのレプリケートが開始されます。

フェールバック ポリシー

オンプレミスのマシンを Azure にコピーするためのオンプレミスのレプリケーション ポリシーを作成すると、関連するフェールバック ポリシーが自動的に作成されます。 ポリシーには、変更できない固定属性がいくつかあります。 次のような属性です。

  • 自分のオンプレミス構成サーバーに対してのみレプリケートして戻すことができます。
  • 目標復旧時点は 15 分に設定されます。
  • 復旧ポイントの保持期間は 24 時間に設定されます。
  • アプリ整合性スナップショットは、1 時間ごとに設定されます。

フェールバックを実行すると、Azure VM は停止されます。 レプリケーションが完了した後、オンプレミスの VM が開始されてワークロードが引き継がれます。 サービスが中断されるため、ビジネスに影響のないときにフェールバックをスケジュールします。

事業継続とディザスター リカバリー計画

Site Recovery の BCDR 計画を使用して、仮想マシンとそれらで実行されるアプリケーションのフェールオーバーとフェールバックのカスタマイズと順序付けを行うことができます。 マシンはグループ化され、フェールオーバーまたはフェールバック中にスクリプトを使用することにより、復旧アクションを自動化できます。 必要に応じて、アクションに手動ステップを追加することもできます。 障害が発生する前に BCDR 計画をテストすれば、良い結果が得られる可能性が高くなります。 企業の目標復旧時間を達成するには、迅速に第 2 の場所でインフラストラクチャを稼働状態にする必要があります。

柔軟性の高いフェールオーバー

Site Recovery を使用すると、フェールオーバーを柔軟に行うことができるため、テストのためにオンデマンドでフェールオーバーを実行できます。 これらのテストを分離することは、ライブ サービスが中断されないことを意味します。 また、この柔軟性により、ライブ サービスの計画的な停止時にフェールオーバーを実行することもできます。 レプリケートされた環境に自動的に切り替えられるため、停止によってシステムのユーザーが中断されることはありません。 柔軟性は逆の場合も同様です。 計画的なテストの一部として、または完全に呼び出されたディザスター リカバリー シナリオの一部として、オンデマンドでのフェールバックを行うことができます。

自分の知識をチェックする

1.

ディザスター リカバリーのコンテキストでは、フェールオーバーおよびフェールバックという用語にはどのような意味がありますか?

2.

オンプレミスの環境を Azure にレプリケートするときの、フェールオーバーとフェールバックの 4 つのステージの正しい順序はどれですか?