ノート:

OCI Full Stack Disaster Recoveryを使用したOracle Enterprise Performance Managementのリカバリの自動化

パート1: 概要

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

このチュートリアルでは、OCI Full Stack DRサービスを利用して、OCIディザスタ・リカバリ・フレームワーク内のOracle Enterprise Performance Managementシステム環境11.1.2.xおよび11.2.xのスイッチオーバーおよびフェイルオーバー・プロセスを管理する手順の概要を示します。システム・トポロジの構成およびその他のライフサイクル・アクティビティ(パッチ適用、テスト、拡張など)は、OCI Full Stack DRの範囲外であることに注意してください。

ディザスタ・リカバリ(DR)戦略では、アプリケーション用のブート・ボリュームとブロック・ボリュームの両方と、本番環境からスタンバイ・サイトへのデータベース用のOracle Data Guardの包括的なレプリケーションが採用され、スタンバイ・ロケーションの構成が大幅に簡素化されます。この方法は、EPM Systemデプロイメント・オプション・ガイドで概説されているDRガイドラインに準拠しています。このガイドは、Fusion Middlewareで提供されるディザスタ・リカバリに関する推奨事項に準拠しています。

Oracle Enterprise Performance Management (Oracle EPM)とHyperion EPMは、チュートリアルで同じ意味で使用されます。

Oracle Enterprise Performance Managementは、通常、より大きなシステムの一部です。

このチュートリアルでは、Oracle EPMがDR保護グループに追加される唯一のアプリケーションであることを前提としています。これは正常ではありません。

このチュートリアルでは、わかりやすくするために、Oracle EPM Systemのみに焦点を当てています。実際には、Oracle EPMは通常、大規模なビジネス・システムのコンポーネントであり、単一のOCI Full Stack DR保護グループと一連のDR計画内にさまざまなサービスとアプリケーションが含まれています。PeopleSoft、Oracle WebLogic Server、Oracle Analytics Cloud、Oracle Integrationなど、他のアプリケーションやサービスについても同様のOracle Help Center (OHC)チュートリアルに従うことがよくあります。

増分実装に関する注意

DR計画の作成後にDR保護グループにメンバーを追加すると、両方のリージョンの保護グループ内のすべての既存のDR計画が削除されます。

OCI Full Stack DRは、特定のビジネス・システムのアプリケーション・スタック全体がOCIリージョン全体にすでにデプロイされており、手動DRがすでに機能していることが証明されていることを前提に設計されています。ビジネス・システムにOracle EPMを超えるものが含まれている場合は、DR計画を作成する前に、他のすべてのアプリケーションまたはOCIサービスのすべてのメンバーをDR保護グループに追加します。

リカバリの仕組み

Oracle EPMのリカバリ・ソリューションでは、フェイルオーバーやスイッチオーバーなどのリカバリ操作中にOCI Full Stack DRで一連のカスタム・シェル・スクリプトを実行する必要があります。このチュートリアルで参照されるスクリプトは、EMEA Cloudアーキテクチャ・スペシャリスト・チームによって提供され、このHyperion EPM DRソリューション用に特別に調整されたOracle EPM GitHubリポジトリで入手できます。スクリプトは、リカバリ操作中にOCI Full Stack DRが管理するアプリケーション・スタックの一部であるコンピュート・インスタンスにダウンロードされます。

このチュートリアルでは、スクリプトをダウンロードする方法と、後の手順でスクリプトを使用する方法を説明します。

一般的なガイダンスについては、次のスクリプトが提供されています。独自のスクリプトを使用するか、企業のポリシーおよびセキュリティ要件に従ってスクリプトをカスタマイズできます。

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

このチュートリアルでは、Oracle EPMアプリケーションの移動インスタンス・トポロジを使用します。一般に、移動インスタンスはコールド VM/パイロット ライトDRトポロジと呼ばれます。アプリケーションVMは、プライマリ・リージョンにのみデプロイされます。DRの実行中、VMはスタンバイ・リージョンに作成されます。Oracle Data Guardを使用するOracle DBシステムは、プライマリおよびスタンバイ・リージョンに作成する必要があります。OCI Full Stack DRソリューションを実装する前に、プライマリHyperion EPM Systemをインストールし、1つのOCIリージョンに完全に構成する必要があります。

この設計は、OCI上のHyperionのリファレンスDRアーキテクチャに基づいており、詳細に確認できます。詳細は、Oracle Enterprise Performance Managementをクラウドにデプロイするためのインフラストラクチャの設計を参照してください。

プライベートOCI Load Balancer

内部およびオンプレミス・ユーザーからのトラフィックは、IPSec VPNトンネルまたはFastConnect仮想回線を経由して、VCNにアタッチされている動的ルーティング・ゲートウェイ(DRG)に移動します。プライベート・ロード・バランサは、リクエストをインターセプトし、プライベートWeb層に分散します。

Web層は、プライベート・サブネットにアタッチされているコンピュート・インスタンスでホストされます。

アプリケーション層

アプリケーション層内のすべてのコンピュート・インスタンスは、プライベート・サブネットにアタッチされます。ネットワーク・レベルでのこの分離により、アプリケーションは、未認可のネットワーク・アクセスおよびトポロジ内のその他のリソースから保護されます。

サービス・ゲートウェイを使用すると、アプリケーション層のプライベート・コンピュート・インスタンスは、リージョン内のYumおよびWSUSサーバーにアクセスして、オペレーティング・システムの更新および追加パッケージを取得できます。また、サービス・ゲートウェイを使用すると、パブリック・インターネットを経由せずに、リージョン内のOCI Object Storageにアプリケーションをバックアップできます。

ブロック・ボリュームおよびファイル・システムに格納されているデータは、クロスリージョン・レプリケーション(CRR)を使用してスタンバイ・リージョンにレプリケートされます。

データベース層

Oracle Base Database Serviceは、EPM Systemスキーマをホストします。データは、Data Guardを使用してスタンバイ・リージョンに同期されます。

oci-arch-oracle-epm.png
図1: Oracle EPMリファレンス・アーキテクチャ

プロセス全体の理解

EMEA OCIスペシャリストおよびOCI Full Stack DRエンジニアリング・チームは、このチュートリアルで使用する一連のコンパニオン・ビデオを作成して、プロセス・フロー全体を理解しています。これらのビデオは、次のリンクを使用してアクセスできるOCI Full Stack DR Oracle EPMプレイリスト(YouTube)の一部です。

パート2: ステップバイステップの手順

この部では、Oracle EPMをOCI Full Stack DRに追加するために必要なステップバイステップの手順を開始します。

目的

次のステップは、フル・スタックDRを使用してOracle EPMのリカバリを自動化する方法を説明するこのチュートリアルで説明します。

  1. タスク1: 障害時リカバリのためのOracle EPMのデプロイ
    1. Oracle Base Database ServiceのクロスリージョンOracle Data Guardの構成
    2. カスタム自動化を実行するためのDR制御ノードの準備
    3. ブロック・ボリューム・グループの作成
    4. フル・スタックDR用のOracle Cloud Infrastructure Identity and Access Management (OCI IAM)ポリシーの作成
    5. 他のOCIサービス用のOCI IAMポリシーの作成
    6. ログ用のOCIオブジェクト・ストレージ・バケットの作成
    7. スタンバイ・ロード・バランサの作成(オプション)
  2. タスク2: DR保護グループ(DRPG)の作成
  3. タスク3: リージョン1およびリージョン2 DRPGへのメンバーの追加
  4. タスク4: リージョン2での基本的なDR計画の作成(Newport)
    1. スイッチオーバー計画の作成
    2. フェイルオーバー計画の作成
  5. タスク5: リージョン2 (Newport)でのスイッチオーバー計画のカスタマイズ
  6. タスク6: リージョン2 (Newport)でのフェイルオーバー計画のカスタマイズ
  7. タスク7: リージョン2 (Newport)でのスイッチオーバー計画の実行
  8. タスク8: リージョン1 (ロンドン)での基本的なDR計画の作成
    1. スイッチオーバー計画の作成
    2. フェイルオーバー計画の作成
  9. タスク9: リージョン1 (ロンドン)でのスイッチオーバー計画のカスタマイズ
  10. タスク10: リージョン1(ロンドン)でのフェイルオーバー計画のカスタマイズ

チュートリアル全体の定義と仮定

地域

