ノート:

このチュートリアルでは、Oracle Cloudへのアクセスが必要です。無料アカウントにサインアップするには、Oracle Cloud Infrastructure Free Tierの開始を参照してください。
Oracle Cloud Infrastructureの資格証明、テナンシおよびコンパートメントに例の値を使用します。演習を完了するときは、これらの値をクラウド環境に固有の値に置き換えます。

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

パート1 - 概要

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

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

フル・スタックDRは、ネットワーキング、コンピュート、ストレージ、ストレージ・レプリケーション、データベース、OACアプリケーション/サービス自体など、Oracle Analytics Cloud (OAC)に関するもののインストール、構成またはデプロイには使用されません。フル・スタックDRを使用しようとする前に、Oracle Analytics Cloudのディザスタ・リカバリ構成に記載されているステップバイステップの手順に従って、リージョン間のDRにOACを完全にデプロイする必要があります。

フル・スタックDRを使用する前に、Oracle Analytics Cloudのディザスタ・リカバリ構成でOACエンジニアリングによって規定されている手動リカバリ・ステップも、スイッチオーバーおよびスイッチバック(OACドキュメントのフォールバックとも呼ばれる)について正常にテストする必要があります。

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

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

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

このチュートリアルでは、移動部品や部品を多すぎて読者を圧倒したくないため、Oracle Analytics Cloudを単独で実装する方法を示します。そのため、このチュートリアルでは、混乱を減らし、Oracle Analytics Cloudのリカバリを自動化するために必要なことに集中するために、OACを単独で示します。

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

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

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

リカバリの動作

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

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

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

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

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

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

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

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

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

Oracle Analytics Cloud(OAC)は、Full Stack DRを導入する前に、まずOCIリージョン間のディザスタ・リカバリ(DR)のためにデプロイする必要があります。フル・スタックDRを使用してリカバリ・プロセスを自動化する前に、OACエンジニアリングでドキュメント化されているとおりにOACをリカバリするための手動ステップをテストして正しく動作することが非常に重要です。

OCIリージョン間でDR用のOACをデプロイする場合は、次に示す2つのリファレンス・アーキテクチャのいずれかに従うことができます。どちらのリファレンス・アーキテクチャも、2つのOCIリージョンに分散された冗長リソースを持つ多層トポロジを示しています。

オプション1: OACパブリック・インスタンスのデプロイ

Oracle Analytics Cloudパブリック・インスタンスは、Oracle Serviceネットワーク内にあり、インターネットから直接アクセスできます。Oracle Analytics CloudパブリックIPアドレスは、DNSレジストラを使用して直接構成されます。

図1: OACパブリック・インスタンスを使用する場合のOICリファレンス・アーキテクチャ

オプション2: OACプライベート・インスタンスのデプロイ

パブリック・インターネットからOracle Analytics Cloudプライベート・インスタンスにアクセスできないため、アクセスを容易にするためにOCIパブリック・ロード・バランサが必要です。パブリック・ロード・バランサのIPアドレスがDNSレジストラに追加されます。

図2: OACプライベート・インスタンスを使用する場合のOICリファレンス・アーキテクチャ

フル・スタックDRデプロイメント・アーキテクチャ

次の図は、フル・スタックDRの各DR保護グループ(DRPG)にメンバーとして追加されたコンピュート・リソースを示しています。これらは、フル・スタックDRがOracle Analytics Cloudサービス(OAC)の外部で管理できる様々なコンポーネントを表します。

Autonomous Data Warehouse (ADW)以外のOACコンポーネントは、次に示すDRPGリファレンス・アーキテクチャのいずれにも表示されません。これは、OAC PaaSがフル・スタックDRでは見えないためです。したがって、ADW以外のOACについては、どちらのリージョンでもDRPGに追加されません。

Full Stack DRには、コンピュート、ブロック・ストレージ、ファイル・ストレージ、Oracleデータベース、ロード・バランサ、その他の多くのリソースをリカバリ中に処理する自動化が組み込まれていますが、OAC自体の自動化が組み込まれていません。OACリカバリは、このチュートリアル専用のGitHubリポジトリからダウンロードできる一連のbashスクリプトによって制御されます。スクリプトを配置および制御するには、次のオプションのいずれかに従って、bashスクリプトを選択したコンピュート・インスタンスにインストールする必要があります。

オプション1: スタンドアロン・アプリケーションとしてのOACのリカバリの自動化

このデプロイメント・アーキテクチャは一般的ではなく、OACがFull Stack DRによってリカバリされる唯一のアプリケーションである非常にまれな状況のために考案されました。この場合、次に示す専用のコンピュート・インスタンスが作成され、OACのリカバリを管理するためにFull Stack DRが呼び出すカスタムbashスクリプトがホストされます。

