ノート:

OCI Full Stack Disaster Recoveryによる災害復旧計画管理の強化

イントロダクション

Oracle Cloud Infrastructure Full Stack Disaster Recovery(OCI Full Stack DR)は、世界中のOracle Cloud Infrastructure(OCI)リージョン間のコンピュート、データベース、アプリケーションの移行をワンクリックで調整します。お客様は、既存のインフラストラクチャ、データベースまたはアプリケーションを再設計または再設計することなく、特別な管理サーバーや変換サーバーを必要とせずに、1つ以上のビジネス・システムをリカバリするために必要なステップを自動化できます。

OCI Full Stack DRサービスの最近の更新により、DR計画の管理が大幅に改善されました。メンバーの更新、追加または削除がある場合、プランは削除されず保持され、ユーザーはプランをリフレッシュして確認できます。これらの変更によってユーザー・エクスペリエンスがどのように強化され、DR管理が簡素化されるかについて検討してみましょう。

初期デプロイメント・アーキテクチャ

デプロイメント・アーキテクチャ

ターゲット・デプロイメント・アーキテクチャ

ターゲット・デプロイメント・アーキテクチャ

目的

既存のDR計画を削除せずに、既存のFull Stack DR Protection Groupメンバー・リソースを変更します。このチュートリアルでは、1つの移動コンピュートを削除し、2つのOCIリージョン間ですでにピアである既存のプライマリDR保護グループとスタンバイDR保護グループに2つの非移動コンピュートを追加することで、プラン・リフレッシュ・ワークフローをデモンストレーションします。

プライマリ・リージョンはアッシュバーンで、スタンバイ・リージョンはフェニックスです。

このチュートリアルでは、次のタスクについて説明します。

前提条件

タスク1: プライマリDRPGからのメンバーの削除

  1. プライマリDRPG (DRPG_Refresh_IAD)で、「メンバー」を選択します。

    メンバーの削除

  2. コンピュートVM (vmapp02)を選択し、「メンバーの削除」をクリックします。

    メンバーの削除

  3. 「すべての既存のプランをリフレッシュして検証する必要があることを理解しています」を選択し、「削除」をクリックします。

    メンバーの削除

タスク2: プライマリおよびスタンバイDRPGへの新規メンバーの追加

  1. プライマリDRPG (DRPG_Refresh_IAD)で、「メンバー」を選択し、コンピュートVM (vmapp03)をメンバーとして追加します。

    新規メンバーの追加

  2. スタンバイDRPG (DRPG_Refresh_PHX)で、「メンバー」を選択し、コンピュートVM (vmapp03dr)をメンバーとして追加します。

    新規メンバーの追加

スタンバイDR保護グループ(DRPG)内のすべてのDR計画は、プライマリDR保護グループまたはスタンバイDR保護グループのメンバーに変更が加えられるたびに注意が必要(リフレッシュが必要)に設定されます。スタンバイ・リージョンとプライマリ・リージョンの両方のDR計画は変更できません。DRPGメンバーシップに対する追加の変更は、どちらのリージョンでも行うことができますが、DR計画グループおよびステップは、リフレッシュおよび検証ワークフローが完了するまで追加、削除または変更できません。

保護グループのメンバーに対する変更を完了すると、次のスクリーンショットのように表示されます。このスクリーンショットは、ベスト・プラクティスとしてスタンバイ保護グループに存在する必要がある4つのDR計画タイプのうち3つを示しています。3つのプラン・タイプすべてを作成した場合と作成しなかった場合があり、これは単なる例です。

FSDR-plans-need-attn.png

タスク3: スタンバイDRPGでのDR計画のリフレッシュ

注意が必要(リフレッシュが必要)状態のDR計画をリフレッシュして、両方のリージョンの保護グループのメンバーに加えられた変更の結果として追加または削除される計画グループおよび計画ステップを表示します。これは、タスク4の一部として計画された変更にコミットする前にDR計画を視覚的に確認できる重要なステップです。