地域1はロンドン

地域2はニューポート

区分

Oracle EPMおよびOCI Full Stack DRは、ITガバナンスの標準内で機能するコンパートメント・スキームに自由に編成できます。アプリケーションを個別のコンパートメントに編成し、すべてのDR保護グループを単一のコンパートメントに編成することを選択しました。このコンパートメントでは、まったく異なるビジネス・システムが一目でわかります。

DR制御ノード

DR制御ノードは、EPM Systemをリカバリするための特定のタスクを実行するカスタム・スクリプトをホストするために指定した任意のコンピュート・インスタンスです。このスクリプトは、リカバリ操作中にFull Stack DRによってコールされます。DR保護グループ(DRPG)のメンバーである既存のコンピュート・インスタンスは、制御ノードにできます。この例では、EPM Systemアプリケーション・サーバーは、リカバリ・プロセスで使用されるすべてのカスタム・スクリプトをホストします。このチュートリアルでは、アプリケーション・ノードと制御ノードの両方が同じです。

前提条件

タスク1: 障害時リカバリのためのOracle EPMのデプロイ

OCI Full Stack DRは、このステップのどの部分にも関与していません。

タスク1.1: Oracle Base Database ServiceのクロスリージョンOracle Data Guardの構成

Oracle Base Database Service用のクロスリージョンOracle Data Guardをデプロイするには、DB SystemでのOracle Data Guardの使用を参照してください。

システム内のデータベースをOracle Data Guardと同期する場合、プライマリ・データベースとスタンバイ・データベースの両方に同じデータベース・サービス名またはTNS別名を使用することが重要です。この演習では、スイッチオーバー後にアプリケーション・レイヤーで必要な変更を最小限に抑え、スムーズな移行を実現します。詳細なガイダンスについては、Fusion Middleware DRドキュメントの「データベースに関する考慮事項」の項を参照してください。ここでは、様々なアプローチについて詳しく説明します。

タスク1.2: カスタム自動化を実行するためのDR制御ノードの準備

EPM Full Stack DRのDR制御ノードとして機能するコンピュート・インスタンスを指定します。これは、既存のコンピュート・インスタンスでも、この目的でのみ作成されたコンピュート・インスタンスでもかまいません。詳細は、後述のオプションを参照してください。DR制御ノードとして機能するコンピュート・インスタンスが、Oracle Cloud Agent: インスタンスでのコマンドの実行を使用してコマンドを実行するように構成されていることを確認します。

移動可能なコンピュート・インスタンスを使用することをお薦めしますが、DRソリューションの一部として移動可能なコンピュートがない場合には、リージョン1の移動不可能なコンピュート・インスタンスとリージョン2の別のコンピュート・インスタンスを指定することもできます。移動不可能なコンピュートがこのロールに使用されている場合は、スクリプトまたはゲストOSに対する変更を両方のリージョンで維持する必要があります。

このEPM System DRの例専用に記述されたOracle EPM Githubスクリプトから、DR制御ノードにカスタム・スクリプトをダウンロードします。次に示すスクリプトは、DR制御ノードとして機能するコンピュート・インスタンス上の任意のサブディレクトリにコピーする必要があります。このチュートリアルでは、DR制御ノードとしてEPMアプリケーション・ノードも使用します。スクリプトは、EPM Systemリカバリのこの例用に特別に作成され、リカバリ・ソリューションで使用するために変更する必要があります。このチュートリアルでは、EPMアプリケーションがWindows VMで実行されているため、Powershell (ps1)スクリプトが使用されます。Linux VMを使用する場合、シェルスクリプトは同じgithubリポジトリで使用できます。スクリプトの実行にEPM VMを使用しているため、DR制御ノードは同じEPM VMと呼ばれます。

タスク1.3: ブロック・ボリューム・グループの作成

リージョン1にブロック・ボリューム・グループを作成し、リージョン2にレプリケートされていることを確認します。DR制御ノードのブート・ボリュームがブロック・ボリューム・グループのメンバーであり、ブロック・ボリューム・グループがリージョン2にレプリケートされていることを確認します。詳細は、ボリューム・グループの作成を参照してください。

このOCI Full Stack DRプロジェクトの他の移動可能なコンピュートに属する他のブートおよびブロックも、リージョン2にレプリケートされたブロック・ボリューム・グループに属していることを確認します。

タスク1.4: OCI Full Stack DRのOCI IAMポリシーの作成

以下のドキュメントで概説されているOCI Full Stack DRの必須OCI IAMポリシーを構成すること。

タスク1.5: OCI Full Stack DRによって管理される他のサービスのためのOCI IAMポリシーの作成

OCI Full Stack DRには、コンピュート、ネットワーキング、ストレージ、ボールト、データベース、その他のサービスなど、他の主要なOCIサービスを制御および管理する機能が必要です。フル・スタック・災害復旧によって管理される他のサービスのポリシーについて、他のサービスに対して必要なOCI IAMポリシーを構成すること。

タスク1.6: DRPGログ用のOCIオブジェクト・ストレージ・バケットの作成

タスク1.6.1: OCIオブジェクト・ストレージへのナビゲート

まず、図1.1に示すように、オブジェクト・ストレージおよびアーカイブ・ストレージに移動します。

  1. ブラウザ・コンテキストがリージョン1 (London)に設定されていることを確認します。
  2. 「記憶域」を選択します。
  3. 「バケット」を選択します。

oss-bucket-nav-lon.png
図1.1:オブジェクト・ストレージにナビゲートします。

タスク1.6.2: リージョン1のOCIオブジェクト・ストレージ・バケット

リージョン1にOCI Object Storageバケットを作成します。後のステップでは、バケットがリージョン1のDR保護グループに割り当てられます。

  1. EPMシステム関連リソースを含むコンパートメントを選択します。
  2. 「バケットの作成」をクリックします。
  3. バケットに意味のある名前を付け、どのアプリケーションと目的が機能するかを簡単に識別します。
  4. 「デフォルト・ストレージ層」および「暗号化」のデフォルト値を使用します。
  5. 「作成」をクリックして、バケットを作成します。

oss-bucket-create-lon.png
図1.2:リージョン1でのオブジェクト・ストレージ・バケットの作成

タスク1.6.3: リージョン2のOCIオブジェクト・ストレージ・バケット

同じプロセスに従って、リージョン2 (Newport)にオブジェクト・ストレージ・バケットを作成します。「Newport」リージョンを選択してください。後のステップでは、バケットがリージョン2のDR保護グループに割り当てられます。

  1. コンテキストをリージョン2に変更します。
  2. リージョン2のEPM System関連リソースを含むコンパートメントを選択します。
  3. 「作成」をクリックして、バケットを作成します。

oss-bucket-create-lon.png
図1.3:リージョン2でのオブジェクト・ストレージ・バケットの作成

タスク1.7: (オプション)スタンバイ・リージョンでのOCI Load Balancerの作成

EPM Systemに含まれていない場合は、OCI Load Balancerの使用はオプションです。このタスクはスキップします。

スタンバイ・リージョンにOCI Load Balancerを作成します。

  1. プライマリ・ロード・バランサの構成をミラー化します。
  2. このロード・バランサ内に空のバックエンド・セットを作成します。スタンバイ・リージョンのこの時点で、構成に含めるバックエンドがないため、空のバックエンド・セットのみを作成する必要があります。

スイッチオーバー時またはフェイルオーバー時の構成:

  1. プライマリEPM Systemバックエンド・セットの構成は、空のスタンバイ・バックエンド・セットにコピーされます。

証明書とリスナー:

  1. 独自の証明書を使用する場合は、それらをスタンバイ・ロード・バランサにロードします。
  2. プライマリ・ロード・バランサの構成と一致するようにリスナーを構成します。

スイッチオーバー後の更新:

  1. スイッチオーバー後、スタンバイ・ロード・バランサのIPアドレスを指すようにDNS情報を更新します。

詳細は、Overview of Load Balancerを参照してください。

タスク2: 両方のリージョンでのDR保護グループ(DRPG)の作成

ノート: Oracle EPMが既存のDR保護グループに追加されている場合は、タスク2を完全にスキップします。

このアプリケーション・スタックの保護グループがまだ存在しない場合は、リージョン1およびリージョン2にDR保護グループを作成します。

タスク2.1: DR保護グループへのナビゲート

