ノート:

OCI Full Stack Disaster Recoveryを使用してOracle Integrationのリカバリを自動化

パート1: 概要

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

Oracle Integrationは、クラウドとオンプレミスのアプリケーションを接続し、ビジネス・プロセスを自動化し、ビジネス・メトリック分析を通じてビジネスに関するインサイトを取得し、Webおよびモバイル・アプリケーションを開発できる、セキュアな統合プラットフォームです。Oracle Integrationは、サービス・レベル合意(SLA)によって管理されるOCIリージョンで使用できます。このチュートリアルでは、Oracle Integration用に、特にOracle Integrationの統合機能用に、リージョン間の顧客管理ディザスタ・リカバリ・ソリューションを構築する手順について説明します。

Oracle Integrationは、Oracle Integration自体がコンピュート、ストレージまたはデータベースをOCIユーザーに公開しないため、OCI Full Stack DRでネイティブに管理できるものではないマネージドOCI Platform as a Service (PaaS)製品です。ただし、OCI Full Stack DRは、Oracle Integrationなどの特定のサービスのエンジニアリング・チームがOCIリージョン間のディザスタ・リカバリのためにサービスをプロビジョニング、構成およびリカバリする方法を記述しているかぎり、PaaSオファリングのリカバリを自動化できます。Oracle Integrationエンジニアリング・チームは、Oracle Integration Generation 2のディザスタ・リカバリ・ソリューションの構成に、Oracle Integrationを手動でプロビジョニング、構成およびリカバリする方法について説明します。

OCI Full Stack Disaster Recovery(DR)は、Oracle Integrationのプロビジョニングや構成には使用されません。OCI Full Stack DRを使用する前に、Oracle Integration Generation 2のディザスタ・リカバリ・ソリューションの構成のステップバイステップの手順に従って、リージョン間のDRに対してOracle Integrationをプロビジョニングおよび構成する必要があります。

このドキュメントのOracle Integrationエンジニアリングによって規定されている手動フェイルオーバー・ステップ: OCIフル・スタックDRを使用する前に、Oracle Integration Generation 2のディザスタ・リカバリ・ソリューションの構成もスイッチオーバーおよびスイッチバックについて正常にテストする必要があります。

通常、Oracle Integrationは大規模なシステムの一部です。

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

このチュートリアルは、Oracle Integrationのみがドキュメント全体を通じて表示および説明され、単純なものに保たれるという事実では珍しくありません。通常、Oracle Integrationは、単一のOCI Full Stack DR保護グループと一連のDR計画に多数の異なるサービスとアプリケーションを含む、はるかに大規模で複雑なビジネス・システムの1つの小さな部分にすぎません。PeopleSoft、WebLogicサーバー、Oracle Analytics Cloudなど、他のアプリケーションやサービスについても同様のOracle Help Center (OHC)チュートリアルに従う可能性が高くなります。

ノート:このチュートリアルのステップは、Oracle Integration Generation 2を使用してテストされました。このチュートリアルでは、Oracle Integration Generation 2のアプリケーション統合機能にDRを実装する方法を示します。これは、移動部品や部品を多すぎてリーダーを圧倒したくないためです。

増分実装に関する注意事項

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

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

リカバリの動作

Oracle Integrationのリカバリ・ソリューションでは、フェイルオーバーやスイッチオーバーなどのリカバリ操作中に一連のカスタムbashスクリプトを実行するために、OCI Full Stack DRが必要です。このチュートリアルで参照されるスクリプトは、Oracle Integration Specialistsチームによって提供され、このOracle Integration DRソリューション専用にカスタマイズされたGitHubリポジトリで使用できます。bashスクリプトは、リカバリ操作中にOCI Full Stack DRが管理するアプリケーション・スタックの一部であるコンピュート・インスタンスにダウンロードされます。

一般的なガイダンスのために、次のスクリプトが用意されています。独自のスクリプトを使用するか、会社のポリシーおよびセキュリティ要件に従ってスクリプトをカスタマイズできます。OCI CLIをインストールし、スクリプトを使用するように資格証明を構成する必要があります。

また、プライマリ・インスタンスが最新のスケジュール済パラメータで更新されるようにするには、integrations.jsonファイルが、すべての統合名とともにバージョン詳細とともにintegration_parameters.jsonファイルとともに更新されていることを確認します。このファイルは、すべてのスケジュール済統合の最新のスケジュール済パラメータ値で更新される必要があります。優先CI/CDプロセスを使用してこれを実現できます。

このチュートリアルでは、スクリプトをダウンロードする方法と、後のステップでスクリプトを使用する方法を説明します。このチュートリアルでは、チュートリアルにOracle Integration以外が含まれていないため、次のオプション2を使用してbashスクリプトをホストします。

スクリプトをホストするためのオプション1

Oracle Integrationは、ほとんどの場合、Oracle E-Business Suite、PeopleSoft、JD Edwards Enterpriseなどのアプリケーションを含む、より大規模で複雑なビジネス・システムの一部であり、その他のデータベース、コンピュート・インスタンスおよび自家製アプリケーションを含みます。この場合、スクリプトをホストするために、すでにビジネス・システムの一部である移動可能なコンピュート・インスタンスのいずれかを選択します。選択したコンピュート・インスタンスは、Oracle Linuxがインストールされているどのインスタンスでもかまいません。おそらく、アプリケーション・サーバーや管理サーバーなどの他の目的に役立つ既存のVMです。

このチュートリアルでは、この特定のコンピュート・インスタンスを「制御ノード」または「DRノード」と呼びますが、実際にはアプリケーション・スタック内の別の目的を満たしています。

スクリプトをホストするためのオプション2

これが、Oracle Integrationがリカバリ操作中にOCI Full Stack DRが管理する唯一のアプリケーション・サービスとなる異常な状況である場合、スクリプトをホストするためだけにコンピュート・インスタンスを作成する必要があります。

通常、OCI Full Stack DRでは、リカバリ操作を自動化するために特別な管理サーバーは必要ありません。ただし、Oracle IntegrationはOCI Full Stack DRでネイティブに管理できるものではないため、この場合、特殊な管理サーバーとして機能するコンピュート・インスタンスを作成します。専用の管理サーバーは、このドキュメント全体を通して「制御ノード」または「DRノード」として表示されます。制御ノードの目的は、リカバリ操作中にカスタム・スクリプトが存在し、OCI Full Stack DRによってコールできるサーバーとして機能することです。このチュートリアルでは、制御ノードにインストールされているスクリプトをコールするDR計画の一部として、ユーザー定義のカスタムDR計画グループおよびステップを作成する方法について説明します。

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

図に示すように、Oracle Integration Generation 2 DRアーキテクチャには、プライマリとセカンダリと区別され、同時に動作する2つのOracle Integrationインスタンスが含まれています。ただし、トラフィックは一度に1つのインスタンスにのみ転送されます。最初は、トラフィックがプライマリ・インスタンスに流れます。プライマリ・インスタンスが使用できなくなった場合、トラフィックをセカンダリ・インスタンスにリダイレクトするようにDNSレコードが調整されます。