図3:特殊なDR制御ノードを必要とするフル・スタックDRデプロイメント・アーキテクチャ

オプション2: アプリケーション・スタックの一部としてOACのリカバリを自動化する

次の図4に示す単純なデプロイメント・アーキテクチャは、OACのより一般的なデプロイメントの例で、多くのサービスとアプリケーションをまとめてリカバリする必要がある、より大規模で複雑なアプリケーション・スタックの1つのコンポーネントにすぎません。Most business systems are much more complex than the fictitious one shown below and usually include additional databases, other Oracle and/or non-Oracle applications, along with other OCI services such as OIC, ODI, OHS, IAM, etc.

この場合、上の図3に示すような特殊なDRノードを作成する必要はありません。OACのリカバリを管理するカスタムbashスクリプトは、次の図4のmovable computeとして示されている任意のサーバーにインストールできます。

図4:特殊なDR制御ノードを必要としないフル・スタックDRデプロイメント・アーキテクチャ

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

Full Stack Disaster Recoveryエンジニアリングチームは、このチュートリアルのための一連のコンパニオンビデオを作成して、人々がプロセスフロー全体を理解するのに役立ちます。これらのビデオは、次のリンクを使用してアクセスできるYouTubeプレイリストの一部です。

ビデオ1: DRのためのOracle Analytics Cloudのデプロイ
ビデオ2: Oracle Analytics Cloudのリカバリの自動化
ビデオ3: Oracle Analytics Cloudのリカバリを自動化するために使用されるスクリプト

パート2 - 手順

この部では、Oracle Analytics CLoudをフル・スタックDRに追加するために必要なステップバイステップの手順を開始します。

このチュートリアルの目的

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

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

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

地域

リージョン1はアッシュバーン
- アッシュバーンは主要地域としてスタートする。
- このロールは、後のステップでスイッチオーバーを実行するように指示された後、最終的にスタンバイに変更されます。
地域2はフェニックス
- フェニックスはスタンバイ・リージョンとして開始されます。
- このロールは、後のステップでスイッチオーバーを実行するように指示された後、最終的にプライマリに変更されます。

区分

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

すべてのDR保護グループをアプリケーションとは別に1つのコンパートメントに編成することで、ITスタッフは、多くのまったく異なるビジネス・システムに対してDR計画を簡単に見つけて実行できます。
すべてのDR保護グループに1つのコンパートメントがあると、人的エラーを排除し、DR計画を検出して実行できる速度を向上できます
- Oracle Analytics Cloudのコンパートメント: oac-demo。OAC自体、ストレージ、ストレージ・バケット、コンピュートおよびOACに関連するデータベースのコンパートメントは、このチュートリアルではOAC-demoです。
- フル・スタックDRのコンパートメント: myprojects_NA。フル・スタックDR保護グループおよびプランのコンパートメントは、このチュートリアルではmyprojects_NAです。

OAC DR制御ノード

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

スタンドアロン・アプリケーションとしてのOACの場合: これは、カスタム・スクリプトのホストとして機能するために作成する特殊なコンピュート・インスタンスになります
アプリケーション・スタックの一部としてのOACの場合: これは、DR保護グループ(DRPG)のメンバーである既存のコンピュート・インスタンスになります。たとえば、Oracle E-Business SuiteまたはPeopleSoftには、OACのリカバリを管理している同じDRPGのメンバーであるアプリケーション・サーバーがあります。これらのいずれかがこのチュートリアルでDR制御ノードのロールを満たすことができます。

前提条件

フル・スタックDRの使用を開始する前に、両方のリージョンにわたるディザスタ・リカバリのためにOracle Analytics Cloudをデプロイする必要があります。これについては、次のタスク1で説明します。

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

フルスタックDRは、この手順のどの部分にも関与しません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図2-4: OACのbashスクリプトを含むgithubリポジトリのスクリーンショット

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

次のドキュメントに記載されている手順に従って、OCIリージョン全体にDR用のOracle Analytics Cloudをデプロイします。

ソリューションを説明するOracleブログ: 手動スイッチオーバー方法を使用したOracle Analytics Cloudのディザスタ・リカバリ計画。
OACエンジニアリングにより書かれたOracleテクニカル・ペーパー: Oracle Analytics Cloudのディザスタ・リカバリ構成。
データ・プラットフォーム・クラウド・アーキテクトによって記述されたOracle Architecture Centerリファレンス・アーキテクチャ: フル・スタック・ディザスタ・リカバリ・サービスを使用したOracle Analytics Cloud DRトポロジの設計。

タスク1.5: Oracle Analytics Cloudの手動によるリカバリのテスト

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

タスク1.6: 次のステップ

次の要件が完了したら、このドキュメントに戻ってフルスタックDRの操作を開始します。

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

タスク2: フル・スタック・ディザスタ・リカバリの準備