まず、図2-1に示すように、DR保護グループ(OCIフル・スタックDR)に移動します。

  1. OCIリージョン・コンテキストがリージョン1 (London)に設定されていることを確認します。
  2. 「Migration & Disaster Recovery」をクリックします。
  3. 「DR保護グループ」をクリックします。

drpg-create-nav-iad.png
図2-1: DR保護グループに移動します。

タスク2.2: リージョン1での保護グループの作成

図2-2に示すように、リージョン1に基本的なDR保護グループ(DRPG)を作成します。ピア、ロールおよびメンバーは、後のステップで割り当てられます。

  1. DRPGを作成するコンパートメントを選択します。これは、EPM Systemリソースが存在するのと同じコンパートメントにできます。
  2. 「DR保護グループの作成」をクリックして、ダイアログを開きます。
  3. DRPGに意味のある名前を使用します。
  4. リージョン1のタスク2で作成したオブジェクト・ストレージ・バケットを選択します。
  5. 「作成」をクリックします。

drpg-create-finish-lon.png
図2.2:リージョン1でDR保護グループを作成するために必要なパラメータ

タスク2.3: リージョン2での保護グループの作成

図2-3に示すように、リージョン2に基本的なDR保護グループ(DRPG)を作成します。ピア、ロールおよびメンバーは、後のステップで割り当てられます。

  1. OCIリージョン・コンテキストをリージョン2 (Newport)に変更します。
  2. DRPGを作成するコンパートメントを選択します。これは、EPM Systemリソースが存在するのと同じコンパートメントにできます。
  3. 「DR保護グループの作成」をクリックして、ダイアログを開きます。
  4. DRPGに意味のある名前を使用します。
  5. リージョン2のタスク2で作成したオブジェクト・ストレージ・バケットを選択します。
  6. 「作成」をクリックします。

drpg-create-finish-newport.png
図2-3:リージョン2でDR保護グループを作成するために必要なパラメータ

タスク2.4: リージョン1およびリージョン2での保護グループの関連付け

各リージョンのDRPGを相互にピアとして関連付け、プライマリおよびスタンバイのピア・ロールを割り当てます。このようにして、OCI Full Stack DRは、Oracle EPM Systemのリカバリのためにどの2つのリージョンが連携しているかを把握します。プライマリとスタンバイのロールは、DR操作/DR計画実行の一環としてOCI Full Stack DRによって自動的に変更されます。いつでも手動でロールを管理する必要はありません。

タスク2.4.1: 関連付けの開始

  1. OCIリージョン・コンテキストがリージョン1 (ロンドン)に設定されていることを確認します。
  2. 「関連付け」をクリックして、プロセスを開始します。

drpg-assoc-begin-lon.png
図2.4.1: DRPGアソシエーションの開始

タスク2.4.2: リージョン1およびリージョン2での保護グループの関連付け

図2.4.2に示すように、パラメータを指定します。

  1. プライマリ・ロールを選択します。OCI Full Stack DRは、スタンバイ・ロールをリージョン2に自動的に割り当てます。
  2. もう一方のDRPGが作成されたリージョン2 (Newport)を選択します。
  3. 作成されたピアDRPGを選択します。
  4. 「関連付け」をクリックします

drpg-assoc-finish-lon.png
図2.4.2: DRPGを関連付けるために必要なパラメータ

タスク2.4.3: アソシエーションの完了後に表示される内容

OCI Full Stack DRは、関連付けが完了すると、図2.4.3のようなものを表示します。

  1. 現在のプライマリ・ピアDRPGはロンドン(リージョン1)です。
  2. 現在のスタンバイ・ピアDRPGはNewport (リージョン2)です。

drpg-assoc-completed-lon.png
図2.4.3:個々のDRPGパースペクティブからのピア関係の表示

次の図2.4.4に示すように、コンテキスト/ビューがすべてのDR保護グループを示すグローバルな視点からのものである場合、同じ情報を見つけることができます。

  1. 現在のプライマリ・ピアDRPGはロンドン(リージョン1)です。
  2. 現在のスタンバイ・ピアDRPGはNewport (リージョン2)です。

drpg-assoc-completed-lon.png
図2.4.4:グローバルDRPGの観点からピア関係を表示

タスク3: DR保護グループへのメンバーの追加

ノート:このタスクでは、既存のDR保護グループにメンバーを追加するときに、両方のリージョンの既存のDR計画が削除されます。OCI Full Stack DRは、この書き込み時にコピーを保存したり、DR保護グループのバックアップを作成したりすることはできません。カスタムのユーザー定義プラン・グループおよびステップの再作成に役立つように、DRプラン・グループおよびステップに関するすべての情報をテキスト・ファイルまたはスプレッドシートに記録していることを確認してください。OCI Full Stack DR CLIコマンドを呼び出すbashスクリプトを作成して、カスタムのユーザー定義プラン・グループおよびステップを再作成することもできます(これは、このチュートリアルの範囲外です)。

データベースおよびOracle EPM Systemアプリケーションの計算ノードをDR保護グループのメンバーとして追加します。DR制御ノードは、DRオーケストレーションをサポートするために作成したコンピュート・インスタンスか、フル・スタックDRで管理するアプリケーション・スタックの一部であるコンピュート・インスタンスです。この例では、EPM Systemアプリケーション・ノードもDR制御ノードの機能を実行します。

リージョン1のプライマリDRPGに次のリソースを追加します。

  1. EPM Systemアプリケーションの計算ノード。DR制御ノードの機能も実行します。
  2. ボリューム・グループには、EPMシステム・アプリケーションの計算ノードのブート・ボリュームが含まれます。存在する場合は、コンピュート・ノードにアタッチされた追加のブロック・ボリュームをボリューム・グループに含める必要があります。
  3. プライマリOracle Base Database Service。
  4. プライマリ・ロード・バランサ。

タスク3.1: リージョン1でのDRPGへのメンバーの追加の開始

まず、図3-1に示すように、リージョン1でDRPGを選択します。

  1. OCIリージョン・コンテキストがリージョン1 (London)であることを確認します。
  2. リージョン1でDRPGを選択します。
  3. 「メンバー」を選択します。
  4. 「メンバーの追加」をクリックしてプロセスを開始します。

drpg-add-nav-lon.png
図3-1:リージョン1でDR保護グループへのメンバーの追加を開始する方法

タスク3.1.1: DR制御ノードのコンピュート・インスタンスの追加

図3.1.1に示すように、EPM Systemのコンピュート・インスタンスを追加します。これはDR制御ノードとしても機能します。この例では、単一のコンピュート・インスタンスがEPM Systemのすべてのモジュールをホストしています。EPM Systemが複数の計算ノードを持つ分散環境にデプロイされている場合は、各ノードがこのステップに含まれていることを確認します。

  1. DR計画に関する警告を確認します。
  2. メンバーの「リソース・タイプ」として「コンピュート」と入力します。
  3. EPM Systemアプリケーションのコンピュート・インスタンスを選択します。この同じコンピュート・インスタンスは、ユーザー定義スクリプトの実行にも使用されます。
  4. 「移動インスタンス」を選択します。
  5. リカバリ中にリージョン2のVNICに割り当てるVCNおよびサブネットのOCIフル・スタックDRを追加します。図4-2は、単一のVNICを示しています。OCI Full Stack DRでは、VNICの数や、いずれかのリージョンでの構成方法は考慮されません。要件に合った必要なものを指定してください。スタンバイ・リージョンのターゲット・サブネットから有効なIPアドレスを指定してください。コンピュート・インスタンスでは常に同じ既知のIPアドレスが使用されるため、スイッチオーバー後のホスト・ファイルの更新が簡略化されます。

drpg-add-compute-lon.png
図3.1.1: DR制御ノードを追加するために必要なパラメータ

タスク3.1.2: DR制御ノードのブロック・ボリューム・グループの追加

EPM Systemアプリケーション・ノードにアタッチされたブート・ボリュームおよびブロック・ボリュームを含むブロック・ボリューム・グループを追加します。ブロック・ボリューム・グループには、DR保護グループに追加する前に、2つのリージョン間にクロスリージョン・レプリケーションがすでに構成されている必要があります。

  1. メンバーの「リソース・タイプ」として「ボリューム・グループ」を選択します。
  2. ボリューム・グループを含む正しいコンパートメントが選択されていることを確認し、ボリューム・グループを選択します。