oci-arch-oracle-integration.svg
図1: Oracle Integration DRリファレンス・アーキテクチャ

インスタンスがプロビジョニングされたら、メタデータをプライマリ・インスタンスからスタンバイ・インスタンスにエクスポートします。これを行うには、REST APIを使用するか、Oracle Integration UIを使用してメタデータをエクスポートおよびインポートします。この最初のメタデータの1回かぎりの移行が完了したら、CICDを使用してインスタンス間でメタデータの同期を維持する必要があります。Jenkinsまたは同様のツールを使用して、インスタンスのCICDを実装し、メタデータを同期させることができます。OCI ComputeインスタンスをJenkins CIサーバーおよびCDハブとして使用することもできます。

OCI Full Stack DRを導入する前に、Oracle IntegrationをOCIリージョン全体でディザスタ・リカバリ(DR)用にプロビジョニングおよび構成する必要があります。OCI Full Stack DRを使用してスイッチオーバー/フェイルオーバー・プロセスを自動化する前に、Oracle Integrationエンジニアリングに記載されているようにOracle Integrationをスイッチオーバーする手動ステップをテストして正しく動作することが非常に重要です。

プロセス全体について理解する

フル・スタック・ディザスタ・リカバリ・エンジニアリング・チームは、このチュートリアルでプロセス・フロー全体を理解するための一連のコンパニオン・ビデオを作成しました。これらのビデオは、次のリンクを使用してアクセスできるYouTubeのOCI Full Stack DR Oracle Integrationプレイリストの一部です:

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

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

目的

このチュートリアルでは、OCI Full Stack DRを使用してOracle Integrationのリカバリを自動化する方法を説明する次のステップについて説明します。

  1. タスク1: OCIリージョン間でのDRのためのOracle Integrationのデプロイ
    1. Oracle Integration DR制御ノードの準備
    2. DR制御ノードへのカスタム・スクリプトのダウンロード
    3. 2つのOCIリージョンにOracle Integration for DRを手動でインストールしてデプロイ
    4. 目的のリージョン1からリージョン2までのすべてのリカバリ・ステップを手動でテストします
    5. 目的のリージョン2からリージョン1までのすべてのリカバリ・ステップを手動でテストします
  2. タスク2: OCI Full Stack DRの準備
    1. OCI Full Stack DRのIAMポリシーの作成
    2. 他のOCIサービスのIAMポリシーの作成
    3. ログのオブジェクト・ストレージ・バケットの作成
  3. タスク3: DR保護グループ(DRPG)の作成
  4. タスク4: リージョン1 DRPGへのメンバーの追加
  5. タスク5: リージョン2でのDR計画の作成(フェニックス)
    1. スイッチオーバー・プランの作成
    2. フェイルオーバー計画の作成
  6. タスク6: リージョン2 (フェニックス)でのスイッチオーバー・プランのカスタマイズ
  7. タスク7: リージョン2 (フェニックス)でのフェイルオーバー計画のカスタマイズ
  8. タスク8: リージョン2でのスイッチオーバー・プランの実行(フェニックス)
  9. タスク9: リージョン1での基本的なDR計画の作成(アッシュバーン)
    1. スイッチオーバー・プランの作成
    2. フェイルオーバー計画の作成
  10. タスク10: リージョン1でのスイッチオーバー・プランのカスタマイズ(アッシュバーン)
  11. タスク11: リージョン1のフェイルオーバー計画のカスタマイズ(アッシュバーン)

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

地域

区分

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

Oracle Integration DR制御ノード

DR制御ノードは、Oracle Integrationをリカバリするために特定のタスクを実行するカスタムbashスクリプトをホストするように指定するコンピュート・インスタンスです。スクリプトは、リカバリ操作中にOCI Full Stack DRによってコールされます。このチュートリアルでは、ステップ6、7、10および11でスクリプトをOCI Full Stack DRに追加する方法について説明します。

前提条件

OCI Full Stack DRの操作を開始する前に、両方のリージョンでディザスタ・リカバリのためにOracle Integrationをデプロイする必要があります。これについては、次のタスク1で説明します。

タスク1: ディザスタ・リカバリのためのOracle Integrationのデプロイ

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

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

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

オプション1: スタンドアロン・アプリケーションとしてのOracle Integration

このチュートリアルでは、Oracle Integrationがスタンドアロン・サービスであると想定しているため、リージョン1でOracle Linuxを使用してコンピュート・インスタンスを作成します。カスタムbashスクリプトのホストにのみ使用されるため、Oracle Linuxでは最低コスト・シェイプを使用します。このロールを満たす専用の特殊なコンピュート・インスタンスの必要性は異例です。オプション2は、大部分の組織にとって最も一般的なシナリオです。

専用コンピュート・インスタンスは、後のステップでリージョン1のDR保護グループのメンバーとして追加されます。

オプション2: アプリケーション・スタックの一部としてOracle Integration

リージョン1のOCI Full Stack DRによって管理されているOracleまたはOracle以外のアプリケーションの一部である既存の任意の移動可能コンピュートを使用できます。これは、このチュートリアルでDR制御ノードを参照するたびに、DR制御ノードの役割を果たします。

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

オプション3: 複数のPaaSオファリングを持つアプリケーション・スタックの一部としてOracle Integration

ビジネス・システムには、Oracle HTTP Server (OHS)、Oracle IntegrationおよびOracle Data Integrator (ODI)もあります。この場合、様々なPaaSサービスのDRリカバリ・スクリプトをホストするためにオプション1を使用する場合と同様に、特殊なコンピュート・インスタンスを作成することを検討できます。

タスク1.2: ボリューム・グループがリージョン2にレプリケートされていることの確認

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

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

タスク1.3: DR制御ノードへのbashスクリプトのダウンロード

このOracle Integration DRソリューション専用に作成されたgithubからカスタムbashスクリプトをダウンロードします。次に示すスクリプトは、Oracle IntegrationのDR制御ノードとして機能するコンピュート・インスタンス上の任意のサブディレクトリにコピーする必要があります

上のリンクは、GitHubリポジトリに解決されます。

  1. これは、bashスクリプトがGitHubにあるリポジトリ・パスを示しています。
  2. これは、bashスクリプトを含むリポジトリを示しています。

github-scripts.png
図2-4: Oracle Integration用のbashスクリプトを含むgithubリポジトリのスクリーンショット

タスク1.4: DR用のOracle Integrationのデプロイ

Oracle Integrationエンジニアリング・チームが提供するステップバイステップの手順を使用して、OCIリージョン間でDRにOracle Integrationをデプロイします。

タスク1.5: Oracle Integrationのリカバリの手動テスト

手動リカバリ・ステップの確認はベスト・プラクティスです。Oracle Integrationのディザスタ・リカバリ構成に記載されているOracle Integrationをリカバリする手動ステップは、OCI Full Stack DRを使用する前に成功する必要があります。

タスク1.6: 次のステップ

次の要件が完了したら、このドキュメントに戻ってOCI Full Stack DRの操作を開始します。

  1. Oracle Integration for DRを2つの目的のOCIリージョンに手動でデプロイします。
  2. リージョン1 (アッシュバーン)からリージョン2 (フェニックス)までのすべてのリカバリ・ステップを手動でテストします。
  3. リージョン2 (フェニックス)からリージョン1 (アッシュバーン)までのすべてのリカバリ・ステップを手動でテストします。

