復旧計画と自動フェールオーバー

Azure Site RecoveryのRecovery Planは、複数のVMのフェイルオーバーをまとめて調整する、構造化された順序付きの手順です。各VMを個別にフェイルオーバーするのではなく、復旧計画によってVMをグループにまとめ、順番にフェイルオーバーします。これにより、初回のデプロイ時と同様に、インフラストラクチャ（データベース、ミドルウェア、Web）が正しい順序で起動します。

復旧計画を作成するには、ソースサイト（プライマリリージョン）とターゲットサイト（セカンダリリージョン）を選択し、対象に含めるVMを追加します。計画ウィザードによって既定のグループが自動的に作成されますが、グループを追加してフェイルオーバーの順序を制御することもできます。同じグループ内のVMは同時にフェイルオーバーされ、グループは番号順に実行されます。

一般的な3層アプリケーションでは、復旧計画に次の3つのグループを設定します。

• グループ1 — データベース層のVM（最初に起動する必要があります）
• グループ2 — アプリケーション／ミドルウェア層のVM
• グループ3 — WebフロントエンドのVM（最後に起動します）

各グループは、前のグループのフェイルオーバーが正常に完了するまで待機してから開始します。これにより正しい起動順序が再現され、データベースが接続を受け付ける準備が整う前にWeb層のVMが起動することを防げます。

復旧計画では、各グループの境界に事前アクションと事後アクションを設定できます。次のようなアクションがあります。

• 手動アクション — フェイルオーバーを一時停止し、人間による確認を待機します（例：「データベースの準備が完了していることを確認」）
• Azure Automation Runbook — スクリプトを自動的に実行します（例：DNSレコードの更新、メンテナンスモードの無効化）

Automation Runbookを使用すると、ティア1のワークロードで人の介入なしにフェイルオーバーを完全に自動化できます。

Azure Site Recoveryでは、次の2種類のフェイルオーバーがサポートされています。

• 計画フェイルオーバー — データセンターのメンテナンスなど、発生が分かっているイベントの前に開始します。プライマリVMを正常にシャットダウンし、データを同期してからセカンダリVMを起動します。データ損失はありません。
• 計画外フェイルオーバー — 実際の災害中に開始されます。プライマリVMを利用できない可能性があるため、ASRは最新のレプリケーションチェックポイントを使用します。RPOに応じて、一部のデータが失われる可能性があります。

フェイルオーバー後、セカンダリリージョンで復旧したVMはコミット保留中の状態になります。フェイルオーバーをコミットして、セカンダリサイトがアクティブサイトになったこと、およびロールバックしないことを確定する必要があります。コミットが完了したら、逆方向のレプリケーションを設定してセカンダリサイトを保護し、プライマリリージョンが復旧した後にフェイルバックできます。

フェイルオーバーをコミットすると、元のプライマリリージョンにあるレプリケート済みアイテムはアクティブにレプリケートされなくなります。保護を再開するには、アイテムを再保護する必要があります。これによりレプリケーションの方向が反転し、新しいプライマリ（以前のセカンダリ）から元のプライマリリージョンへレプリケートされるようになります。再保護には時間がかかるため、元のプライマリリージョンが再び利用可能になったら、できるだけ早く開始してください。

復旧計画の各ステップが、合計RTOに加算されます。時間がかかる主な要因は次のとおりです。

• VMの起動時間（VM 1台あたり2～5分）
• アプリケーションのウォームアップ時間（データベース接続プールの初期化、キャッシュのウォームアップ）
• IPアドレス変更後のDNS伝播
• 手動承認ゲートの待機時間

テストフェールオーバー中に各ステップを測定し、合計することで、目標RTOに対する実際のRTOを算出します。

フェールオーバー後、セカンダリリージョンのVMには異なるIPアドレスが割り当てられます。パブリックDNS名を公開するアプリケーションでは、DNSを更新して新しいIPアドレスを指すようにする必要があります。フェールオーバー後のアクションとしてAzure Automation runbookを使用し、Azure DNSまたはTraffic Managerのエンドポイントの正常性を更新して、自動的にトラフィックをリダイレクトします。これにより、RTOを遅延させる可能性のある手動ステップを省略できます。

フェールオーバー中は、Recovery Services vaultのAzure portal Jobsビューに、復旧計画の各ステップのリアルタイムの進行状況が表示されます。実行中のグループ、正常に起動したVM、保留中のスクリプトや手動アクションを確認できます。このビューを監視することで、ステップが失敗した場合に復旧チームが迅速に介入できます。

復旧計画における主なベストプラクティスは次のとおりです。

• グループを小さく保ち（VM 5～10台）、グループが失敗した場合の影響範囲を限定する
• RTOを短縮するため、可能な限り手動アクションではなくAutomation runbookを使用する
• RTOを算出できるよう、各グループの想定起動時間を文書化する
• 計画を検証するため、少なくとも四半期に1回テストフェールオーバーを実行する
• 新しいVMを追加した場合やアプリケーションのアーキテクチャを変更した場合は、必ず計画を見直して更新する

このレッスンで学んだMicrosoft Azure Fundamentals（AZ-900）の概念について理解度を確認します。

このレッスンでは、復旧計画が各グループでの事前・事後アクションを伴う複数VMの順序付けられたフェールオーバーを調整すること、計画外フェールオーバーでは最後のレプリケーションチェックポイントが使用される一方、計画フェールオーバーではデータ損失がゼロになること、そしてフェールオーバー後にDR保護を復元するにはコミットして再保護する必要があることを学びました。次は、本番環境に影響を与えずにDR計画をテストする方法について説明します。