drpg-add-vg-lon.png
図3.1.2: EPM Computeのブート・ボリューム・グループを追加するために必要なパラメータ

タスク3.1.3: プライマリOracle Base Database Serviceの追加

この時点で、Oracle Data Guardは、タスク1の一部としてOracle Base Databaseサービス・システムにすでに構成されている必要があります。プライマリDBをリージョン1のDRPGのメンバーとして追加します。

  1. メンバーの「リソース・タイプ」として「データベース」を選択します。
  2. データベースの正しいコンパートメントが選択されていることを確認します。
  3. EPMデータベースのSYSユーザー・パスワードを含むOCI Vaultにシークレットの詳細を指定します。このシークレットは、タスク1のOracle Data Guardの構成時に作成しました。

drpg-add-db-lon.png
図3.1.3:ベースDBサービスから実行されているプライマリDBを追加するために必要なパラメータ

タスク3.1.4: OCI Load Balancerの追加

この例では、リージョン1のDRPGのメンバーとしてロード・バランサを追加します。

  1. メンバーの「リソース・タイプ」として「Load Balancer」を選択します。
  2. ロード・バランサの正しいコンパートメントが選択されていることを確認します。
  3. 「ソース・バックエンド・セット」:これは、EPM Systemアプリケーションで使用されるバックエンド・セットです。OCI Load Balancerは、複数のアプリケーション間で共有でき、複数のバックエンド・セットが構成されている場合があります。DRスイッチオーバー中、ここで指定したバックエンド・セットのみの構成がスタンバイ・リージョンに移動されます。
  4. 「宛先バックエンド・セット」を選択します。これは、リージョン2のタスク1.7で作成された空のバックエンド・セットです。

drpg-add-db-lbr.png
図3.1.4: Load Balancerの追加に必要なパラメータ

タスク3.1.5: リージョン1のメンバー・リソースの検証

図3.1.5に示すように、リージョン1のDRPGには4つのメンバー・リソースが必要です。メンバー・リソースの名前は異なります。

  1. プライマリ・データベース。
  2. 移動可能なコンピュート・インスタンス。
  3. コンピュート・インスタンスのブロック・ボリューム・グループ。
  4. OCIロード・バランサ

drpg-add-finish-lon.png
図3.1.5:リージョン1でのDRPGのメンバーの表示

タスク3.2: リージョン2でのDRPGへのメンバーの追加の開始

まず、リージョン2でDRPGを選択します。

  1. OCIリージョン・コンテキストがリージョン2 (Newport)であることを確認します。
  2. リージョン2でDRPGを選択します。
  3. 「メンバー」をクリックします。
  4. 「メンバーの追加」をクリックしてプロセスを開始します。

プライマリ・リージョンと同様のステップに従って、リージョン2のスタンバイDRPGに次のリソースを追加します。

  1. スタンバイ/リモートのOracle Base Database Serviceシステム。
  2. スタンバイOCI Load Balancer。

タスクが完了したら、次の図3.2に示すように、リージョン2のDRPGに2つのメンバー・リソースが必要です。

drpg-add-finish-newport.png
図3.2:リージョン2でのDRPGのメンバーの表示

タスク4: リージョン2での基本的なDR計画の作成(Newport)

このステップでは、リージョン2 (Newport)のスタンバイDR保護グループに関連付けられた基本的なスイッチオーバーおよびフェイルオーバー計画を作成します。

各計画の目的は、ワークロードをプライマリ・リージョン1からスタンバイ・リージョン2に移行することです。両方のリージョンのDR保護グループのロールは、DR操作の一部として自動的に元に戻されるため、リージョン1の保護グループがスタンバイになり、フェイルオーバーまたはスイッチオーバー後にリージョン2の保護グループがプライマリになります。

OCI Full Stack DRは、前のタスクで追加したメンバー・リソースに基づいて、両方の計画に組込みステップを事前移入します。計画は、後のステップでカスタマイズされ、リカバリ操作中にEPM Systemに関連するすべてのタスクを処理します。

スイッチオーバー計画は、常にスタンバイ・ロールを持つ保護グループに作成されます。リージョン2は現在スタンバイ保護グループであるため、Newportから開始します。

タスク4.1: DR計画の作成

リージョン2 (Newport)でDRPGを選択して基本計画を作成します。

  1. OCIリージョン・コンテキストがリージョン2 (Newport)であることを確認します。
  2. リージョン2でスタンバイDRPGを選択します。
  3. 「プラン」を選択します。
  4. 「プランの作成」をクリックしてプロセスを開始します。

計画- 作成- 新規ポート-nav.png
図4-1:リージョン2での基本的なDR計画の作成を開始する方法

タスク4.1.1: スイッチオーバー計画の作成

DR計画の作成は、次の図4.1.1に示すように簡単です。

  1. スイッチオーバー計画の名前は簡単ですが意味があります。名前はできるだけ短くする必要がありますが、一目でわかりやすく、危機時の混乱や人的ミスを減らすことができます。
  2. 「プラン・タイプ」に「スイッチオーバー(計画済)」を選択します。この記述の時点では、プラン・タイプは4つのみです。

計画- 作成- 新規ポート-so.png
図4.1.1: DRスイッチオーバー計画の作成に必要なパラメータ

タスク4.1.2: フェイルオーバー計画の作成

次の図4.1.2に示すように、同じプロセスに従って基本的なフェイルオーバー計画を作成します。

  1. フェイルオーバー計画の名前は簡単で意味のあるものにします。名前はできるだけ短くする必要がありますが、一目でわかりやすく、危機時の混乱や人的ミスを減らすことができます。
  2. 「計画タイプ」に「フェイルオーバー(計画外)」を選択します。この記述の時点では、プラン・タイプは4つのみです。

計画- 作成- 新規ポート-fo.png
図4.1.2: DRフェイルオーバー計画の作成に必要なパラメータ

次の図に示すように、リージョン2のスタンバイDR保護グループには、2つのDR計画が必要です。これらは、リージョン1からリージョン2へのワークロードの移行を処理します。同様の計画をリージョン1で作成し、後のタスクでワークロードをリージョン2からリージョン1に移行します。

計画- 作成- 新規ポート-completed.png
図4.1.3:先に進む前にリージョン2に存在する必要がある2つの基本的なDR計画を表示

タスク5: リージョン2でのスイッチオーバー計画のカスタマイズ(Newport)

タスク4で作成される基本的なDR計画には、Full Stack DRに組み込まれており、EPM Systemアプリケーションに固有のリカバリ・タスクを管理するためのものを含まないリカバリ・タスクの事前移入されたステップが含まれています。このステップでは、カスタムのユーザー定義DR計画グループを追加する方法と、EPM Systemのスイッチオーバー中に完了する必要があるタスクを管理するステップについて説明します。

タスク5.1: スイッチオーバー計画の選択

タスク4で作成したスイッチオーバー計画にナビゲートします。

プラン- カスタム- 新規ポート-nav.png
図5.1:リージョン2でのスイッチオーバー・プランのカスタマイズを開始する方法

タスク5.2: (オプション)アーティファクトを終了するDR計画グループの有効化

次のスクリーンショットに示すように、スイッチオーバー・プランには、デフォルトで無効になっている2つのプラン・グループがあります。これらは、テスト中に実際に削除されるものがないこと、およびテスト中に問題が発生した場合に備えて、バックアップとしてアーティファクトの実行可能なコピーを保持していることを快適にするために無効になっています。

ただし、これら2つの計画グループは、今後DR操作の一部として再利用されないアーティファクトを終了(削除)します。アーティファクトは、2つのリージョン間を切り替えて、実際にアクティブにする必要があるコンピュート・インスタンスとボリューム・グループについて混乱を招くため、時間の経過とともに蓄積し続けます。

これらの計画グループは、OCI Full Stack DRが本番に移行したら有効にする必要があります。スイッチオーバーおよびスイッチバックのテスト中にこれら2つのプラン・グループが無効になっている間に所定の位置に残されたアーティファクトは、通常操作中の混乱および人的エラーの可能性を減らすために、本番に移行する前に終了およびクリーン・アップする必要があります。

必要に応じて、これらのプラン・グループを有効にして、本番環境に移行する前に余分なアーティファクトを手動でクリーンアップする必要がなくなります。

plan-custom-so-newport-disabled-show.png
図5.2:デフォルトで無効になっているプラン・グループ