タスク2: OCI Full Stack DRの準備

OCI Full Stack DRは、このステップのどの部分にも含まれていません。次のステップでは、OCI Full Stack DRによる自動リカバリのために、テナンシ、コンパートメント、OCIサービスおよびOracle Integrationを準備します。

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

次のドキュメントで説明するように、フル・スタック・ディザスタ・リカバリに必要なOCI IAMポリシーを構成します。

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

OCI Full Stack DRには、コンピュート、ネットワーキング、ストレージ、ボールト、データベース、その他のサービスなどの他の主要なOCIサービスを制御および管理する機能が必要です。次のドキュメントの説明に従って、他のサービスに必要なOCI IAMポリシーを構成します。

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

ノート:既存のDR保護グループにOracle Integrationを追加する場合は、タスク2.3を完全にスキップします。

OCI Object Storageバケットをプライマリ・リージョンとスタンバイ・リージョンに作成し、リカバリ操作中にOCI Full Stack DRによって生成されたログを格納します: Object Storage。

タスク2.3.1: OCIオブジェクト・ストレージへの移動

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

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

oss-bucket-nav-iad.svg
図2-1:オブジェクト・ストレージへの移動

タスク2.3.2: リージョン1のOCIストレージ・バケット

リージョン1にオブジェクト・ストレージ・バケットを作成します。バケットは、後のステップでリージョン1のDR保護グループに割り当てられます。

  1. OIC関連リソースを含むコンパートメントを選択します。
  2. 「Create Bucket (バケットの作成)」を選択します。
  3. バケットにわかりやすい名前を付けて、そのバケットがどのアプリケーションおよび用途に役立つかを簡単に特定します。名前の一部としてリージョンを含める理由はありません。たとえば、この名前は、OICのDR操作に関連するOCI Full Stack DRログに使用されることを示します。
  4. 階層および暗号化にデフォルト値を使用します。
  5. 「Create (作成)」を選択してバケットを作成します。

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

タスク2.3.3: リージョン2のOCIストレージ・バケット

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

  1. コンテキストをリージョン2に変更します。
  2. リージョン2のOIC関連リソースを含むコンパートメントを選択します。
  3. リージョン1のバケットに割り当てられたものと同じ名前を使用します。これにより、後のステップで簡単に識別できます。
  4. 「Create (作成)」を選択してバケットを作成します。

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

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

ノート: Oracle Integrationを既存のDR保護グループに追加する場合は、タスク3を完全にスキップします。

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

タスク3.1: DR保護グループへの移動

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

  1. OCIリージョン・コンテキストがリージョン1 (アッシュバーン)に設定されていることを確認します。
  2. 「Migration & Disaster Recovery」を選択します。
  3. 「DR Protection Groups」を選択します。

drpg-create-nav-iad.svg
図3-1: DR保護グループへの移動

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

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

  1. DRPGを作成するコンパートメントを選択します。これは、Oracle Integrationリソースが存在するコンパートメントにすることも、この場合は、様々なビジネス・システムのDRPGを含むリポジトリとして機能するコンパートメントにすることもできます。
  2. 「Create DR protection group」を選択してダイアログを開きます。

drpg-create-begin-iad.png
図3-2:リージョン1でのDR保護グループの作成を開始します

次の図3-3に示すように、ログの名前とオブジェクト・ストレージ・バケットを追加します。

  1. DRPGにはわかりやすい単純な名前を使用します。この例は、ビジネス・システムの名前とリージョンを示しています。
  2. リージョン1のタスク2で作成したオブジェクト・ストレージ・バケットを選択します。

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

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

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

  1. OCIリージョン・コンテキストをリージョン2に変更します。
  2. DRPGを作成するコンパートメントを選択します。これは、Oracle Integrationリソースが存在するコンパートメントにすることも、この場合は、様々なビジネス・システムのDRPGを含むリポジトリとして機能するコンパートメントにすることもできます。
  3. 「Create DR protection group」を選択してダイアログを開きます。

drpg-create-begin-phx.png
図3-4:リージョン2でのDR保護グループの作成を開始します

次の図3-5に示すように、ログの名前とオブジェクト・ストレージ・バケットを追加します。

  1. DRPGにはわかりやすい単純な名前を使用します。この例は、ビジネス・システムの名前とリージョンを示しています。
  2. リージョン2のタスク2で作成したオブジェクト・ストレージ・バケットを選択します

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

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

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

タスク3.4.1: アソシエーションの開始

  1. OCIリージョン・コンテキストがリージョン1 (アッシュバーン)に設定されていることを確認します。
  2. 「Associate」を選択してプロセスを開始します。

drpg-assoc-begin-iad.png
図3-6: DRPGアソシエーションの開始

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

次の図3-7に示すように、パラメータを指定します。

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

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

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

アソシエーションが完了すると、OCI Full Stack DRに図3-8のようなものが表示されます。

  1. 現在のプライマリ・ピアDRPGはアッシュバーン(リージョン1)です。
  2. 現在のスタンバイ・ピアのDRPGはフェニックス(リージョン2)です。

drpg-assoc-completed-iad.png
図3-8:個々のDRPGの観点からのピア関係の表示

次の図3-9に示すように、すべてのDR保護グループを示すグローバルな観点からコンテキスト/ビューが参照されるたびに、同じ情報を見つけることができます。

  1. 現在のプライマリ・ピアDRPGはアッシュバーン(リージョン1)です。
  2. 現在のスタンバイ・ピアのDRPGはフェニックス(リージョン2)です。

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

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

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

DR制御ノードをメンバーとしてプライマリDR保護グループに追加します。DR制御ノードは、Oracle Integrationを制御するために作成したコンピュート・インスタンスか、OCI Full Stack DRで管理するアプリケーション・スタックの一部であるコンピュート・インスタンスです。

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

  1. DR制御ノード、
  2. DR制御ノードのブートボリュームを含むボリュームグループ。

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

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

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

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

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

次の図4-2に示すように、DR制御ノードのコンピュート・インスタンスを追加します。

  1. DR計画に関する警告を確認します。
  2. 「Compute as member resource type」を選択します。
  3. DR制御ノードを使用するコンピュート・インスタンスを選択します。
  4. 移動インスタンスを選択します。
  5. リカバリ中にリージョン2のVNICに割り当てるVCNおよびサブネットをOCIフル・スタックDRに伝えます。図4-2に、単一のVNICを示します。OCI Full Stack DRは、どのリージョンにいくつのVNICがあるか、またはそれらの構成方法を気にしません。要件に合ったものは何でも指定します。

drpg-add-compute - iad.png
図4-2: DR制御ノードの追加に必要なパラメータ

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

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

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

drpg-add-vg-iad.png
図4-3: DR制御ノードのブート・ボリューム・グループを追加するために必要なパラメータ

タスク4.1.3: リージョン1のメンバー・リソースの確認