スタンバイDRPGに含まれるDR計画のみがリフレッシュおよび検証できます。これは、「注意が必要(リフレッシュが必要)」状態であるためです。非アクティブ状態のプライマリDRPGのDR計画は、そのDRPGがスタンバイ・ロールを継承するまでリフレッシュできません。DR保護グループの詳細ページでロールを手動で切り替えると、リフレッシュ・プロセスは機能しないため、プライマリDRPGのロールをスタンバイに変更する唯一の有効な方法は、スタンバイDRPGでスイッチオーバー計画を実行することです。スイッチオーバーについては、次のタスクで説明します。

リフレッシュの目的は、変更のコミット前にDR計画に対して追加または削除されるすべての内容を確認できるようにすることです。メンバーシップの変更によって影響を受けるプラン・グループおよびステップは、プランのリフレッシュの完了後にタグ付けされます。次のリストは、変更された計画グループおよびステップをコールアウトする様々なタグを示しています。

ステップに従います。

  1. 最初に、注意が必要(リフレッシュが必要)状態のDR計画を選択します。

  2. 次のスクリーンショットに示すように、「リフレッシュ」をクリックします。

  3. 確認ボックスが表示されます。確認ボックスの「リフレッシュ」をクリックして続行します。

    プランのリフレッシュ

    リフレッシュが完了すると、DR計画は次のスクリーンショットのようになります。リフレッシュ・プロセスでは、両方のリージョンのメンバー・リソースに対して行われたすべての変更がイントロスペクトされ、プラン・グループおよびステップが変更されて、メンバーシップの変更に基づいて行われる調整が示されます。リフレッシュが完了すると、リフレッシュされたDR計画の状態が「注意が必要(検証が必要)」に変わります。「リフレッシュ」ボタンのラベルの下のスクリーンショットが「検証」に変更されていることを確認します。

    プランのリフレッシュ

    次のスクリーンショットに示すように、すべてのプラン・グループを展開すると、検証タスクの一部として追加または削除される個々のプラン・ステップがすべて表示されます。更新されたプラン・グループおよび対応するステップは、上記のリストのタグを使用して一時的にラベル付けされます。

    プランのリフレッシュ

    プランのリフレッシュ

    注意が必要(リフレッシュが必要)状態にあるスタンバイDRPG内の残りのすべてのDR計画をリフレッシュして視覚的に確認してから、次のタスクに移動します。

タスク4: スタンバイDRPGでのDR計画の検証

リフレッシュされたDR計画を視覚的に確認した後で検証します。これは、変更されたDR計画の計画変更をコミットするもう1つの重要なステップです。

  1. 開始するには、「注意が必要(検証が必要)」状態のプランを選択します。

  2. 次のスクリーンショットに示すように、「検証」をクリックします。

  3. 確認ボックスが表示されます。確認ボックスの「検証」をクリックして続行します。

    プランの確認

検証プロセスでは、プランからすべての変更タグが削除され、次のスクリーンショットに示すように、「事前チェックの実行」および「プランの実行」ボタンが有効になります。検証が完了すると、プランの状態が「アクティブ」に変わります。

プランの確認

すべての計画が「アクティブ」に変更されるまで、スタンバイDRPGの残りのDR計画のうち、「注意が必要(検証が必要)」状態にあるものをすべて確認してから、次のタスクに移動します。

FSDR-all-plans-active.png

タスク5: スタンバイDRPGの計画に対する最終調整

このチュートリアルで示すDR計画の例には、ユーザー定義の計画グループまたはステップはありません。ただし、ユーザー定義プラン・グループおよびステップが存在しない場合は、追加を試すことができます。

このチュートリアルを使用してテナンシ内の既存のDR保護グループおよび計画を更新する場合は、この機会を使用して、リフレッシュされたDR計画に適切な変更を加えます。次のリストは、既存の計画で調整するいくつかの例を示しています。

次のタスクに進む前に、既存のすべてのDR計画が調整されていることを確認します。