使用不可のプラン・グループが有効化されると、次の処理が実行されます。

  1. この計画グループは、OCIオブジェクト・ストレージ操作中にレプリケートされたバージョンのVMがリージョン2で起動された後、リージョン1に残されたコンピュート・インスタンスのアーティファクトを終了し、スイッチオーバーの一部としてリージョン2からリージョン1にレプリケーションをリバースします。残りのVMはスイッチバック中は使用されません。ブロック・ボリューム・レプリケーションをリバースする操作によって、まったく新しいブロック・ボリューム・グループにすべての新しいVMが作成されるためです。

  2. この計画グループは、リージョン2でレプリケートされたバージョンのVGがアクティブ化され、スイッチオーバー中にボリューム・グループ・レプリケーションが元に戻された後、リージョン1で残されたブロック・ボリューム・グループ(VG)のアーティファクトを終了します。残りのブロック・ボリューム・グループは、リージョン2からリージョン1へのスイッチオーバーの一部としてさえも、二度と使用されません。

タスク5.2.1: コンピュート・プラン・グループの終了の有効化

計画グループを使用可能にします。

  1. プラン・グループ名の右側にあるコンテキスト・メニューから「すべてのステップの有効化」を選択します。

    計画- カスタム- 新規ポート- 有効化- 終了-vm.png
    図5.2.1:コンピュート・インスタンスの終了を有効にする方法

タスク5.2.2ボリューム・グループの終了プラン・グループの有効化

計画グループを使用可能にします。

  1. プラン・グループ名の右側にあるコンテキスト・メニューから「すべてのステップの有効化」を選択します。

    計画- カスタム- 新規ポート- 有効化- 終了-vg.png
    図5.2.2:ボリューム・グループの終了を有効にする方法

タスク5.3: リージョン1 (プライマリ)でカスタム・スクリプトを実行するプラン・グループの作成

カスタムのユーザー定義DR計画グループの追加を開始します。

最初のユーザー定義プラン・グループは、カスタム・スクリプトを実行して、プライマリ・リージョン1で実行されているEPM Systemサービスを停止します。このプラン・グループには、タスク1.2のEPMアプリケーション・ノードのフォルダc:/scriptsにダウンロードされたWindows PowerShellスクリプトstop_services.ps1をコールする単一のステップが含まれます。

タスク5.3.1: 「プラン・グループの追加」の選択

プラン・グループの追加プロセスを開始します。

  1. 「グループの追加」をクリックして開始します。
  2. プラン・グループにわかりやすい名前を付けます。これはオプションですが、ベスト・プラクティスは、プラン・グループがステップを実行するリージョンに関するノートを追加することです。
  3. 計画グループをDR計画に挿入する位置を選択します。この場合、リージョン1のVMを停止する組込み計画グループの前に、ユーザー定義の計画グループを挿入します。
  4. 組込みのコンピュート・インスタンスの停止(プライマリ)プラン・グループを選択します。
  5. 「ステップの追加」をクリックしてダイアログを開き、EPM Systemを停止するスクリプトを指定します。

プラン- カスタム- 新規ポート-grp1-name.svg
図5.3.1:計画グループを作成し、ステップを追加してEPMを停止するためのパラメータ

タスク5.3.2: ステップ名およびローカル・スクリプト・パラメータの指定

「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップで実行する内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、リージョン1のEPM Systemサービスが停止します。

このダイアログでは、すべてのフィールドについて説明しますが、この詳細は、同じプロセスを繰り返し実行するため、後続のステップで残りのすべてのスクリーンショットに残します。

  1. このステップで実行するタスクを説明する、わかりやすいステップ名。
  2. スイッチオーバー中にEPMアプリケーション・ノードが実行される場所ではなく、EPMアプリケーション・ノードが現在実行されているリージョンを常に選択します。OCI Full Stack DRは、VMが実行されている場所を追跡するため、今すぐどこにいるかを指定する必要があります。この場合、EPMアプリケーション・ノードはリージョン1 (ロンドン)で実行されています。
  3. DR制御ノードを含む正しいコンパートメントを選択します。次に、DR制御ノードとして指定されたコンピュート・インスタンスを選択します。この例では、EPMシステム・アプリケーションのコンピュートです。
  4. 「ローカル・スクリプトの実行」を選択して、スクリプトがコンピュート・インスタンスで検出されることをOCI Full Stack DRに通知します。WindowsのPowerShellスクリプトは、タスク1.2でDR制御ノードにダウンロードされました。
  5. DR制御ノードにstop_services.ps1スクリプトをインストールした絶対パスに貼り付けます。1つ目のパラメータとしてstopを追加し、2つ目のパラメータとしてOCIリージョンIDを追加します。
  6. スクリプトでEPMサービスの停止に失敗した場合、DR計画は停止する必要があります。これにより、問題があることを確認して修正できます。OCI Full Stack DRは、問題の修正後にスイッチオーバー計画の実行を継続する機会を提供します。
  7. Full Stack DRで障害が宣言される前のデフォルト値は1時間です。この値は30分に変更することも、より現実的なタイムアウト値であると感じるものに変更することもできます。
  8. 「ステップの追加」をクリックして、このステップを計画グループに追加します。

プラン- カスタム- 新規ポート-grp1-step.png
図5.3.2: EPMを停止するための計画ステップを作成するためのパラメータ

タスク5.3.3: プラン・グループおよびステップの追加の完了

次の図5.3.3に示すように、EPM Systemを停止するステップがDR計画グループに追加されました。

これは、追加したばかりのプラン・ステップを示しています。DR計画グループにステップを追加することは可能ですが、この計画グループにはEPMサービスを停止するステップのみが含まれます。「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。

プラン- カスタム- 新規ポート-grp1-finish.png
図5.3.3: EPMを停止するための計画グループおよびステップの追加を確定します

タスク5.4: リージョン2でカスタム・スクリプトを実行するプラン・グループの作成(スタンバイ)

2番目のユーザー定義プラン・グループは、スタンバイ・リージョン2でDR制御ノードを起動した後、コンピュート・ノードのホスト・ファイルを更新し、EPM Systemサービスを起動します。この計画グループには、タスク1.2でDR制御ノードにダウンロードされたhost_switch_failover.ps1およびstart_services.ps1 PowerShellスクリプトをコールする2つのステップが含まれます。

タスク5.4.1スタンバイ・リージョンへのスイッチオーバー後にホスト・ファイルを更新するためのDR計画グループの作成

  1. 単純でわかりやすいグループ名をプラン・グループに指定します。
  2. 計画グループをDR計画に挿入する位置を選択します。この場合、EPM Systemアプリケーション・ノードのレプリケート・バージョンを起動する組込み計画グループの後に、リージョン2でDR制御ノードの機能も実行するユーザー定義計画グループを挿入します。
  3. 組込みのコンピュート・インスタンスの起動プラン・グループを選択します
  4. 「ステップの追加」をクリックしてダイアログを開き、ホスト・ファイルを更新するスクリプトを指定します。

プラン- カスタム- 新規ポート-grp2-step.png
図5.4.1: EPMを開始するための計画ステップを作成するためのパラメータ

タスク5.4.2: ホスト・ファイル更新スクリプトのステップ名およびローカル・スクリプト・パラメータの指定

「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップで実行する内容およびリカバリ時の動作に関するパラメータを指定できます。host_switch_failover.ps1スクリプトは、コンピュート・ノードのホスト・ファイルを更新して、リージョン2のコンピュート・インスタンスおよびデータベース・インスタンスの新しいIPアドレスが元のリージョン1のホスト名にマップされるようにします。これにより、アプリケーション・レイヤーを変更せずにアプリケーションを起動できます。

このステップは、図5.4.2に示す項目を除き、タスク5.3.2と同じです。

  1. このステップで実行するタスクを説明する、わかりやすいステップ名。
  2. PowerShell.exeの絶対パスと、EPMアプリケーション・ノードにhost_switch_failover.ps1スクリプトをインストールした場所に貼り付けます。
  3. 「ステップの追加」をクリックして、このステップを計画グループに追加します。

プラン- カスタム- 新規ポート-grp2-step1.png
図5.4.2:ホスト・ファイルを更新するためのパラメータ

タスク5.4.3: EPM Systemサービス開始スクリプトのステップ名およびローカル・スクリプト・パラメータの指定

