Full Stack Disaster RecoveryでDR計画管理を強化 (2025/01/07)

https://blogs.oracle.com/cloud-infrastructure/post/fsdr-enhances-dr-plan-mgmt

投稿者： Gregory King | Senior principal product manager for OCI Full Stack Disaster Recovery

Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recoveryは、DR保護グループのメンバー・リソースが変更されるたびに、既存のDR計画のDR計画ステップを自動的に追加および削除するようにDR計画管理を強化しました。Full Stack DRでは、保護グループに対して追加または削除したメンバーに基づいて、すべてのDR計画が自動的に変更され、計画に追加したカスタム・ステップが保持されます。

図1: 拡張された計画管理では、保護グループのメンバーを更新した後に変更を承認する必要があります。

ビジネス・システムとアプリケーション・スタックが進化するにつれ、ディザスタ・リカバリ計画は足並みを揃える必要があります。この機能により、Full Stack DRはこれらの継続的な変更を容易に管理できます。

リカバリ計画の整合性を維持することは、ディザスタ・リカバリ管理者向けのジョブ番号1であり、保護グループのメンバー・リソースに対する変更は、DR計画のリカバリ・ステップに大きく影響します。そのため、保護グループが変更されるたびに計画の整合性を確保するために、次の簡単なワークフローが導入されました。

1. リフレッシュ: DR計画をリフレッシュすると、追加または削除されたステップにタグ付けすることで、何が変化したかを簡単に確認できます。
2. 検証: DR計画によって変更がコミットされ、計画がアクティブ化されることを確認します。

この新機能の使用がいかに簡単かについて見ていきましょう。プライマリ保護グループまたはスタンバイ保護グループのメンバー・リソースの追加、削除または変更によって、プラン・リフレッシュ・ワークフローがトリガーされます。

メンバー・リソースの更新がプロセスを開始

メンバー・リソースの追加方法に関する変更はありません。リソース・タイプを選択し、リカバリ中にオブジェクトに対して必要な処理をFull Stack DRに通知するために必要な適切なプロパティを指定します。

図2に示すように、プライマリ・リージョンのDR保護グループに、現在2つの仮想マシン(VM)と1つのボリューム・グループを含む2つの移動コンピュート・インスタンスを追加するとします。

図2: DR保護グループの現在のメンバー

2つのコンピュート・インスタンスを追加すると、保護グループは図3のようになります。メンバー・リソースを追加または削除した後に常に確認したように見えますが、ここでは何も異なります。

図3: 保護グループのメンバーとして、さらに2つのコンピュート・インスタンスが追加されています。

新しいワークフローの確認

これで、拡張された計画管理スキームで導入された変更を確認できます。スタンバイ保護グループ内のすべてのプランの状態が「注意が必要」(リフレッシュが必要)に変わり、プライマリ保護グループ内のプランが「非アクティブ」(リフレッシュが必要)に変わります。

図4: 保護グループのメンバーを更新すると、すべてのプランの状態が「注意が必要」に変わります。

この状態ではどのプランも実行できないため、スタンバイ保護グループでプラン・リフレッシュ・ワークフローが完了するまで、リカバリ機能は完全にオフラインになります。図5に示すように、各DR計画を選択し、「リフレッシュ」ボタンを選択する必要があります。この選択により、フル・スタックDRは、プライマリ・リージョンとスタンバイ・リージョンの両方のメンバーを検査し、スタンバイ保護グループの計画を更新します。

図5: 「注意が必要」状態のすべての計画の上部に「リフレッシュ」アクション・ボタンが表示されます。

リフレッシュ操作では、追加または削除されたプラン・ステップがタグ付けされるため、次のステップでプランが完全に更新される前に行われるすべての変更を確認できます。

図6: リフレッシュされたプランには、変更、追加または削除されたすべてのプラン・グループとステップが表示されます。

受け入れて変更を永続的にするには、「検証」を選択します。

図7: リフレッシュされたすべてのDR計画の上部に「検証」アクション・ボタンが表示されます。

検証操作によって変更がコミットされ、計画が更新され、タグがすべて通常どおりに表示されるように削除されます。

図8: 検証操作の完了後にステップが追加されました。

スタンバイ保護グループに含まれる既存のすべてのDR計画をリフレッシュする必要があります。Oracle Cloudコンソールのプランのリソース・リスト・ページには、進捗の追跡に役立つすべてのプランの状態が表示されます。

図9: Oracle Cloudコンソールのプラン・リソース・リストを使用して進行状況を追跡します。

スタンバイ保護グループ内のすべてのプランがアクティブになると、その準備が整います。ピア・リージョンのDR計画は引き続きリフレッシュする必要がありますが、プロセスのこの時点でプライマリOCIリージョンの停止からリカバリできます。計画は常にスタンバイ保護グループから実行されます。

図10: すべてのDR計画がスタンバイ・リージョンでリフレッシュおよび検証されていることを確認します。

プライマリ保護グループ内のプランのリフレッシュ

プライマリ保護グループのDR計画は、まだ非アクティブ(リフレッシュが必要)状態であり、リフレッシュも必要です。ただし、プライマリ・ロールを持つ保護グループに含まれるリカバリ計画(リフレッシュや検証など)は変更できません。そのため、ピア・リージョン内のプランをリフレッシュできるように、スイッチオーバーを実行する必要があります。

図11: スイッチオーバー後に、プライマリDR保護グループで計画をリフレッシュする必要があります。

まとめ

変化への対応は複雑になる可能性がありますが、Full Stack DRは、この新しい機能強化により、変更の管理を少しシンプルにしました。新しいDR計画リフレッシュ機能では、計画が自動的に再構築され、完了までに多くの時間を要したユーザー定義ステップが保護されます。

もっと知りたいですか?

新しいDR計画のリフレッシュ機能を含めるためのメンバー・リソースの追加に関するドキュメントが更新されました。また、Oracle Help Centerで、新機能の使用方法の詳細を説明するチュートリアルも作成しました。

OCI Full Stack Disaster Recoveryをまだ実際にご覧になっていない場合は、Oracle Cloud Infrastructureのアカウント・チームに今すぐデモンストレーションを設けてください。ドキュメント、価格、チュートリアル、顧客成功事例、チュートリアル、ハンズオン・ラボなどの詳細は、Full Stack Disaster Recoveryを参照してください。