ノート:
- このチュートリアルでは、Oracle Cloudへのアクセス権が必要です。無料アカウントにサインアップするには、Oracle Cloud Infrastructure Free Tierの開始を参照してください。
- Oracle Cloud Infrastructureの資格証明、テナンシおよびコンパートメントの値の例を使用します。演習を完了したら、これらの値をクラウド環境に固有の値に置き換えてください。
OCI Full Stack Disaster Recoveryを使用した複数ノードのOracle E-Business Suiteのリカバリの自動化
イントロダクション
OCI Full Stack Disaster Recoveryは、独自のディザスタ・リカバリ機能と機能を設計、記述、維持するために、アプリケーション・エンジニアリング・チームに依存しています。アプリケーション・エンジニアリング・チームに、ディザスタ・リカバリ用のOCIソフトウェア開発キット(SDK) APIを含むOCIネイティブ・ディザスタ・リカバリ機能が組み込まれている場合、そのアプリケーションをネイティブ・メンバー・リソースとしてフル・スタックDRに追加できます。
現在、Oracle E-Business SuiteにはOCIネイティブのディザスタ・リカバリ機能はありません。そのため、Full Stack DRのネイティブ・メンバー・リソースではありません。ただし、Oracle E-Business Suitエンジニアリング・チームは、OCIリージョン間でEBSを手動でデプロイおよびリカバリするプロセスを文書化しました。フル・スタックDRを使用して、手動プロセスを自動化できます。このドキュメントでは、フェイルオーバー、スイッチオーバーおよびドリル用の基本的なDR計画にカスタムのユーザー定義プラン・グループおよびステップを追加して、手動リカバリ・プロセスを自動化する方法について説明します。
Oracle Cloud Infrastructure Full Stack Disaster Recovery(OCI Full Stack DR)は、世界中のOracle Cloud Infrastructure(OCI)リージョン間のコンピュート、データベース、およびアプリケーションの移行をワンクリックで調整します。お客様は、既存のインフラストラクチャ、データベースまたはアプリケーションを再設計または再設計することなく、1つ以上のビジネス・システムをリカバリするために必要なステップを自動化できます。
Oracle E-Business Suiteは、今日の進化するビジネス・モデルをサポートし、生産性を向上させ、最新のモバイル・ユーザーの要求を満たします。30年にわたるイノベーションの歴史を基盤として、Oracle E-Business Suiteは、OCIのすべてのメリットを享受しながら、新しいアプリケーション機能を提供し、既存の機能の機能を拡張し続けています。
Oracle E-Business Suiteは通常、より大規模なシステムの一部です。
Oracle E-Business Suiteは、通常、多数の追加データベース、OCIマーケットプレイス・アプリケーションおよびOCIサービスを含む、より複雑なビジネス・システムの基盤であり、すべてを1つの単位としてリカバリする必要があります。To keep things simple and focused on Oracle E-Business Suite, this tutorial shows only those tasks related to Oracle E-Business Suite.ただし、Oracle E-Business SuiteがDR保護グループおよびDR計画の一部である唯一のアプリケーションになることは非常に珍しいことです。
増分実装に関する注意事項
DR計画の作成後にDR保護グループにメンバーを追加または削除すると、両方のリージョンの保護グループにある既存のDR計画がリフレッシュされます。詳細は、ディザスタ・リカバリ計画のリフレッシュを参照してください。
OCI Full Stack DRは、特定のビジネス・システムのアプリケーション・スタック全体がOCIリージョンにすでに導入されており、手動DRがすでに機能していることを前提に設計されています。ビジネス・システムにOracle E-Business Suiteを超えるものが含まれている場合は、DR計画を作成する前に、他のすべてのコンピュート、ストレージ、データベース、アプリケーションまたはOCIサービスをDR保護グループに追加します。
リカバリの仕組み
Oracle E-Business Suiteのリカバリ・ソリューションでは、フェイルオーバーやスイッチオーバー、ドリルなどのリカバリ操作中に一連のカスタムbashスクリプトを実行するために、OCI Full Stack DRが必要です。このチュートリアルでは、スクリプトをホストおよび実行するための制御ノードとしてOracle E-Business Suiteアプリケーション・ノードを使用します。
このチュートリアルで参照されるスクリプトは、Oracle EMEA Cloud Engineering Oracle Apps to OCIスペシャリスト・チームによって提供されており、OCI Full Stack Disaster Recovery用のOracle E-Business Suiteスクリプトから入手できます。bashスクリプトは、デプロイメントの固有のニーズに合せて若干変更する必要がある場合があります。
図1: OracleサンプルのGitHubリポジトリにあるOracle E-Business Suiteスクリプト
このチュートリアルでは、スクリプトをダウンロードする方法と、後のステップで使用する方法について説明します。このチュートリアルでは、Oracle E-Business Suite以外のものが含まれていないため、bashスクリプトをホストするためにオプション1のみを使用します。
ノート:一般的なガイダンスとして、次のスクリプトが用意されています。独自のスクリプトを使用するか、企業のポリシーおよびセキュリティ要件に従ってスクリプトをカスタマイズできます。
ホスト・スクリプトのオプション1
両方のリージョンで実行されているOracle E-Business Suiteアプリケーション・サーバーにbashスクリプトをインストールします。このチュートリアルでは、スクリプトがアプリケーション・スタック内の1つ以上のOracle E-Business Suiteアプリケーション・サーバーであっても、スクリプトを制御ノードまたはDRノードとしてインストールするコンピュート・インスタンスを参照します。
ホスト・スクリプトのオプション2
特殊な制御ノードまたはDRノードを作成して、すべてのOracle E-Business Suiteスクリプトと、他のアプリケーションやOCIサービスに必要なスクリプトをホストします。
Oracle E-Business Suiteは、多くの場合、カスタムの社内アプリケーション、Oracle Cloud Marketplaceアプリケーション、Oracle Business Analyticsとその他のデータベース、コンピュート・インスタンス、自社製アプリケーションを含む、より大規模で複雑なビジネス・システムの一部です。この場合、スクリプトをホストするビジネス・システムにすでに含まれているコンピュート・インスタンスの1つを選択するだけです。選択したコンピュート・インスタンスは、Oracle Linuxがインストールされているものであれば何でもかまいません。多くの場合、アプリケーション・サーバーや管理サーバーのような別の目的に役立つ既存のVMです。
通常、OCI Full Stack DRは、リカバリ操作を自動化するために特別な管理サーバーを必要としません。ただし、この場合は専用の管理サーバーとして機能するコンピュート・インスタンスを作成します。専用の管理サーバーは、このドキュメント全体を通して制御ノードまたはDRノードとして表示されます。制御ノードの目的は、単にすべてのカスタム・スクリプトが存在し、リカバリ操作中にOCI Full Stack DRによってコールできるサーバーとして機能することです。
注意:このチュートリアルでは、オプション1を使用して、Oracle E-Business Suiteアプリケーション・サーバーにカスタムOracle E-Business Suiteアプリケーション関連スクリプトを格納します。
Oracle E-Business Suiteデプロイメント・アーキテクチャ
Oracle E-Business Suiteは、OCI Full Stack DRを導入する前に、まずOCIリージョン全体のディザスタ・リカバリ(DR)のために導入する必要があります。OCI Full Stack DRを使用してリカバリ・プロセスを自動化する前に、リカバリを実行するための手動ステップをテストして正しく動作させることが非常に重要です。
OCIリージョンにOracle E-Business Suite for DRをデプロイする場合、次に示す2つのリファレンス・アーキテクチャのいずれかを実行できます。どちらのリファレンス・アーキテクチャも、2つのOCIリージョンに分散された冗長リソースを持つ多層トポロジを示しています。
マルチインスタンス・データベースは、Oracle Real Application Clusters (Oracle RAC)を使用して構築され、Oracle Data Guardを使用して、2つのOCIリージョン間でデータベースの同期を維持します。
Oracle Base Database Serviceを使用したOracle E-Business Suiteのリファレンス・アーキテクチャ
Oracle E-Business SuiteでOracle Base Database Serviceを使用している場合は、このデプロイメント・アーキテクチャを選択します。Oracle E-Business Suiteは、『Business Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Base Database Service DB Systems』(Doc ID 2875417.1)で説明されているように、2つのOCIリージョンにわたってDR用にデプロイする必要があります。図1に示す図は、ドキュメントID 2875417.1から取得されています。
図1: OCIベース・データベースを使用したOracle E-Business Suite DRデプロイメント・アーキテクチャ(詳細は、ドキュメントID 2875417.1を参照)
Oracle Exadata Database Service on Dedicated Infrastructureを使用したOracle E-Business Suiteのリファレンス・アーキテクチャ
Oracle E-Business SuiteでOracle Exadata Database Service on Dedicated Infrastructureを使用している場合は、このデプロイメント・アーキテクチャを選択します。Oracle E-Business Suiteは、『Business Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Exadata Database Service on Dedicated Infrastructure』(Doc ID 2919723.1)で説明されているように、2つのOCIリージョンにわたってDR用にデプロイする必要があります。図1に示す図は、ドキュメントID 2919723.1から取得されています。
図2: OCI Exadata Databaseを使用したOracle E-Business Suite DRデプロイメント・アーキテクチャ(詳細は、ドキュメントID 2919723.1を参照してください)
論理ホスト名と物理ホスト名の違い
Oracle E-Business Suiteでは、論理ホスト名をアプリケーション・サーバーに使用し、物理ホスト名をデータベースに使用することを強くお薦めします。Oracle E-Business Suiteエンジニアリングによって記述されたBusiness Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Base Database Service DB Systems (Doc ID 2875417.1)およびBusiness Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Base Database Service DB Systems (Doc ID 2919723.1)の両方で、データベース層が物理ホスト名を使用しながら、アプリケーション層が論理ホスト名を使用する必要があります。
OCI Full Stack DRには、論理ホスト名を使用するか物理ホスト名を使用するかに関する要件はありませんが、問題が発生した場合には、Oracle E-Business Suiteのサポートを確保するために、次のOracle E-Business Suiteの要件に従うことをお薦めします。一部の顧客は、アプリケーション層とデータベース層の両方に論理ホスト名を使用します。このソリューションで提供されるスクリプトは、アプリケーション層および物理ホスト名のデータベース層の論理ホスト名とともに使用するように設計されています。ダウンロード手順については、タスク1.2を参照してください。
OCI Full Stack DRデプロイメント・アーキテクチャ
次の図は、OCIフル・スタックDRの各DR保護グループ(DRPG)にメンバーとして追加されたコンピュート・リソースを示しています。これらは、OCI Full Stack DRがOracle E-Business Suiteアプリケーションの外部で管理できる様々なコンポーネントを表しています。
OCI Full Stack DRには、リカバリ中にOCI Compute、OCI Block Storage、OCI File Storage、Oracleデータベース、OCI Load Balancer、Oracle Cloud Infrastructure Kubernetes Engine (OKE)クラスタおよびその他の多くのリソースを処理するための自動化が組み込まれていますが、Oracle E-Business Suite自体の自動化が組み込まれていません。Oracle E-Business Suiteのリカバリは、このチュートリアル専用のGitHubリポジトリからダウンロードできる一連のbashスクリプトによって制御されます。bashスクリプトは、スクリプトの配置および制御のために次のオプションのいずれかに従って、選択したコンピュート・インスタンスにインストールする必要があります。
オプション1: Oracle Base Database Serviceを使用したOracle E-Business Suiteのリカバリの自動化
このデプロイメント・アーキテクチャは一般的ではなく、OCI Full Stack DRによってリカバリされる唯一のアプリケーションがOracle E-Business Suiteである非常にまれな状況で考案されました。この場合、Oracle E-Business Suiteアプリケーション・ノードでカスタム・スクリプトをホストします。
図3: OCI Base Databaseサービスを使用したフル・スタックDRデプロイメント・アーキテクチャ
オプション2: Oracle Exadata Database Service on Dedicated Infrastructureを使用したOracle E-Business Suiteのリカバリの自動化
図4に示す単純なデプロイメント・アーキテクチャは、Oracle E-Business Suiteのより一般的なデプロイメントの例で、多くのサービスとアプリケーションをまとめてリカバリする必要がある、より大規模で複雑なアプリケーション・スタックの1つのコンポーネントにすぎません。ほとんどのビジネス・システムは、次のイメージに示されている架空のシステムよりもはるかに複雑であり、通常、追加のデータベース、他のOracleおよび/または非Oracle applications、およびOIC、ODI、OHS、OCI IAMなどの他のOCIサービスが含まれます。
図4: Oracle Exadata Database Service on Dedicated Infrastructureを使用したフル・スタックDRデプロイメント・アーキテクチャ
チュートリアル全体での定義と仮定
地域
プライマリおよびスタンバイの役割は、リージョン自体ではなく、OCI Full Stack DR保護グループの機能です。リージョンは、1つのアプリケーション・スタックのプライマリとして機能し、完全に異なるアプリケーション・スタックのスタンバイとしても機能します。プライマリおよびスタンバイの役割はfluidです。
このチュートリアルは、フェニックスで実行されているOracle E-Business Suiteアプリケーション・スタックと、アッシュバーンで実行されているすべてのスタンバイ・リソースから始まります。これらの2つのリージョンは例にすぎません。アプリケーション・スタックをサポートする2つのOCIリージョンを実際に使用できます。
-
地域1はフェニックス。
- フェニックスがプライマリ・リージョンとしてスタートします。
- フェニックスがプライマリ・リージョンとして開始するのは、次の理由からです。
- Oracle E-Business Suiteアプリケーションはフェニックスで実行されています。
- Oracle E-Business Suiteのrsync cronジョブは、フェニックスにあるOracle E-Business Suiteアプリケーション・サーバー(VM)上の
/u01
から、アッシュバーンで実行されているアプリケーション・サーバーにデータをコピーします。 - フェニックス内のデータベースには、Oracle Data Guardのプライマリ・ロールがあります。
- 後続のタスクでスイッチオーバーを実行するように指示された後に、フェニックスが最終的にスタンバイになります。
-
地域2はアッシュバーン。
- アッシュバーンはスタンバイ・リージョンとして開始されます。
- アッシュバーンは、次の理由によりスタンバイ・リージョンとして開始します。
- Oracle E-Business Suiteのスタンバイ・アプリケーション・サーバー(VM)はアッシュバーンで実行されています。
- Oracle E-Business Suiteアプリケーションはアッシュバーンで実行されていません。
/u01
のデータは、フェニックスからアッシュバーンの仮想マシンにコピーされています。- アッシュバーンのデータベースには、Oracle Data Guardスタンバイ・ロールがあります。
- 後続のタスクでスイッチオーバーを実行するように指示された後に、最終的にアッシュバーンがプライマリになります。
区分
Oracle E-Business SuiteとOCI Full Stack DRは、ITガバナンスの標準内で動作する任意のコンパートメント・スキームに自由に編成できます。アプリケーションを個別のコンパートメントに編成し、すべてのDR保護グループを単一のコンパートメントに編成することで、まったく異なるビジネス・システムを一目で確認できるようになりました。
- すべてのDR保護グループをアプリケーションとは別の単一のコンパートメントに編成することで、ITスタッフは、完全に異なる多くのビジネス・システムのDR計画を簡単に見つけて実行できます。
- すべてのDR保護グループに対して単一のコンパートメントを持つことで、人的エラーを排除し、DR計画を見つけて実行できる速度を向上させることができます。
- Oracle E-Business Suiteのコンパートメント(
ebstesting
)。Oracle E-Business Suite自体、ストレージ、ストレージ・バケット、コンピュートおよびOracle E-Business Suiteに関連するデータベースのコンパートメントは、このチュートリアルのebstesting
です。 - OCI Full Stack DR
myprojects
のコンパートメント。OCI Full Stack DR保護グループおよびプランのコンパートメントは、このチュートリアルのmyprojects
です。
- Oracle E-Business Suiteのコンパートメント(
目的
このチュートリアルでは、OCI Full Stack DRを使用してOracle E-Business Suiteのリカバリを自動化する方法を説明する次のタスクについて説明します。
ノート:リージョン1 (フェニックス)およびリージョン2 (アッシュバーン)から開始します。本番Oracle E-Business Suiteアプリケーションはリージョン1で実行され、DRはリージョンで構成されます。これは、チュートリアル全体を通して、デプロイメントで異なるOCIリージョンを使用する実際のリージョンname.Ifではなく、リージョン1およびリージョン2と呼ばれるため、非常に重要です。次に、それぞれの本番リージョンおよびDRリージョンを参照してください。
-
タスク1: OCIリージョン間でのDR用のOracle E-Business Suiteのデプロイ
- 2つのOCIリージョン間でOracle E-Business Suite for DRを手動でインストールおよびデプロイします。
- 必要なリージョン1からリージョン2までのすべてのリカバリ・ステップを手動でテストします。
- 必要なリージョン2からリージョン1までのすべてのリカバリ・ステップを手動でテストします。
-
タスク2: OCI Full Stack DRの準備
- フル・スタックDRのOCI IAMポリシーを設定します。
- 他のOCIサービスのOCI IAMポリシーを設定します。
- Oracle E-Business Suiteアプリケーション・サーバーにカスタムOracle E-Business Suiteスクリプトをダウンロードしてインストールします。
- Oracle E-Business Suiteアプリケーション・サーバーがスクリプトおよびコマンドを実行できることを確認します。
- Oracle E-Business Suiteデータベースのボールト・シークレットを作成します。
- ログのオブジェクト・ストレージ・バケットを作成します。
-
タスク3: DR保護グループの作成と関連付け
-
タスク4: Oracle E-Business Suiteデータベースおよびコンピュート・メンバーをリージョン1およびリージョン2のDR保護グループに追加します。
-
タスク5: リージョン2 (アッシュバーン)でのDR計画の作成
- スイッチオーバー計画を作成します。
- フェイルオーバー計画を作成します。
- 開始ドリル計画を作成します。
-
タスク6: リージョン2 (アッシュバーン)でのDR計画のカスタマイズ。
-
タスク7: リージョン2 (アッシュバーン)でスイッチオーバー計画を実行します。
-
タスク8: リージョン1 (フェニックス)で基本的なDR計画を作成し、リージョン1 (フェニックス)でDR計画をカスタマイズします。
- スイッチオーバー計画を作成し、リージョン1 (フェニックス)でスイッチオーバー計画をカスタマイズします。
- リージョン1 (フェニックス)でフェイルオーバー計画を作成し、フェイルオーバー計画をカスタマイズします。
- 開始ドリル・プランを作成し、リージョン1 (フェニックス)の開始ドリル・プランをカスタマイズします。
前提条件
Oracle E-Business Suiteは、OCI Full Stack DRの操作を開始する前に、両方のリージョンでディザスタ・リカバリのためにデプロイする必要があります。これについては、タスク1で説明します。
タスク1: ディザスタ・リカバリのためのOracle E-Business Suiteのデプロイ
OCI Full Stack DRは、このタスクのどの部分にも関与しません。
OCI Full Stack DRの操作を開始する前に、2つの異なるMy Oracle Support (MOS)ナレッジ記事(KMノート)のいずれかを使用して、OCIリージョン間のディザスタ・リカバリのためにOracle E-Business Suiteをデプロイする必要があります。
また、Oracle E-Business Suiteのリカバリに必要なカスタム・スクリプトや自動化とともに、KMノートで説明されている手動ステップが、OCI Full Stack DRの操作を開始する前に完全にテストされていることも非常に重要です。
Oracle E-Business Suiteは、現在、Oracle Base Database ServiceおよびOracle Exadata Database Service on Dedicated Infrastructureサービスをサポートしています。Oracle Autonomous Databaseサービスは、現在、Oracle E-Business Suiteではサポートされていません。次のKMノートの1つまたはもう1つにある手順に従います。
-
ドキュメントID 2875417.1: Deploy Oracle E-Business Suite for DR using BaseDB
-
ドキュメントID 2919723.1: Deploy Oracle E-Business Suite for DR using ExaDB-D
タスク2: OCI Full Stack DRのテナンシの準備
OCI Full Stack DRは、このタスクのどの部分にも関与しません。次のステップでは、OCI Full Stack DRによる自動リカバリのために、テナンシ、コンパートメント、OCIサービスおよびOracle E-Business Suiteを準備します。この項で説明するほとんどのタスクについては、「フル・スタック・ディザスタ・リカバリの前提条件」を参照してください。
タスク2.1: OCI Full Stack DRのOCI IAMポリシーの設定
以下のドキュメントに概説されている、OCI Full Stack DRの必要なOCI IAMポリシーを構成すること。
タスク2.2: OCI Full Stack DRによって管理されるその他のサービスに対するOCI IAMポリシーの設定
OCI Full Stack DRには、コンピュート、ネットワーキング、ストレージ、ボールト、データベース、その他のサービスなどの他の主要なOCIサービスを制御および管理する機能が必要です。次のドキュメントに記載された他のサービスに必要なOCI IAMポリシーを構成すること。
タスク2.3: Oracle E-Business Suiteアプリケーション・サーバーでのカスタムOracle E-Business SuiteScriptsのダウンロードとインストール
OCI Full Stack DRには、OCI Infrastructure as a Service (IaaS)およびPlatform as a Service (PaaS)リソースのリカバリを編成するためのインテリジェンスが組み込まれています。OCI Full Stack DRには、Oracle E-Business Suiteのリカバリを編成するための組み込みのインテリジェンスはありません。Oracle E-Business Suiteは現在、組み込みのディザスタ・リカバリを導入または管理するためのOCIネイティブ・ディザスタ・リカバリAPIを提供していないためです。
ただし、OCI Full Stack DRは、このチュートリアルの後半で作成した基本DR計画にユーザー定義のDR計画グループとステップを追加することで、引き続きOracle E-Business Suiteのリカバリを調整できます。このチュートリアルのパート1で説明したように、ユーザー定義のステップでは、Oracle E-Business Suiteのリカバリに必要な様々なタスクを実行する一連のカスタム・スクリプトをコールします。スクリプトは、両方のリージョンのOracle E-Business Suiteアプリケーション・サーバー上のすべてのコンピュート・インスタンスにダウンロードしてインストールする必要があります。
- OCI Full Stack Disaster Recovery用のOracle E-Business Suiteスクリプトから、Oracle E-Business Suiteスクリプトをダウンロードします。
- リージョン1の各Oracle E-Business Suiteアプリケーション・サーバーの任意のディレクトリにスクリプトをコピーします。
- リージョン2の各Oracle E-Business Suiteアプリケーション・サーバーの同じディレクトリにスクリプトをコピーします。
- ファイルがoracleユーザーによって所有されていることを確認します。
- ファイルが実行可能であることを確認します。
タスク2.4: Oracle E-Business Suiteアプリケーション・サーバーがスクリプトおよびコマンドを実行できることの確認
OCI Full Stack DRは、Oracle E-Business Suiteアプリケーション・サーバーにダウンロードされたOracle E-Business Suiteスクリプトを実行する必要があります。OCI Full Stack DRは、各コンピュート・インスタンスでOracle Cloud Agentを使用してスクリプトを実行します。両方のリージョンでOracle E-Business Suiteアプリケーション・サーバーとして使用されるすべてのコンピュート・インスタンスが、Oracle Cloud Agentを使用してOCIコンソールを介してコマンドを実行できることが非常に重要です。
詳細は、フル・スタック・ディザスタのリカバリのためのコンピュート・インスタンスの準備を参照してください。管理者権限を持つコマンドの実行の手順に特に注意してください。
OCIコンソールからコマンドを実行できることの検証
ノート:このタスクは、Oracle Could Agentがコマンドを実行できることを確認します。フル・スタックDRでOracle Cloud Agentを介してコマンドを実行できるように、適切なポリシーが設定されていることは検証されません。これは、このチュートリアルでリージョン2のスイッチオーバーDR計画を検証する方法を説明した後のステップで明らかになります。
インスタンス化されたコンピュートの実行コマンド機能を使用して、Oracle Cloud Agentがコマンドを実行できることを確認します。次のイメージは、OCIコンソールのコンピュート・インスタンスの詳細ページの「実行」コマンドを示しています。
- 「コマンドの実行」を選択します。
- 「コマンドの作成」を選択し、dateなどの有効なLinuxコマンドを入力します。コマンドを実行する前に、タイムアウトを妥当な3分に変更してください。
図2.4.1.1: OCIコンソールからコマンドを実行します。
タスク2.5: Oracle E-Business Suiteデータベース用のOCI Vaultシークレットの作成
OCI Full Stack DRには、フェイルオーバーおよびスイッチオーバー時にOracle Data Guardを自動的にトリガーできるように、データベースのsys
パスワードが必要です。「フル・スタック・ディザスタ・リカバリのためのOracle Databasesの準備」の説明に従って、両方のリージョンのボールト・シークレットにデータベースsys
パスワードを追加します。
タスク2.6: ログ用のOCIオブジェクト・ストレージ・バケットの作成
注意:既存のDR保護グループにOracle E-Business Suiteを追加する場合は、タスク2.3を完全にスキップしてください。
プライマリ・リージョンおよびスタンバイ・リージョンにOCIオブジェクト・ストレージ・バケットを作成し、リカバリ操作中にOCIフル・スタックDRによって生成されたログを格納します(操作ログのログの場所の準備を参照)。
タスク2.6.1: OCIオブジェクト・ストレージへのナビゲート
まず、図2-1に示すように、オブジェクト・ストレージおよびアーカイブ・ストレージに移動します。
- ブラウザ・コンテキストがリージョン1 (フェニックス)に設定されていることを確認します。
- 「ストレージ」をクリックします。
- 「バケット」をクリックします。
図2.6.1.1:オブジェクト・ストレージに移動します。
タスク2.6.2: リージョン1および2でのOCIオブジェクト・ストレージ・バケットの作成
リージョン1でOCIオブジェクト・ストレージ・バケットを作成します。次に、リージョン2に同一のストレージ・バケットを作成します。バケットは、後のタスクでリージョン1および2のDR保護グループに割り当てられます。
- Oracle E-Business Suite関連リソースを含むコンパートメントを選択します。コンパートメントは、リージョンごとに異なる場合があります。
- 「バケットの作成」をクリックします。
- バケットにわかりやすい名前を付けて、どのアプリケーションと目的が役立つかを簡単に識別します。名前の一部としてリージョンを含める理由はありません。たとえば、この名前は、Oracle E-Business SuiteのDR操作に関連するOCI Full Stack DRログに使用されていることを示します。
- 「層」および「暗号化」のデフォルト値を使用します。
- 「作成」をクリックしてバケットを作成します。
図2.6.2.1:リージョン1および2にオブジェクト・ストレージ・バケットを作成します。
タスク3: DR保護グループの作成および関連付け
これは、フル・スタックDRを含む最初のタスクです。このアプリケーション・スタックの保護グループがまだ存在しない場合は、リージョン1およびリージョン2でDR保護グループを作成します。
注意: Oracle E-Business Suiteを既存のDR保護グループに追加する場合は、タスク3を完全にスキップします。
このタスクでは、Oracle E-Business Suiteを含むアプリケーション・スタックに対してOCI Full Stack DRを構成する最初のステップを開始します。DR保護グループは、OCI Full Stack DRに、OCI IaaSおよびPaaSサービスが単一のアプリケーション・スタックの一部であり、どのリージョンがビジネス・システムのプライマリおよびスタンバイとして機能するかを通知します。DR保護グループは、他のすべてのものが構築される基盤を形成します。
両方のリージョンのアプリケーション・スタックに属するすべてのOCI IaaSおよびPaaSリソースは、タスク4の一部として追加されます。
Note: Although this tutorial only includes Oracle E-Business Suite, DR Protection Groups normally contain OCI IaaS and PaaS services for many different Oracle and non-Oracle applications and in addition to those needed by Oracle E-Business Suite.
タスク3.1: スタンバイ・リージョン2での保護グループの作成(アッシュバーン)
最初に、リージョン2で関連付けられていないDR保護グループを作成します。スタンバイ・リージョンに保護グループを作成する必要はありません。このプロセスは、リージョン2から開始して少しだけ改善されます。
タスク3.1.1: DR保護グループへのナビゲート
まず、図3.1.1に示すように、DR保護グループ(OCIフル・スタックDR)に移動します。
- OCIリージョン・コンテキストがリージョン2 (アッシュバーン)に設定されていることを確認します。
- 「移行とディザスタ・リカバリ」をクリックします。
- 「DR保護グループ」をクリックします。
図3.1.1: DR保護グループに移動します。
タスク3.1.2: 保護グループの作成
図3-1-2に示すように、リージョン2に基本的なDR保護グループ(DRPG)を作成します。ピア、ロールおよびメンバーは、後のステップで割り当てられます。
- DRPGを作成するコンパートメントを選択します。これは、Oracle E-Business Suiteリソースが存在するのと同じコンパートメント、またはプロジェクトに関連する他のコンパートメントです。
- 「DR保護グループの作成」を選択して、保護グループを作成するパラメータを入力するダイアログ・ボックスを開きます。
図3.1.2:リージョン2でのDR保護グループの作成を開始します。
タスク3.1.3: 保護グループの作成に必要なパラメータの追加
図3.1.3に示すように、ログの名前およびOCIオブジェクト・ストレージ・バケットを追加します。
- DRGPにはわかりやすく簡単な名前を使用します。この例は、ビジネス・システムの名前とリージョンを示しています。
- リージョン2でDRPGを作成するコンパートメントを選択します。
- リージョン2のタスク2で作成したオブジェクト・ストレージ・バケットを選択します。バケットを別のコンパートメントに作成した場合は、コンパートメントの変更が必要になる場合があります。
追加のパラメータは入力しないでください。ダイアログ・ボックスの下部にある「作成」をクリックします(ここには示されていません)。
図3.1.3:リージョン2でDR保護グループを作成するために必要なパラメータ
保護グループの作成後に表示される内容
図3-2.3に示すように、最初のDR保護グループが作成されます。ロールおよびピア情報は、タスク3.4の一部として割り当てられます。
図3.1.4:リージョン2に新しく作成したDR保護グループを表示しています
タスク3.2: プライマリ・リージョン1での保護グループの作成(フェニックス)
リージョン1で保護グループを作成します。後のタスクでは、このリージョンのアプリケーション・スタックに属するすべてのOCIリソースを追加します。このようにして、OCI Full Stack DRは、このリージョンのビジネス・システムの一部とみなされるアセットを認識します。
タスク3.2.1: 保護グループの作成
図3.2.1に示すように、リージョン1に基本的なDR保護グループ(DRPG)を作成します。ピア、ロールおよびメンバーは、後のステップで割り当てられます。
- OCIリージョン・コンテキストをリージョン1に変更します。
- DRPGを作成するコンパートメントを選択します。通常、リージョン2でDRPGを作成するために使用したものと同じコンパートメントを選択します。
- 「DR保護グループの作成」を選択して、保護グループを作成するパラメータを入力するダイアログ・ボックスを開きます。
図3.2.1:リージョン1でのDR保護グループの作成を開始します。
タスク3.2.2: 保護グループの作成に必要なパラメータの追加
図3-5に示すように、ログの名前とオブジェクト・ストレージ・バケットを追加します。
- DR PRotectionグループには、わかりやすい単純な名前を使用します。この例は、ビジネス・システムおよびリージョンの名前を示しています。
- リージョン1でDRPGを作成するコンパートメントを選択します。通常、両方のリージョンで同じコンパートメントを使用します。
- リージョン1のタスク2で作成したオブジェクト・ストレージ・バケットを選択します。バケットを別のコンパートメントに作成した場合は、コンパートメントの変更が必要になる場合があります。
図3.2.2:リージョン1でDR保護グループを作成するために必要なパラメータ
保護グループの作成後に表示される内容
図3.2.3に示すように、2番目のDR保護グループが作成されます。ロールおよびピア情報は、タスク3.3の一部として割り当てられます。
図3.2.3:リージョン2に新しく作成されたDR保護グループを表示しています
タスク3.3: リージョン1およびリージョン2での保護グループの関連付け
各リージョンのDRPGを互いのピアとして関連付け、プライマリおよびスタンバイのロールを割り当てます。これにより、OCI Full Stack DRは、Oracle E-Business Suiteのリカバリのために連携する2つのリージョンを認識します。プライマリおよびスタンバイのロールは、DR操作/DR計画実行の一部としてOCIフル・スタックDRによって自動的に変更されます。DRPGがこのタスクで初期ロールを割り当てられた後は、いつでもロールを手動で管理する必要はありません。
タスク3.3.1: アソシエーションの開始
- OCIリージョン・コンテキストがリージョン1 (フェニックス)に設定されていることを確認します。
- 「関連付け」をクリックしてプロセスを開始します。
図3.3.1: DRPGアソシエーションの開始
タスク3.3.2: リージョン1およびリージョン2での保護グループの関連付け
図3.3.2に示すように、パラメータを指定します。
- プライマリ・ロールを選択します。OCI Full Stack DRは、スタンバイ・ロールをリージョン2に自動的に割り当てます。
- 他のDRPGが作成されたリージョン2 (フェニックス)を選択します。
- 作成したピアDRPGを選択します。
図3.3.2: DRPGを関連付けるために必要なパラメータ
アソシエーションの完了後に表示される内容:
関連付けが完了すると、OCI Full Stack DRに図3.3.3のような内容が表示されます。
- 現在のプライマリ・ピアDRPGはフェニックス(リージョン1)です。
- 現在のスタンバイ・ピアDRPGはアッシュバーン(リージョン2)です。
図3.3.3:個々のDRPGの観点から見たピア関係の表示
図3.4.3.2に示すように、コンテキスト/ビューがすべてのDR保護グループを示すグローバルな視点にある場合は常に同じ情報を確認できます。
- 現在のプライマリ・ピアDRPGはフェニックス(リージョン1)です。
- 現在のスタンバイ・ピアDRPGはアッシュバーン(リージョン2)です。
図3.4.3.2:グローバルDRPGの観点から見たピア関係の表示
タスク4: リージョン1およびリージョン2のDR保護グループへのOracle E-Business Suiteメンバーの追加
両方のリージョンで、DR保護グループ(DRPG)のメンバーとして、データベースおよび移動しないOracle E-Business Suiteアプリケーション・サーバーを追加します。移動しないコンピュートとは、リージョン1に存在するOracle E-Business Suiteアプリケーション・サーバーがリージョン2で起動または起動されないことを意味します。移動しないコンピュート用のブート・ボリュームは、OCIストレージ・レプリケーションを使用してリージョン2にレプリケートされず、DR保護グループのメンバーとして追加されません。
このチュートリアルでは、Oracle E-Business Suiteに関連するステップのみを示しますが、この機会に、Oracle E-Business Suiteとともにリカバリする必要があるOCI IaaSおよびPaaSサービスを追加する必要もあります。For example, there may be other moving compute, non-moving compute, databases, load balancers, file systems, block storage or object storage associated with other in-house or Oracle applications that are part of the Oracle E-Business Suite ecosystem.
ノート:このタスクは、既存のDR保護グループにメンバーを追加するときに、両方のリージョンの既存のDR計画をリフレッシュします。詳細は、ディザスタ・リカバリ計画のリフレッシュを参照してください。
タスク4.1: DR保護グループへのメンバー・リソースのリージョン1への追加(フェニックス)
次のリソースをリージョン1のプライマリDRPGのメンバーとして追加します。
- 2つの非移動Oracle E-Business Suiteアプリケーション・サーバー(Oracle E-Business Suiteがインストールされ、実行されている)。
- Oracle E-Business Suite (Oracle Data Guardプライマリ・ピア)用のOracle RACデータベース。
タスク4.1.1: プライマリDR保護グループへのナビゲート
図4.1.1に示すように、リージョン1のDR保護グループに移動します。
- OCIリージョン・コンテキストがリージョン1 (フェニックス)であることを確認します。
- リージョン1でDR保護グループを選択します。
図4.1.1:リージョン1のDR保護グループに移動します。
タスク4.1.2: Oracle E-Business Suiteアプリケーション・サーバー1の追加
まず、「メンバーの追加」ダイアログ・ボックスを開き、最初のアプリケーション・サーバーを追加します。
- 「メンバー」をクリックします。
- 「メンバーの追加」をクリックします。
図4.1.2.1:「メンバーの追加」ダイアログ・ボックスを開きます。
図4.1.2.2に示すように、リージョン1のアプリケーション・サーバー1を選択します。ブロック・ボリューム・グループを追加したり、ネットワーク・プロパティを指定する必要はありません。これは、移動しないインスタンスであるためです。
- 「リソース・タイプ」として「コンピュート」を選択します。
- Oracle E-Business Suiteアプリケーション・サーバーを含むコンパートメントを選択し、アプリケーション・サーバー1として指定したコンピュート・インスタンスを選択します。
- 「非移動インスタンス」を選択します。これにより、DR操作中にレプリケートされた仮想マシンをスタンバイ・リージョンで起動しようとしないことがOCI Full Stack DRに通知されます。
- 「追加」をクリックして、コンピュート・インスタンスをDRPGに追加します(表示されていません)。
図4.1.2.2:アプリケーション・サーバー1のパラメータを指定します。
タスク4.1.3: Oracle E-Business Suiteアプリケーション・サーバー2の追加
-
「メンバーの追加」をクリックします。
図4.1.3.1:「メンバーの追加」ダイアログ・ボックスを開きます。
図4.1.3.2に示すように、リージョン1のアプリケーション・サーバー2を選択します。ブロック・ボリューム・グループを追加したり、ネットワーク・プロパティを指定する必要はありません。これは、移動しないインスタンスであるためです。
- 「リソース・タイプ」として「コンピュート」を選択します。
- Oracle E-Business Suiteアプリケーション・サーバーを含むコンパートメントを選択し、アプリケーション・サーバー2として指定したコンピュート・インスタンスを選択します。
- 「非移動インスタンス」を選択します。これにより、DR操作中にレプリケートされた仮想マシンをスタンバイ・リージョンで起動しようとしないことがOCI Full Stack DRに通知されます。
- 「追加」をクリックして、コンピュート・インスタンスをDRPGに追加します(表示されていません)。
図4.1.3.2:アプリケーション・サーバー2のパラメータを指定します。
タスク4.1.4: プライマリ・クラスタ化Oracle Databaseの追加
-
「メンバーの追加」をクリックして、データベースをメンバーとして追加します。
図4.1.4.1:「メンバーの追加」ダイアログ・ボックスを開きます。
図4.1.4.2に示すように、リージョン1でOracle E-Business SuiteのRACデータベースを選択します。これは、単一インスタンス・データベースでもまったく同じように機能します。
- 「リソース・タイプ」として「データベース」を選択します。データベース・リソース・タイプでは、Oracle Base Database ServiceまたはOracle Exadata Database Service on Dedicated Infrastructureのいずれかを選択できます。どちらも、Oracle E-Business Suiteエンジニアリングでサポートされている有効な選択肢です。
- この図はOracle Base Database Serviceを示していますが、一般的なOracle Exadata Database Service on Dedicated Infrastructureを使用することもできます。
- デプロイメントに一致するこれらのフィールドの値を選択します。これらの選択に対する回答がわからない場合は、データベース管理者に問い合せてください。
- データベースのパスワードを含むコンパートメントおよびボールト・シークレットを選択します。タスク2.4の一部として、リージョン2に同様のボールトおよびシークレットを作成しました。このパラメータは、他のDBaaS APIとの互換性のためにダイアログにありますが、パスワードは実際には使用されません。
- 「追加」をクリックして、データベースをメンバーとして追加します(表示されていません)。
図4.1.4.2:リージョン1のRACデータベースのパラメータを指定します。
DR保護グループのメンバーのリストは、図4.1.4.3に示すスクリーンショットのようになります。この特定のDR保護グループにOracle E-Business Suiteを超えるものを追加する場合、または既存のDR保護グループにOracle E-Business Suiteメンバー・リソースを追加する場合、リストは異なる場合があります。
図4.1.4.3:リージョン1のOracle E-Business Suiteに必要なメンバーの完全なリスト
タスク4.2: リージョン2のDRPGへのメンバー・リソースの追加(アッシュバーン)
リストに表示されるリソースを、リージョン2のスタンバイDRPGのメンバーとして追加します。
- 2つの移動していないOracle E-Business Suiteアプリケーション・サーバー(Oracle E-Business Suiteはインストールされていますが、実行されていません)。
- Oracle E-Business Suite (Oracle Data Guardスタンバイ・ピア)のRACデータベース。
Oracle E-Business Suiteでは、アプリケーションがインストールされている両方のリージョンにアプリケーション・サーバーが存在する必要があります。Oracle E-Business Suiteアプリケーションがインストールされているが、スタンバイ・リージョンで実行されていないスタンバイ・リージョンでは、アプリケーション・サーバーは常に実行中状態である必要があります。
つまり、オペレーティング・システムとアプリケーションのアップグレード、パッチ、その他の定期的なメンテナンスは、両方のリージョンで個別に実行する必要があります。
OCI Full Stack DRは、仮想マシンが別のリージョンにレプリケートされず、DR操作中に他のリージョンに移動されないため、このモデルを非移動コンピュートと呼びます。OCI Full Stack DRで移動しないコンピュートとして指定されているコンピュート・インスタンスのブート・デバイスは、スタンバイ・リージョンにレプリケートしないでください。したがって、移動していないコンピュート用のブート・デバイスを含むレプリケートされたブロック・ボリューム・グループは、DR保護グループ(DRPG)に追加されません。
注意:前述したように、OCI Full Stack DR Protection Groupsに関連付けられた唯一のアプリケーションまたはサービスであることは、Oracle E-Business Suiteでは珍しくありません。スタンバイ・リージョンのDR保護グループのメンバーとして、他のIaaSおよびPaaSリソースを使用することもできます。
タスク4.2.1: スタンバイDR保護グループへのナビゲート
図4.2.1に示すように、リージョン2のDR保護グループに移動します。
- OCIリージョン・コンテキストがリージョン2 (アッシュバーン)であることを確認します。
- リージョン2でDR保護グループを選択します。
図4.2.1:リージョン2のDR保護グループに移動します
タスク4.2.2: Oracle E-Business Suiteアプリケーション・サーバー1の追加
「メンバーの追加」を開き、最初のアプリケーション・サーバーを追加します。
- 「メンバー」を選択します。
- 「メンバーの追加」をクリックします。
図4.2.2.1:「メンバーの追加」ダイアログ・ボックスを開きます。
図4.2.2.2に示すように、リージョン2のアプリケーション・サーバー1を選択します。ブロック・ボリューム・グループを追加したり、ネットワーク・プロパティを指定する必要はありません。これは、移動しないインスタンスであるためです。
- 「リソース・タイプ」として「コンピュート」を選択します。
- Oracle E-Business Suiteアプリケーション・サーバーを含むコンパートメントを選択し、アプリケーション・サーバー1として指定したコンピュート・インスタンスを選択します。
- 「非移動インスタンス」を選択します。これにより、DR操作中にレプリケートされた仮想マシンをスタンバイ・リージョンで起動しようとしないことがOCI Full Stack DRに通知されます。
- 「追加」をクリックして、コンピュート・インスタンスをDRPGに追加します(表示されていません)。
図4.2.2.2:アプリケーション・サーバー1のパラメータを指定します。
タスク4.2.3: Oracle E-Business Suiteアプリケーション・サーバー2の追加
-
「メンバーの追加」をクリックして、2番目のアプリケーション・サーバーを追加します。
図4.2.3.1:「メンバーの追加」ダイアログ・ボックスを開きます。
図4.2.3.2に示すように、リージョン2のアプリケーション・サーバー2を選択します。ブロック・ボリューム・グループを追加したり、ネットワーク・プロパティを指定する必要はありません。これは、移動しないインスタンスであるためです。
- 「リソース・タイプ」として「コンピュート」を選択します。
- Oracle E-Business Suiteアプリケーション・サーバーを含むコンパートメントを選択し、アプリケーション・サーバー2として指定したコンピュート・インスタンスを選択します。
- 「非移動インスタンス」を選択します。これにより、DR操作中にレプリケートされた仮想マシンをスタンバイ・リージョンで起動しようとしないことがOCI Full Stack DRに通知されます。
- 「追加」をクリックして、コンピュート・インスタンスをDRPGに追加します(表示されていません)。
図4.2.3.2:アプリケーション・サーバー2のパラメータを指定します。
タスク4.2.4: Oracleスタンバイ・クラスタ・データベースの追加
-
「メンバーの追加」をクリックして、データベースをメンバーとして追加します。
図4.2.4.1:「メンバーの追加」ダイアログ・ボックスを開きます。
図4.2.4.2に示すように、リージョン2でOracle E-Business SuiteのRACデータベースを選択します。これは、単一インスタンス・データベースでもまったく同じように機能します。
- 「リソース・タイプ」として「データベース」を選択します。データベース・リソース・タイプでは、Oracle Base Database ServiceまたはOracle Exadata Database Service on Dedicated Infrastructureのいずれかを選択できます。どちらも、Oracle E-Business Suiteエンジニアリングでサポートされている有効な選択肢です。
- 次の図は、Oracle Base Database Serviceを示していますが、一般的なOracle Exadata Database Service on Dedicated Infrastructureを使用することもできます。
- デプロイメントに一致するこれらのフィールドの値を選択します。これらの選択に対する回答がわからない場合は、データベース管理者に問い合せてください。
- データベースのパスワードを含むコンパートメントおよびボールト・シークレットを選択します。タスク2.4の一部として、リージョン2に同様のボールトおよびシークレットを作成しました。このパラメータは、他のDBaaS APIとの互換性のためにダイアログにありますが、パスワードは実際には使用されません。
- 「追加」をクリックして、データベースをメンバーとして追加します(表示されていません)。
図4.2.4.2:リージョン2のRACデータベースのパラメータを指定します。
DR保護グループのメンバーのリストは、図4.2.4.3に示すスクリーンショットのようになります。この特定のDR保護グループにOracle E-Business Suiteを超えるものを追加する場合、または既存のDR保護グループにOracle E-Business Suiteメンバー・リソースを追加する場合、リストは異なる場合があります。
図4.2.4.3:リージョン2のOracle E-Business Suiteに必要なメンバーの完全なリスト
タスク5: リージョン2でのDR計画の作成
このタスクでは、リージョン2 (アッシュバーン)のスタンバイDR保護グループに関連付けられた基本的なスイッチオーバー、フェイルオーバーおよび開始ドリル・プランを作成します。
各計画の目的は、ワークロードをプライマリ・リージョン1からスタンバイ・リージョン2に移行することです。両方のリージョンのDR保護グループのロールは、DR操作の一部として自動的に元に戻されるため、リージョン1の保護グループがスタンバイになり、フェイルオーバーまたはスイッチオーバー後にリージョン2の保護グループがプライマリになります。
OCI Full Stack DRでは、前のタスクで追加したメンバー・リソースに基づいて、両方のプランに組込みステップが事前移入されます。以降の手順で計画をカスタマイズして、リカバリ操作中にOracle E-Business Suiteシステムに関連するすべてのタスクを処理します。
DR計画は、常にスタンバイ・ロールを持つ保護グループに作成されます。リージョン2は現在スタンバイ保護グループであるため、アッシュバーンから開始します。
図5-1に示すように、リージョン2のDRPGを選択して、基本計画を作成します。
- OCIリージョン・コンテキストがリージョン2 (アッシュバーン)であることを確認します。
- リージョン2のスタンバイDRPGを選択します。
- 「プラン」を選択します。
- 「プランの作成」をクリックしてプロセスを開始します。
図5-0:リージョン2での基本的なDR計画の作成を開始する方法
タスク5.1: リージョン2へのスイッチオーバー用のDR計画の作成
図5-2に示すように、DR計画の作成は簡単です。
- スイッチオーバー・プランの名前を簡単かつ意味のあるものにします。名前はできるだけ短くする必要がありますが、危機時の混乱や人的ミスを軽減するために一目で理解しやすい名前にする必要があります。
- 「プラン・タイプ」を選択します。この記述の時点では、プラン・タイプは4つのみです。
図5-1: DRスイッチオーバー計画の作成に必要なパラメータ
タスク5.2: リージョン2へのフェイルオーバーのためのDR計画の作成
図5-2に示すように、同じプロセスに従って基本的なフェイルオーバー計画を作成します。
- フェイルオーバー計画の名前を簡単かつ意味のあるものにします。
- 「プラン・タイプ」を選択します。この記述の時点では、プラン・タイプは4つのみです。
図5-2: DRフェイルオーバー計画の作成に必要なパラメータ
タスク5.3: リージョン2でのドリルの開始のためのDR計画の作成
図5-3に示すように、同じプロセスに従って開始ドリル計画を作成します。
- 開始ドリル計画の名前を単純にし、意味のあるものにします。
- 「プラン・タイプ」を選択します。この記述の時点では、プラン・タイプは4つのみです。
図5-3: DR開始ドリル・プランの作成に必要なパラメータ
リージョン2のスタンバイDR保護グループには、次の図に示すように3つのDR計画が必要です。これらは、リージョン1からリージョン2へのワークロードの移行を処理します。同様の計画をリージョン1で作成し、後のタスクでワークロードをリージョン2からリージョン1に戻します。
図5-4:続行する前にリージョン2に存在する必要がある3つの基本的なDR計画を示します。
ノート: OCI Full Stack DRでは、開始ドリル・プランが正常に実行された後にのみ、ストップ・ドリル・プランの作成がサポートされます。チュートリアルでは、ストップ・ドリル・プランの作成は範囲外ですが、両方のDR保護グループにもストップ・ドリルを作成することをお薦めします。
タスク6: リージョン2 (アッシュバーン)でのDR計画のカスタマイズ
OCI Full Stack DRには、OCI Infrastructure as a Service (IaaS)およびPlatform as a Service (PaaS)リソースのリカバリを編成するためのインテリジェンスが組み込まれています。OCI Full Stack DRには、Oracle E-Business Suiteのリカバリを編成するための組み込みのインテリジェンスはありません。Oracle E-Business Suiteは現在、組み込みのディザスタ・リカバリを導入または管理するためのOCIネイティブ・ディザスタ・リカバリAPIを提供していないためです。
ただし、OCI Full Stack DRは、タスク5の一部として作成された基本DR計画にユーザー定義のDR計画グループとステップを追加することで、引き続きOracle E-Business Suiteのリカバリを調整できます。ユーザー定義ステップは、タスク2.3の一部として、両方のリージョンまたは専用DR制御ノードのOracle E-Business Suiteアプリケーション・サーバーにダウンロードおよびインストールされたOracle E-Business Suiteスクリプトをコールします。ユーザー定義のプラン・グループの概要を次に示します。追加する必要があるプラン・グループは、DRプラン・タイプによって異なります。
- Oracle E-Business Suiteを停止し、リージョン1のnode2でrsyncジョブを無効にします。
- Oracle E-Business SuiteSを停止し、リージョン1のnode1でrsyncジョブを無効にします。
- リージョン2のデータベースfnd表のノード名をクリアします。
- リージョン2のnode1のデータベースにアプリケーション・コンテキストを設定します。
- リージョン2のnode2のデータベースにアプリケーション・コンテキストを設定します。
- リージョン2のnode1で
autoconfig
を実行します。 - リージョン2のnode2で
autoconfig
を実行します。 - Oracle E-Business Suiteを起動し、リージョン2のnode1でrsyncジョブを有効にします。
- Oracle E-Business Suiteを起動し、リージョン2のnode2でrsyncジョブを有効にします。
タスク6.1: スイッチオーバー計画の選択
まず、タスク5で作成したスイッチオーバー計画にナビゲートします。
図6.1:リージョン2でスイッチオーバー・プランを選択します。
OCI Full Stack DRは、事前チェック組込みおよびデータベース・スイッチオーバー・プラン・グループを生成します。これは、リージョン1およびリージョン2のDR保護グループに追加したメンバーに基づいて生成されました。
図6.1.1:リージョン2のスイッチオーバー・プランのデフォルト・プラン・グループ
タスク6.2: Oracle E-Business Suiteを停止し、リージョン1のノード2でRsyncジョブを無効にするプラン・グループの作成
カスタムのユーザー定義DR計画グループの追加を開始します。
最初のユーザー定義の計画グループは、Oracle E-Business Suiteを停止し、リージョン1のnode2でrsyncジョブを無効にします。このプラン・グループには、タスク2.3でOracle E-Business Suiteアプリケーション・サーバー・ノードにダウンロードされたshutdownapps.sh
およびfsdr-rsync-ebs.sh
bashスクリプトをコールする2つのステップが含まれます。
タスク6.2.1: 「プラン・グループの追加」の選択
プラン・グループを追加するプロセスを開始します。
-
「グループの追加」をクリックして開始します。
図6-2.1: Oracle E-Business Suiteを停止し、node2でrsyncジョブを無効にするプラン・グループの追加を開始します。
タスク6.2.2: プラン・グループ名、オーダーおよびステップの追加の指定
DR計画グループには、すべてパラレルに実行される多くのステップを含めることができます。ここでは、bashスクリプトを実行して、node2でOracle E-Business Suiteを停止し、リージョン1のnode2でrsync cronジョブを無効にする2つのステップを追加します。この例では、node2の名前はebshaapp02phx
です。
- プラン・グループにわかりやすい名前を付けます。
- 計画グループがDR計画に挿入される位置を選択します。この場合、ユーザー定義の計画グループをデータベース・スイッチオーバー計画グループの前に追加します。
- 組込みの「データベース- スイッチオーバー」プラン・グループを選択します。
- 2つのステップを追加します。最初の手順は、ノード2でOracle E-Business Suiteを停止することです。2番目のスクリプトは、ノード2でrsyncジョブを無効にすることです。
- 「ステップの追加」をクリックしてダイアログを開き、node2でOracle E-Business Suiteを停止するスクリプトを指定します。
図6.2.2:グループを計画して、Oracle E-Business Suiteを停止し、rsyncジョブを停止します。
タスク6.2.3: ステップ名およびローカル・スクリプト・パラメータの指定
「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。このプラン・グループに2つのステップを追加します。
- ステップ1は、node2でOracle E-Business Suiteアプリケーションを停止することです。
- ステップ2: node2でRysncジョブを無効にします。
この設定では、ノード2は ebshaapp02phx
です
このダイアログのすべてのフィールドについて説明しますが、同じプロセスを繰り返し実行するため、以降の手順で残りのすべてのスクリーンショットにこの詳細を省略します。
-
このステップが実行するタスクを説明するわかりやすい名前。
-
リージョン1を選択します。この場合はフェニックスです。
-
「ローカル・スクリプトの実行」を選択します。
-
Oracle E-Business Suiteアプリケーションnode2を含む正しいコンパートメントを選択し、ノード2を選択します(この場合は
ebshaapp02phx
)。 -
適切なパラメータを使用して、Oracle E-Business Suiteアプリケーションnode2に
shutdownapps.sh
スクリプトをインストールした絶対パスに貼り付けます。正確な構文については、タスク2.3のGitHubリンクからreadmeの詳細を参照できます。 -
スクリプトを実行するユーザーとしてoracleを指定します。
-
スクリプトがnode2上のOracle E-Business Suiteアプリケーションの停止に失敗した場合、DR計画は停止します。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRでは、問題の修正後もスイッチオーバー計画の実行を継続できます。
-
OCI Full Stack DRが障害を宣言する前のデフォルト値は60分(3600秒)です。この値は1800秒に変更することも、より現実的なタイムアウト値として感じられる値に変更することもできます。
-
「ステップの追加」をクリックして、このステップをプラン・グループに追加します。
図6.2.3.1:ノード2でOracle E-Business Suiteを停止するための計画ステップを作成するパラメータ -
ステップ1が追加されると、次のように表示されます。
図6.2.3.2:ノード2のステップでOracle E-Business Suiteを停止します。 -
「ステップの追加」をクリックして、このプラン・グループに2番目のステップを追加します。
-
このステップが実行するタスクを説明するわかりやすい名前。
-
「Region 1」を選択します。この場合は「Phoenix」です。
-
「ローカル・スクリプトの実行」を選択します。
-
Oracle E-Business Suiteアプリケーションnode2を含む正しいコンパートメントを選択し、ノード2を選択します(この場合は
ebshaapp02phx
)。 -
適切なパラメータを使用して、Oracle E-Business Suiteアプリケーションnode2に
fsdr-rsync-ebs
.shスクリプトをインストールした絶対パスに貼り付けます。正確な構文については、タスク2.3のGitHubリンクからreadmeの詳細を参照できます。 -
スクリプトを実行するユーザーとしてoracleを指定します。
-
スクリプトがnode2のrsyncジョブの無効化に失敗すると、DR計画は停止します。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRでは、問題の修正後もスイッチオーバー計画の実行を継続できます。
-
OCI Full Stack DRが障害を宣言する前のデフォルト値は60分(3600秒)です。この値は300秒に変更することも、より現実的なタイムアウト値に変更することもできます。
-
「ステップの追加」をクリックして、このステップをプラン・グループに追加します。
図6.2.3.1:ノード2でsysncジョブを無効にする計画ステップを作成するパラメータ -
ステップ2が追加されると、次のように表示されます。
図6.2.3.2:ノード2の「Disable rysnc jobs」が追加されました。
タスク6.2.4: 計画グループおよびステップの追加の完了
Oracle E-Business Suiteアプリケーションの停止とnode2のrsyncジョブの無効化の両方が、DR計画グループに追加されます。
-
「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。
図6.2.4.1: Oracle E-Business Suiteを停止し、node1でrsyncジョブを無効にするプラン・グループおよびステップの追加を完了します。 -
追加したプラン・グループがスイッチオーバー・プランで使用可能であることを確認します。
図6.2.4.1: Oracle E-Business Suiteを停止し、追加されたnode1プラン・グループでrsyncジョブを無効にします。
タスク6.3: Oracle E-Business Suiteを停止し、リージョン1のノード1でRsyncジョブを無効にするプラン・グループの作成
次に、ユーザー定義のプラン・グループを追加します。
このユーザー定義の計画グループは、Oracle E-Business Suiteを停止し、リージョン1のnode1でrsyncジョブを無効にします。このプラン・グループには、タスク2.3でOracle E-Business Suiteアプリケーション・サーバー・ノードにダウンロードされたshutdownapps.sh
およびfsdr-rsync-ebs.sh
bashスクリプトをコールする2つのステップが含まれます。
タスク6.3.1: 「プラン・グループの追加」の選択
プラン・グループを追加するプロセスを開始します。
-
「グループの追加」をクリックして開始します。
図6-3.1: Oracle E-Business Suiteを停止し、node1でrsyncジョブを無効にするプラン・グループの追加を開始します。
タスク6.3.2: プラン・グループ名、オーダーおよびステップの追加の指定
DR計画グループには、すべてパラレルに実行される多くのステップを含めることができます。ここでは、bashスクリプトを実行して、node1でOracle E-Business Suiteを停止し、リージョン1のnode1でrsync cronジョブを無効にする2つのステップを追加します。この例では、node1の名前はebshaapp01phx
です。
- プラン・グループにわかりやすい名前を付けます。
- 計画グループがDR計画に挿入される位置を選択します。In this case, we are going to insert our user-defined plan group add after the Shutdown EBS on node2 at PHX plan group.
- 「PHXのnode2でEBSを停止」というユーザー定義プラン・グループを選択します。
- 2つのステップを追加します。最初の手順は、ノード1でOracle E-Business Suiteを停止することです。2番目のスクリプトは、ノード1でrsyncジョブを無効にすることです。
- 「ステップの追加」をクリックしてダイアログを開き、node2でOracle E-Business Suiteを停止するスクリプトを指定します。
図6.3.2:グループを計画して、Oracle E-Business Suiteを停止し、rsyncジョブを停止します。
タスク6.3.3: ステップ名およびローカル・スクリプト・パラメータの指定
「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。このプラン・グループに2つのステップを追加します。
- ステップ1は、node1でOracle E-Business Suiteアプリケーションを停止することです。
- ステップ2では、node1でRysncジョブを無効にします。
この設定では、ノード1は ebshaapp01phx
です
このダイアログのすべてのフィールドについて説明しますが、同じプロセスを繰り返し実行するため、以降の手順で残りのすべてのスクリーンショットにこの詳細を省略します。
-
このステップが実行するタスクを説明するわかりやすい名前。
-
「ローカル・スクリプトの実行」としてユーザー定義タイプを選択します。
-
「Region 1」を選択します。この場合は「Phoenix」です。
-
Oracle E-Business Suiteアプリケーションnode1を含む正しいコンパートメントを選択し、ノード1を選択します(この場合は
ebshaapp01phx
)。 -
適切なパラメータを使用して、Oracle E-Business Suiteアプリケーションnode2に
shutdownapps.sh
スクリプトをインストールした絶対パスに貼り付けます。正確な構文については、タスク2.3のGitHubリンクからreadmeの詳細を参照できます。 -
スクリプトを実行するユーザーとしてoracleを指定します。
-
スクリプトがnode1上のOracle E-Business Suiteアプリケーションの停止に失敗した場合、DR計画は停止します。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRでは、問題の修正後もスイッチオーバー計画の実行を継続できます。
-
OCI Full Stack DRが障害を宣言する前のデフォルト値は60分(3600秒)です。この値は1800秒に変更することも、より現実的なタイムアウト値として感じられる値に変更することもできます。
-
「ステップの追加」をクリックして、このステップをプラン・グループに追加します。
図6.3.3.1:ノード1でOracle E-Business Suiteを停止するための計画ステップを作成するパラメータ -
ステップ1が追加されると、次のように表示されます。
図6.3.3.2:ノード1のステップでOracle E-Business Suiteを停止します。 -
「ステップの追加」をクリックして、このプラン・グループに2番目のステップを追加します。
-
このステップが実行するタスクを説明するわかりやすい名前。
-
「Region 1」を選択します。この場合は「Phoenix」です。
-
「ローカル・スクリプトの実行」を選択します。
-
Oracle E-Business Suiteアプリケーションnode1を含む正しいコンパートメントを選択し、ノード1を選択します(この場合は
ebshaapp02phx
)。 -
適切なパラメータを使用して、Oracle E-Business Suiteアプリケーションnode2に
fsdr-rsync-ebs.sh
スクリプトをインストールした絶対パスに貼り付けます。正確な構文については、タスク2.3のGitHubリンクからreadmeの詳細を参照できます。 -
スクリプトを実行するユーザーとしてoracleを指定します。
-
スクリプトがnode1のrsyncジョブの無効化に失敗すると、DR計画は停止します。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRでは、問題の修正後もスイッチオーバー計画の実行を継続できます。
-
OCI Full Stack DRが障害を宣言する前のデフォルト値は60分(3600秒)です。この値は300秒に変更することも、より現実的なタイムアウト値に変更することもできます。
-
「ステップの追加」をクリックして、このステップをプラン・グループに追加します。
図6.3.3.1:ノード1でsysncジョブを無効にする計画ステップを作成するパラメータ -
ステップ2が追加されると、次のように表示されます。
図6.3.3.2:ノード1の「Disable rysnc jobs」が追加されました。
タスク6.3.4: 計画グループおよびステップの追加の完了
Oracle E-Business Suiteアプリケーションの停止とnode2のrsyncジョブの無効化の両方が、DR計画グループに追加されます。
-
「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。
図6.3.4.1: Oracle E-Business Suiteを停止し、node1でrsyncジョブを無効にするプラン・グループおよびステップの追加を完了します。 -
追加したプラン・グループがスイッチオーバー・プランで使用可能であることを確認します。
図6.3.4.1: Oracle E-Business Suiteを停止し、追加されたnode1プラン・グループでrsyncジョブを無効にします。
タスク6.4: リージョン2のデータベースfnd
表のノード名をクリアするプラン・グループの作成
次に、ユーザー定義のプラン・グループを追加します。
このユーザー定義の計画グループは、リージョン2のデータベースfnd
表のノード名を消去します。このプラン・グループには、タスク2.3でOracle E-Business Suiteアプリケーション・サーバー・ノードにダウンロードされたfndnodeclean.sh
bashスクリプトをコールするステップが1つ含まれます。
タスク6.4.1: プラン・グループの追加の選択
プラン・グループを追加するプロセスを開始します。
-
「グループの追加」をクリックして開始します。
図6.4.1: Oracle E-Business Suiteを停止し、node1でrsyncジョブを無効にするプラン・グループの追加を開始します。
タスク6.4.2: プラン・グループ名、オーダーおよびステップの追加の指定
bashスクリプトを実行して、リージョン1のnode1上のデータベースfnd
表のノード名をクリアするノードを追加します。この例では、node1の名前はebshaapp01iad
です。
- プラン・グループにわかりやすい名前を付けます。
- 計画グループがDR計画に挿入される位置を選択します。この場合、ユーザー定義の計画グループを「データベース- スイッチオーバー」計画グループの後に追加します。
- 組込みの「データベース- スイッチオーバー」プラン・グループを選択します。
- データベースfndテーブルのノード名をクリアする手順を1つ追加します。
- 「ステップの追加」をクリックして、データベース
fnd
表のノード名をクリアするスクリプトを指定するダイアログを開きます。
図6.4.2:データベースfnd表のノード名をクリアするグループを計画します。
タスク6.4.3: ステップ名およびローカル・スクリプト・パラメータの指定
「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。このプラン・グループに1つ追加します。
- ステップでは、node1で
fndnodeclean
を実行します。
この設定では、ノード1は ebshaapp01iad
です
このダイアログのすべてのフィールドについて説明しますが、同じプロセスを繰り返し実行するため、以降の手順で残りのすべてのスクリーンショットにこの詳細を省略します。
-
このステップが実行するタスクを説明するわかりやすい名前。
-
「ローカル・スクリプトの実行」としてユーザー定義タイプを選択します。
-
リージョン2を選択します。この場合はアッシュバーンです。
-
Oracle E-Business Suiteアプリケーションnode1を含む正しいコンパートメントを選択し、ノード1を選択します(この場合は
ebshaapp01iad
)。 -
適切なパラメータを使用して、Oracle E-Business Suiteアプリケーションnode1に
fndnodeclean.sh
スクリプトをインストールした絶対パスに貼り付けます。正確な構文については、タスク2.3のGitHubリンクからreadmeの詳細を参照できます。 -
スクリプトを実行するユーザーとしてoracleを指定します。
-
スクリプトがnode1上のOracle E-Business Suiteアプリケーションの停止に失敗した場合、DR計画は停止します。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRでは、問題の修正後もスイッチオーバー計画の実行を継続できます。
-
OCI Full Stack DRが障害を宣言する前のデフォルト値は60分(3600秒)です。この値は900秒に変更することも、より現実的なタイムアウト値に変更することもできます。
-
「ステップの追加」をクリックして、このステップをプラン・グループに追加します。
図6.4.3.1:データベースfnd表のノード名をクリアする計画ステップを作成するパラメータ -
ステップ1が追加されると、次のように表示されます。
図6.4.3.2:データベースfnd表のノード名のクリア
タスク6.4.4: プラン・グループおよびステップの追加の完了
データベースfnd表のノード名をクリアするステップがDR計画グループに追加されます。
-
「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。
図6.4.4.1:データベースfnd表のノード名をクリアする計画グループおよびステップの追加を確定します。 -
追加したプラン・グループがスイッチオーバー・プランで使用可能であることを確認します。
図6.4.4.2:追加されたnode1プラン・グループのデータベースfnd表のノード名をクリアするには
タスク6.5: リージョン2のnode1でデータベース内のアプリケーション・コンテキストを設定するためのプラン・グループの作成
次に、ユーザー定義のプラン・グループを追加します。
このユーザー定義のプラン・グループは、リージョン2のnode1上のデータベースにアプリケーション・コンテキストを設定します。このプラン・グループには、タスク2.3でOracle E-Business Suiteアプリケーション・サーバー・ノードにダウンロードされたdbtxkconfig.sh bashスクリプトをコールするステップが1つ含まれます。
タスク6.5.1: 「プラン・グループの追加」の選択
プラン・グループを追加するプロセスを開始します。
-
「グループの追加」をクリックして開始します。
図6.5.1: node1上のデータベースにアプリケーション・コンテキストを設定するためのプラン・グループの追加を開始します。
タスク6.5.2: プラン・グループ名、オーダーおよびステップの追加の指定
bashスクリプトを実行して、リージョン2のnode1上のデータベースにアプリケーション・コンテキストを設定するステップを1つ追加します。この例では、node1の名前はebshaapp01iad
です。
- プラン・グループにわかりやすい名前を付けます。
- 計画グループがDR計画に挿入される位置を選択します。この場合、ユーザー定義の計画グループを「IADのデータベースfnd表のノード名のクリア」計画グループの後に追加します。
- 組込みの「IADのデータベースfnd表のノード名のクリア」プラン・グループを選択します。
- node1のデータベースでアプリケーション・コンテキストを設定するためのステップを1つ追加します。
- 「ステップの追加」をクリックしてダイアログを開き、node1上のデータベースにアプリケーション・コンテキストを設定するスクリプトを指定します。
図6.5.2: node1上のデータベースにアプリケーション・コンテキストを設定するプラン・グループ
タスク6.5.3: ステップ名およびローカル・スクリプト・パラメータの指定
「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。このプラン・グループに1つ追加します。
- 手順は、node1で
dbtxkconfig
を実行します(物理ホスト名を変更します)。
この設定では、ノード1は ebshaapp01iad
です
このダイアログのすべてのフィールドについて説明しますが、同じプロセスを繰り返し実行するため、以降の手順で残りのすべてのスクリーンショットにこの詳細を省略します。
-
このステップが実行するタスクを説明するわかりやすい名前。
-
「ローカル・スクリプトの実行」としてユーザー定義タイプを選択します。
-
リージョン2を選択します。この場合はアッシュバーンです。
-
Oracle E-Business Suiteアプリケーションnode1を含む正しいコンパートメントを選択し、ノード1を選択します(この場合は
ebshaapp01iad
)。 -
適切なパラメータを使用して、Oracle E-Business Suiteアプリケーションnode1にdbtxkconfig.shスクリプトをインストールした絶対パスに貼り付けます。正確な構文については、タスク2.3のGitHubリンクからreadmeの詳細を参照できます。すべての詳細を適切なパラメータで指定することは非常に重要です。
-
スクリプトを実行するユーザーとしてoracleを指定します。
-
スクリプトがデータベースnode1のアプリケーション・コンテキストの設定に失敗した場合、DR計画は停止する必要があります。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRでは、問題の修正後もスイッチオーバー計画の実行を継続できます。
-
OCI Full Stack DRが障害を宣言する前のデフォルト値は60分(3600秒)です。この値は900秒に変更することも、より現実的なタイムアウト値に変更することもできます。
-
「ステップの追加」をクリックして、このステップをプラン・グループに追加します。
図6.5.3.1:データベースnode1にアプリケーション・コンテキストを設定するプラン・ステップを作成するパラメータ -
ステップ1が追加されると、次のように表示されます。
図6.5.3.2:データベースnode1でアプリケーション・コンテキストを設定するには
タスク6.5.4: プラン・グループおよびステップの追加の完了
データベースnode1のアプリケーション・コンテキストを設定するステップがDR計画グループに追加されます。
-
「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。
図6.5.4.1:データベースnode1でアプリケーション・コンテキストを設定するプラン・グループおよびステップの追加を確定します。 -
追加したプラン・グループがスイッチオーバー・プランで使用可能であることを確認します。
図6.5.4.2:データベースnode1プラン・グループに追加されたアプリケーション・コンテキストを設定するには
タスク6.6: リージョン2のnode2でデータベース内のアプリケーション・コンテキストを設定するためのプラン・グループの作成
次に、ユーザー定義のプラン・グループを追加します。
このユーザー定義のプラン・グループは、リージョン2のnode2上のデータベースにアプリケーション・コンテキストを設定します。このプラン・グループには、タスク2.3でOracle E-Business Suiteアプリケーション・サーバー・ノードにダウンロードされたdbtxkconfig.sh
bashスクリプトをコールするステップが1つ含まれます。
タスク6.6.1: 「プラン・グループの追加」の選択
プラン・グループを追加するプロセスを開始します。
-
「グループの追加」をクリックして開始します。
図6.6.1: node2上のデータベースにアプリケーション・コンテキストを設定するためのプラン・グループの追加を開始します。
タスク6.6.2: プラン・グループ名、オーダーおよびステップの追加の指定
bashスクリプトを実行して、リージョン2のnode2上のデータベースにアプリケーション・コンテキストを設定するステップを1つ追加します。この例では、node2の名前はebshaapp02iad
です。
- プラン・グループにわかりやすい名前を付けます。
- 計画グループがDR計画に挿入される位置を選択します。この場合、ユーザー定義プラン・グループをIADプラン・グループのnode1上のデータベースに設定アプリケーション・コンテキストの後に追加します。
- 組込みの「IADのnode1のデータベース内のアプリケーション・コンテキストの設定」プラン・グループを選択します。
- node2のデータベースでアプリケーション・コンテキストを設定するためのステップを1つ追加します。
- 「ステップの追加」をクリックしてダイアログを開き、node1上のデータベースにアプリケーション・コンテキストを設定するスクリプトを指定します。
図6.6.2: node2上のデータベースにアプリケーション・コンテキストを設定するプラン・グループ
タスク6.6.3: ステップ名およびローカル・スクリプト・パラメータの指定
「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。このプラン・グループに1つ追加します。
- 手順は、node2で
dbtxkconfig
を実行します(物理ホスト名を変更します)。
この設定では、ノード2は ebshaapp02iad
です
このダイアログのすべてのフィールドについて説明しますが、同じプロセスを繰り返し実行するため、以降の手順で残りのすべてのスクリーンショットにこの詳細を省略します。
-
このステップが実行するタスクを説明するわかりやすい名前。
-
「ローカル・スクリプトの実行」としてユーザー定義タイプを選択します。
-
リージョン2を選択します。この場合はアッシュバーンです。
-
Oracle E-Business Suiteアプリケーションnode1を含む正しいコンパートメントを選択し、ノード1を選択します(この場合は
ebshaapp02iad
)。 -
適切なパラメータを使用して、Oracle E-Business Suiteアプリケーションnode1にdbtxkconfig.shスクリプトをインストールした絶対パスに貼り付けます。正確な構文については、タスク2.3のGitHubリンクからreadmeの詳細を参照できます。すべての詳細を適切なパラメータで指定することは非常に重要です。
-
スクリプトを実行するユーザーとしてoracleを指定します。
-
スクリプトがデータベースnode2のアプリケーション・コンテキストの設定に失敗した場合、DR計画は停止する必要があります。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRでは、問題の修正後もスイッチオーバー計画の実行を継続できます。
-
OCI Full Stack DRが障害を宣言する前のデフォルト値は60分(3600秒)です。この値は900秒に変更することも、より現実的なタイムアウト値に変更することもできます。
-
「ステップの追加」をクリックして、このステップをプラン・グループに追加します。
図6.6.3.1:データベースnode2にアプリケーション・コンテキストを設定するプラン・ステップを作成するパラメータ -
ステップ1が追加されると、次のように表示されます。
図6.6.3.2:データベースnode2でアプリケーション・コンテキストを設定するには
タスク6.6.4: プラン・グループおよびステップの追加の完了
データベースnode1のアプリケーション・コンテキストを設定するステップがDR計画グループに追加されます。
-
「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。
図6.6.4.1:データベースnode2でアプリケーション・コンテキストを設定するプラン・グループおよびステップの追加を確定します。 -
追加したプラン・グループがスイッチオーバー・プランで使用可能であることを確認します。
図6.6.4.2:データベースnode2プラン・グループに追加されたアプリケーション・コンテキストを設定するには
タスク6.7: リージョン2のアプリケーションnode1でautoconfig
を実行するプラン・グループの作成
次に、ユーザー定義のプラン・グループを追加します。
このユーザー定義プラン・グループは、リージョン2のアプリケーションnode1でautoconfig
を実行します。このプラン・グループには、タスク2.3でOracle E-Business Suiteアプリケーション・サーバー・ノードにダウンロードされたautoconfigapps.sh
bashスクリプトをコールするステップが1つ含まれます。
タスク6.7.1: 「プラン・グループの追加」の選択
プラン・グループを追加するプロセスを開始します。
-
「グループの追加」をクリックして開始します。
図6.7.1:アプリケーションnode1でautoconfigを実行するプラン・グループの追加を開始します。
タスク6.7.2: プラン・グループ名、オーダーおよびステップの追加の指定
bashスクリプトを実行して、リージョン2のアプリケーションnode1で autoconfig
を実行するステップを1つ追加します。この例では、node1の名前はebshaapp01iad
です。
- プラン・グループにわかりやすい名前を付けます。
- 計画グループがDR計画に挿入される位置を選択します。この場合、ユーザー定義プラン・グループをIADプラン・グループのnode2上のデータベースに設定アプリケーション・コンテキストの後に追加します。
- 組込みの「IADのnode2のデータベース内のアプリケーション・コンテキストの設定」プラン・グループを選択します。
- node2のデータベースでアプリケーション・コンテキストを設定するためのステップを1つ追加します。
- 「ステップの追加」をクリックして、アプリケーションnode1で
autoconfig
を実行するスクリプトを指定するダイアログを開きます。
図6.7.2:アプリケーションnode1でautoconfigを実行するプラン・グループ
タスク6.7.3: ステップ名およびローカル・スクリプト・パラメータの指定
「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。このプラン・グループに1つ追加します。
- ステップでは、node1で
autoconfig
を実行します。
この設定では、ノード1は ebshaapp01iad
です
このダイアログのすべてのフィールドについて説明しますが、同じプロセスを繰り返し実行するため、以降の手順で残りのすべてのスクリーンショットにこの詳細を省略します。
-
このステップが実行するタスクを説明するわかりやすい名前。
-
「ローカル・スクリプトの実行」としてユーザー定義タイプを選択します。
-
リージョン2を選択します。この場合はアッシュバーンです。
-
Oracle E-Business Suiteアプリケーションnode1を含む正しいコンパートメントを選択し、ノード1を選択します(この場合は
ebshaapp01iad
)。 -
適切なパラメータを指定して、Oracle E-Business Suiteアプリケーションnode1に
autoconfigapps
.sh
スクリプトをインストールした絶対パスに貼り付けます。正確な構文については、タスク2.3のGitHubリンクからreadmeの詳細を参照できます。すべての詳細を適切なパラメータで指定することは非常に重要です。 -
スクリプトを実行するユーザーとしてoracleを指定します。
-
スクリプトがアプリケーションnode1で
autoconfig
の実行に失敗した場合、DR計画は停止する必要があります。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRでは、問題の修正後もスイッチオーバー計画の実行を継続できます。 -
OCI Full Stack DRが障害を宣言する前のデフォルト値は60分(3600秒)です。この値は900秒に変更することも、より現実的なタイムアウト値に変更することもできます。
-
「ステップの追加」をクリックして、このステップをプラン・グループに追加します。
図6.7.3.1:アプリケーションnode1でautoconfigを実行するプラン・ステップを作成するパラメータ -
ステップ1が追加されると、次のように表示されます。
図6.7.3.2:アプリケーションnode1でautoconfigを実行するには
タスク6.7.4: プラン・グループおよびステップの追加の完了
アプリケーションnode1でautoconfig
を実行するステップがDR計画グループに追加されます。
-
「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。
図6.7.4.1:アプリケーションnode1でautoconfigを実行するプラン・グループおよびステップの追加を完了します。 -
追加したプラン・グループがスイッチオーバー・プランで使用可能であることを確認します。
図6.7.4.2:追加されたアプリケーションnode1プラン・グループでautoconfigを実行するには
タスク6.8: リージョン2のアプリケーションnode2でautoconfig
を実行するプラン・グループの作成
次に、ユーザー定義のプラン・グループを追加します。
このユーザー定義プラン・グループは、リージョン2のアプリケーションnode2でautoconfig
を実行します。このプラン・グループには、タスク2.3でOracle E-Business Suiteアプリケーション・サーバー・ノードにダウンロードされたautoconfigapps.sh
bashスクリプトをコールするステップが1つ含まれます。
タスク6.8.1: 「プラン・グループの追加」の選択
プラン・グループを追加するプロセスを開始します。
-
「グループの追加」をクリックして開始します。
図6.8.1:アプリケーションnode2でautoconfigを実行するプラン・グループの追加を開始します。
タスク6.8.2: プラン・グループ名、オーダーおよびステップの追加の指定
bashスクリプトを実行して、リージョン2のアプリケーションnode2でautoconfig
を実行するステップを1つ追加します。この例では、node2の名前はebshaapp02iad
です。
- プラン・グループにわかりやすい名前を付けます。
- 計画グループがDR計画に挿入される位置を選択します。この場合、IADのアプリケーションnode1でautoconfigを実行プラン・グループの後に追加するユーザー定義プラン・グループを挿入します。
- 組込みの「IADのアプリケーションnode1で自動構成を実行」プラン・グループを選択します。
- node2のデータベースでアプリケーション・コンテキストを設定するためのステップを1つ追加します。
- 「ステップの追加」をクリックして、アプリケーションnode2で
autoconfig
を実行するスクリプトを指定するダイアログを開きます。
図6.8.2:アプリケーションnode2でautoconfigを実行するプラン・グループ
タスク6.8.3: ステップ名およびローカル・スクリプト・パラメータの指定
「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。このプラン・グループに1つ追加します。
- ステップでは、node2で
autoconfig
を実行します。
この設定では、ノード1は ebshaapp02iad
です
このダイアログのすべてのフィールドについて説明しますが、同じプロセスを繰り返し実行するため、以降の手順で残りのすべてのスクリーンショットにこの詳細を省略します。
-
このステップが実行するタスクを説明するわかりやすい名前。
-
「ローカル・スクリプトの実行」としてユーザー定義タイプを選択します。
-
リージョン2を選択します。この場合はアッシュバーンです。
-
Oracle E-Business Suiteアプリケーションnode2を含む正しいコンパートメントを選択し、ノード2を選択します(この場合は
ebshaapp02iad
)。 -
適切なパラメータを使用して、Oracle E-Business Suiteアプリケーションnode1に
autoconfigapps.sh
スクリプトをインストールした絶対パスに貼り付けます。正確な構文については、タスク2.3のGitHubリンクからreadmeの詳細を参照できます。すべての詳細を適切なパラメータで指定することは非常に重要です。 -
スクリプトを実行するユーザーとしてoracleを指定します。
-
スクリプトがアプリケーションnode2でautoconfigの実行に失敗すると、DR計画が停止します。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRでは、問題の修正後もスイッチオーバー計画の実行を継続できます。
-
OCI Full Stack DRが障害を宣言する前のデフォルト値は60分(3600秒)です。この値は900秒に変更することも、より現実的なタイムアウト値に変更することもできます。
-
「ステップの追加」をクリックして、このステップをプラン・グループに追加します。
図6.8.3.1:アプリケーションnode2でautoconfigを実行するプラン・ステップを作成するパラメータ -
ステップ1が追加されると、次のように表示されます。
図6.8.3.2:アプリケーションnode2でautoconfigを実行するには
タスク6.8.4: プラン・グループおよびステップの追加の完了
アプリケーションnode2でautoconfig
を実行するステップがDR計画グループに追加されます。
-
「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。
図6.8.4.1:アプリケーションnode2でautoconfigを実行するプラン・グループおよびステップの追加を完了します。 -
追加したプラン・グループがスイッチオーバー・プランで使用可能であることを確認します。
図6.8.4.2:追加されたアプリケーションnode2プラン・グループでautoconfigを実行するには
タスク6.9: Oracle E-Business Suiteを起動し、リージョン2のノード1でRsyncジョブを有効化するプラン・グループの作成
次に、ユーザー定義のプラン・グループを追加します。
このユーザー定義のプラン・グループは、Oracle E-Business Suiteを起動し、リージョン2のnode1でrsyncジョブを有効にします。このプラン・グループには、タスク2.3でOracle E-Business Suiteアプリケーション・サーバー・ノードにダウンロードされたstartapps.sh
およびfsdr-rsync-ebs.sh
bashスクリプトをコールする2つのステップが含まれます。
タスク6.9.1: 「プラン・グループの追加」の選択
プラン・グループを追加するプロセスを開始します。
-
「グループの追加」をクリックして開始します。
図6-9.1: Oracle E-Business Suiteを起動するためのプラン・グループの追加を開始し、node1でrsyncジョブを有効にします。
タスク6.9.2: プラン・グループ名、オーダーおよびステップの追加の指定
DR計画グループには、すべてパラレルに実行される多くのステップを含めることができます。ここでは、bashスクリプトを実行してnode1でOracle E-Business Suiteを起動し、リージョン2のnode1でrsync cronジョブを有効にする2つのステップを追加します。この例では、node1の名前はebshaapp01iad
です。
- プラン・グループにわかりやすい名前を付けます。
- 計画グループがDR計画に挿入される位置を選択します。この場合、IADのアプリケーションnode2でautoconfigを実行プラン・グループの後に追加するユーザー定義プラン・グループを挿入します。
- 「IADのアプリケーションnode2でautoconfigを実行」プラン・グループを選択します。
- 2つのステップを追加します。最初の手順は、ノード1でOracle E-Business Suiteを起動することです。2番目のスクリプトは、ノード1でrsyncジョブを有効にすることです。
- 「ステップの追加」をクリックしてダイアログを開き、node2でOracle E-Business Suiteを起動するスクリプトを指定します。
図6.9.2: node1でebsを起動し、rsyncジョブを有効にするグループを計画します。
タスク6.9.3: ステップ名およびローカル・スクリプト・パラメータの指定
「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。このプラン・グループに2つのステップを追加します。
- ステップ1は、node1でOracle E-Business Suiteアプリケーションを起動することです。
- 手順2は、node1上でRysncジョブを有効にすることです。
この設定では、ノード1は ebshaapp01iad
です。
このダイアログのすべてのフィールドについて説明しますが、同じプロセスを繰り返し実行するため、以降の手順で残りのすべてのスクリーンショットにこの詳細を省略します。
-
このステップが実行するタスクを説明するわかりやすい名前。
-
「ローカル・スクリプトの実行」としてユーザー定義タイプを選択します。
-
「Region 2」を選択します。この場合はアッシュバーンです。
-
Oracle E-Business Suiteアプリケーションnode1を含む正しいコンパートメントを選択し、ノード1を選択します(この場合は
ebshaapp01iad
)。 -
適切なパラメータを使用して、Oracle E-Business Suiteアプリケーションnode1に
startapps.sh
スクリプトをインストールした絶対パスに貼り付けます。正確な構文については、タスク2.3のGitHubリンクからreadmeの詳細を参照できます。 -
スクリプトを実行するユーザーとしてoracleを指定します。
-
スクリプトがnode1でOracle E-Business Suiteアプリケーションの起動に失敗すると、DR計画が停止します。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRでは、問題の修正後もスイッチオーバー計画の実行を継続できます。
-
OCI Full Stack DRが障害を宣言する前のデフォルト値は60分(3600秒)です。この値は1800秒に変更することも、より現実的なタイムアウト値として感じられる値に変更することもできます。
-
「ステップの追加」をクリックして、このステップをプラン・グループに追加します。
図6.9.3.1:ノード1でOracle E-Business Suiteを起動するための計画ステップを作成するパラメータ -
ステップ1が追加されると、次のように表示されます。
図6.9.3.2:ノード1のステップでOracle E-Business Suiteを起動します。 -
「ステップの追加」をクリックして、このプラン・グループに2番目のステップを追加します。
-
このステップが実行するタスクを説明するわかりやすい名前。
-
「Region 2」を選択します。この場合はアッシュバーンです。
-
「ローカル・スクリプトの実行」を選択します。
-
Oracle E-Business Suiteアプリケーションnode1を含む正しいコンパートメントを選択し、ノード1を選択します(この場合は
ebshaapp0iad
)。 -
適切なパラメータを使用して、Oracle E-Business Suiteアプリケーションnode1に
fsdr-rsync-ebs.sh
スクリプトをインストールした絶対パスに貼り付けます。正確な構文については、タスク2.3のGitHubリンクからreadmeの詳細を参照できます。 -
スクリプトを実行するユーザーとしてoracleを指定します。
-
スクリプトがnode1でrsyncジョブの有効化に失敗すると、DR計画は停止します。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRでは、問題の修正後もスイッチオーバー計画の実行を継続できます。
-
OCI Full Stack DRが障害を宣言する前のデフォルト値は60分(3600秒)です。この値は300秒に変更することも、より現実的なタイムアウト値に変更することもできます。
-
「ステップの追加」をクリックして、このステップをプラン・グループに追加します。
図6.9.3.1:ノード1でsysncジョブを有効にする計画ステップを作成するパラメータ -
ステップ2が追加されると、次のように表示されます。
図6.9.3.2:ノード1で「Enable rysnc jobs」が追加されました。
タスク6.9.4: プラン・グループおよびステップの追加の完了
Oracle E-Business Suiteアプリケーションの起動とnode1でのrsyncジョブの有効化の両方が、DR計画グループに追加されます。
-
「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。
図6.9.4.1: Oracle E-Business Suiteを起動し、node1でrsyncジョブを有効にするプラン・グループおよびステップの追加を完了します。 -
追加したプラン・グループがスイッチオーバー・プランで使用可能であることを確認します。
図6.9.4.1: Oracle E-Business Suiteを起動し、追加されたnode1プラン・グループでrsyncジョブを有効にします。
タスク6.10: 地域2のノード2でOracle E-Business Suiteを起動してRsyncジョブを有効にするための計画グループの作成
次に、ユーザー定義のプラン・グループを追加します。
このユーザー定義のプラン・グループは、Oracle E-Business Suiteを起動し、リージョン2のnode2でrsyncジョブを有効にします。このプラン・グループには、タスク2.3でOracle E-Business Suiteアプリケーション・サーバー・ノードにダウンロードされたstartapps.sh
およびfsdr-rsync-ebs.sh
bashスクリプトをコールする2つのステップが含まれます。
タスク6.10.1: 「プラン・グループの追加」の選択
プラン・グループを追加するプロセスを開始します。
-
「グループの追加」をクリックして開始します。
図6-10.1: Oracle E-Business Suiteを起動するためのプラン・グループの追加を開始し、node2でrsyncジョブを有効にします。
タスク6.10.2: プラン・グループ名、オーダーおよびステップの追加の指定
DR計画グループには、すべてパラレルに実行される多くのステップを含めることができます。ここでは、bashスクリプトを実行してnode1でOracle E-Business Suiteを起動し、リージョン2のnode1でrsync cronジョブを有効にする2つのステップを追加します。この例では、node1の名前はebshaapp02iad
です。
- プラン・グループにわかりやすい名前を付けます。
- 計画グループがDR計画に挿入される位置を選択します。この場合、IADのnode1でEBSを起動するプラン・グループの後に追加、ユーザー定義プラン・グループを挿入します。
- IADプラン・グループのnode1でEBSを起動というユーザー定義を選択します。
- 2つのステップを追加します。最初の手順は、ノード2でOracle E-Business Suiteを起動することです。2番目のスクリプトは、ノード2でrsyncジョブを有効にすることです。
- 「ステップの追加」をクリックしてダイアログを開き、node2でOracle E-Business Suiteを起動するスクリプトを指定します。
図6.10.2:グループを計画してOracle E-Business Suiteを起動し、node2でrsyncジョブを有効にします。
タスク6.10.3: ステップ名およびローカル・スクリプト・パラメータの指定
「プラン・グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。このプラン・グループに2つのステップを追加します。
- ステップ1は、node2でOracle E-Business Suiteアプリケーションを起動することです。
- 手順2は、node2上でRysncジョブを有効にすることです。
この設定では、ノード2は ebshaapp02iad
です
このダイアログのすべてのフィールドについて説明しますが、同じプロセスを繰り返し実行するため、以降の手順で残りのすべてのスクリーンショットにこの詳細を省略します。
-
このステップが実行するタスクを説明するわかりやすい名前。
-
「ローカル・スクリプトの実行」としてユーザー定義タイプを選択します。
-
「Region 2」を選択します。この場合はアッシュバーンです。
-
Oracle E-Business Suiteアプリケーションnode1を含む正しいコンパートメントを選択し、ノード2を選択します(この場合は
ebshaapp02iad
)。 -
適切なパラメータを使用して、Oracle E-Business Suiteアプリケーションnode1に
startapps.sh
スクリプトをインストールした絶対パスに貼り付けます。正確な構文については、タスク2.3のGitHubリンクからreadmeの詳細を参照できます。 -
スクリプトを実行するユーザーとしてoracleを指定します。
-
スクリプトがnode2でOracle E-Business Suiteアプリケーションの起動に失敗すると、DR計画が停止します。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRでは、問題の修正後もスイッチオーバー計画の実行を継続できます。
-
OCI Full Stack DRが障害を宣言する前のデフォルト値は60分(3600秒)です。この値は1800秒に変更することも、より現実的なタイムアウト値として感じられる値に変更することもできます。
-
「ステップの追加」をクリックして、このステップをプラン・グループに追加します。
図6.10.3.1:ノード2でOracle E-Business Suiteを起動するための計画ステップを作成するパラメータ -
ステップ1が追加されると、次のように表示されます。
図6.10.3.2:ノード2でOracle E-Business Suiteを起動します。 -
「ステップの追加」をクリックして、このプラン・グループに2番目のステップを追加します。
-
このステップが実行するタスクを説明するわかりやすい名前。
-
「Region 2」を選択します。この場合はアッシュバーンです。
-
「ローカル・スクリプトの実行」を選択します。
-
Oracle E-Business Suiteアプリケーションnode1を含む正しいコンパートメントを選択し、ノード2を選択します(この場合は
ebshaapp0iad
)。 -
適切なパラメータを使用して、Oracle E-Business Suiteアプリケーションnode1に
fsdr-rsync-ebs.sh
スクリプトをインストールした絶対パスに貼り付けます。正確な構文については、タスク2.3のGitHubリンクからreadmeの詳細を参照できます。 -
スクリプトを実行するユーザーとしてoracleを指定します。
-
スクリプトがnode2でrsyncジョブの有効化に失敗すると、DR計画は停止します。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRでは、問題の修正後もスイッチオーバー計画の実行を継続できます。
-
OCI Full Stack DRが障害を宣言する前のデフォルト値は60分(3600秒)です。この値は300秒に変更することも、より現実的なタイムアウト値に変更することもできます。
-
「ステップの追加」をクリックして、このステップをプラン・グループに追加します。
図6.10.3.1:ノード2でsysncジョブを有効にする計画ステップを作成するパラメータ -
ステップ2が追加されると、次のように表示されます。
図6.10.3.2:ノード2で「Enable rysnc jobs」が追加されました。
タスク6.10.4: 計画グループおよびステップの追加の完了
Oracle E-Business Suiteアプリケーションの起動とnode2でのrsyncジョブの有効化の両方が、DR計画グループに追加されます。
-
「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。
図6.10.4.1: Oracle E-Business Suiteを起動し、node2でrsyncジョブを有効にするプラン・グループおよびステップの追加を完了します。 -
追加したプラン・グループがスイッチオーバー・プランで使用可能であることを確認します。
図6.10.4.1: Oracle E-Business Suiteを起動し、追加されたnode2プラン・グループでrsyncジョブを有効にします。
ノート:これにより、スイッチオーバー計画に必要なすべてのユーザー定義計画グループが完了しました。プラン・グループを正しい順序で取得したことを確認してください。これは本当に重要です。
スイッチオーバー計画をカスタマイズすると、次のようになります。
図6.10.5.1:リージョン2のスイッチオーバー計画のすべての計画グループ
ノート:適切な順序でオーダーしていない場合は、プラン・グループの順序を変更できます。
タスク6.11: フェイルオーバー計画の選択
まず、前のタスクで作成したフェイルオーバー計画に移動します。
図6.11:リージョン2でフェイルオーバー計画を選択します。
OCI Full Stack DRは、事前チェック組込みおよびデータベース・フェイルオーバー・プラン・グループを生成します。これは、リージョン1およびリージョン2のDR保護グループに追加したメンバーに基づいて生成されました。
図6.11.1:リージョン2のフェイルオーバー計画のデフォルト計画グループ
スイッチオーバー計画をカスタマイズした方法と同様に、フェイルオーバー計画に必要なユーザー定義計画グループを追加します。
組込みプラン・グループDatabases-Failoverの後に、次のユーザー定義プラン・グループを追加する必要があります。
- リージョン2のデータベース
fnd
表のノード名をクリアします。 - リージョン2のnode1のデータベースにアプリケーション・コンテキストを設定します。
- リージョン2のnode2のデータベースにアプリケーション・コンテキストを設定します。
- リージョン2のnode1で
autoconfig
を実行します。 - リージョン2のnode2で
autoconfig
を実行します。 - Oracle E-Business Suiteを起動し、リージョン2のnode1でrsyncジョブを有効にします。
- Oracle E-Business Suiteを起動し、リージョン2のnode2でrsyncジョブを有効にします。
ノート:ユーザー定義プラン・グループを再度追加するステップは実行しません。詳細な手順は、タスク6.4から6.9を参照してください。
フェイルオーバー計画をカスタマイズすると、次のようになります。
図6.11.1:リージョン2のフェイルオーバー計画のすべてのプラン・グループ
ノート:
適切な順序でオーダーしていない場合は、プラン・グループの順序を変更できます。
「ドリルの開始」プランをカスタマイズすることもできます。
開始ドリル・プランでは、データベースに対して作成された組込みプラン・グループは存在しないことに注意してください。
フィジカル・スタンバイをスナップショット・スタンバイ・データベースに変換するには、ユーザー定義プラン・グループを作成する必要があります。標準のOracle Data Guard Brokerコマンドを使用して、これらの操作を実行し、ラッパー・スクリプトに挿入できます。
また、フェイルオーバー・プランでの作業と同様に、アプリケーション関連のユーザー定義プラン・グループを追加できます。
OCI Full Stack DRでは、開始ドリル計画の実行後に停止ドリル計画を作成できます。詳細は、「DRドリル計画」を参照してください。「ドリルの停止」プランは、開始ドリル・プランで実行された操作を元に戻しています。
「ドリルの停止」プランをカスタマイズすることもできます。
ストップ・ドリル・プランの場合、データベースに対して作成される組込みプラン・グループはないことに注意してください。
スナップショット・スタンバイを物理データベースに変換するには、ユーザー定義プラン・グループを作成する必要があります。標準のOracle Data Guard Brokerコマンドを使用して、これらの操作を実行し、ラッパー・スクリプトに挿入できます。
さらに、アプリケーション関連のユーザー定義プラン・グループを追加して、すべてのOracle E-Business Suite関連アプリケーションを停止できます。
このチュートリアルの一部として、後続のタスクで**スイッチオーバー計画を実行します。**
タスク7: リージョン2でのスイッチオーバー計画の実行(アッシュバーン)
スイッチオーバーおよびフェイルオーバーDR計画の両方が、スタンバイ・リージョン2 (アッシュバーン)に作成されています。リージョン2のDR計画により、OCI Full Stack DRはリージョン1からリージョン2にワークロードを移行できます。次のタスクは、リージョン1 (フェニックス)の保護グループにスイッチオーバー、フェイルオーバーおよびドリル・プランを開始して、OCI Full Stack DRがリージョン2からリージョン1にワークロードを移行できるようにすることです。
ただし、DR計画は、スタンバイ・ロールを持つ保護グループでのみ作成および変更できます。リージョン1のDR保護グループは現在プライマリであるため、リージョン1ではDR計画を作成できません。
したがって、リージョン1がスタンバイで、リージョン2がプライマリになるように、保護グループのロールを戻す必要があります。作成したスイッチオーバー計画を実行して、ワークロードをリージョン1 (フェニックス)からリージョン2 (アッシュバーン)に遷移します。
タスク7.1: 計画実行の開始
DR計画を実行して、Oracle Integration Cloudワークロードをリージョン1からリージョン2に移行するプロセスを開始します。
- リージョン・コンテキストがスタンバイ・リージョン2 (アッシュバーン)に設定されていることを確認します。
- コンソールの上部にあるブレッドクラムを使用して、DR保護グループの詳細が現在の計画コンテキストであることを確認します。
- リージョン2の正しいDR保護グループが選択されていることを確認します。これはスタンバイ・ロールである必要があります。
- 続行する前にフェイルオーバー計画とスイッチオーバー計画の両方が存在することを確認します。存在しない場合は、前のステップに戻り、両方のDR計画を作成およびカスタマイズします。
- 「DR計画の実行」をクリックします。
図7-1:スタンバイ・リージョンへのスイッチオーバーの実行方法を示します。
タスク7.2: スイッチオーバー計画の選択および実行
このタスクは、リージョン2でスイッチオーバー計画を実行します。
- スイッチオーバー計画を選択します。
- 「事前チェックの有効化」を選択します。
- 「DR計画の実行」をクリックして開始します。
図7-2:スイッチオーバー計画を選択して実行します。
タスク7.3: DR計画実行の監視
Oracle E-Business Suiteのワークロードがリージョン1からリージョン2に完全に移行されるまで、スイッチオーバー計画を監視します。スイッチオーバー計画が正常に完了すると、OCI Full Stack DRは、リージョン間のプライマリおよびスタンバイDR保護グループのロールの変更をクリーンアップします。
リージョン2 (フェニックス)がプライマリ・リージョンとなり、リージョン1 (アッシュバーン)は、OCI Full Stack DRがスイッチオーバーを完了するとスタンバイ・リージョンになります。
-
スイッチオーバー計画が正常に実行されたことを確認します。
図7-2:リージョン2でスイッチオーバー計画が正常に完了しました -
DR保護グループのロール変更、リージョン2 (フェニックス)にスタンバイ・ロールが現在あり、リージョン1 (アッシュバーン)にプライマリ・ロールが現在あることを確認します。
図7-2:スイッチオーバー計画後のDR保護グループのロール変更
タスク8: リージョン1でのDRおよびDR計画のカスタマイズ(フェニックス)
リージョン1 (フェニックス)のDR保護グループに、現在スタンバイ・ピアであるDR計画を作成します。
各計画の目的は、リージョン2がプライマリ・ピアである場合は常に、ワークロードをリージョン2からリージョン1に移行することです。両方のリージョンのDR保護グループのロールは、DR操作の一部として自動的に元に戻されるため、リージョン2の保護グループがスタンバイになり、フェイルオーバーまたはスイッチオーバー後にリージョン1の保護グループがプライマリになります。
OCI Full Stack DRでは、前のステップに追加されたメンバー・リソースに基づいて、両方のプランに組込みステップが事前移入されます。計画は、リカバリ操作中にOracle Integration Cloudに関連するすべてのタスクを処理するために、後のステップでカスタマイズされます。
DR計画は、常にスタンバイ・ロールを持つ保護グループに作成されます。現在、リージョン1は、タスク7でスイッチオーバー計画を実行した後のスタンバイ保護グループです。
タスク5と同じプロセスに従って、リージョン1にDR計画を作成します。プランが作成されたら、プランを確認します。
図8-1:リージョン1のDR計画
タスク6と同じプロセスに従って、リージョン1のDR計画をカスタマイズします。ユーザー定義のプラン・グループを追加してください。スクリプトを実行するために、本番およびDRリージョンに適したOracle E-Business SuiteアプリケーションVMを選択することは非常に重要です。
- Oracle E-Business Suiteを停止し、リージョン2のnode2でrsyncジョブを無効にします。
- Oracle E-Business Suiteを停止し、リージョン2のnode1でrsyncジョブを無効にします。
- リージョン1のデータベースfnd表のノード名をクリアします。
- リージョン1のnode1のデータベースにアプリケーション・コンテキストを設定します。
- リージョン1のnode2のデータベースにアプリケーション・コンテキストを設定します。
- リージョン1のnode1で
autoconfig
を実行します。 - リージョン1のnode2で
autoconfig
を実行します。 - Oracle E-Business Suiteを起動し、リージョン1のnode1でrsyncジョブを有効にします。
- Oracle E-Business Suiteを起動し、リージョン1のnode2でrsyncジョブを有効にします。
スイッチオーバー計画がカスタマイズされると、次のようになります。
図8.2:リージョン1のスイッチオーバー計画のすべての計画グループ
フェイルオーバー計画をカスタマイズすると、次のようになります。
図8.3:リージョン1のフェイルオーバー計画のすべてのプラン・グループ
ノート:
適切な順序でオーダーしていない場合は、プラン・グループの順序を変更できます。
「ドリルの開始」プランをカスタマイズすることもできます。
開始ドリル・プランでは、データベースに対して作成された組込みプラン・グループは存在しないことに注意してください。
フィジカル・スタンバイをスナップショット・スタンバイ・データベースに変換するには、ユーザー定義プラン・グループを作成する必要があります。標準のOracle Data Guard Brokerコマンドを使用して、これらの操作を実行し、ラッパー・スクリプトに挿入できます。
また、フェイルオーバー・プランでの作業と同様に、アプリケーション関連のユーザー定義プラン・グループを追加できます。
OCI Full Stack DRでは、開始ドリル計画の実行後に停止ドリル計画を作成できます。詳細は、「DRドリル計画」を参照してください。「ドリルの停止」プランは、開始ドリル・プランで実行された操作を元に戻しています。
「ドリルの停止」プランをカスタマイズすることもできます。
ストップ・ドリル・プランの場合、データベースに対して作成される組込みプラン・グループはないことに注意してください。
スナップショット・スタンバイを物理データベースに変換するには、ユーザー定義プラン・グループを作成する必要があります。標準のOracle Data Guard Brokerコマンドを使用して、これらの操作を実行し、ラッパー・スクリプトに挿入できます。
さらに、アプリケーション関連のユーザー定義プラン・グループを追加して、すべてのOracle E-Business Suite関連アプリケーションを停止できます。
次のステップ
OCI Full Stack DR for Oracle E-Business Suiteは、この時点で完全に実装する必要があります。ただし、本番用のOCI Full Stack DRを使用する前に、完全な機能を検証する必要があります。すべてのフェイルオーバーおよびスイッチオーバー計画を実行して、すべてが期待どおりに機能し、リカバリ・チームがプロセス全体を完全に理解していることを確認する必要があります。
スイッチオーバー計画のテスト
スイッチオーバー計画は、すべてのアーティファクトをクリーンアップし、OCIロード・バランサ、OCIブロック・ストレージ、OCIファイル・システム、Oracle Base Database Service、Oracle Autonomous Databaseなどの組込みリカバリ・ステップのすべてのロールが、人手を介さずにスタンバイ・リージョンからリカバリできるように設計されています。
フェイルオーバー計画のテスト
フェイルオーバーは異なります。フェイルオーバーの性質上、アーティファクトをクリーンアップしたり、障害が発生したリージョンのサービスおよびデータベースがワークロードをリージョン1に戻す準備ができていることを確認することはできません。リカバリ・チームは、Oracle Data Guardが正しい状態であること、ストレージおよびコンピュート・インスタンスのアーティファクトが終了していることを確認するタスクを理解して実行する必要があります。詳細は、Resetting DR Configuration After a Failoverを参照してください。
最終受入に対するすべてのDR計画の検証
リカバリ・チームは、OCI Full Stack DR保護グループおよび本番ワークロードの計画の準備状況を示すために、最終検証を実行する必要があります。リージョン2 (アッシュバーン)は、プロセスのこの時点でプライマリ・リージョンである必要があります。次のステップを実行して、すべてのプランの最終検証を開始します。
- リージョン2(プライマリ)からリージョン1(スタンバイ)へのスイッチオーバーをテストします。
- リージョン1(プライマリ)からリージョン2(スタンバイ)へのフェイルオーバーをテストします。
- リージョン2からのフェイルオーバー用にリージョン1 (プライマリ)を準備します。
- リージョン2 (プライマリ)からリージョン1 (スタンバイ)へのフェイルオーバーをテストします。
- リージョン2へのフェイルオーバーまたはスイッチオーバーのリージョン2 (プライマリ)を準備します。
- DR保護グループおよびアプリケーション・スタックは、通常の動作状態であり、この時点でフェイルオーバーまたはスイッチオーバーの準備ができている必要があります。
- 要件に応じて、いずれかのリージョンでDRドリル計画を実行することもできます。
このソリューションのサポートを受ける
OCI Full Stack DRエンジニアリングは、このソリューションの第1レベルのサポートを提供します。
ただし、このチュートリアルで提供されるソリューションおよびカスタム自動化は、Oracle E-Business Suite組織やOCI Full Stack DRエンジニアリング・チームとは独立して、Oracle Cloud EMEAスペシャリスト・チームによって考案および実装されました。
Oracle E-Business SuiteとOCI Full Stack DRの関係
OCI Full Stack DRは、Oracle E-Business Suiteのインストールまたはデプロイメント・プロセスの一部ではなく、Oracle E-Business Suiteによって記述および管理されるドキュメントに記載されていません。OCIリージョン間のディザスタ・リカバリのためにOracle E-Business Suiteをインストール、構成およびデプロイする方法は、byOracle E-Business Suiteエンジニアリングが考案および記述されており、このチュートリアルまたはOCI Full Stack DRから完全に独立しています。
Oracle E-Business Suite組織は、OCI Full Stack DRに精通しておらず、OCI Full Stack DRの外部で手動で実行されたディザスタ・リカバリのためにOracle E-Business Suiteによって書かれたドキュメントに記載されているように、Oracle E-Business Suiteプロセスの問題の解決にのみ役立ちます。
Oracle E-Business Suiteによって文書化された手動のOracle E-Business Suiteプロセスに関する問題のトラブルシューティングは、Oracle E-Business Suiteのサポートの責任であり、OCI Full Stack DRとは独立して行われます。OCI Full Stack DRは、お客様またはOracle E-Business Suiteサポートが文書化されたOracle E-Business Suiteディザスタ・リカバリ・プロセスを手動で実行することを妨げません。したがって、Oracle E-Business Suiteのサポートは、OCI Full Stack DRを必要とせずに、手動によるディザスタ・リカバリ・プロセスの問題を解決します。
ただし、Oracle E-Business Suiteによって文書化された手動リカバリ・プロセスをウォークスルーすると、OCI Full Stack DR保護グループは使用不能な状態のままになる可能性があります。これは、Oracle E-Business SuiteでOCI Full Stack DRを使用して操作を再開する前にリセットする必要があります。OCI Full Stack DRサポートは、Oracle E-Business Suiteサポートが手動によるトラブルシューティングおよび解決を完了した後に、DR保護グループをリセットするのに役立ちます。
OCI Full Stack DRの開始
OCI Full Stack DRサポートは、このチュートリアルで説明するステップおよびタスクで発生した問題に関する最初の窓口です。OCI Full Stack DRサポートは、問題を分離し、問題を解決する最適なサポート組織を決定します。
- OCI Full Stack DRサポートは、次のことを担当します。
- DR操作中に生成されたエラー・メッセージの意味と原因をお客様が理解できるよう支援します。
- DR操作中にフル・スタックDRがリソースを管理できないようにするIAMポリシーの問題をお客様が解決するのに役立ちます。
- DR保護グループの作成または管理に問題があります。
- Oracle E-Business SuiteまたはEMEA Cloud Solutionsチームが提供するカスタム自動化を正しく呼び出すためのDR計画の作成、実行または失敗に関する問題。
- このチュートリアルに含まれていないカスタム・スクリプトに関する問題のトラブルシューティングと解決は、お客様が担当します。
- OCI Full Stack DRサポートは、Oracle E-Business Suite自体に直接関連する問題に対するOracle E-Business SuiteサポートのSRをオープンします。お客様は、Oracle E-Business Suiteサポートに直接連携して、Oracle E-Business Suiteの問題を解決します。Oracle E-Business Suiteは、次のことを担当します。
- Oracle E-Business Suiteによって記述および管理されるMy Oracle Support (MOS)ドキュメントの問題。
- Oracle E-Business Suiteによって顧客に提供されたスクリプトに関する問題。
- Oracle E-Business Suiteに関するデータベース上の問題。
- Oracle E-Business Suiteに関連するアプリケーションの問題。
- OCI Full Stack DRの外部で手動でOracle E-Business Suiteをリカバリするための文書化されたOracle E-Business Suiteプロセスの問題。
- OCI Full Stack DRサポートは、このチュートリアルで説明されているスクリプトまたはプロセスに直接関連する問題について、適切なOracle Cloud Solutions内部のチームにSRをオープンします。お客様は、このチュートリアルの問題を解決するために、Oracle Cloud Solutionsチームと直接連携します。Oracle Cloud Solutionsチームは、次のことを担当します。
- クラウド・ソリューション・チームが提供するカスタム・スクリプトに関する問題。
- このチュートリアルで説明するプロセス全体の問題。
サポート・リクエストを開く方法
OCIコンソールを使用して、OCI Full Stack DRサポートのサポート・リクエストを開きます。このプロセスを開始する前に、このチュートリアルの一部として作成したDR保護グループがブラウザ・コンテキストに表示されていることを確認します。
- ブラウザ・コンテキストが適切なDR保護グループに設定されていることを確認します。
- OCIコンソールでライフ・サーバーを選択します。
- 「サポート・リクエストの作成」を選択します。
図5: OCIコンソールのヘルプ・ツールを使用して、サービス・リクエストを開きます。
図6:サポート・リクエストは「ヘルプのリクエスト」ボタンを使用して開く必要があります。
関連リンク
確認
- 著者 - Chandra Dharanikota (Oracle Apps to OCIスペシャリスト、Oracle Technology Cloud Engineering、EMEA)、Suraj Ramesh - (フル・スタックDR、テクニカル・レビュー担当者)
その他の学習リソース
docs.oracle.com/learnで他のラボを確認するか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスして、Oracle Learning Explorerになります。
製品ドキュメントについては、Oracle Help Centerを参照してください。
Automate Recovery for Multi-Node Oracle E-Business Suite Using OCI Full Stack Disaster Recovery
G35485-02
Copyright ©2025, Oracle and/or its affiliates.