フルスタックDRは、この手順のどの部分にも関与しません。次のステップでは、フル・スタックDRによる自動リカバリのために、テナンシ、コンパートメント、OCIサービスおよびOACを準備します。

タスク2.1: フル・スタックDRのIAMポリシーの作成

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

タスク2.2: フル・スタックDRによって管理される他のサービスのIAMポリシーの作成

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

フル・スタック・ディザスタ・リカバリによって管理される他のサービスのポリシー

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

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

プライマリ・リージョンとスタンバイ・リージョンにオブジェクト・ストレージ・バケットを作成して、リカバリ操作中にフル・スタックDRによって生成されたログを格納します: オブジェクト・ストレージ。

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

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

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

図2-1:オブジェクト・ストレージへの移動

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図3-1: DR保護グループへの移動

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図3-6: DRPGアソシエーションの開始

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

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

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

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

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

アソシエーションが完了すると、フル・スタックDRに図3-8のようなものが表示されます。

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

図3-8:個々のDRPGの観点からのピア関係の表示

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

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

図3-9:グローバルDRPGの観点からのピア関係の表示

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

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

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

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

DR制御ノード、
DR制御ノードのブートボリュームを含むボリュームグループ
プライマリAutonomous Data Warehouse。

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

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

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

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

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

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

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

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

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

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

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

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

タスク4.1.3: プライマリAutonomous Data Warehouseの追加

Autonomous Data Guardは、タスク1の一部として、この時点でAutonomous Data Warehouse (ADW)用にすでに構成されている必要があります。プライマリADWをリージョン1のDRPGのメンバーとして追加します。

メンバー・リソース・タイプとしてAutonomous Databaseを選択します。
ADWを含む正しいコンパートメントが選択されていることを確認し、OACのプライマリADWを選択します。

図4-4:プライマリADWの追加に必要なパラメータ

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

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

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

図4-5:リージョン1でのDRPGのメンバーの表示

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

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

スタンバイ/リモートAutonomous Data Warehouse (ADW)。

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

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

図4-6:リージョン2でDR保護グループへのメンバーの追加を開始する方法

タスク4.2.1: スタンバイAutonomous Data Warehouseの追加

次の図4-7に示すように、リージョン2のDRPGのメンバーとしてスタンバイADWを追加します。

OCIリージョン・コンテキストをリージョン2 (フェニックス)に変更します。
タスク3.3で作成したDRPGを選択します。

図4-7:スタンバイADWの追加に必要なパラメータ

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

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

スタンバイ/リモートADW。

図4-8:リージョン2でのDRPGの単一メンバーの表示

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VMを停止する前に、現在のプライマリ・リージョン1でOACを停止します。
VMを起動した後、現在のスタンバイ・リージョン2でOACを起動します。
スタンバイ・リージョン2で定期的なスナップショットをリカバリします。定期的なスナップショットは、前述のタスク1.4の一部として設定されています。
スタンバイ・リージョン2でスナップショットcronジョブを変更します。cronジョブは、前述のタスク1.4の一部として設定されました。

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

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

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

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

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

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

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

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

図6-2:プラン・グループはデフォルトで無効になっています。

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

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

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

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

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

図6-3:コンピュート・インスタンスの終了を有効にする方法

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

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

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

図6-4:ボリューム・グループの終了を有効にする方法

タスク6.3: 地域1(プライマリ)でOACを停止する計画グループの作成

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

最初のユーザー定義プラン・グループは、プライマリ・リージョン1でのOACの実行を停止します。この計画グループには、タスク1.4でDR制御ノードにダウンロードされたoac-start-stop.sh bashスクリプトをコールする単一のステップが含まれます。

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

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

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

図6-5: OACを停止するための計画グループの追加を開始します。

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

DR計画グループには、すべてパラレルに実行される多数のステップを含めることができます。OACを停止するbashスクリプトを実行するための単一のステップを追加するだけです。

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

図6-6:計画グループを作成し、OACを停止するステップを追加するためのパラメータ

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

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

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

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

図6-7: OACを停止するための計画ステップを作成するパラメータ

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

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

追加された計画ステップが表示されます。DR計画グループにステップを追加することは可能ですが、この計画グループにはOACを停止するステップのみが含まれます。
「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。

図6-8: OACを停止するプラン・グループおよびステップの追加を確定します

タスク6.4: リージョン2 (スタンバイ)でOACを起動するプラン・グループの作成

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

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

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

図6-9:スタンバイでOACを起動する計画グループの追加を開始します

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

OACを起動するDR計画グループを作成します。