次の図4-5に示すように、リージョン1のDRPGには少なくとも2つのメンバー・リソースが必要です。メンバー・リソースの名前は異なります。

  1. OIC DR制御ノードを実行するように指定したコンピュート・インスタンスの移動可能なコンピュート・インスタンスおよびブロック・ボリューム・グループ。

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

Oracle IntegrationスクリプトをホストするためにDRノードとしてコンピュート・インスタンスを移動しているため、スタンバイDR保護グループにメンバーを追加する必要はありません

タスク5: リージョン2での基本的なDR計画の作成(フェニックス)

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

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

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

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

タスク5.1: DR計画の作成の開始

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

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

プラン作成-phx-nav.png
図5-1:リージョン2での基本的なDR計画の作成を開始する方法

タスク5.1.1: スイッチオーバー・プランの作成

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

  1. スイッチオーバー・プランの名前をシンプルでわかりやすいものにします。名前はできるだけ短くする必要がありますが、危機時の混乱や人的ミスを軽減するために一目でわかりやすくする必要があります。
  2. プラン・タイプを選択します。この執筆時点では4つのプラン・タイプしかありません。

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

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

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

  1. フェイルオーバー計画の名前をシンプルでわかりやすいものにします。名前はできるだけ短くする必要がありますが、危機時の混乱や人的ミスを軽減するために一目でわかりやすくする必要があります。
  2. プラン・タイプを選択します。この作成時には2つのプラン・タイプしかありません。

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

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

プラン作成-phx-completed.png
図5-4:続行する前にリージョン2に存在する必要がある2つの基本的なDR計画を表示

タスク6: リージョン2 (フェニックス)でのスイッチオーバー・プランのカスタマイズ

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

  1. リージョン1からリージョン2へのスケジュール済パラメータの同期
  2. リージョン2の関連統合のアクティブ化
  3. リージョン2でスケジュールされた統合を開始
  4. リージョン2でDNSレコードを更新
  5. リージョン1でのスケジュール済統合の非アクティブ化

タスク6.1: スイッチオーバー・プランの選択

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

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

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

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

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

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

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

plan-custom-so-phx-disabled-show.png
図6-2:プラン・グループはデフォルトで無効になっています。

使用不可のプラン・グループが使用可能な場合の動作は次のとおりです。

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

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

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

計画グループを有効にします。

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

plan-custom-so-phx-enable-terminate-vm.png
図6-3:コンピュート・インスタンスの終了を有効にする方法

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

計画グループを有効にします。

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

plan-custom-so-phx-enable-terminate-vg.png
図6-4:ボリューム・グループの終了を有効にする方法

タスク6.3: スケジュール済パラメータをリージョン1からリージョン2に同期するプラン・グループの作成

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

最初のユーザー定義プラン・グループは、スケジュール済パラメータをリージョン1からリージョンに同期します。この計画グループには、タスク1.4でDR制御ノードにダウンロードされたoic-sync-schedule-parameters.sh bashスクリプトをコールする単一のステップが含まれます。

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

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

  1. 「Add group」をクリックして開始します。

plan-custom-so-phx-grp1-add.png
図6-5:スケジュール済パラメータを同期するためのプラン・グループの追加を開始します。

タスク6.3.2: プラン・グループ名、順序およびステップの追加の指定

DR計画グループには、すべてパラレルに実行される多数のステップを含めることができます。スケジュール済パラメータを同期するbashスクリプトを実行するステップを1つ追加するだけです。

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

plan-custom-so-phx-grp1-name.svg
図6-6:プラン・グループを作成し、スケジュール済パラメータを同期するためのステップを追加するパラメータ

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

「計画グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、スケジュール済パラメータはリージョン1からリージョン2に同期されます。

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

  1. このステップが実行するタスクを説明するわかりやすい名前。
  2. スイッチオーバー中にDR制御ノードが実行される場所ではなく、DR制御ノードが現在実行されているリージョンを常に選択します。OCI Full Stack DRは、VMが実行されている場所を追跡するため、今すぐその場所を指定する必要があります。この場合、DR制御ノードはリージョン1 (アッシュバーン)で実行されています。
  3. コンピュート・インスタンスでスクリプトが検出されることをOCI Full Stack DRに通知するには、「ローカル・スクリプトの実行」を選択します。bashスクリプトは、タスク1.3のDR制御ノードにダウンロードされました。
  4. DR制御ノードを含む正しいコンパートメント(任意のコンパートメント)を選択します。DR制御ノードとして指定されたコンピュート・インスタンスを選択します(このプロジェクト/チュートリアル用に作成されたアプリケーション・サーバーまたはVMの場合があります)。
  5. oic-sync-schedule-parameters.shスクリプトをインストールした絶対パスをDR制御ノードに貼り付けます。パラメータとしてPHXを追加します。これは、スケジュール済パラメータを同期するターゲット・リージョンです。異なるOCIリージョンおよび更新スクリプトを使用している場合は、正しいリージョン・パラメータを指定する必要があります。
  6. スクリプトを実行するユーザーとして opcを指定します。
  7. スクリプトがスケジュール済パラメータの同期に失敗した場合、DR計画は停止します。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRは、問題の修正後にスイッチオーバー計画の実行を継続する機会を提供します。
  8. OCI Full Stack DRで障害を宣言する前のデフォルト値は1時間です。この値は、30分に変更することも、より現実的なタイムアウト値であると感じるものに変更することもできます。
  9. 「ステップの追加」をクリックして、このステップを計画グループに追加します。

plan-custom-so-phx-grp1-step.png
図6-7:同期スケジュール済パラメータのプラン・ステップを作成するためのパラメータ

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

次の図6-8に示すように、同期スケジュール済パラメータを停止するステップがDR計画グループに追加されました。

  1. 追加された計画ステップが表示されます。DR計画グループにステップを追加することは可能ですが、この計画グループには、スケジュール済パラメータを同期するステップのみが含まれます。
  2. 「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。

plan-custom-so-phx-grp1-finish.png
図6-8:スケジュール済パラメータを同期するためのプラン・グループおよびステップの追加の確定

タスク6.4: スタンバイで関連する統合をアクティブ化するプラン・グループの作成

2番目のユーザー定義プラン・グループは、スタンバイ・リージョン2でDR制御ノードが起動された後、スタンバイで関連する統合をアクティブ化します。この計画グループには、タスク1.3でDR制御ノードにダウンロードされたoic-integration-switch.sh bashスクリプトをコールする単一のステップが含まれます。

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

以前と同様に、「グループの追加」をクリックして開始します。

plan-custom-so-phx-grp2-add.png
図6-9:スタンバイで関連する統合をアクティブ化するための計画グループの追加を開始します

タスク6.4.2: プラン・グループ名、順序およびステップの追加の指定

DR計画グループを作成して、関連する統合をスタンバイでアクティブ化します。

  1. プラン・グループにわかりやすい名前を付けます。
  2. 計画グループをDR計画に挿入する位置を選択します。この場合、リージョン2でDR制御ノードのレプリケート・バージョンを起動する組込み計画グループの後に、ユーザー定義計画グループを挿入します。
  3. 組込みの「コンピュート・インスタンスの起動(スタンバイ)」プラン・グループを選択します
  4. 「ステップの追加」をクリックしてダイアログを開き、スタンバイで関連する統合をアクティブ化するスクリプトを指定します。

