ディザスター リカバリー訓練の実行
- 6 分
このユニットでは、Site Recovery のディザスター ドリルについて説明します。考慮する必要がある内容と、構成が正しいことを確認するテストを実行する方法について説明します。
ディザスター リカバリー (DR) 訓練を使用して、運用サービスに影響を与えることなく、機能停止から復旧する組織の能力をテストします。
前の演習では、Azure Site Recovery の設定を完了しました。 次に、DR ドリルを実行してインフラストラクチャ レプリケーションをテストする必要があります。 Azure Site Recovery を使用すると、運用環境に影響を与えないように、これらの訓練を安全に実行できます。 また、DR ソリューションが動作していることを確認するために、構成に対していくつかの品質保証テストを実行する必要があります。
ディザスター リカバリー訓練とは
DR 訓練とは、ソリューションを正しく構成したかどうかを確認する方法です。 訓練により、皆さん、また会社は、災害が発生した場合でもデータとサービスを確実に利用できるという自信が得られます。 通常、組織は目標復旧時間 (RTO) を設定します。これは、インフラストラクチャの復旧にかかる時間を示します。 また、時間の関数として許容されるデータ損失の量を定義する、目標復旧時点 (RPO) も定義する必要があります。 たとえば、会社の RPO が 1 日の場合は、毎日すべてのデータのバックアップを作成する必要があります。 また、このバックアップを復元するのに 1 日未満かかることも確認する必要があります。
DR テストを確実に実行するために、Site Recovery では、Site Recovery ダッシュボード上でテストの実行が促されます。
DR 訓練の実行が必要な理由
DR 訓練は、実装されているソリューションが事業継続とディザスター リカバリー (BCDR) の要件を満たしていることを確認し、レプリケーションが適切に機能することを確認するために不可欠です。 RTO および RPO と組み合わせた DR ドリルは、レプリケーション、フェールオーバー、および復旧が必要な期間に確実に行われるように、徹底的にテストする必要があります。
たとえば、RTO が 1 時間、RPO が 6 時間であるとします。 システムが 1 時間おきにバックアップされる場合、失われたデータの 1 時間に加えて、システムを復旧するための余分な時間が発生します。
実際の復旧時間が 5 時間であると仮定します。 現在、システムは 6 時間以上古くなっています。つまり、BCDR RPO 目標に違反しています。 障害からの復旧にかかる実際の時間をテストすることで、システムが BCDR プランに従っているという自信が得られます。
個々のマシンのテスト フェールオーバー
フェールオーバー テストを使って、障害をシミュレートし、その影響を確認することができます。 フェールオーバー テストは、Site Recovery ダッシュボードから、または特定の仮想マシン (VM) のディザスター リカバリー メニューから直接開始できます。 まず、復旧ポイントを選択します。 最後に処理されたポイント、最新のアプリ整合性ポイント、カスタム復旧ポイントのいずれかから選択できます。
フェールオーバー テストを作成する
ここでは、運用インフラストラクチャが影響を受けないように、分離した仮想ネットワークを作成します。 これを行うには、次の手順に従います。
patient-records という名前のターゲット VM を開きます。 この VM を見つける簡単な方法は、すべてのリソースをフィルター処理して 、種類 == 仮想マシンのみを表示することです。 結果一覧から 患者レコード を選択します。
リソース メニューで、[ 操作] までスクロールし、[ ディザスター リカバリー] を選択します。
新しい [レプリケートされたアイテム ] ウィンドウが表示されます。 [状態] フィールドに [保護済み] が表示されるまで [更新] を選択します。 次に、上部のメニュー バーから [ テスト フェールオーバー] を選択します。
検証が成功したら、Azure 仮想ネットワークドロップダウンで仮想 ネットワーク を選択し、[ テスト フェールオーバー ] ボタンを選択します。 このオプションでは、VM のテスト フェールオーバーを実行し、[ 通知 ] アイコンを選択し、[タスクの開始] を選択して 仮想マシンのテスト フェールオーバーを実行 することで、Site Recovery ジョブ ページでその進行状況を追跡できます。
完了すると、フェールオーバーされた VM が、復旧リージョンの 仮想マシン の下のポータルに表示されます。 そこで、VM が実行中で、サイズと接続が正しく、ソース VM をミラーリングしているが、別の Azure リージョンにあることを確認できます。
すべてが期待どおりに動作したことを検証したら、[ディザスター リカバリー] ウィンドウから [テスト フェールオーバーのクリーンアップ] を選択して、レプリケートされた VM を削除できます。 この時点で、テスト結果に関するメモを追加することをお勧めします。 [ テストが完了 しました] の横にあるチェック ボックスをオンにしてテスト フェールオーバー仮想マシンを削除し、[ OK] を選択します。
複数のマシンの柔軟なフェールオーバー
Site Recovery により、すべての VM に対して完全な DR テスト シナリオを実行する柔軟性が得られます。 1 台以上の VM を含めた復旧計画を作成できます。 フェールオーバーは何回でも実行でき、柔軟なポリシーでインフラストラクチャのさまざまな組み合わせをテストできます。
単一の VM をテストするのと同様に、復旧計画に含まれるすべてに対して同じテスト クリーンアップを使用できます。
訓練と運用フェールオーバーの違い
Site Recovery での運用フェールオーバーの実行は、テスト訓練の実行に似ています。 例外がいくつかあり、最初のものはテストフェールオーバーではなくフェールオーバーが選択されることです。 切り替え中にデータが失われないように、フェールオーバーを開始する前にソース VM のシャットダウンを選択できます。 フェールオーバーが完了すると、Site Recovery ではソース環境をクリーンアップしません。
フェールオーバーが完了したら、VM が想定どおりに動作していることを確認します。 Site Recovery では、この段階で復旧ポイントを変更できます。 フェールオーバーが正常に動作する場合は、フェールオーバーを コミット します。 Site Recovery によって、ソース VM のすべての復旧ポイントが削除され、フェールオーバーが完了します。 レプリケートされたインフラストラクチャとデータがセカンダリ リージョンにあり、セカンダリ リージョンの新しい VM も保護が必要であることに注意する必要があります。