タスク6: スタンバイDRPGでのスイッチオーバー計画の実行

ノート:

現在のスタンバイ・リージョンでリフレッシュしたスイッチオーバー計画の事前チェックを実行し、事前チェックが成功した場合はスイッチオーバー計画を実行します。その後、スイッチオーバーが正常に完了したら、2番目のリージョンのピアDR保護グループに含まれるすべてのDR計画について、タスク3および4をステップ・スルーします。

プライマリ・リージョンのDR計画は引き続き「非アクティブ(リフレッシュが必要)」状態になり、リフレッシュも必要になります。ただし、プライマリ・ロールを持つ保護グループに含まれるリカバリ計画は、リフレッシュや検証など、変更できません。DR計画の完全なリフレッシュ・ライフサイクルを完了し、ディザスタ・リカバリの整合性を確保するには、ワークロードを現在のスタンバイ・リージョンに移行する必要があります。

ベスト・プラクティスとして、最初に独立した操作として事前チェックを実行します。

  1. 開始するには、スタンバイ・リージョンでスイッチオーバー計画を開きます。

  2. 「事前チェックの実行」をクリックします。

  3. 確認ボックスが表示されます。確認ボックスの「事前チェックの実行」をクリックして続行します。

    スイッチオーバー事前チェック

    次のスクリーンショットに示すように、事前チェックが正常に完了していることを確認します。この時点で失敗した事前チェック・ステップを修正してから、すべてのステップが成功するまで事前チェックを再度実行する必要がある場合があります。

    スイッチオーバー事前チェック・ステータス

スイッチオーバー計画を実行します。

  1. 開始するには、「計画の実行」をクリックします。

  2. 確認ボックスが表示されます。確認ボックスの「計画の実行」をクリックして続行します。

  3. 計画の実行を監視して、計画内のすべてのステップが成功することを確認します。

    ディザスタ・リカバリ計画の実行

次のスクリーンショットは、スイッチオーバー計画が正常に完了したことを示しています。ただし、事前チェックが正常に完了しても、失敗したステップが発生することがあります。リカバリ・ステップが実際に実行されているため、ステップが失敗する可能性があります。失敗したステップを修正し、再試行してください。

障害リカバリ・プランの実行ステータス

タスク7: スイッチオーバー後のDR計画のリフレッシュおよび検証

スイッチオーバーが完了すると、DR保護グループのロールは自動的に元に戻されます。この例を続行すると、フェニックスがプライマリ・ロールになり、アッシュバーンがスタンバイ・ロールになります。

この時点で、アッシュバーン内のすべてのDR計画は、スタンバイDRPGになるため、「非アクティブ(リフレッシュが必要)」状態になります。新しいスタンバイ・リージョンで、次のタスクを繰り返す必要があります。

次のステップ

DR計画の準備を確実にするために、通常の日常業務に組み込む必要がある2つのベスト・プラクティスがあります。

スタンバイDR保護グループ内のすべてのDR計画の週次事前チェックをスケジュールすることを検討してください。事前チェックはいつでも実行でき、本番ワークロードには影響しません。これにより、DR計画の整合性の確保、欠落しているメンバー・リソースの捕捉、ネットワークの欠落、ユーザー定義ステップによってコールされる予期されるスクリプトの検出不能などに役立ちます。

ディザスタ・リカバリの準備状況を検証するもう1つの非常に重要な方法は、定期的なDR Drillsを月または四半期に1回スケジュールすることです。DR Drillsは本番ワークロードにも影響しませんが、スタンバイ・リージョンのコンピュート、ストレージ、Oracleデータベースおよびロード・バランサのバックエンド・セットのリカバリを1回のボタンで検証できます。Full Stack DR Drillsの詳細

承認

その他の学習リソース

docs.oracle.com/learnの他のラボを確認するか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスしてOracle Learning Explorerになります。

製品ドキュメントは、Oracle Help Centerを参照してください。