plan-custom-so-phx-grp2-name.png
図6-10:計画グループを作成し、スタンバイで関連する統合をアクティブ化するステップを追加するパラメータ

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

「計画グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、関連する統合がリージョン2でアクティブ化されます。

次の図6-11に示す項目を除き、このステップの項目はすべてタスク6.3.3と同じです。

  1. このステップが実行するタスクを説明するわかりやすい名前。
  2. DR制御ノードにoic-integration-switch.shスクリプトをインストールした絶対パスに貼り付けます。最初のパラメータとしてactivateを追加し、second.Thisが関連する統合をアクティブ化するターゲット・リージョンであるため、PHXを追加します。異なるOCIリージョンおよび更新スクリプトを使用している場合は、正しいリージョン・パラメータを指定する必要があります。
  3. 「ステップの追加」をクリックして、このステップを計画グループに追加します。

plan-custom-so-phx-grp2-step.png
図6-11:スタンバイで関連する統合をアクティブ化するためのプラン・ステップを作成するパラメータ

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

次の図6-12に示すように、スタンバイで関連する統合をアクティブ化するステップがDR計画グループに追加されました。

  1. 追加された計画ステップが表示されます。
  2. 「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。

plan-custom-so-phx-grp2-finish.png
図6-12:スタンバイで関連する統合をアクティブ化するためのプラン・グループおよびステップの追加の確定

タスク6.5: リージョン2でスケジュール済統合を開始するプラン・グループの作成

3番目のユーザー定義プラン・グループは、スタンバイ・リージョン2でDR制御ノードが起動された後、スタンバイでスケジュールされた統合を開始します。この計画グループには、タスク1.3でDR制御ノードにダウンロードされたoic-integration-schedule.sh bashスクリプトをコールする単一のステップが含まれます。

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

以前と同様に、「グループの追加」をクリックして開始します。

plan-custom-so-phx-grp3-add.png
図6-13:スタンバイでスケジュール済統合を開始するためのプラン・グループの追加を開始します

タスク6.5.2: プラン・グループ名、順序およびステップの追加の指定

スタンバイ・リージョン2でスケジュールされた統合を開始するDR計画グループを作成します。

  1. プラン・グループにわかりやすい名前を付けます。
  2. 計画グループをDR計画に挿入する位置を選択します。この場合、関連する統合をアクティブ化するために、前のタスクで作成したユーザー定義プラン・グループの後にユーザー定義プラン・グループを挿入します。
  3. 組込みの「スタンバイでの関連統合のアクティブ化」プラン・グループを選択します
  4. 「ステップの追加」をクリックしてダイアログを開き、スタンバイでスケジュール済統合を開始するスクリプトを指定します。

plan-custom-so-phx-grp3-name.png
図6-14:計画グループを作成し、スタンバイでスケジュール済統合を開始するステップを追加するパラメータ

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

「計画グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、スケジュールされた統合はスタンバイ・リージョン2で開始されます。

次の図6-15に示す項目を除き、このタスクのすべてはタスク6.3.3と同じです。

  1. このステップが実行するタスクを説明するわかりやすい名前。
  2. DR制御ノードにoic-integration-schedule.shスクリプトをインストールした絶対パスに貼り付けます。最初のパラメータとしてstart、2番目のパラメータとしてPHXを追加します。
  3. 「ステップの追加」をクリックして、このステップを計画グループに追加します。

plan-custom-so-phx-grp3-step.png
図6-15:スタンバイでスケジュール済統合を開始するプラン・ステップを作成するためのパラメータ

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

次の図6-16に示すように、スタンバイでスケジュール済統合を開始するステップがDR計画グループに追加されました。

  1. 追加された計画ステップが表示されます。
  2. 「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。

plan-custom-so-phx-grp3-finish.png
図6-16:プラン・グループの追加を確定し、スケジュールされた統合をスタンバイで開始

タスク6.6: リージョン2でDNSレコードを更新するプラン・グループの作成

4番目のユーザー定義プラン・グループは、スタンバイ・リージョン2でDR制御ノードが起動された後、スタンバイでDNSレコードを更新します。この計画グループには、タスク1.3でDR制御ノードにダウンロードされたdns_record_update.sh bashスクリプトをコールする単一のステップが含まれます。

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

以前と同様に、「グループの追加」をクリックして開始します。

plan-custom-so-phx-grp4-add.png
図6-17:スタンバイでDNSレコードを更新するプラン・グループの追加を開始します

タスク6.6.2: プラン・グループ名、順序およびステップの追加の指定

DR計画グループを作成して、DNSレコードをリージョン2に更新します。

  1. プラン・グループにわかりやすい名前を付けます。
  2. 計画グループをDR計画に挿入する位置を選択します。この場合、組込みプラン・グループの後にユーザー定義プラン・グループを挿入して、スタンバイでスケジュール済統合を開始します
  3. 組込みの「スケジュールされた統合をスタンバイで開始」プラン・グループを選択します。
  4. 「ステップの追加」をクリックしてダイアログを開き、スタンバイでDNSレコードを更新するスクリプトを指定します。

plan-custom-so-phx-grp4-name.png
図6-18:計画グループを作成し、スタンバイでDNSレコードを更新するステップを追加するためのパラメータ

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

「計画グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、スタンバイでDNSレコードが更新されます。

次の図6-19に示す項目を除き、このタスクのすべてはタスク6.3.3と同じです。

  1. このステップが実行するタスクを説明するわかりやすい名前。
  2. DR制御ノードにdns_record_update.shスクリプトをインストールした絶対パスに貼り付けます。リージョン2 (この例ではPHX)のOCIリージョン・キーをパラメータとして追加します。
  3. 「ステップの追加」をクリックして、このステップを計画グループに追加します。

plan-custom-so-phx-grp4-step.png
図6-19:スタンバイでDNSレコードを更新するプラン・ステップを作成するためのパラメータ

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

次の図6-20に示すように、スタンバイでDNSレコードを更新するステップがDR計画グループに追加されました。

  1. 追加された計画ステップが表示されます。
  2. 「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。

plan-custom-so-phx-grp4-finish.png
図6-20:スタンバイでDNSレコードを更新するプラン・グループおよびステップの追加を確定します

タスク6.7: 地域1でスケジュール済統合を非アクティブ化するプラン・グループの作成

最終ユーザー定義プラン・グループは、DR制御ノードがスタンバイ・リージョン2で起動された後、リージョン1のスケジュール済統合を非アクティブ化します。この計画グループには、タスク1.3のDR制御ノードにダウンロードされたoic-integration-switch.shスクリプトをコールする単一のステップが含まれます。

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

以前と同様に、「グループの追加」をクリックして開始します。

plan-custom-so-phx-grp5-add.png
図6-21:プラン・グループの追加を開始し、リージョン1でスケジュール済統合を非アクティブ化します

タスク6.7.2: プラン・グループ名、順序およびステップの追加の指定