「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップで実行する内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、EPMシステム・サービスはリージョン2から始まります。

  1. このステップで実行するタスクを説明する、わかりやすいステップ名。
  2. PowerShell.exeの絶対パスと、EPMアプリケーション・ノードにstart_services.ps1スクリプトをインストールした場所に貼り付けます。
  3. 「ステップの追加」をクリックして、このステップを計画グループに追加します。
  4. 「追加」をクリックして、2つのカスタム・スクリプトを実行する2つのステップが含まれるプラン・グループを追加します。

プラン- カスタム- 新規ポート-grp2-step2.png
図5.4.3: EPMを起動するパラメータ

次のスクリーンショットに示すように、スイッチオーバー計画に両方のDR計画グループが含まれるようになりました。

plan-custom-so-newport-all-grps.png
図5.4.4:起動後のカスタム・スクリプト

タスク6: リージョン2でのフェイルオーバー計画のカスタマイズ(Newport)

このタスクでは、カスタムのユーザー定義のDR計画グループを追加する方法と、リージョン1へのアクセスが実際に停止または失われた場合にリージョン2でEPM Systemのフェイルオーバー中に完了する必要があるタスクを管理するステップについて説明します。これらのステップは、前述のタスク5のスイッチオーバー計画に追加したステップと同じステップのサブセットになります。ただし、フェイルオーバー時にはリージョン1に完全にアクセスできないと想定されるため、スタンバイ・リージョン2で実行されるステップのみがフェイルオーバー計画に追加されます。

タスク6.1: フェイルオーバー計画の選択

まず、タスク5で作成したフェイルオーバー計画にナビゲートします。

  1. スタンバイ・リージョン2がコンソールの現在のリージョン・コンテキストであることを確認します。
  2. フェイルオーバー計画を選択します。

プラン- カスタム- フォ- ニューポート-nav.png
図6-1:リージョン2でフェイルオーバー計画のカスタマイズを開始する方法。

タスク6.1.2: 新しいユーザー定義プラン・グループへのステップの追加

  1. 「グループの追加」をクリックします。

    プラン- カスタム- フォ- ニューポート-grp1-step.png
    図6.1.2 EPMを開始するための計画ステップを作成するためのパラメータ

  2. タスク5.4の手順に従って、ユーザー定義プラン・グループに2つのステップを追加して、カスタム・スクリプトhost_switch_failover.ps1およびstart_services.ps1を実行します。

  3. ステップとユーザー定義プラン・グループを追加した後、フェイルオーバー・プランは次のようになります。

    プラン- カスタム- フォ- ニューポート-grp1-finish.png
    図6.1.3 EPMを起動してホストを更新するための計画ステップを作成するためのパラメータ

タスク7: リージョン2でのスイッチオーバー計画の実行(Newport)

スイッチオーバーとフェイルオーバーの両方のDR計画は、スタンバイ・リージョン2 (Newport)で完了しています。リージョン2のDR計画により、OCI Full Stack DRはワークロードをリージョン1からリージョン2に移行できます。次のタスクは、リージョン1 (ロンドン)の保護グループにスイッチオーバーおよびフェイルオーバー計画を作成して、OCI Full Stack DRがワークロードをリージョン2からリージョン1に遷移できるようにすることです。

ただし、DR計画は、スタンバイ・ロールを持つ保護グループでのみ作成および変更できます。リージョン1のDR保護グループが現在プライマリであるため、DR計画はリージョン1で作成できません。

したがって、リージョン1がスタンバイで、リージョン2がプライマリになるように、保護グループのロールを戻し処理する必要があります。作成したスイッチオーバー計画を実行して、ワークロードをリージョン1 (ロンドン)からリージョン2 (ニューポート)に移行します。

タスク7.1: 計画実行の開始

DR計画を実行して、EPM Systemワークロードのリージョン1からリージョン2への移行プロセスを開始します。

  1. リージョン・コンテキストがスタンバイ・リージョン2 (Newport)に設定されていることを確認します。
  2. コンソールの上部にあるブレッドクラムを使用すると、DR保護グループの詳細が現在の計画コンテキストであることを確認できます。
  3. リージョン2の正しいDR保護グループが選択されていることを確認します。これはスタンバイ・ロールである必要があります。
  4. 続行する前に、フェイルオーバー計画とスイッチオーバー計画の両方が存在することを確認してください。存在しない場合は、前のタスクに戻って両方のDR計画を作成してください。
  5. 「DR計画の実行」をクリックします。

images-exec-so-to-newport-begin.png
図7-1:スタンバイ・リージョンへのスイッチオーバーの実行方法を示す

タスク7.2: スイッチオーバー計画の選択および実行

このタスクでは、リージョン2でスイッチオーバー計画を実行します。

  1. スイッチオーバー計画を選択します。
  2. 「事前チェックの有効化」を選択します。
  3. 「DR計画の実行」をクリックして開始します。

images-exec-so-to-newport-exec.png
図7.2:スイッチオーバー・プランを選択して実行します

タスク7.3: 次のステップ

EPM Systemワークロードがリージョン1からリージョン2に完全に移行されるまで、スイッチオーバー計画をモニターします。Full Stack DRは、アーティファクトをクリーンアップし、リージョン間のプライマリ・ロールとスタンバイ・ロールを変更します。スイッチオーバー計画の実行が失敗した場合は、ログを確認し、計画が正常に実行されていることを確認します。

Full Stack DRのスイッチオーバーが完了すると、リージョン2 (Newport)がプライマリ・リージョンになり、リージョン1 (London)がスタンバイ・リージョンになります。

タスク8: リージョン1でのDR計画の作成(ロンドン)

リージョン1 (London)のDR保護グループで、スタンバイ・ピアと同じ基本的なスイッチオーバーおよびフェイルオーバー計画を作成します。

各計画は、リージョン2がプライマリ・ピアである場合は常に、ワークロードをリージョン2からリージョン1に移行することを目的としています。DR操作の一環として、両方のリージョンのDR保護グループのロールは自動的に元に戻されるため、リージョン2のDR保護グループがスタンバイになり、フェイルオーバーまたはスイッチオーバー後にリージョン1のDR保護グループがプライマリになります。

OCI Full Stack DRは、前のタスクで追加したメンバー・リソースに基づいて、両方の計画に組込みステップを事前移入します。後続のステップでは、リカバリ操作中にEPM Systemに関連するすべてのタスクを処理するように計画をカスタマイズします。

スイッチオーバー計画は、常にスタンバイ・ロールを持つ保護グループに作成されます。リージョン1は現在、タスク8でスイッチオーバー計画を実行した後のスタンバイ保護グループです。

タスク8.1: DR計画の作成

図8.1に示すように、リージョン1でDRPGを選択して基本計画を作成します。

  1. OCIリージョン・コンテキストがリージョン1 (London)であることを確認します。
  2. リージョン1でスタンバイDRPGを選択します。
  3. 「プラン」を選択します。
  4. 「プランの作成」をクリックしてプロセスを開始します。
  5. スイッチオーバー計画の名前は簡単ですが意味があります。名前はできるだけ短くする必要がありますが、一目でわかりやすく、危機時の混乱や人的ミスを減らすことができます。
  6. 「プラン・タイプ」に「スイッチオーバー(計画済)」を選択します。この記述の時点では、プラン・タイプは4つのみです。
  7. 「作成」をクリックして、基本的な組込みステップが事前に移入された基本的なスイッチオーバー計画を作成します。

プラン- 作成- ロン-so.png
図8.1: DRスイッチオーバー計画の作成に必要なパラメータ

タスク8.2: フェイルオーバー計画の作成

図8.2に示すように、同じプロセスに従って基本的なフェイルオーバー計画を作成します。

  1. フェイルオーバー計画の「名前」をシンプルで意味のあるものにします。名前はできるだけ短くする必要がありますが、一目でわかりやすく、危機時の混乱や人的ミスを減らすことができます。

  2. 「計画タイプ」に「フェイルオーバー(計画外)」を選択します。この作成時には、4つのプラン・タイプがあります。

  3. 「作成」をクリックして、基本的な組込みステップが事前移入された基本的なフェイルオーバー計画を作成します。

プラン- 作成- ロン-fo.png
図8.2: DRフェイルオーバー計画の作成に必要なパラメータ