プラン・グループにわかりやすい名前を付けます。グループ名に「(Standby)」を追加すると、ステップが一目で適用されるリージョンが明らかになります。
計画グループをDR計画に挿入する位置を選択します。この場合、リージョン2でDR制御ノードのレプリケート・バージョンを起動する組込み計画グループの後に、ユーザー定義計画グループを挿入します。
組込みの「コンピュート・インスタンスの起動(スタンバイ)」プラン・グループを選択します
「ステップの追加」をクリックしてダイアログを開き、OACを起動するスクリプトを指定します

図6-10:計画グループを作成し、スタンバイでOACを起動するステップを追加するパラメータ

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

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

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

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

図6-11:スタンバイでOACを起動するための計画ステップを作成するパラメータ

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

次の図6-12に示すように、OACを起動するステップがDR計画グループに追加されました。

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

図6-12:スタンバイでOACを起動する計画グループおよびステップの追加を確定します

タスク6.5: リージョン2 (スタンバイ)でスナップショットをリカバリするプラン・グループの作成

タスク1.4の一部として、DR制御ノードにcronジョブが設定されました。cronジョブは、OAC-create-snapshot.shという名前のbashスクリプトをコールします。このスクリプトは、リージョン1のOACデータのスナップショットをエクスポートし、スタンバイ・リージョン2のオブジェクト・ストレージ・バケットに保存します。cronジョブおよびバケットもタスク1.4で作成されました。

3番目のユーザー定義プラン・グループは、リージョン1のオブジェクト・ストレージ・バケットからリージョン2にレプリケートされる定期スナップショットを使用して、スタンバイ・リージョン2でOACをリカバリします。この計画グループには、タスク1.3でDR制御ノードにダウンロードされたoac-register-snapshot.sh bashスクリプトをコールする単一のステップが含まれます。

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

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

図6-13:スタンバイでスナップショットをリカバリする計画グループの追加を開始します

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

スタンバイ・リージョン2でOACをリカバリするDR計画グループを作成します。

プラン・グループにわかりやすい名前を付けます。
計画グループをDR計画に挿入する位置を選択します。この場合、OACを起動するために、前のタスクで作成したユーザー定義プラン・グループの後にユーザー定義プラン・グループを挿入します。
組込みの「Start OAC (Standby)」プラン・グループを選択します。
「ステップの追加」をクリックしてダイアログを開き、OACスナップショットをリカバリするスクリプトを指定します。

図6-14:計画グループを作成し、スタンバイでOACスナップショットをリカバリするためのステップを追加するパラメータ

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

「計画グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、リージョン2のOACスナップショットがリカバリされます。スナップショットは、通常の操作中にプライマリ・リージョンで取得され、リージョン2のオブジェクト・ストレージ・バケットに格納されます。

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

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

図6-15:スタンバイでスナップショットをリカバリするための計画ステップを作成するパラメータ

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

次の図6-16に示すように、OACをリカバリするステップがDR計画グループに追加されました。

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

図6-16:スタンバイでスナップショットをリカバリするための計画グループおよびステップの追加を確定します

タスク6.6: リージョン2 (スタンバイ)でスナップショットを戻し処理するプラン・グループの作成

最後のユーザー定義プラン・グループは、前述のタスク6.5で説明したcronジョブを変更します。Full Stack DRは、OAC-chg-cronjob.shをコールしてcronジョブを変更し、エクスポートされたOACスナップショットをリージョン1のストレージ・バケットに保存します。

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

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

図6-17:スタンバイでスナップショット・コピーをリバースする計画グループの追加を開始します

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

DR計画グループを作成して、OACスナップショットをリージョン1に戻します。

プラン・グループにわかりやすい名前を付けます。グループ名に「(Standby)」を追加すると、ステップが一目で適用されるリージョンが明らかになります。
計画グループをDR計画に挿入する位置を選択します。この場合、リージョン2のOACスナップショットをリカバリする組込みプラン・グループの後に、ユーザー定義プラン・グループを挿入します。
組込みの「OACスナップショットのリカバリ(スタンバイ)」プラン・グループを選択します。
「ステップの追加」をクリックして、OACを起動するスクリプトを指定するダイアログを開きます。

図6-18:計画グループを作成し、スタンバイでスナップショット・コピーをリバースするステップを追加するパラメータ

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

「計画グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、OACスナップショットは逆になるため、リージョン1に保存され、スイッチオーバーの完了後に自動的にスタンバイ・リージョンになります。

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

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

図6-19:スタンバイでスナップショット・コピーを元に戻すための計画ステップを作成するパラメータ

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

次の図6-20に示すように、OACスナップショットの方向を逆にするステップがDR計画グループに追加されました。

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

図6-20:スタンバイでスナップショット・コピーを元に戻すための計画グループおよびステップの追加を確定します

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

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

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

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

VMを起動した後、スタンバイ・リージョン2でOACを起動します。
スタンバイ・リージョン2で定期的なスナップショットをリカバリします。定期的なスナップショットは、前述のタスク1.4の一部として設定されています。
スタンバイ・リージョン2でスナップショットcronジョブを変更します。cronジョブは、前述のタスク1.4の一部として設定されました。

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

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

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

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

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