DR計画グループを作成して、リージョン1でスケジュール済統合を非アクティブ化します

  1. プラン・グループにわかりやすい名前を付けます。
  2. 計画グループをDR計画に挿入する位置を選択します。この場合、組込みプラン・グループの後にユーザー定義プラン・グループを挿入し、スタンバイでDNSレコードを更新します
  3. 組込みのスタンバイでのDNSレコードの更新プラン・グループを選択します。
  4. 「ステップの追加」をクリックしてダイアログを開き、リージョン1でスケジュール済統合を非アクティブ化するスクリプトを指定します

plan-custom-so-phx-grp5-name.png
図6-22:プラン・グループを作成し、リージョン1でスケジュール済統合を非アクティブ化するステップを追加するパラメータ

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

「計画グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、リージョン1でスケジュール済統合を非アクティブ化します

次の図6-23に示す項目を除き、このタスクのすべてはタスク6.3.3と同じです。

  1. このステップが実行するタスクを説明するわかりやすい名前。
  2. DR制御ノードにoic-integration-switch.shスクリプトをインストールした絶対パスに貼り付けます。リージョン1 (この例ではIAD)のOCIリージョン・キーをパラメータとして追加します。
  3. 「ステップの追加」をクリックして、このステップを計画グループに追加します。

plan-custom-so-phx-grp5-step.png
図6-23:リージョン1でスケジュール済統合を非アクティブ化するプラン・ステップを作成するためのパラメータ

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

次の図6-20に示すように、リージョン1でスケジュール済統合を非アクティブ化するステップがDR計画グループに追加されました。

  1. 追加された計画ステップが表示されます。
  2. 「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。

plan-custom-so-phx-grp5-finish.png
図6-24:リージョン1でスケジュール済統合を非アクティブ化するプラン・グループおよびステップの追加を確定します

スイッチオーバー計画には、次のスクリーンショットに示すように、Oracle Integrationの5つのDR計画グループが含まれるようになりました。保護グループにOracle Integrationとともに他のアプリケーションまたは他のOCIサービスが含まれている場合は、追加のプラン・グループがある可能性があります

プラン- カスタム-so-phx-completed.png
図6-25:スイッチオーバー・プランに追加された5つのユーザー定義プラン・グループの表示

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

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

  1. リージョン2の関連統合のアクティブ化
  2. リージョン2でスケジュール済パラメータを更新
  3. リージョン2でスケジュールされた統合を開始
  4. リージョン2でDNSレコードを更新

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

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

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

plan-custom-fo-phx-nav.png
図7-1:リージョン2でフェイルオーバー計画のカスタマイズを開始する方法

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

最初のユーザー定義プラン・グループは、リージョン2の関連統合をアクティブ化します。この計画グループには、タスク1.3でDR制御ノードにダウンロードされたoic-integration-switch.sh bashスクリプトをコールする単一のステップが含まれます。

  1. 「Add group」をクリックして開始します。

plan-custom-fo-phx-grp1-add.svg
図7-2:関連する統合をアクティブ化するためのプラン・グループの追加を開始します。

タスク7.2.1: プラン・グループ名、順序およびステップの追加の指定

DR計画グループには、すべてパラレルに実行される多数のステップを含めることができます。bashスクリプトを実行して関連する統合をアクティブ化するステップを1つ追加するだけです。

  1. プラン・グループにわかりやすい名前を付けます。
  2. 計画グループをDR計画に挿入する位置を選択します。この場合、リージョン2でレプリケートされたVMを起動する組込みプラン・グループの後に、ユーザー定義プラン・グループを挿入します
  3. 組込みの「コンピュート・インスタンスの起動(スタンバイ)」プラン・グループを選択します
  4. 「ステップの追加」をクリックしてダイアログを開き、関連する統合をアクティブ化するスクリプトを指定します

plan-custom-fo-phx-grp1-name.png
図7-3:計画グループを作成し、スタンバイで関連する統合をアクティブ化するステップを追加するパラメータ

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

「計画グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、次の図7-4に示すように、関連する統合がリージョン2でアクティブ化されます。

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

  1. このステップが実行するタスクを説明するわかりやすい名前。
  2. スクリプトが関連する統合のアクティブ化に失敗した場合、DR計画は停止します。これにより、誰でも問題があることを確認して修正できます。OCI Full Stack DRは、問題の修正後にスイッチオーバー計画の実行を継続する機会を提供します。
  3. OCI Full Stack DRで障害を宣言する前のデフォルト値は1時間です。この値は、30分に変更することも、より現実的なタイムアウト値であると感じるものに変更することもできます。
  4. スイッチオーバー中にDR制御ノードが実行される場所ではなく、DR制御ノードが現在実行されているリージョンを常に選択します。OCI Full Stack DRは、VMが実行されている場所を追跡するため、今すぐその場所を指定する必要があります。この場合、DR制御ノードはリージョン1 (アッシュバーン)で実行されています。
  5. コンピュート・インスタンスでスクリプトが検出されることをOCI Full Stack DRに通知するには、「ローカル・スクリプトの実行」を選択します。bashスクリプトは、タスク1.3のDR制御ノードにダウンロードされました。
  6. DR制御ノードを含む正しいコンパートメント(任意のコンパートメント)を選択します。DR制御ノードとして指定されたコンピュート・インスタンスを選択します(このプロジェクト/チュートリアル用に作成されたアプリケーション・サーバーまたはVMの場合があります)。
  7. DR制御ノードにoic-integration-switch.shスクリプトをインストールした絶対パスに貼り付けます。最初のパラメータとしてactivateを追加し、2番目のパラメータとしてPHXを追加します。
  8. スクリプトを実行するユーザーとして opcを指定します。
  9. 「ステップの追加」をクリックして、このステップを計画グループに追加します。

plan-custom-fo-phx-grp1-step.png
図7-4:スタンバイで関連する統合をアクティブ化するためのプラン・ステップを作成するパラメータ

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

次の図7-5に示すように、関連する統合をアクティブ化するステップがDR計画グループに追加されました。

  1. 追加された計画ステップが表示されます。
  2. 「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。

plan-custom-fo-phx-grp1-finish.png
図7-5:関連する統合をアクティブ化するためのプラン・グループおよびステップの追加の確定

タスク7.3: 地域2でスケジュール済パラメータを更新するプラン・グループの作成

2番目のユーザー定義計画グループは、スタンバイ・リージョン2でスケジュール済パラメータを更新します。この計画グループには、タスク1.3でDR制御ノードにダウンロードされたoic-update-parameters.sh bashスクリプトをコールする単一のステップが含まれます。

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

以前と同様に、「グループの追加」をクリックして開始します。

plan-custom-fo-phx-grp2-add.png
図7-6:スタンバイでスケジュール済パラメータを更新するプラン・グループの追加を開始します

タスク7.3.2: プラン・グループ名、順序およびステップの追加の指定

