Azure Site Recovery のしくみ

  • 14 分

Azure Site Recovery を使って、ディザスター リカバリーのオーケストレーションを管理します。 Azure Site Recovery は、プライマリの場所またはリージョンからセカンダリの場所にワークロードをレプリケートするように設計されています。

ワークロードが実行されている場所を移動する場合や、プライマリの場所で中断を引き起こしている問題がある場合、フェールオーバーを実行できます。 フェールオーバーを実行すると、プライマリの場所またはリージョンで実行されていたワークロードがセカンダリの場所で実行できます。 プライマリの場所での問題が解決されたら、ワークロードをプライマリの場所にフェールバックできます。

Diagram showing source and target replication.

プライマリの場所に問題がある場合、Azure Site Recovery では、保護対象の VM を別の Azure リージョンにレプリケートできます。

レプリケーション

レプリケーションは、保護対象のワークロードの状態をプライマリの場所またはリージョンからセカンダリの場所に継続的に転送するプロセスです。 オンプレミスから Azure へのレプリケーションは、パブリック インターネット上の TLS 1.2 接続を介して行われます。

Diagram showing on-premises Hyper-V site replication to Azure.

Azure VPN 経由でレプリケーションを構成することはできません。 ただし、次の条件で、Azure ExpressRoute を介してレプリケーションを構成することができます。

  • Azure Site Recovery では、データはパブリック エンドポイントを介して Azure Storage にレプリケートされます。 Site Recovery レプリケーションに ExpressRoute を使用するには、Microsoft ピアリングを設定するか、既存のパブリック ピアリング (新しい回線では非推奨) を使用する必要があります。

  • Microsoft ピアリングは、レプリケーション用に推奨されるルーティング ドメインです。

  • プライベート ピアリングを介したレプリケーションはサポートされていません。

  • VMware マシンまたは物理マシンを保護する場合は、構成サーバーのネットワーク要件も確実に満たしてください。 Site Recovery レプリケーションを調整する場合、構成サーバーが特定の URL に接続する必要があります。 この接続には ExpressRoute を使用できません。

  • 仮想マシンは、Azure 仮想ネットワークにフェールオーバーされた後、Azure 仮想ネットワークでプライベート ピアリング設定を使用してアクセスできます。

Azure サイト間のレプリケーションは、Microsoft ネットワーク バックボーンを介して行われます。

レプリケーション ポリシー

レプリケーション ポリシーによって、復旧ポイントの保持履歴設定が定義されます。 また、アプリ整合性スナップショットの頻度も定義します。

既定では、新しいレプリケーション ポリシーは、Azure Site Recovery によって、次の既定の設定で作成されます。

  • 復旧ポイントの保有の履歴は 24 時間
  • アプリ整合性スナップショットの頻度は 0 時間

復旧ポイントの保持履歴を 14 日に増やすことができます。 アプリ整合性復旧ポイントは、1 時間に 1 回の頻度で取得するように構成できます。

プライマリとセカンダリの場所間のレプリケーション データ転送の頻度は、レプリケートされるワークロードの種類によって異なります。

  • Hyper-V VM: 30 秒 (Premium Storage を除く)、5 分、または 15 分ごとにレプリケートできます。
  • Azure VM、VMware VM、物理サーバー: レプリケーションは連続します。

注意

Azure への最初のレプリケーションに Azure Data Box などのストレージ テクノロジを使用してオフライン レプリケーションを実行することはできません。

ある Azure リージョンから別のリージョンにレプリケートするシナリオでは、Azure サブスクリプションが同じ Microsoft Entra テナントに関連付けられている場合は、それらのサブスクリプション間でレプリケートできます。

[回復ポイント]

Azure Site Recovery のレプリケーション ポリシーはカスタマイズ可能で、復旧ポイントの保持履歴とスナップショットの頻度を定義するために使用できます。 VM のディスクのスナップショットから復旧ポイントを作成できます。

使用可能なスナップショットには、"クラッシュ整合性" と "アプリ整合性" の 2 種類があります。

  • クラッシュ整合性の復旧は、スナップショットが取得された時点のディスク上のデータを表します。 既定では、スナップショットは 5 分ごとにキャプチャされます。 クラッシュ整合性復旧ポイントには、スナップショットの作成時にメモリに入っていたものは一切含まれません。

  • アプリ整合性の復旧では、クラッシュ整合性と同じデータがキャプチャされるほか、メモリ内のデータとインプロセスのトランザクションもすべて含まれます。 メモリ内のデータが含まれるということは、Site Recovery では、VM と実行中のすべてのアプリをデータを失うことなく復元できるということです。 既定では、スナップショットはキャプチャされません。 必要に応じて、レプリケーション ポリシーで有効にすることができます。

既定では、すべての復旧ポイントは 24 時間保持されますが、必要に応じて 14 日間に延長できます。 中断が発生し、新しい復旧ポイントを作成できない場合、最も古い復旧ポイントが上書きされることはありません。 これは、Azure Site Recovery では、新しいポイントが生成された場合にのみ、最も古いポイントが置き換えられるためです。 新しい復旧ポイントができるまで、リテンション期間に到達した後も古いポイントはすべて残ります。

復旧計画