最初のユーザー定義プラン・グループは、スタンバイ・リージョン2で実行されているOACを起動します。この計画グループには、タスク1.3でDR制御ノードにダウンロードされたoac-start-stop.sh bashスクリプトをコールする単一のステップが含まれます。

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

図7-2: OACを起動する計画グループの追加を開始します。

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

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

プラン・グループにわかりやすい名前を付けます。これはもちろんオプションですが、ベスト・プラクティスは、プラン・グループがステップを実行するリージョンに関するノートを追加することです。この場合、スタンバイ・リージョン2であるため、グループ名に(スタンバイ)を追加しました。
計画グループをDR計画に挿入する位置を選択します。この場合、リージョン2でレプリケートされたVMを起動する組込みプラン・グループの後に、ユーザー定義プラン・グループを挿入します
組込みの「コンピュート・インスタンスの起動(スタンバイ)」プラン・グループを選択します
「ステップの追加」をクリックしてダイアログを開き、OACを起動するスクリプトを指定します

図7-3:プラン・グループを作成し、ステップを追加してOACを起動するためのパラメータ

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

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

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

図7-4:スタンバイでOACを起動するための計画ステップを作成するパラメータ

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

次の図7-5に示すように、OACを起動するステップがDR計画グループに追加されました。

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

図7-5: OACを起動するプラン・グループおよびステップの追加を確定します

タスク7.3: リージョン2 (スタンバイ)でスナップショットをリカバリする計画グループの作成

2番目のユーザー定義プラン・グループは、リージョン1のオブジェクト・ストレージ・バケットからリージョン2にレプリケートされる定期スナップショットを使用して、スタンバイ・リージョン2でOACをリカバリします。これは、スイッチオーバー・プランに追加されたタスクと同じタスクがタスク6です。

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

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

図7-6:スタンバイでスナップショットをリカバリする計画グループの追加を開始します

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

スタンバイ・リージョン2でOACをリカバリするDR計画グループを作成します。

プラン・グループにわかりやすい名前を付けます。
計画グループをDR計画に挿入する位置を選択します。この場合、OACを起動するために、前のタスクで作成したユーザー定義プラン・グループの後にユーザー定義プラン・グループを挿入します。
組込みの「Start OAC (Standby)」プラン・グループを選択します。
「ステップの追加」をクリックしてダイアログを開き、OACスナップショットをリカバリするスクリプトを指定します。

図7-7:計画グループを作成し、スタンバイでOACスナップショットをリカバリするためのステップを追加するパラメータ

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

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

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

図7-8:スタンバイでスナップショットをリカバリするための計画ステップを作成するパラメータ

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

次の図7-9に示すように、OACをリカバリするステップがDR計画グループに追加されました。

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

図7-9:スタンバイでスナップショットをリカバリするための計画グループおよびステップの追加を確定します

タスク7.4: リージョン2 (スタンバイ)でスナップショットを戻し処理するプラン・グループの作成

最後のユーザー定義プラン・グループによってcronジョブが変更されるため、OACスナップショットは再度アクセス可能になったらリージョン1に保存されます。これは、タスク6のスイッチオーバー計画に追加されたタスクと同じです。

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

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

図7-10:スタンバイでスナップショット・コピーをリバースする計画グループの追加を開始します

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

DR計画グループを作成して、OACスナップショットをリージョン1に戻します。

プラン・グループにわかりやすい名前を付けます。グループ名に「(Standby)」を追加すると、ステップが一目で適用されるリージョンが明らかになります。
計画グループをDR計画に挿入する位置を選択します。この場合、リージョン2のOACスナップショットをリカバリする組込みプラン・グループの後に、ユーザー定義プラン・グループを挿入します。
組込みの「OACスナップショットのリカバリ(スタンバイ)」プラン・グループを選択します。
「ステップの追加」をクリックして、OACを起動するスクリプトを指定するダイアログを開きます。

図7-11:計画グループを作成し、スタンバイでスナップショット・コピーをリバースするステップを追加するパラメータ

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

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

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

図7-12:スタンバイでスナップショット・コピーを元に戻すための計画ステップを作成するパラメータ

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

次の図7-13に示すように、OACスナップショットの方向を逆にするステップがDR計画グループに追加されました。

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

図7-13:スタンバイでスナップショット・コピーを元に戻すための計画グループおよびステップの追加を確定します

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

図7-14:フェイルオーバー・プランに追加された3つのユーザー定義プラン・グループの表示

タスク8: リージョン2でのスイッチオーバー・プランの実行(フェニックス)

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

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