リージョン1のスタンバイDR保護グループには、次に示すように2つのDR計画が必要です。これらは、リージョン2からリージョン1へのワークロードの移行を処理します。

プラン- 作成- ロン-completed.png
図8.3:先に進む前にリージョン2に存在する必要がある2つの基本的なDR計画の表示

タスク9: リージョン1でのスイッチオーバー計画のカスタマイズ(ロンドン)

このタスクに関する内容は、リージョン2のタスク5で行った内容とほぼ同じですが、リージョン1で行われています。

タスク8で作成される基本的なDR計画には、OCI Full Stack DRに組み込まれており、EPM Systemアプリケーションに固有のリカバリ・タスクを管理するためのものを含まないリカバリ・タスクの事前移入されたステップが含まれています。このステップでは、カスタムのユーザー定義DR計画グループを追加する方法と、EPM Systemのスイッチオーバー中に完了する必要があるタスクを管理するステップについて説明します。

タスク9.1: スイッチオーバー計画の選択

前のタスクで作成したスイッチオーバー計画にナビゲートします。

plan-custom-so-lon-nav.png
図9-1:リージョン1でのスイッチオーバー・プランのカスタマイズを開始する方法

タスク9.2: (オプション)アーティファクトを終了するDR計画グループの有効化

これらは、前のタスクのリージョン2に対して実行したステップと同じで、リージョン1に対して同じプロセスを実行する必要があります。

次のスクリーンショットに示すように、スイッチオーバー・プランでは、2つのプラン・グループがデフォルトで無効になっています。これらは、実際には何も削除されていないというテスト中に快適性を提供するために無効になり、テスト中に問題が発生した場合に備えて、アーティファクトの実行可能なコピーがバックアップとして残ります。

ただし、これら2つの計画グループは、今後DR操作の一部として再利用されないアーティファクトを終了(削除)します。アーティファクトは、2つのリージョンを切り替えると、実際にはアクティブである必要があるコンピュート・インスタンスとボリューム・グループについて人間が混乱を引き起こすため、時間の経過とともに蓄積し続けます。

これらの計画グループは、OCI Full Stack DRが本番に移行したら有効にする必要があります。スイッチオーバーおよびスイッチバックのテスト中にこれら2つのプラン・グループが無効になっている間に所定の位置に残されたアーティファクトは、通常操作中の混乱および人的エラーの可能性を減らすために、本番に移行する前に終了およびクリーン・アップする必要があります。

必要に応じて、これらのプラン・グループを有効にして、本番環境に移行する前に余分なアーティファクトを手動でクリーンアップする必要がなくなります。

plan-custom-so-lon-disabled-show.png
図9-2:デフォルトで無効になっているプラン・グループ

使用不可のプラン・グループが有効化されると、次の処理が実行されます。

  1. この計画グループは、OCIブロック・ストレージ操作中にレプリケートされたバージョンのVMがリージョン1で起動された後、リージョン2に残されたコンピュート・インスタンスのアーティファクトを終了し、スイッチオーバーの一部としてリージョン1からリージョン2にレプリケーションを逆転させます。残りのVMはスイッチバック中は使用されません。ブロック・ボリューム・レプリケーションをリバースする操作によって、まったく新しいブロック・ボリューム・グループにすべての新しいVMが作成されるためです。

  2. この計画グループは、リージョン1でレプリケートされたバージョンのVGがアクティブ化され、スイッチオーバー中にボリューム・グループ・レプリケーションが元に戻された後、リージョン2で残されたブロック・ボリューム・グループ(VG)のアーティファクトを終了します。残りのブロック・ボリューム・グループは、リージョン1からリージョン2へのスイッチオーバーの一部としてさえも、二度と使用されません。

タスク9.2.1: 「計算プランの終了」グループの有効化

計画グループを使用可能にします。

  1. プラン・グループ名の右側にあるコンテキスト・メニューから「すべてのステップの有効化」を選択します

    計画- カスタム- 新規ポート- 有効化- 終了-vm.png
    図9.2.1:コンピュート・インスタンスの終了を有効にする方法

タスク9.2.2ボリューム・グループの終了計画グループの有効化

計画グループを使用可能にします。

  1. プラン・グループ名の右側にあるコンテキスト・メニューから「すべてのステップの有効化」を選択します

    計画- カスタム- 新規ポート- 有効化- 終了-vg.png
    図9.2.2:ボリューム・グループの終了を有効にする方法

タスク9.3: リージョン2でカスタム・スクリプトを実行するプラン・グループの作成(プライマリ)

カスタムのユーザー定義DR計画グループの追加を開始します。

最初のユーザー定義プラン・グループは、カスタム・スクリプトを実行して、プライマリ・リージョン2で実行されているEPM Systemサービスを停止します。この計画グループには、タスク1.2のDR制御ノードのc:/scriptsフォルダにダウンロードされたWindows PowerShellスクリプトstop_services.ps1をコールする単一のステップが含まれます。

タスク9.3.1: 「プラン・グループの追加」の選択

計画グループを追加するプロセスを開始します。

  1. 「グループの追加」をクリックして開始します。
  2. プラン・グループにわかりやすい名前を付けます。
  3. 計画グループをDR計画に挿入する位置を選択します。この場合、リージョン2でVMを停止する組込み計画グループの前に、ユーザー定義の計画グループを挿入します。
  4. 組込みのコンピュート・インスタンスの停止(プライマリ)プラン・グループを選択します。
  5. 「ステップの追加」をクリックしてダイアログを開き、EPM Systemを停止するスクリプトを指定します。

プラン- カスタム- ソロ- ロン-grp1-name.svg
図9.3.1:計画グループを作成し、ステップを追加してEPMシステム・サービスを停止するためのパラメータ

タスク9.3.2: ステップ名およびローカル・スクリプト・パラメータの指定

「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップで実行する内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、リージョン2のEPM Systemサービスが停止します。

このダイアログでは、すべてのフィールドについて説明しますが、この詳細は、同じプロセスを繰り返し実行するため、後続のステップで残りのすべてのスクリーンショットに残します。

  1. このステップで実行するタスクを説明する、わかりやすいステップ名。
  2. スクリプトでEPMサービスの停止に失敗した場合、DR計画は停止する必要があります。これにより、問題があることを確認して修正できます。Full Stack DRは、問題の修正後にスイッチオーバー計画の実行を継続する機会を提供します。
  3. OCI Full Stack DRで障害が宣言される前のデフォルト値は1時間です。この値は30分に変更することも、より現実的なタイムアウト値であると感じるものに変更することもできます。
  4. スイッチオーバー中にDR制御ノードが実行される場所ではなく、DR制御ノードが現在実行されているリージョンを常に選択します。OCI Full Stack DRは、VMが実行されている場所を追跡するため、今すぐどこにいるかを指定する必要があります。この場合、DR制御ノードはリージョン1 (ロンドン)で実行されています。
  5. 「ローカル・スクリプトの実行」を選択して、スクリプトがコンピュート・インスタンスで検出されることをFull Stack DRに通知します。WindowsのPowerShellスクリプトは、タスク1.2でDR制御ノードにダウンロードされました。
  6. DR制御ノードを含む正しいコンパートメントを選択します。次に、DR制御ノードとして指定されたコンピュート・インスタンス(この例ではEPMシステム・アプリケーション・コンピュート)を選択します。
  7. DR制御ノードにstop_services.ps1スクリプトをインストールした絶対パスに貼り付けます。1つ目のパラメータとしてstopを追加し、2つ目のパラメータとしてOCIリージョンIDを追加します。
  8. 「ステップの追加」をクリックして、このステップを計画グループに追加します。

plan-custom-so-lon-grp1-step1.svg
図9.3.2:計画グループを作成し、ステップを追加してEPMシステム・サービスを開始するためのパラメータ

タスク9.3.3: プラン・グループおよびステップの追加の完了

  1. 図9.3.3に示すように、EPM Systemを停止するステップがDR計画グループに追加されました。

    プラン- カスタム- ソロ- ロン-grp1-step1-added.svg
    図9.3.3:計画グループを作成し、EPMシステム・サービスの停止にステップを追加するパラメータ

  2. これは、追加したばかりのプラン・ステップを示しています。DR計画グループにステップを追加することは可能ですが、この計画グループにはEPMサービスを停止するステップのみが含まれます。

  3. 「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。

    プラン- カスタム- ソロ- ロン-grp1-added.svg
    図9.3.4: EPMシステム・サービスの停止に追加されたプラン・グループおよびグループを作成するためのパラメータ