DR計画グループを作成して、リージョン2でスケジュール済パラメータを更新します。

  1. プラン・グループにわかりやすい名前を付けます。
  2. 計画グループをDR計画に挿入する位置を選択します。この場合、関連する統合をアクティブ化するために、前のタスクで作成したユーザー定義プラン・グループの後にユーザー定義プラン・グループを挿入します。
  3. 「スタンバイでの関連統合のアクティブ化」プラン・グループを選択します。
  4. 「ステップの追加」をクリックしてダイアログを開き、スタンバイでスケジュール済パラメータを更新するスクリプトを指定します。

plan-custom-fo-phx-grp2-name.png
図7-7:計画グループを作成し、スタンバイでスケジュール済パラメータを更新するステップを追加するパラメータ

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

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

次の図7-8に示す項目を除き、このタスクのすべてはタスク7.3.2と同じです。

  1. このステップが実行するタスクを説明するわかりやすい名前。
  2. DR制御ノードにoic-update-parameters.shスクリプトをインストールした絶対パスに貼り付けます。唯一のパラメータとしてPHXを追加します(この例ではPHX)。
  3. 「ステップの追加」をクリックして、このステップを計画グループに追加します。

plan-custom-fo-phx-grp2-step.png
図7-8:スタンバイでスケジュール済パラメータを更新するためのプラン・ステップを作成するパラメータ

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

次の図7-9に示すように、スタンバイでスケジュール済パラメータを更新するステップがDR計画グループに追加されました。

  1. 追加された計画ステップが表示されます。
  2. 「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。

plan-custom-fo-phx-grp2-finish.png
図7-9:スタンバイでのプラン・グループおよびステップ更新スケジュール済パラメータの追加の確定

タスク7.4: リージョン2でスケジュール済統合を開始するプラン・グループの作成

3番目のユーザー定義プラン・グループは、スタンバイ・リージョン2でDR制御ノードが起動された後、スタンバイでスケジュールされた統合を開始します。この計画グループには、タスク1.3でDR制御ノードにダウンロードされたoic-integration-schedule.sh bashスクリプトをコールする単一のステップが含まれます。

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

以前と同様に、「グループの追加」をクリックして開始します。

plan-custom-fo-phx-grp3-add.png
図7-10:スタンバイでスケジュール済統合を開始するためのプラン・グループの追加を開始します

タスク7.4.2: プラン・グループ名、順序およびステップの追加の指定

スタンバイでスケジュールされた統合を開始するためのDR計画グループの作成

  1. プラン・グループにわかりやすい名前を付けます。
  2. 計画グループをDR計画に挿入する位置を選択します。この場合、スタンバイ・プラン・グループの「更新」スケジュール済パラメータの後にユーザー定義プラン・グループを挿入します
  3. 組込みの「スタンバイでのスケジュール済パラメータの更新」プラン・グループを選択します。
  4. 「ステップの追加」をクリックしてダイアログを開き、スタンバイでスケジュール済統合を開始するスクリプトを指定します

plan-custom-fo-phx-grp3-name.png
図7-11:計画グループを作成し、スタンバイでスケジュール済統合を開始するステップを追加するパラメータ

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

「計画グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。

次の図6-19に示す項目を除き、このタスクのすべてはタスク7.2.2と同じです。

  1. このステップが実行するタスクを説明するわかりやすい名前。
  2. DR制御ノードにoic-integration-schedule.shスクリプトをインストールした絶対パスに貼り付けます。最初のパラメータとしてstart、2番目のパラメータとしてPHXを追加します。
  3. 「ステップの追加」をクリックして、このステップを計画グループに追加します。

plan-custom-fo-phx-grp3-step.png
図7-12:スタンバイでスケジュール済統合を開始するプラン・ステップを作成するためのパラメータ

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

次の図7-13に示すように、スタンバイでスケジュール済統合を開始するステップがDR計画グループに追加されました。

  1. 追加された計画ステップが表示されます。
  2. 「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。

plan-custom-fo-phx-grp3-finish.png
図7-13:スタンバイでスケジュールされた統合を開始するためのプラン・グループおよびステップの追加の確定

タスク7.5: リージョン2でDNSレコードを更新するプラン・グループの作成

4番目のユーザー定義プラン・グループは、スタンバイ・リージョン2でDR制御ノードが起動された後、スタンバイでDNSレコードを更新します。この計画グループには、タスク1.3でDR制御ノードにダウンロードされたdns_record_update.sh bashスクリプトをコールする単一のステップが含まれます。

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

以前と同様に、「グループの追加」をクリックして開始します。

plan-custom-fo-phx-grp4-add.png
図7-14:スタンバイでDNSレコードを更新するプラン・グループの追加を開始します

タスク7.5.2: プラン・グループ名、順序およびステップの追加の指定

DR計画グループを作成して、DNSレコードをリージョン2に更新します。

  1. プラン・グループにわかりやすい名前を付けます。
  2. 計画グループをDR計画に挿入する位置を選択します。この場合、組込みプラン・グループの後にユーザー定義プラン・グループを挿入して、スタンバイでスケジュール済統合を開始します
  3. 組込みの「スケジュールされた統合をスタンバイで開始」プラン・グループを選択します。
  4. 「ステップの追加」をクリックしてダイアログを開き、スタンバイでDNSレコードを更新するスクリプトを指定します。

plan-custom-fo-phx-grp4-name.png
図7-14:プラン・グループを作成し、スタンバイでDNSレコードを更新するステップを追加するパラメータ

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

「計画グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、スタンバイでDNSレコードが更新されます。

次の図7-15に示す項目を除き、このタスクのすべてはタスク6.3.3と同じです。

  1. このステップが実行するタスクを説明するわかりやすい名前。
  2. DR制御ノードにdns_record_update.shスクリプトをインストールした絶対パスに貼り付けます。リージョン2 (この例ではPHX)のOCIリージョン・キーをパラメータとして追加します。
  3. 「ステップの追加」をクリックして、このステップを計画グループに追加します。

plan-custom-fo-phx-grp4-step.png
図7-15:スタンバイでDNSレコードを更新するプラン・ステップを作成するためのパラメータ

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

次の図7-16に示すように、スタンバイでDNSレコードを更新するステップがDR計画グループに追加されました。

  1. 追加された計画ステップが表示されます。
  2. 「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。

plan-custom-fo-phx-grp4-finish.png
図7-16:スタンバイでDNSレコードを更新するプラン・グループおよびステップの追加を確定します

次のスクリーンショットに示すように、フェイルオーバー計画にOracle Integrationの4つのDR計画グループが含まれるようになりました。保護グループにOracle Integrationとともに他のアプリケーションまたはOCIサービスが含まれている場合は、追加のプラン・グループがある場合があります。

plan-custom-fo-phx-completed.png
図7-14:フェイルオーバー計画に追加された4つのユーザー定義計画グループの表示

タスク8: リージョン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 (フェニックス)に移行するために作成されたばかりのスイッチオーバー・プランを実行します。

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

DR計画を実行して、Oracle Integrationワークロードをリージョン1からリージョン2に移行するプロセスを開始します。

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

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

タスク8.2: スイッチオーバー計画を選択して実行

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

  1. スイッチオーバー・プランを選択します。
  2. 「Enable prechecks(事前チェックの有効化)」が選択されていることを確認します。
  3. 「DR計画の実行」をクリックして開始します。

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