したがって、リージョン1がスタンバイ、リージョン2がプライマリになるように、保護グループのロールを元に戻す必要があります。ワークロードをリージョン1 (アッシュバーン)からリージョン2 (フェニックス)に移行するために作成されたばかりのスイッチオーバー・プランを実行します。

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

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

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

図8-1:スタンバイ・リージョンへのスイッチオーバーの実行方法の表示

タスク8.2: フェイルオーバー計画を選択して実行

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

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

図8-2:スイッチオーバー・プランを選択して実行します。

タスク8.3: 次のステップ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

フェイルオーバー計画の名前をシンプルでわかりやすいものにします。名前はできるだけ短くする必要がありますが、危機時の混乱や人的ミスを軽減するために一目でわかりやすくする必要があります。
プラン・タイプを選択します。この作成時には2つのプラン・タイプしかありません。
「作成」をクリックして、基本的な組込みステップが事前移入された基本的なフェイルオーバー計画を作成します。

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

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

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

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

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

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

VMを停止する前に、現在のプライマリ・リージョン2でOACを停止します。
VMを起動した後、現在のスタンバイ・リージョン1でOACを起動します。
スタンバイ・リージョン1で定期的なスナップショットをリカバリします。定期的なスナップショットは、前述のタスク1.4の一部として設定されています。
スタンバイ・リージョン1でスナップショットcronジョブを変更します。cronジョブは、前述のタスク1.4の一部として設定されました。

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

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

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

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

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

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

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

図10-2:プラン・グループはデフォルトで無効になっています。

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

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

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

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

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

図10-3:コンピュート・インスタンスの終了を有効にする

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

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

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

図10-4:ボリューム・グループの終了を有効にする方法

タスク10.3: リージョン2 (プライマリ)でOACを停止するプラン・グループの作成

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

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

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

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

図10-5: OACを停止するための計画グループの追加を開始します。

タスク10.3.2: プラン・グループ名、オーダーおよびステップの追加の指定

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

図10-6:計画グループを作成し、OACを停止するステップを追加するパラメータ

タスク10.3.3: ステップ名とローカル・スクリプト・パラメータの指定

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

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

図10-7: OACを停止するための計画ステップを作成するパラメータ

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

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

追加された計画ステップが表示されます。DR計画グループにステップを追加することは可能ですが、この計画グループにはOACを停止するステップのみが含まれます。
「追加」をクリックして、DR計画グループおよびステップをDR計画に追加します。

図10-8: OACを停止する計画グループおよびステップの追加を確定します。

タスク10.4: リージョン1 (スタンバイ)でOACを起動するプラン・グループの作成

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

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

図10-9:スタンバイでOACを起動する計画グループの追加を開始します

タスク10.4.2: プラン・グループ名、オーダーおよびステップの追加の指定

OACを起動するDR計画グループを作成します。

プラン・グループにわかりやすい名前を付けます。グループ名に「(Standby)」を追加すると、ステップが一目で適用されるリージョンが明らかになります。
計画グループをDR計画に挿入する位置を選択します。この場合、リージョン1でDR制御ノードのレプリケート・バージョンを起動する組込み計画グループの後に、ユーザー定義計画グループを挿入します。
組込みの「コンピュート・インスタンスの起動(スタンバイ)」プラン・グループを選択します。
「ステップの追加」をクリックして、OACを起動するスクリプトを指定するダイアログを開きます。

図10-10:計画グループを作成し、スタンバイでOACを起動するステップを追加するパラメータ

タスク10.4.3: ステップ名とローカル・スクリプト・パラメータの指定

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

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

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

図10-11:スタンバイでOACを起動するための計画ステップを作成するパラメータ

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

次の図10-12に示すように、OACを起動するステップがDR計画グループに追加されました。

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

図10-12:スタンバイでOACを起動する計画グループおよびステップの追加を確定します

タスク10.5: リージョン1 (スタンバイ)でスナップショットをリカバリする計画グループの作成

3番目のユーザー定義プラン・グループは、リージョン2のオブジェクト・ストレージ・バケットからリージョン1にレプリケートされる定期スナップショットを使用して、スタンバイ・リージョン1でOACをリカバリします。この計画グループには、タスク1.3でDR制御ノードにダウンロードされたoac-register-snapshot.sh bashスクリプトをコールする単一のステップが含まれます。

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

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

図10-13:スタンバイでスナップショットをリカバリする計画グループの追加を開始します

タスク10.5.2: プラン・グループ名、オーダーおよびステップの追加の指定

スタンバイ・リージョン1でOACをリカバリするDR計画グループを作成します。

プラン・グループにわかりやすい名前を付けます。
計画グループをDR計画に挿入する位置を選択します。この場合、前のステップで作成したユーザー定義プラン・グループの後にユーザー定義プラン・グループを挿入して、OACを起動します。
組込みの「Start OAC (Standby)」プラン・グループを選択します。
「ステップの追加」をクリックしてダイアログを開き、OACスナップショットをリカバリするスクリプトを指定します。