復旧計画では、フェールオーバーを目的としてマシンを復旧グループに収集します。 復旧計画は、フェールオーバー可能な小さい独立したユニットを作成することにより、体系的な復旧プロセスを定義するのに役立ちます。 ユニットは通常、環境内のアプリを示します。

  • 復旧計画では、マシンについて、フェールオーバーの方法とフェールオーバー後の起動シーケンスを定義します。

  • Azure へのフェールオーバーと Azure からのフェールバックの両方に復旧計画を使用できます。

  • 1 つの復旧計画には、最大 100 個の保護されたインスタンスを追加できます。

  • 順序、説明、タスクを追加することで計画をカスタマイズできます。

  • 計画を定義した後に、フェールオーバーを実行できます。

  • マシンは、複数の復旧計画で参照できます。その中で、マシンが別の復旧計画を使用してデプロイされている場合、後続の計画ではマシンのデプロイ/起動はスキップされます。

大規模なアプリケーションの復旧は複雑になる可能性があります。 手作業ではプロセスでエラーが発生しやすくなり、フェールオーバーを実行する担当者がすべてのアプリケーションの複雑な状況を把握しているとは限りません。 復旧計画は順序を指定し、各ステップで必要とされるアクションを自動化します。Azure へのフェールオーバーには Azure Automation の Runbook かスクリプトを使用します。 自動化できないタスクについては、手動アクションを実行するために、復旧計画に一時停止を挿入できます。

ディザスター リカバリー訓練とは

ディザスター リカバリー訓練は、ソリューションを正しく構成したかどうかをチェックする方法です。 訓練により、災害が発生した場合でもデータとサービスを利用できることを確信できます。 通常、組織は、インフラストラクチャの復旧にかかる時間を示す目標復旧時間 (RTO) を設定します。 また、時間の関数として許容されるデータ損失の量を定義する、目標復旧時点 (RPO) も定義する必要があります。 たとえば、会社の RPO が 1 日の場合、すべてのデータのバックアップを毎日作成する必要があります。 また、このバックアップの復元にかかる時間が必ず 1 日未満になるようにする必要もあります。

Azure Site Recovery を利用することで、すべての VM に対して完全なディザスター リカバリー テスト シナリオを柔軟に実行できます。 1 台以上の VM を含めた復旧計画を作成できます。 フェールオーバーを複数回実行し、インフラストラクチャのさまざまな組み合わせをテストするための柔軟なポリシーを可能にすることができます。

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

フェールオーバーは、組織のディザスター リカバリー計画実行が決定されたときに発生します。 フェールオーバーを開始すると、VM は、ターゲット リソース グループ、ターゲット仮想ネットワーク、ターゲット サブネット、ターゲット可用性セットに作成されます。 フェールオーバー中は、任意の復旧ポイントを使用できます。

ターゲット環境が、組織の運用サービスが実行される事実上の運用環境になります。 ターゲット リージョンがアクティブになったら、ソース環境は使用できなくなるようにする必要があります。

Azure Site Recovery の運用フェールオーバーは、テスト訓練に似ています。 いくつかの例外があります。製品のフェールオーバーの場合、オプションはフェールオーバーですが、テストの場合はテスト フェールオーバーです。

切り替え中にデータが失われないように、フェールオーバーを開始する前にソース VM のシャットダウンを選択できます。

フェールオーバーが完了したら、VM が想定どおりに動作していることを保証します。 Azure Site Recovery では、この段階で復旧ポイントを変更できます。 フェールオーバーが期待どおりに動作する場合は、フェールオーバーをコミットできます。 Azure Site Recovery によって、ソース VM のすべての復旧ポイントが削除され、フェールオーバーが完了します。 レプリケートされたインフラストラクチャとデータがセカンダリ リージョンにあり、セカンダリ リージョンの新しい VM も保護が必要であることに注意する必要があります。

注意

Azure Site Recovery では、フェールオーバーの完了後、ソース環境はクリーンアップされません。

Azure portal を使用すると、Azure Site Recovery フェールオーバーとフェールバックをすばやく開始できます。 フェールオーバーを実行する場合は、復旧ポイントを選択します。 フェールバックの実行はこのプロセスを単に逆にしたもので、フェールオーバーが正常にコミットされると、ワークロードを保護することができ、その後はフェールバックに利用できます。

プライマリの場所で予期しない停止が発生したとき、フェールオーバーが自動的に実行されるわけではありません。 フェールオーバーは、ポータルから 1 回のクリックで開始できます。または、Azure Site Recovery PowerShell を使用してフェールオーバーをトリガーすることもできます。 Site Recovery ポータルではフェールバックを簡単な操作で行えます。

注意

Azure からオンプレミスの物理サーバーへのフェールバックは現在サポートされていませんが、Azure にレプリケートされた物理サーバーを VMware 仮想マシンにフェールバックすることは可能です。

プライマリ データセンターで予期しない障害が発生した場合は、セカンダリ サイトから計画外フェールオーバーをトリガーできます。 Site Recovery は、フェールオーバーを実行するためにプライマリ サイトからの接続を必要としません。

VM の再保護

VM がフェールオーバーされると、Site Recovery によって実行されるレプリケーションは行われなくなります。 フェールオーバーされた VM の保護を開始するには、保護を再度有効にする必要があります。 インフラストラクチャは既に別のリージョンにあるので、ソース リージョンへのレプリケーションを開始できます。 再保護により、Azure Site Recovery では、開始元のソース環境に戻す新しいターゲット環境のレプリケーションを開始できます。