タスク8.3: 次のステップ

Oracle Integrationワークロードがリージョン1からリージョン2に完全に遷移するまで、スイッチオーバー計画を監視します。OCI Full Stack DRは、アーティファクトのクリーンアップと、リージョン間のプライマリとスタンバイの役割の変更を行います。

OCI Full Stack DRがスイッチオーバーを完了すると、リージョン2 (フェニックス)がプライマリ・リージョンになり、リージョン1 (アッシュバーン)がスタンバイ・リージョンになります。

タスク9: リージョン1でのDR計画の作成(アッシュバーン)

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

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

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

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

タスク9.1: DR計画の作成の開始

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

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

プラン作成-phx-nav.pvg
図9-1:リージョン1での基本的なDR計画の作成を開始する方法

タスク9.1.1: スイッチオーバー・プランの作成

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

  1. スイッチオーバー・プランの名前をシンプルでわかりやすいものにします。名前はできるだけ短くする必要がありますが、危機時の混乱や人的ミスを軽減するために一目でわかりやすくする必要があります。

  2. プラン・タイプを選択します。この作成時には2つのプラン・タイプしかありません。

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

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

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

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

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

  2. プラン・タイプを選択します。この作成時には2つのプラン・タイプしかありません。

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

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

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

プラン作成-phx-completed.png
図9-4:続行する前にリージョン2に存在する必要がある2つの基本的なDR計画を表示

タスク10: リージョン1でのスイッチオーバー・プランのカスタマイズ(アッシュバーン)

このタスクに関する作業は、リージョン1で行われることを除き、タスク6で行った作業とほぼ同じです。

タスク9で作成された基本的なDR計画には、Oracle Integrationに固有のリカバリ・タスクを管理するためのものは含まれていません。このタスクでは、カスタムのユーザー定義DR計画グループを追加する方法と、Oracle Integrationのスイッチオーバー中に実行する必要があるものを管理するステップについて説明します。

  1. スケジュール済パラメータをリージョン1からリージョン2に同期します。
  2. 関連する統合をリージョン2でアクティブ化します。
  3. リージョン2でスケジュールされた統合を開始します。
  4. リージョン2でDNSレコードを更新します。
  5. リージョン1でスケジュール済統合を非アクティブ化します。

タスク10.1: スイッチオーバー・プランの選択

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

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

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

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

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

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

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

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

plan-custom-so-iad-disabled-show.png
図10-2:プラン・グループはデフォルトで無効になっています。

使用不可のプラン・グループが使用可能な場合の動作は次のとおりです。

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

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

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

計画グループを有効にします。

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

plan-custom-so-iad-enable-terminate-vm.png
図10-3:コンピュート・インスタンスの終了を有効にする方法

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

計画グループを有効にします。

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

plan-custom-so-iad-enable-terminate-vg.png
図10-4:ボリューム・グループの終了を有効にする方法

タスク10.3: スイッチオーバー計画に対する様々なユーザー定義計画の作成

スイッチオーバー・プランの様々なユーザー定義プランをタスク6.3から6.7に作成する方法はすでに示されています。同様のプロセスを使用して、5つのカスタム・ユーザー定義プラン・グループを作成します。スクリプトを実行するには、フェニックス・リージョンで実行されているコンピュート・インスタンスを使用する必要があります。

  1. プライマリからスタンバイ/home/opc/oic-scripts/oic-sync-schedule-parameters.sh IADへのスケジュール済パラメータの同期。
  2. スタンバイ/home/opc/oic-scripts/oic-integration-switch.shで関連する統合をアクティブ化し、IADをアクティブ化します。
  3. スタンバイ/home/opc/oic-scripts/oic-integration-schedule.shでスケジュールされた統合を開始すると、IADが起動します。
  4. スタンバイ/home/opc/oic-scripts/DNS-record-update.sh IADでDNSレコードを更新します。
  5. プライマリ/home/opc/oic-scripts/oic-integration-switch.shでスケジュール済統合を非アクティブ化すると、IADが非アクティブ化されます。

これらが作成されると、次のスクリーンショットに示すように、スイッチオーバー計画にOracle統合用の5つのDR計画グループが含まれるようになります。保護グループにOracle統合とともに他のアプリケーションまたはOCIサービスが含まれている場合は、追加のプラン・グループがある場合があります。

plan-custom-so-iad-completed.png
図10-21:スイッチオーバー・プランに追加された5つのユーザー定義プラン・グループの表示

タスク11: リージョン1のフェイルオーバー計画のカスタマイズ(アッシュバーン)

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

  1. 関連する統合をリージョン1でアクティブ化します。
  2. リージョン1でスケジュール済パラメータを更新します。
  3. リージョン1でスケジュールされた統合を開始します。
  4. リージョン1でDNSレコードを更新します。

タスク11.1: スイッチオーバー・プランの選択

まず、タスク9で作成したフェイルオーバー計画に移動します。

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

plan-custom-fo-iad-nav.png
図7-1:リージョン2でフェイルオーバー計画のカスタマイズを開始する方法

タスク11.2: リージョン1での複数のユーザー定義プラン・グループの作成(スタンバイ)

すでに、タスク7.2から7.5までのフェイルオーバー計画の様々なユーザー定義計画の作成方法が示されています。同様のプロセスを使用して、次の4つのカスタム・ユーザー定義プラン・グループを作成します。スクリプトを実行するには、フェニックス・リージョンで実行されているコンピュート・インスタンスを使用する必要があります。

  1. スタンバイ/home/opc/oic-scripts/oic-integration-switch.shで関連する統合をアクティブ化し、IADをアクティブ化します。

  2. スタンバイ/home/opc/oic-scripts/oic-update-parameters.sh IADでスケジュール済パラメータを更新します。

  3. スタンバイ/home/opc/oic-scripts/oic-integration-schedule.shでスケジュールされた統合を開始すると、IADが起動します。

  4. スタンバイ/home/opc/oic-scripts/DNS-record-update.sh IADでDNSレコードを更新します。

これらが作成されると、次のスクリーンショットに示すように、フェイルオーバー計画にOracle統合用の4つのDR計画グループが含まれるようになります。保護グループにOracle統合とともに他のアプリケーションまたはOCIサービスが含まれている場合は、追加のプラン・グループがある場合があります。

plan-custom-fo-iad-completed.png
図11-14:フェイルオーバー・プランに追加された4つのユーザー定義プラン・グループの表示

次のステップ

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

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

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

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

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

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

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

ノート: 同じクライアント・アプリケーションを使用して両方のOracle Integrationインスタンスの残りのAPIを認証できるように、両方のインスタンス(プライマリおよびセカンダリ)のスコープをOAuthクライアント・アプリケーションに追加できます。OAuthクライアント・アプリケーションの設定については、公式ドキュメントを参照してください。

承認

ビデオ1: ディザスタ・リカバリのためのOracle Integrationのデプロイのビデオ2: OCI Full Stack DRを使用したOracle Integrationのディザスタ・リカバリ操作の自動化ビデオ3: Oracle Integrationのリカバリを自動化するために使用されるスクリプト

その他の学習リソース

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

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