図10-14:計画グループを作成し、スタンバイでOACスナップショットをリカバリするステップを追加するパラメータ

タスク10.5.3: ステップ名とローカル・スクリプト・パラメータの指定

「計画グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、リージョン1のOACスナップショットがリカバリされます。スナップショットは、通常の操作中にプライマリ・リージョンで取得され、リージョン1のオブジェクト・ストレージ・バケットに格納されます。

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

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

図10-15:スタンバイでスナップショットをリカバリするための計画ステップを作成するパラメータ

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

次の図10-16に示すように、OACをリカバリするステップがDR計画グループに追加されました。

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

図10-16:スタンバイでスナップショットをリカバリするための計画グループおよびステップの追加を確定します

タスク10.6: リージョン1 (スタンバイ)でスナップショットを戻し処理するプラン・グループの作成

最後のユーザー定義プラン・グループは、前述のタスク10.5で説明したcronジョブを変更します。Full Stack DRは、OAC-chg-cronjob.shをコールしてcronジョブを変更し、エクスポートされたOACスナップショットをリージョン2のストレージ・バケットに保存します。

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

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

図10-17:スタンバイでスナップショット・コピーをリバースする計画グループの追加を開始します

タスク10.6.2: プラン・グループ名、オーダーおよびステップの追加の指定

DR計画グループを作成して、OACスナップショットをリージョン2に戻します。

プラン・グループにわかりやすい名前を付けます。グループ名に「(Standby)」を追加すると、ステップが一目で適用されるリージョンが明らかになります。
計画グループをDR計画に挿入する位置を選択します。この場合、リージョン1のOACスナップショットをリカバリする組込みプラン・グループの後に、ユーザー定義プラン・グループを挿入します。
組込みの「OACスナップショットのリカバリ(スタンバイ)」プラン・グループを選択します。
「ステップの追加」をクリックして、OACを起動するスクリプトを指定するダイアログを開きます。

図10-18:計画グループを作成し、スタンバイでスナップショット・コピーをリバースするステップを追加するパラメータ

タスク10.6.3: ステップ名とローカル・スクリプト・パラメータの指定

「計画グループ・ステップの追加」ダイアログでは、この1つのステップの実行内容およびリカバリ時の動作に関するパラメータを指定できます。この場合、OACスナップショットは逆になるため、リージョン2に保存され、スイッチオーバーの完了後に自動的にスタンバイ・リージョンになります。

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

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

図10-19:スタンバイでスナップショット・コピーを元に戻すための計画ステップを作成するパラメータ

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

次の図10-20に示すように、OACスナップショットの方向を逆にするステップがDR計画グループに追加されました。

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

3.
図10-20:スタンバイでスナップショット・コピーを元に戻すための計画グループおよびステップの追加を確定します

図10-21:スイッチオーバー・プランに追加された4つのユーザー定義プラン・グループの表示

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

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

VMを起動した後、スタンバイ・リージョン1でOACを起動します。
スタンバイ・リージョン1で定期的なスナップショットをリカバリします。定期的なスナップショットは、前述のタスク1.4の一部として設定されています。
スタンバイ・リージョン1でスナップショットcronジョブを変更します。cronジョブは、前述のタスク1.4の一部として設定されました。

タスク11.1: リージョン1 (スタンバイ)でOACを起動するプラン・グループの作成

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

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

図11-1:リージョン1のフェイルオーバー計画のカスタマイズを開始する方法

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

最初のユーザー定義プラン・グループは、スタンバイ・リージョン1で実行されているOACを起動します。この計画グループには、タスク1.3でDR制御ノードにダウンロードされたoac-start-stop.sh bashスクリプトをコールする単一のステップが含まれます。

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

図11-2: OACを起動する計画グループの追加を開始します。

タスク11.2.1: プラン・グループ名、オーダーおよびステップの追加の指定

プラン・グループにわかりやすい名前を付けます。これはもちろんオプションですが、ベスト・プラクティスは、プラン・グループがステップを実行するリージョンに関するノートを追加することです。この場合、スタンバイ・リージョン1であるため、グループ名に(スタンバイ)を追加しました。
計画グループをDR計画に挿入する位置を選択します。この場合、リージョン1でレプリケートされたVMを起動する組込みプラン・グループの後に、ユーザー定義プラン・グループを挿入します
組込みの「コンピュート・インスタンスの起動(スタンバイ)」プラン・グループを選択します
「ステップの追加」をクリックしてダイアログを開き、OACを起動するスクリプトを指定します

図11-3:計画グループを作成し、OACを起動するステップを追加するパラメータ

タスク11.2.2: ステップ名とローカル・スクリプト・パラメータの指定

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