タスク9.4: リージョン1でカスタム・スクリプトを実行するプラン・グループの作成(スタンバイ)

2番目のユーザー定義プラン・グループは、スタンバイ・リージョン1でDR制御ノードが起動された後、コンピュート・ノードのホスト・ファイルを更新し、EPM Systemサービスを起動します。この計画グループには、タスク1.2でDR制御ノードにダウンロードされたhost_switch_failback.ps1およびstart_services.ps1 PowerShellスクリプトをコールする2つのステップが含まれます。host_switch_failback.ps1スクリプトは、Newportリージョンのhost_switch_failover.ps1スクリプトによって導入された変更を元に戻し、元のプライマリ・リージョンLondonに戻った後、計算ノード上の元のホスト・ファイルをリストアします。

タスク9.4.1スタンバイ・リージョンへのスイッチオーバー後にホスト・ファイルを更新するためのDR計画グループの作成

  1. プラン・グループにわかりやすい名前を付けます。
  2. 計画グループをDR計画に挿入する位置を選択します。この場合、EPM Systemアプリケーション・ノードのレプリケート・バージョンを起動する組込み計画グループの後に、ユーザー定義計画グループを挿入します。これにより、リージョン1でDR制御ノードの機能も実行されます。
  3. 組込みのコンピュート・インスタンスの起動(スタンバイ)プラン・グループを選択します。
  4. 「ステップの追加」をクリックしてダイアログを開き、ホスト・ファイルを更新するスクリプトを指定します。

プラン- カスタム-soo-lon-grp1-step1.svg
図9.4.1:ホスト・ファイルを更新するために追加されたプラン・グループおよびグループを作成するためのパラメータ

タスク9.4.2: ホスト・ファイル更新スクリプトのステップ名およびローカル・スクリプト・パラメータの指定

「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップで実行する内容およびリカバリ時の動作に関するパラメータを指定できます。host_switch_failback.ps1スクリプトは、計算ノードのホスト・ファイルを更新します。ニューポート・リージョンでhost_switch_failback.ps1スクリプトによって導入された変更を元に戻し、リージョン1 (ロンドン)の元のホスト・ファイルをリストアします。これにより、アプリケーション・レイヤーを変更せずにアプリケーションを起動できます。

このステップは、図に示す項目を除き、タスク9.3.2と同じです。

  1. このステップで実行するタスクを説明するわかりやすい名前。
  2. PowerShell.exeの絶対パスと、DR制御ノードにhost_switch_failover.ps1スクリプトをインストールした場所に貼り付けます。
  3. 「ステップの追加」をクリックして、このステップを計画グループに追加します。

プラン- カスタム- ソロ- ロン-grp1-step1-details.svg
図9.4.2:ホスト・ファイルを更新するために追加されたプラン・グループおよびステップ詳細を作成するためのパラメータ

タスク9.4.3: EPM Systemサービス開始スクリプトのステップ名およびローカル・スクリプト・パラメータの指定

「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップで実行する内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、EPMシステム・サービスはリージョン2から始まります。

  1. このステップで実行するタスクを説明するわかりやすい名前。
  2. PowerShell.exeの絶対パスと、DR制御ノードにstart_services.ps1スクリプトをインストールした場所に貼り付けます。
  3. 「ステップの追加」をクリックして、このステップを計画グループに追加します。
  4. 「追加」をクリックして、2つのカスタム・スクリプトを実行する2つのステップが含まれるプラン・グループを追加します。

次のスクリーンショットに示すように、スイッチオーバー計画に両方のDR計画グループが含まれるようになりました。

plan-custom-so-lon-all-grps.png
図9.4.3:ユーザー定義のプラン・グループのスウィッチオーバー

タスク10: リージョン1でのフェイルオーバー計画のカスタマイズ(ロンドン)

このタスクでは、カスタムのユーザー定義DR計画グループを追加する方法と、リージョン2への実際の停止またはアクセスの損失時に、リージョン1のEPM Systemのフェイルオーバー中に完了する必要があるタスクを管理するステップについて説明します。これらは、前述のタスク9のスイッチオーバー計画に追加したステップと同じステップのサブセットになります。ただし、フェイルオーバー時にはリージョン2に完全にアクセスできないと想定されるため、スタンバイ・リージョン1で実行されるステップのみがフェイルオーバー計画に追加されます。

タスク10.1: フェイルオーバー計画へのユーザー定義計画グループの追加

タスク8で作成したフェイルオーバー計画にナビゲートします。

プラン- 作成- ロン-failover.png
図10.1:リージョン1のフェイルオーバー計画

タスク10.1.1: 計画グループの追加

  1. スタンバイ・リージョン2がコンソールの現在のリージョン・コンテキストであることを確認します。
  2. フェイルオーバー計画を選択します。
  3. 「グループの追加」をクリックします。
  4. グループの名前を指定します。
  5. 組込みステップ「コンピュート・インスタンスの起動」の後にプランに追加します。

プラン- カスタム-fo-lon-add-grp.png
図10.1:リージョン2へのフェイルオーバー後にカスタム・スクリプトを実行するプラン・グループを作成するためのパラメータ。

タスク10.1.2: 新規ユーザー定義プラン・グループへのステップの追加

  1. タスク9.4の手順に従って、ユーザー定義プラン・グループに2つのステップを追加して、カスタム・スクリプトhost_switch_failback.ps1を実行します。

    プラン- カスタム-fo-lon-add-step1.png
    図10.2:ホスト・ファイルを更新するスクリプトのプラン・グループ・ステップを作成するためのパラメータ。

  2. start_services.ps1スクリプトを使用してサービスを開始するには、プラン・グループに2番目のステップを追加します。

    プラン- カスタム-fo-lon-add-step1.png
    図10.3:ホスト・ファイルを更新するスクリプトのプラン・グループ・ステップを作成するためのパラメータ。

  3. ステップを追加すると、ユーザー定義プラン・グループは次のようになり、「追加」をクリックします。

    plan-custom-fo-lon-added-steps.png
    図10.4:コンピュート・インスタンスの起動後に2つのローカル・スクリプトを実行する構成済ステップを示すプラン・グループ。

  4. 次のスクリーンショットに示すように、フェイルオーバー計画にEPM Systemのユーザー定義DR計画グループが含まれるようになりました。保護グループにEPMシステムとともに他のアプリケーションまたはOCIサービスが含まれている場合は、追加のプラン・グループを設定できます。

    plan-custom-fo-lon-all-groups.png
    図10.5:ユーザー定義計画グループを示すフェイルオーバー計画

次のステップ

EPM SystemのOCI Full Stack DRは、この時点で完全に実装する必要があります。ただし、本番で使用する前に、すべての機能を検証する必要があります。すべてのフェイルオーバーおよびスイッチオーバー計画を実行して、すべてが期待どおりに機能し、リカバリ・チームがプロセス全体を完全に理解していることを検証する必要があります。

スイッチオーバー計画のテスト

スイッチオーバー計画は、すべてのアーティファクトをクリーン・アップし、ロード・バランサ、ブロック・ストレージ、ファイル・システム、BaseDB、ExaCS、Autonomous Databaseなどの組込みリカバリ・ステップのすべてのロールが、人間の介入なしにスタンバイ・リージョンからリカバリできる状態になるように設計されています。

フェイルオーバー計画のテスト

恋人は違う。フェイルオーバーは、その性質上、アーティファクトをクリーン・アップしたり、障害が発生したリージョンのサービスおよびデータベースが、ワークロードをリージョン1に戻す準備ができていることを確認することはできません。リカバリ・チームは、Oracle Data Guardが正しい状態であること、ストレージおよびコンピュート・インスタンスのアーティファクトが終了していることなどを確認するタスクを理解して実行する必要があります。詳細は、「フェイルオーバー後のDR構成のリセット」を参照してください。

最終受入のすべてのDR計画の検証

リカバリ・チームは、OCI Full Stack DR保護グループの準備状況と本番ワークロードの計画を実証するために、最終検証を実行する必要があります。リージョン2 (ニューポート)は、プロセスのこの時点でプライマリ・リージョンである必要があります。次のステップを実行して、すべての計画の最終検証を開始します。

承認

その他の学習リソース

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

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