図11-4:スタンバイでOACを起動するための計画ステップを作成するパラメータ

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

次の図11-5に示すように、OACを起動するステップがDR計画グループに追加されました。

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

図11-5: OACを起動する計画グループとステップの追加を確定します。

タスク11.3: リージョン1 (スタンバイ)でスナップショットをリカバリするプラン・グループの作成

2番目のユーザー定義プラン・グループは、リージョン2のオブジェクト・ストレージ・バケットからリージョン1にレプリケートされる定期スナップショットを使用して、スタンバイ・リージョン1でOACをリカバリします。これは、スイッチオーバー・プランに追加されたタスクと同じタスクがタスク9です。

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

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

図11-6:スタンバイでスナップショットをリカバリする計画グループの追加を開始します

タスク11.3.2: プラン・グループ名、オーダーおよびステップの追加の指定

スタンバイ・リージョン1でOACをリカバリするDR計画グループを作成します。

プラン・グループにわかりやすい名前を付けます。
計画グループをDR計画に挿入する位置を選択します。この場合、前のステップで作成したユーザー定義プラン・グループの後にユーザー定義プラン・グループを挿入して、OACを起動します。
組込みの「Start OAC (Standby)」プラン・グループを選択します。
「ステップの追加」をクリックしてダイアログを開き、OACスナップショットをリカバリするスクリプトを指定します。

図11-7:計画グループを作成し、スタンバイでOACスナップショットをリカバリするステップを追加するパラメータ

タスク11.3.3: ステップ名とローカル・スクリプト・パラメータの指定

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

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

図11-8:スタンバイでスナップショットをリカバリするための計画ステップを作成するパラメータ

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

次の図11-9に示すように、OACをリカバリするステップがDR計画グループに追加されました。

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

図11-9:スタンバイでスナップショットをリカバリする計画グループおよびステップの追加を確定します

タスク11.4: リージョン1(スタンバイ)でスナップショットを戻し処理するプラン・グループの作成

最後のユーザー定義プラン・グループによってcronジョブが変更されるため、OACスナップショットは再度アクセス可能になったらリージョン2に保存されます。これは、タスク10のスイッチオーバー計画に追加されたタスクと同じです。

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

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

図11-10:スタンバイでスナップショット・コピーをリバースする計画グループの追加を開始します。

タスク11.4.2: プラン・グループ名、オーダーおよびステップの追加の指定

DR計画グループを作成して、OACスナップショットをリージョン2に戻します。

プラン・グループにわかりやすい名前を付けます。グループ名に「(Standby)」を追加すると、ステップが一目で適用されるリージョンが明らかになります。
計画グループをDR計画に挿入する位置を選択します。この場合、リージョン1のOACスナップショットをリカバリする組込みプラン・グループの後に、ユーザー定義プラン・グループを挿入します。
組込みの「OACスナップショットのリカバリ(スタンバイ)」プラン・グループを選択します。
「ステップの追加」をクリックして、OACを起動するスクリプトを指定するダイアログを開きます。

図11-11:計画グループを作成し、スタンバイでスナップショット・コピーをリバースするステップを追加するパラメータ

タスク11.4.3: ステップ名とローカル・スクリプト・パラメータの指定

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

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

図11-12:スタンバイでスナップショット・コピーを元に戻すための計画ステップを作成するパラメータ

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

次の図11-13に示すように、OACスナップショットの方向を逆にするステップがDR計画グループに追加されました。

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

図11-13:スタンバイでスナップショット・コピーを元に戻すための計画グループおよびステップの追加を確定します

図11-14:フェイルオーバー・プランに追加された3つのユーザー定義プラン・グループの表示

次のステップ

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

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

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

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

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

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

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

リージョン2 (プライマリ)からリージョン1 (スタンバイ)へのスイッチオーバーをテストします。
リージョン1 (プライマリ)からリージョン2 (スタンバイ)へのフェイルオーバーをテストします。
リージョン2からのフェイルオーバー用にリージョン1 (プライマリ)を準備します。
リージョン2 (プライマリ)からリージョン1 (スタンバイ)へのフェイルオーバーをテストします。
リージョン2へのフェイルオーバーまたはスイッチオーバーのリージョン2 (プライマリ)を準備します。
DR保護グループおよびアプリケーション・スタックは、通常の動作状態であり、この時点でフェイルオーバーまたはスイッチオーバーの準備ができている必要があります。

確認

著者 - Bala Guddeti (NACEクラウド・ソリューション・スペシャリスト)
コントリビュータ - Greg King(Full Stack Disaster Recovery Product Manager)、Suraj Ramesh(Full Stack Disaster Recovery Product Manager)

その他の学習リソース

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

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

タイトルおよび著作権情報

Automate Recovery for Oracle Analytics Cloud Using OCI Full Stack Disaster Recovery

F88861-01

December 2023