ノート:

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

OCI Full Stack Disaster Recoveryを使用したOracle HeatWave MySQLのコールド・ディザスタ・リカバリの自動化

イントロダクション

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

Oracle HeatWave MySQLは、Oracle Cloud Infrastructure(OCI)内に導入されたフルマネージド・データベース・サービスで、セキュアなクラウドネイティブ・アプリケーションを迅速に導入しようとしているオペレーターや開発者をサポートします。Oracle HeatWave MySQLは、統合された高パフォーマンスのインメモリー問合せアクセラレータであるHeatWaveを使用する機能を含む唯一のMySQL製品です。HeatWaveを使用すると、運用上のMySQLデータベースに対して高度な分析を直接実行できるため、複雑で時間のかかるコストのかかるデータ移行や、別の分析データベースとの統合が不要になります。HeatWaveは、分析および混合ワークロードに対してMySQLのパフォーマンスを大幅に高速化します。HeatWaveはOCI用に完全に最適化されており、Oracle HeatWave MySQLはOCIおよびMySQLエンジニアリング・チームによって100%構築、管理、サポートされています。

このチュートリアルでは、OCIでOracle HeatWave MySQLのコールド・ディザスタ・リカバリを自動化する方法を学習します。ここでは、OCI Full Stack DRサービスを利用してスイッチオーバーおよびフェイルオーバー・プロセスを管理する手順の概要を説明します。

ノート:このタイプのディザスタ・リカバリ(DR)戦略は、バックアップおよびリストア・メカニズムに依存するため、リカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)のビジネス要件が過度に要求されていない非クリティカルなアプリケーションに最適です。

アーキテクチャの説明

このチュートリアルで示すアーキテクチャは、OCI仮想マシン(VM)で実行されているWordPressアプリケーションをOracle HeatWave MySQLとシームレスに統合したものです。また、設定では、OCI File Storageサービスをネットワーク・ファイル・システム(NFS)共有として利用して、WordPressコンテンツを格納します。この共有ストレージは各VMにマウントされ、環境全体のすべての新しいコンテンツへの即時および同期アクセスが保証されます。

OCIロード・バランサは、外部ユーザー接続を効率的に管理するためにパブリック・サブネット内にデプロイされ、受信トラフィックをWordPress VMに分散します。

障害リカバリのアーキテクチャの説明

WordPressアプリケーションVMのDR戦略には、VMの各ブート・ボリュームとボリューム・グループ・レプリケーションの完全なレプリケーション、WordPressコンテンツの同期を確実にするためのファイル・ストレージ・レプリケーションの使用率など、包括的なアプローチが含まれます。

ロード・バランサはリモート・リージョンに事前にプロビジョニングされているため、スイッチオーバーまたはフェイルオーバーのシナリオでWordPress仮想マシンがリモート・リージョンに移行されたときに、トラフィックをシームレスに処理する準備ができています。

Oracle HeatWave MySQLの場合、データ保護およびディザスタ・リカバリの準備が整うように、バックアップは定期的にリモート・リージョンにコピーされます。このプロセスは、カスタム・スクリプトを使用して1つのアプリケーションVMから開始できます。カスタム・スクリプトは、自動化された一貫性のある実行のためにcrontabを使用してスケジュールできます。

次の図は、使用可能な最新のMySQLバックアップをプライマリ・リージョンからリモート・リージョンにコピーするためのワークフローを示しています。

fsdr_mds_copy_restore_bkp-Logical_Workflow_Copy_Backup_to_Remote.png

次のcrontab設定は、WordPressアプリケーションVM1のopcユーザーの下で、4時間ごとにmds_copy_bkp.pyスクリプトを実行するように構成されています。これにより、スタンバイ・リージョンへの自動バックアップ同期が保証され、ディザスタ・リカバリの向上につながります。

15 */4 * * * /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01

このジョブは、4時間ごとの15分後にスクリプトを実行します。

すべてのスクリプトはGitHubで入手でき、次の各項で詳しく説明します。

ノート: MySQLバックアップをリモート・リージョンに定期的にコピーするには、ビジネス要件に従ってこのスクリプト(または同様のスクリプト)をスケジュールしてください。このステップがないと、バックアップがセカンダリ・リージョンで使用できないため、リストア・プロセスが失敗する可能性があります。

リカバリの仕組み

計画されたスイッチオーバーが実行されると、ロールは逆になります。プライマリ・ワークロードはリージョン2で実行され、スタンバイはリージョン1で動作します。このアーキテクチャーは、次のように表示されます。

fsdr_mds_copy_restore_bkp-Physical_Switchover_Architecture.png

現在の設定では、OCIプライベートDNSサービスを利用して、アクティブなOracle HeatWave MySQLエンドポイントにトラフィックを転送するDNSレコードを管理します。リカバリ・プロセス中に、このDNSレコードはカスタム・スクリプトを介して更新され、新しいOracle HeatWave MySQLが反映されるため、シームレスなフェイルオーバーとサービスの継続性が保証されます。

次の図は、スタンバイ・リージョンの最新のMySQLバックアップをリストアするためのワークフローを示しています。

fsdr_mds_copy_restore_bkp-Logical_Workflow_Restore_Backup_to_Remote.png

このデプロイメントのリカバリ・ソリューションでは、フェイルオーバーやスイッチオーバーなどのリカバリ操作中にOCI Full Stack DRが一連のカスタムPythonスクリプトを実行する必要があります。このチュートリアルで参照されるスクリプトは、EMEA Cloud Architecture Specialistsチームによって提供され、このDRソリューション用に特別に調整されたfull-stack-disaster-recoveryで入手できます。

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

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

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

リージョン:
- リージョン1はドバイ:ドバイは当初、プライマリ・リージョンとして機能します。ただし、このロールはスイッチオーバー・プロセス中にスタンバイに遷移し、障害時リカバリ計画の一環として後のタスクで実行されます。
- リージョン2はアブダビ:アブダビは当初、スタンバイ・リージョンとして機能します。このロールは、スイッチオーバー・プロセスの後にプライマリに遷移します。このプロセスは、ディザスタ・リカバリ手順の一部として後続のタスクで実行されます。
コンパートメント:このデプロイメントおよびOCI Full Stack DRは、ITガバナンスの標準内で動作する任意のコンパートメント・スキームに自由に編成できます。このチュートリアルのすべてのOCIリソースを1つのコンパートメントに編成することを選択しました。

WordPressアプリケーションVMおよびOCIファイル・ストレージ

このチュートリアルで使用するアーキテクチャは、すべてのアプリケーションVMが同じWordPressコンテンツに共有アクセスできるように、OCIファイル・ストレージを中心に設計されています。

Linuxインスタンスにファイル・システムを正しくマウントする方法の詳細は、「(Linuxインスタンス)を自動的にマウントするためのファイル・システムの構成」を参照してください。

次に、WordPressアプリケーションVMにファイル・システムをマウントするための/etc/fstabファイル構成の例を示します。

xxx.xxx.xxx.xxx:/wordpress /var/www/html nfs nfsvers=3,noacl,nosuid,nofail 0 0

xxx.xxx.xxx.xxxをリージョン1にあるマウント・ターゲットのIPアドレスに置き換えて、適切な接続を確保します。

目的

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

タスク1: ディザスタ・リカバリのための環境の準備
タスク2: 両方のリージョンでのDR保護グループ(DRPG)の作成
タスク3: DR保護グループへのメンバーの追加
タスク4: リージョン2での基本的なDR計画の作成
タスク5: リージョン2でのスイッチオーバー計画のカスタマイズ
タスク6: リージョン2でのフェイルオーバー計画のカスタマイズ
タスク7: リージョン2でのDR計画の事前チェックの実行
タスク8: リージョン2でのスイッチオーバー計画の実行
タスク9: リージョン1でのDR計画の作成およびカスタマイズ

タスク1: ディザスタ・リカバリのための環境の準備

タスク1.1: ボリューム・グループの作成およびレプリケーションの有効化

リージョン1でWordPressアプリケーションVMのボリューム・グループを作成し、リージョン2でレプリケートされていることを確認します。各アプリケーションVMのブート・ボリューム(WordPress)がボリューム・グループのメンバーであり、ボリューム・グループがリージョン2にレプリケートされていることを確認します。

次の図は、2つのWordPressアプリケーションVMのブート・ボリュームを含む、リージョン2へのレプリケーションが正常に有効化された、作成されたボリューム・グループを示しています。詳細は、「ボリューム・グループの作成」を参照してください。

タスク1.2: WordPressコンテンツのファイル・ストレージ・レプリケーションの有効化

リージョン2で、レプリケーション専用に指定されたファイル・システムを作成します。このファイル・システムは、リージョン1からリージョン2へのデータのシームレスなレプリケートに使用されます。
リージョン2で、リージョン1からリージョン2へのリカバリ・プロセス中に使用されるマウント・ターゲットを作成します。
ステップ1で作成したファイル・システムを使用して、リージョン1のソースOCIファイル・ストレージからのレプリケーションを有効化および構成します。

次の図は、リージョン2へのファイル・ストレージのレプリケーションの詳細を示しています。

詳細は、ファイル・システム・レプリケーションを参照してください。

タスク1.3: カスタム自動化を実行するためのアプリケーションVMの準備

Oracle Cloud Infrastructureコマンドライン・インタフェース(OCI CLI)をインストールおよび構成します。このチュートリアルでは、Oracle Linux 8がWordPressアプリケーションVMに使用されます。詳細は、CLIのインストールを参照してください。
/home/opcフォルダのGitHubリポジトリ(mds_colddr_scripts)からスクリプトをデプロイします。
提供されているスクリプトで使用されるpandasおよびtabulateモジュールをインストールします。
```
pip install pandas
pip install tabulate
```
config.csvファイルを、リージョン1のOracle HeatWave MySQLに必要な詳細で更新します。
- MYSQL_DB_SYSTEM_OCIDをOracle HeatWave MySQLのOCIDに置き換えます。MySQLラベルは、特定の要件にあわせて保持またはカスタマイズできます。
- COMPARTMENT_OCIDを、MySQLシステムが配置されているコンパートメントのOCIDに置き換えます。
- 両方のリージョンで、PRIMARY_SUBNET_OCIDおよびSTANDBY_SUBNET_OCIDをサブネットOCIDsに置き換えます。
- PRIMARY_DNS_VIEW_OCIDおよびSTANDBY_DNS_VIEW_OCIDを、Oracle HeatWave MySQLエンドポイント・レコードを管理するプライベートDNSゾーンに関連付けられたプライベートDNSビューのOCIDsに置き換えます。
ノート:すべての値が正確に更新されていることを確認します。

チュートリアルの一部として、この同じVMを使用してユーザー定義スクリプトを実行します。DR制御ノードとして機能するVMがコマンドを実行するように構成されていることを確認します。詳細は、Oracle Cloud Infrastructure Full Stack Disaster Recoveryでのrunコマンドを使用したカスタム・スクリプトの起動を参照してください。

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

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

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

OCI Full Stack DRには、コンピュート、ネットワーキング、ストレージ、その他のサービスなど、他の主要なOCIサービスを制御および管理する能力が必要です。他のサービスに必要なOCI IAMポリシーを構成するには、フル・スタック・ディザスタ・リカバリで管理されるその他のサービスのポリシーおよびOCI IAMポリシーを参照してください。

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

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

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

図2.1に示すように、OCIコンソールに移動し、DR保護グループに移動します。
1. OCIリージョン・コンテキストがRegion 1 (Dubai)に設定されていることを確認します。
2. 「Migration & Disaster Recovery」をクリックします。
3. 「DR保護グループ」をクリックします。
図2.1: DR保護グループに移動します。
図2.2に示すように、リージョン1に基本的なDR保護グループ(DRPG)を作成します。ピア、ロールおよびメンバーは、後のステップで割り当てられます。
1. DRPGを作成するコンパートメントを選択します。
2. 「DR保護グループの作成」をクリックして、ダイアログを開きます。
3. DRPGに意味のある名前を使用します。
4. OCI Full Stack DRログのOCI Object Storageバケットを選択します。
5. 「作成」をクリックします。
図2.2:リージョン1でDR保護グループを作成するために必要なパラメータ

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

図2.3に示すように、OCIコンソールに移動し、「DR保護グループ」に移動します。
1. OCIリージョン・コンテキストがリージョン2 (Abu Dhabi)に設定されていることを確認します。
2. 「Migration & Disaster Recovery」をクリックします。
3. 「DR保護グループ」をクリックします。
図2.3: DR保護グループに移動します。
図2.4に示すように、リージョン2に基本的なDR保護グループ(DRPG)を作成します。ピア、ロールおよびメンバーは、後のステップで割り当てられます。
1. DRPGを作成するコンパートメントを選択します。
2. 「DR保護グループの作成」をクリックして、ダイアログを開きます。
3. DRPGに意味のある名前を使用します。
4. OCI Full Stack DRログのOCI Object Storageバケットを選択します。
5. 「作成」をクリックします。
図2.4:リージョン2でDR保護グループを作成するために必要なパラメータ

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

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

「DR保護グループの詳細」ページに移動します。
1. OCIリージョン・コンテキストがRegion 1 (Dubai)に設定されていることを確認します。
2. 「関連付け」をクリックして、プロセスを開始します。
図: DRPG関連付けの開始
次の図に示すようにパラメータを入力します。
1. ロール: 「プライマリ」ロールを選択します。OCI Full Stack DRは、スタンバイ・ロールをリージョン2に自動的に割り当てます。
2. ピア・リージョン:他のDRPGが作成されたリージョン2 (アブダビ)を選択します。
3. ピアDR保護グループ:作成されたピアDRPGを選択します。
4. 「関連付け」をクリックします
図: DRPGの関連付けに必要なパラメータ

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

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

図:個々のDRPGパースペクティブからのピア関係の表示

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

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

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

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

このタスクでは、リージョン1のプライマリDRPGに次のOCIリソースを追加します。

WordPressアプリケーションをホストする2つのコンピュート・インスタンスが、移動するVMとして追加されます。また、「拡張オプション」の「ファイル・システム」セクションが適切に構成されていることを確認します。
WordPressアプリケーション・コンピュート・ノードのブート・ボリュームを含むボリューム・グループ。
WordPressコンテンツを含むOCIファイル・ストレージ。
プライマリ・ロード・バランサ。

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

次の図に示すように、リージョン1でDRPGを選択します。
1. OCIリージョン・コンテキストがリージョン1 (Dubai)であることを確認します。
2. リージョン1でDRPGを選択します。
3. 「メンバー」を選択します。
4. 「メンバーの追加」をクリックしてプロセスを開始します。
図:リージョン1でDR保護グループへのメンバーの追加を開始する方法
WordPressアプリケーションVMのコンピュート・インスタンスを追加します。
1. DR計画に関する警告を確認します。
2. メンバーの「リソース・タイプ」として「コンピュート」と入力します。
3. WordPressアプリケーションをホストするコンピュート・インスタンスを選択します。
4. 「移動インスタンス」を選択します。
5. 「VNICマッピングの追加」をクリックして、リカバリ中にリージョン2でVNICに割り当てるVCNおよびサブネットを選択します。
6. 「拡張オプションの表示」をクリックします。
7. 「設定」で、「フォルト・ドメインの保持」を選択します。
8. 「ファイル・システム」で、次のイメージに示すように、設定に従ってエクスポート・マッピング・セクションを完了します。
図: WordPressアプリケーションVMを追加するために必要なパラメータ

図:リージョン2でVNICをマップするために必要なパラメータ

図:拡張オプション、「フォルト・ドメインの保持」

図:拡張オプション、ファイル・システムのマッピング

図:リージョン1のDRPGに追加されたコンピュート・インスタンス

ノート: WordPressアプリケーションVMのすべてのコンピュート・インスタンスについて、前のサブステップを繰り返します。

図:リージョン1のDRPGに追加された2つのコンピュート・インスタンス
WordPressアプリケーションVMのブート・ボリュームを含むブロック・ボリューム・グループを追加します。
1. DR計画に関する警告を確認します。
2. メンバーの「リソース・タイプ」として「ボリューム・グループ」を選択します。
3. ボリューム・グループを含む正しいコンパートメントが選択されていることを確認し、ボリューム・グループを選択します。
図: WordPressコンピュート用のボリューム・グループを追加するために必要なパラメータ

図:リージョン1のDRPGに追加されたWordPressコンピュート用のボリューム・グループ
WordPressコンテンツを含むOCIファイル・ストレージを追加します。
1. DR計画に関する警告を確認します。
2. メンバーの「リソース・タイプ」として「ファイル・システム」を選択します。
3. ファイル・システムを含む正しいコンパートメントが選択されていることを確認し、ファイル・システムを選択します。
4. リージョン2で使用する「宛先可用性ドメイン」を選択します。
5. このファイル・システムの「ソース・エクスポート・パス」を選択します。このエクスポート・パスは、ファイル・システムのリストア後に宛先リージョン2に作成されます。
6. リストアされたファイル・システムのエクスポートを作成するために使用されるリージョン2で、「宛先マウント・ターゲット」を選択します。
図: WordPressコンテンツのファイル・システムを追加するために必要なパラメータ

図:リージョン1のDRPGに追加されたWordPressコンテンツのファイル・システム
OCIロード・バランサを追加します。

この例では、ロード・バランサをリージョン1のDRPGのメンバーとして追加します。
1. DR計画に関する警告を確認します。
2. メンバーの「リソース・タイプ」として「ロード・バランサ」を選択します。
3. ロード・バランサの正しいコンパートメントが選択されていることを確認し、追加するロード・バランサを選択します。
4. リージョン2で使用する「宛先ロード・バランサ」を選択します。
5. 「ソース・バックエンド・セット」を選択します。これは、WordPressアプリケーションVMで使用されるバックエンド・セットです。OCIロード・バランサは、複数のアプリケーション間で共有でき、複数のバックエンド・セットが構成されている場合があります。DRスイッチオーバー中、ここで指定したバックエンド・セットのみの構成がスタンバイ・リージョンに移動されます。
6. 「宛先バックエンド・セット」を選択します。これは、リージョン2で作成された空のバックエンド・セットです。
図:ロード・バランサの追加に必要なパラメータ

図:リージョン1のDRPGに追加されたロード・バランサ

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

次の図に示すように、リージョン2でDRPGを選択します。
1. OCIリージョン・コンテキストがリージョン1 (Abu Dhabi)であることを確認します。
2. リージョン2でDRPGを選択します。
3. 「メンバー」を選択します。
4. 「メンバーの追加」をクリックしてプロセスを開始します。
図:リージョン2でDR保護グループへのメンバーの追加を開始する方法
OCIロード・バランサを追加します。

この例では、ロード・バランサをリージョン2のDRPGのメンバーとして追加します。
1. DR計画に関する警告を確認します。
2. メンバーの「リソース・タイプ」として「ロード・バランサ」を選択します。
3. ロード・バランサの正しいコンパートメントが選択されていることを確認し、追加するロード・バランサを選択します。
4. リージョン1で使用する宛先ロード・バランサを選択します。
5. 「ソース・バックエンド・セット」を選択します。これは、WordPressアプリケーションVMで使用されるバックエンド・セットです。OCIロード・バランサは、複数のアプリケーション間で共有でき、複数のバックエンド・セットが構成されている場合があります。DRスイッチオーバー中、ここで指定したバックエンド・セットのみの構成がスタンバイ・リージョンに移動されます。
6. 「宛先バックエンド・セット」を選択します。このバックエンド・セットはリージョン2で作成されます。
図:ロード・バランサの追加に必要なパラメータ

図:リージョン2のDRPGに追加されたロード・バランサ

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

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

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

OCI Full Stack DRは、前のタスク中に追加されたメンバー・リソースから導出された組込みステップを使用して、これらの計画を事前移入します。これらの計画は、後で、リカバリ・プロセス中にOracle HeatWave MySQLに固有のタスクを管理するようにカスタマイズされます。

スイッチオーバー計画は、常にスタンバイ・ロールを保持する保護グループ内に作成されます。地域2(アブダビ)は現在スタンバイ保護グループであるため、そこで計画の作成を開始します。

タスク4.1: DR計画の作成

リージョン2(アブダビ)でDRPGを選択して基本計画を作成します。
1. OCIリージョン・コンテキストがリージョン2 (Abu Dhabi)であることを確認します。
2. リージョン2でスタンバイDRPGを選択します。
3. 「プラン」を選択します。
4. 「プランの作成」をクリックしてプロセスを開始します。
図:リージョン2での基本的なDR計画の作成を開始する方法
スイッチオーバー計画を作成します。
1. スイッチオーバー・プランの単純で意味のある「名前」を入力します。名前はできるだけ短くする必要がありますが、一目でわかりやすく、危機時の混乱や人的ミスを減らすことができます。
2. 「プラン・タイプ」に「スイッチオーバー(計画済)」を選択します。
図: DRスイッチオーバー計画の作成に必要なパラメータ
フェイルオーバー計画の作成

次の図に示すように、同じプロセスに従って基本的なフェイルオーバー計画を作成します。
1. 単純で意味のあるフェイルオーバー計画の「名前」を入力します。名前はできるだけ短くする必要がありますが、一目でわかりやすく、危機時の混乱や人的ミスを減らすことができます。
2. 「計画タイプ」に「フェイルオーバー(計画外)」を選択します。
図: DRフェイルオーバー計画の作成に必要なパラメータ

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

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

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

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

データの一貫性を確保するために、アプリケーションVMを正常に停止した後、データベース・バックアップを作成します。
冗長性とディザスタ・リカバリのために、最新のデータベース・バックアップをリモートOCIリージョン2に転送します。
リージョン2の最新のデータベース・バックアップをリストアして、スイッチオーバーのための環境を準備します。
プライベート・データベースのDNSレコードを更新し、アプリケーションVMがリージョン2のデータベースにシームレスに接続できるようにします。
リージョン1のソースMySQLデータベースを終了します。

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

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

図:リージョン2のスイッチオーバー計画のカスタマイズを開始する方法

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

次の図に示すように、スイッチオーバー・プランには、デフォルトで無効になっている3つのプラン・グループがあります。これらの計画グループは、テスト中に安心感を与えるために無効にされ、アーティファクトが削除されないこと、およびテスト・フェーズ中に問題が発生した場合でも実行可能なバックアップ・コピーはそのまま残ります。

ただし、これらの3つの計画グループは、将来のDR操作に必要でなくなるアーティファクトを終了(削除)するように設計されています。これらのプラン・グループを有効にしないと、未使用のアーティファクトは、2つのリージョン間のスイッチオーバーを実行するときに時間の経過とともに累積され続けます。これにより、どのコンピュート・インスタンス、OCIファイル・ストレージおよびボリューム・グループをアクティブにするかが混乱する可能性があります。

オプションで、これらのプラン・グループを有効にすると、本番環境に移行する前に不要なアーティファクトを手動でクリーンアップする必要がなくなります。このプロアクティブなステップにより、本番への移行を合理化し、よりクリーンで管理しやすい環境を維持できます。

プラン- カスタム-so-auh-disabled-show.png
図:計画グループはデフォルトで無効になっています。

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

図:ファイル・システムの終了を有効にする方法

図:「有効化」をクリックして検証します。

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

図:「有効化」をクリックして検証します。

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

図:「有効化」をクリックして検証します。

タスク5.3: DR計画グループの順序変更

ロード・バランサのバックエンド・セットを更新する前に、リージョン2に移動した新しいVMにファイル・システムをマウントする必要があります。これにより、アプリケーションは必要なストレージ・リソースに適切にアクセスできるため、スイッチオーバー・プロセス中のスムーズな移行が容易になります。

図:スイッチオーバー計画の初期順序と順序変更の開始方法を示すスクリーンショット

図:順序変更を開始します。

「ファイル・システム- コンピュート・インスタンスにマウント」を「ロード・バランサ- 宛先バックエンド・セットの更新」の前に移動します。
「変更の保存」をクリックします。

図:最終スイッチオーバー計画の順序

タスク5.4: カスタム・スクリプトを実行するプラン・グループの作成

まず、カスタムのユーザー定義DR計画グループを追加して、DRワークフローをMySQLバックアップ/リストアDRプロセスの特定のニーズにあわせて調整します。

これらの計画グループは、リージョン1のWordPress VM1から必要なスクリプトを起動し、WordPressアプリケーションVMを起動する前にDRワークフローに配置する必要があります。これにより、MySQLデータベースが完全にリストアされ、アプリケーションVMがオンラインになる前に動作することが保証されます。

事前移入されたスイッチオーバー・プランに、「MySQL Databaseバックアップの作成」、「MySQL Databaseバックアップのコピー」、「MySQL Databaseバックアップのリストア」、「MySQL Database DNSの更新」および「MySQL Databaseソースの終了」というカスタム・プランを追加する必要があります。

カスタム・プラン・グループを追加して、MySQLデータベース・バックアップを作成します。
1. 「グループの追加」をクリックします。
2. 単純でわかりやすいプラン・グループの「名前」を入力します。この例では、Create MySQL DB Backupを使用します。
3. 計画グループをDR計画に挿入する位置を選択します。この例では、「次より後に追加」を選択して、組込みプラン・グループ「コンピュート・インスタンス- 起動」の後にユーザー定義プラン・グループを挿入します。
4. 「ステップの追加」をクリックしてダイアログを開き、MySQLデータベース・バックアップを作成するスクリプトを指定します。
図:計画グループを作成するパラメータ MySQL DBバックアップの作成

「プラン・グループ・ステップの追加」に、次の情報を入力します。
1. 単純でわかりやすいステップ名を入力します。この例では、Create MySQL DB Backupを使用します。プラン・グループ名と同じです。
2. このステップが実行されるインスタンスを含むリージョンを選択します。この例では、スクリプトはリージョン1のWordPressアプリケーションVM1で実行されます。
3. 「ローカル・スクリプトの実行」を選択します。
4. リージョン1のWordPressアプリケーションVM1である「ターゲット・インスタンス」を選択します。
5. 「スクリプト・パラメータ」に、スクリプトのフルパスをパラメータとともに入力します。たとえば: /home/opc/mds_copy_restore_bkp/mds_create_bkp.py mds01。
6. 「Run as user」に、opcと入力します。
7. 「ステップの追加」をクリックします。
図:ステップ作成MySQL DBバックアップの追加を作成するためのパラメータ

「追加」をクリックします。

図:計画グループ「MySQL DBバックアップの作成」を追加します。
MySQLデータベース・バックアップをコピーするカスタム・プラン・グループを追加します。
1. 「グループの追加」をクリックします。
2. 単純でわかりやすいプラン・グループ「名前」を入力します。この例では、Copy MySQL DB Backupを使用します。
3. 計画グループをDR計画に挿入する位置を選択します。この例では、「後に追加」を選択して、組込みプラン・グループの「MySQL DBバックアップの作成」の後にユーザー定義プラン・グループを挿入します。
4. 「ステップの追加」をクリックしてダイアログを開き、MySQLデータベース・バックアップをコピーするスクリプトを指定します。
図:計画グループを作成するパラメータ MySQL DBバックアップのコピー

「プラン・グループ・ステップの追加」に、次の情報を入力します。
1. 単純でわかりやすいステップ名を入力します。この例では、Copy MySQL DB Backupを使用します。プラン・グループ名と同じです。
2. このステップが実行されるインスタンスを含むリージョンを選択します。この例では、スクリプトはリージョン1のWordPressアプリケーションVM1で実行されます。
3. 「ローカル・スクリプトの実行」を選択します。
4. リージョン1のWordPressアプリケーションVM1である「ターゲット・インスタンス」を選択します。
5. 「スクリプト・パラメータ」に、スクリプトのフルパスをパラメータとともに入力します。たとえば: /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01。
6. 「Run as user」に、opcと入力します。
7. 「ステップの追加」をクリックします。
図:ステップ・コピーMySQL DBバックアップを追加するパラメータ

「追加」をクリックします。

図:計画グループの追加 MySQL DBバックアップのコピー
カスタム・プラン・グループを追加して、MySQLデータベース・バックアップをリストアします。
1. 「グループの追加」をクリックします。
2. 単純でわかりやすいプラン・グループの「名前」を入力します。この例では、Restore MySQL DB Backupを使用します。
3. 計画グループをDR計画に挿入する位置を選択します。この例では、「次より後に追加」を選択して、組込みプラン・グループの「MySQL DBバックアップのコピー」の後にユーザー定義プラン・グループを挿入します。
4. 「ステップの追加」をクリックしてダイアログを開き、MySQLデータベース・バックアップをリストアするスクリプトを指定します。
図:計画グループを作成するためのパラメータ MySQL DBバックアップのリストア

「プラン・グループ・ステップの追加」に、次の情報を入力します。
1. 単純でわかりやすいステップ名を入力します。この例では、Restore MySQL DB Backupを使用します。プラン・グループ名と同じです。
2. このステップが実行されるインスタンスを含むリージョンを選択します。この例では、スクリプトはリージョン1のWordPressアプリケーションVM1で実行されます。
3. 「ローカル・スクリプトの実行」を選択します。
4. リージョン1のWordPressアプリケーションVM1である「ターゲット・インスタンス」を選択します。
5. 「スクリプト・パラメータ」に、スクリプトのフルパスをパラメータとともに入力します。たとえば: /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config --switch。
6. 「Run as user」に、opcと入力します。
7. 「ステップの追加」をクリックします。
図:ステップ・リストアMySQL DBバックアップを追加するパラメータ

「追加」をクリックします。

図:計画グループの追加 MySQL DBバックアップのリストア
カスタム・プラン・グループを追加して、MySQLデータベースDNSを更新します。
1. 「グループの追加」をクリックします。
2. 単純でわかりやすいプラン・グループ「名前」を入力します。この例では、Update MySQL DB DNSを使用します。
3. 計画グループをDR計画に挿入する位置を選択します。この例では、「次より後に追加」を選択して、組込みプラン・グループの「MySQL DBバックアップのリストア」の後にユーザー定義プラン・グループを挿入します。
4. 「ステップの追加」をクリックしてダイアログを開き、MySQLデータベースDNSを更新するスクリプトを指定します。
図:計画グループを作成するパラメータ MySQL DB DNSの更新

「プラン・グループ・ステップの追加」に、次の情報を入力します。
1. 単純でわかりやすいステップ名を入力します。この例では、Update MySQL DB DNSを使用します。プラン・グループ名と同じです。
2. このステップが実行されるインスタンスを含むリージョンを選択します。この例では、スクリプトはリージョン1のWordPressアプリケーションVM1で実行されます。
3. 「ローカル・スクリプトの実行」を選択します。
4. リージョン1のWordPressアプリケーションVM1である「ターゲット・インスタンス」を選択します。
5. 「スクリプト・パラメータ」に、スクリプトのフルパスをパラメータとともに入力します。たとえば: /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local --remote。
6. 「Run as user」に、opcと入力します。
7. 「ステップの追加」をクリックします。
図:ステップ更新MySQL DB DNSを追加するパラメータ

「追加」をクリックします。

図:計画グループの追加 MySQL DB DNSの更新
MySQLソース・データベースを終了するカスタム・プラン・グループを追加します。
1. 「グループの追加」をクリックします。
2. 単純でわかりやすいプラン・グループの「名前」を入力します。この例では、Terminate MySQL DB Sourceを使用します。
3. 計画グループをDR計画に挿入する位置を選択します。この例では、「後に追加」を選択して、組込みプラン・グループの「ファイル・システム- DR保護グループから削除」の後にユーザー定義プラン・グループを挿入します。
4. 「ステップの追加」をクリックしてダイアログを開き、MySQLデータベース・ソースを終了するスクリプトを指定します。
図:計画グループを作成するためのパラメータMySQLソースDBの終了

「プラン・グループ・ステップの追加」に、次の情報を入力します。
1. 単純でわかりやすいステップ名を入力します。この例では、Terminate MySQL Source DBを使用します。プラン・グループ名と同じです。
2. このステップが実行されるインスタンスを含むリージョンを選択します。この例では、スクリプトはリージョン1のWordPressアプリケーションVM1で実行されます。
3. 「ローカル・スクリプトの実行」を選択します。
4. リージョン1のWordPressアプリケーションVM1である「ターゲット・インスタンス」を選択します。
5. 「スクリプト・パラメータ」に、スクリプトのフルパスをパラメータとともに入力します。たとえば: /home/opc/mds_copy_restore_bkp/mds_terminate_db.py mds01。
6. 「Run as user」に、opcと入力します。
7. 「ステップの追加」をクリックします。
図:ステップを追加するパラメータMySQLソースDBを終了します

「追加」をクリックします。

図:計画グループの追加 MySQLソースDBの終了
(オプション)カスタム・プラン・グループを追加して、WordPressアプリケーションを停止します。
1. 「グループの追加」をクリックします。
2. 単純でわかりやすいプラン・グループの「名前」を入力します。この例では、Application - Stopを使用します。
3. 計画グループをDR計画に挿入する位置を選択します。この例では、「次より後に追加」を選択して、組込みプラン・グループロード・バランサ- ソース・バックエンド・セットの更新の後にユーザー定義プラン・グループの最後に挿入します。
4. 「ステップの追加」をクリックしてダイアログを開き、アプリケーションを停止するスクリプトを指定します。
図:プラン・グループを作成するためのパラメータアプリケーション- 停止

「プラン・グループ・ステップの追加」に、次の情報を入力します。
1. 単純でわかりやすいステップ名を入力します。この例では、Application - Stop - VM1を使用します。
2. このステップが実行されるインスタンスを含むリージョンを選択します。この例では、スクリプトはリージョン1のWordPressアプリケーションVM1で実行されます。
3. 「ローカル・スクリプトの実行」を選択します。
4. リージョン1のWordPressアプリケーションVM1である「ターゲット・インスタンス」を選択します。
5. 「スクリプト・パラメータ」に、スクリプトのフルパスをパラメータとともに入力します。たとえば: /home/opc/fsdrscripts/wdp_stop.sh。
6. 「Run as user」に、opcと入力します。
7. 「ステップの追加」をクリックします。
図:ステップ・アプリケーションを作成するパラメータ- 停止- VM1

「ステップの追加」をクリックして、VM2でアプリケーションを停止する2番目のステップを追加します。

図:ステップ・アプリケーションの追加- 停止- VM2

「プラン・グループ・ステップの追加」に、次の情報を入力します。
1. 単純でわかりやすいステップ名を入力します。この例では、Application - Stop - VM2を使用します。
2. このステップが実行されるインスタンスを含むリージョンを選択します。この例では、スクリプトはリージョン1のWordPressアプリケーションVM2で実行されます。
3. 「ローカル・スクリプトの実行」を選択します。
4. リージョン1のWordPressアプリケーションVM2である「ターゲット・インスタンス」を選択します。
5. 「スクリプト・パラメータ」に、スクリプトのフルパスをパラメータとともに入力します。たとえば: /home/opc/fsdrscripts/wdp_stop.sh。
6. 「Run as user」に、opcと入力します。
7. 「ステップの追加」をクリックします。
図:ステップ・アプリケーションを作成するパラメータ- 停止- VM2

「追加」をクリックします。

図:プラン・グループの追加アプリケーション- 停止
(オプション)カスタム・プラン・グループを追加して、WordPressアプリケーションを起動します。
1. 「グループの追加」をクリックします。
2. 単純でわかりやすいプラン・グループの「名前」を入力します。この例では、Application - Startを使用します。
3. 計画グループをDR計画に挿入する位置を選択します。この場合、「後に追加」を選択して、組込みプラン・グループ「ファイル・システム- コンピュート・インスタンスへのマウント」の後にユーザー定義プラン・グループの最後に挿入します。
4. 「ステップの追加」をクリックしてダイアログを開き、アプリケーションを起動するスクリプトを指定します。
図:プラン・グループを作成するためのパラメータアプリケーション- 開始

「プラン・グループ・ステップの追加」に、次の情報を入力します。
1. 単純でわかりやすいステップ名を入力します。この例では、Application - Start - VM1を使用します。
2. このステップが実行されるインスタンスを含むリージョンを選択します。この場合、スクリプトはリージョン1のWordPressアプリケーションVM1で実行されます。
3. 「ローカル・スクリプトの実行」を選択します。
4. リージョン1のWordPressアプリケーションVM1である「ターゲット・インスタンス」を選択します。
5. 「スクリプト・パラメータ」に、スクリプトのフルパスをパラメータとともに入力します。たとえば: /home/opc/fsdrscripts/wdp_start.sh。
6. 「Run as user」に、opcと入力します。
7. 「ステップの追加」をクリックします。
図:ステップ・アプリケーションを作成するパラメータ- 開始- VM1

「ステップの追加」をクリックして、VM2でアプリケーションを起動する2番目のステップを追加します。

図:ステップ・アプリケーションの追加- 開始- VM2

「プラン・グループ・ステップの追加」に、次の情報を入力します。
1. 単純でわかりやすいステップ名を入力します。この例では、Application - Start - VM2を使用します。
2. このステップが実行されるインスタンスを含むリージョンを選択します。この場合、スクリプトはリージョン1のWordPressアプリケーションVM2で実行されます。
3. 「ローカル・スクリプトの実行」を選択します。
4. リージョン1のWordPressアプリケーションVM2である「ターゲット・インスタンス」を選択します。
5. 「スクリプト・パラメータ」に、スクリプトのフルパスをパラメータとともに入力します。たとえば: /home/opc/fsdrscripts/wdp_start.sh。
6. 「Run as user」に、opcと入力します。
7. 「ステップの追加」をクリックします。
図:ステップ・アプリケーションを作成するパラメータ- 開始- VM2

「追加」をクリックします。

図:プラン・グループの追加: アプリケーション- 開始

スイッチオーバー・プランのカスタマイズが正常に完了しました。

プラン・カスタム・ソー・オー complete.png

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

このタスクでは、カスタムのユーザー定義DR計画グループおよびステップを追加して、フェイルオーバー中に実行する必要があるタスクを管理します。

リージョン2の最新のデータベース・バックアップをリストアして、スイッチオーバーのための環境を準備します。
プライベート・データベースのDNSレコードを更新し、アプリケーションVMがリージョン2のデータベースにシームレスに接続できるようにします。

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

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

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

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

これらの計画グループは、WordPressアプリケーションVMから必要なスクリプトを起動し、WordPressアプリケーションVMを再起動する前にDRワークフローに配置する必要があります。これにより、MySQLデータベースが完全にリストアされ、アプリケーションVMがオンラインになる前に動作することが保証されます。

事前移入されたフェイルオーバー計画に、「MySQL Databaseバックアップのリストア」および「MySQL Database DNSの更新」というカスタム計画を追加する必要があります。

カスタム・プラン・グループを追加して、MySQLデータベース・バックアップをリストアします。
1. 「グループの追加」をクリックして開始します。
2. 単純でわかりやすいプラン・グループの「名前」を入力します。この例では、Restore MySQL DB Backupを使用します。
3. 計画グループをDR計画に挿入する位置を選択します。この例では、「次より後に追加」を選択して、組込みプラン・グループ「コンピュート・インスタンス- 起動」の後にユーザー定義プラン・グループを挿入します。
4. 「ステップの追加」をクリックしてダイアログを開き、MySQLデータベース・バックアップをリストアするスクリプトを指定します。
図:計画グループを作成するためのパラメータ MySQL DBバックアップのリストア

「プラン・グループ・ステップの追加」に、次の情報を入力します。
1. 単純でわかりやすいステップ名を入力します。この例では、Restore MySQL DB Backupを使用します。プラン・グループ名と同じです。
2. このステップが実行されるインスタンスを含むリージョンを選択します。この例では、スクリプトはリージョン1のWordPressアプリケーションVM1で実行されます。
3. 「ローカル・スクリプトの実行」を選択します。
4. リージョン1のWordPressアプリケーションVM1である「ターゲット・インスタンス」を選択します。
5. 「スクリプト・パラメータ」に、スクリプトのフルパスをパラメータとともに入力します。たとえば: /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config。
6. 「Run as user」に、opcと入力します。
7. 「ステップの追加」をクリックします。
図:ステップ・リストアMySQL DBバックアップを追加するパラメータ

「追加」をクリックします

図:計画グループの追加 MySQL DBバックアップのリストア
MySQLデータベースDNSを更新するカスタム・プラン・グループを追加します。
1. 「グループの追加」をクリックして開始します。
2. 単純でわかりやすいプラン・グループの「名前」を入力します。この例では、Update MySQL DB DNSを使用します。
3. 計画グループをDR計画に挿入する位置を選択します。この例では、「次より後に追加」を選択して、組込みプラン・グループの「MySQL DBバックアップのリストア」の後にユーザー定義プラン・グループを挿入します。
4. 「ステップの追加」をクリックしてダイアログを開き、MySQLデータベースDNSを更新するスクリプトを指定します。
図:計画グループを作成するパラメータ MySQL DB DNSの更新

「プラン・グループ・ステップの追加」に、次の情報を入力します。
1. 単純でわかりやすいステップ名を入力します。この例では、Update MySQL DB DNSを使用します。プラン・グループ名と同じです。
2. このステップが実行されるインスタンスを含むリージョンを選択します。この例では、スクリプトはリージョン1のWordPressアプリケーションVM1で実行されます。
3. 「ローカル・スクリプトの実行」を選択します。
4. リージョン1のWordPressアプリケーションVM1である「ターゲット・インスタンス」を選択します。
5. 「スクリプト・パラメータ」に、スクリプトのフルパスをパラメータとともに入力します。たとえば: /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local。
6. 「Run as user」に、opcと入力します。
7. 「ステップの追加」をクリックします。
図:ステップ更新の追加MySQL DB DNSを作成するためのパラメータ

「追加」をクリックします。

図:計画グループの追加 MySQL DB DNSの更新
(オプション)カスタム・プラン・グループを追加して、WordPressアプリケーションを再起動します。
1. 「グループの追加」をクリックします。
2. 単純でわかりやすいプラン・グループの「名前」を入力します。この例では、Application - Restartを使用します。
3. 計画グループをDR計画に挿入する位置を選択します。この例では、「後に追加」を選択して、組込みプラン・グループの「ファイル・システム- コンピュート・インスタンスへのマウント」の後にユーザー定義プラン・グループを挿入します。
4. 「ステップの追加」をクリックしてダイアログを開き、アプリケーションを起動するスクリプトを指定します。
図:プラン・グループを作成するためのパラメータアプリケーション- 再起動

「プラン・グループ・ステップの追加」に、次の情報を入力します。
1. 単純でわかりやすいステップ名を入力します。この例では、Application - Restart - VM1を使用します。
2. このステップが実行されるインスタンスを含むリージョンを選択します。この例では、スクリプトはリージョン1のWordPressアプリケーションVM1で実行されます。
3. 「ローカル・スクリプトの実行」を選択します。
4. リージョン1のWordPressアプリケーションVM1である「ターゲット・インスタンス」を選択します。
5. 「スクリプト・パラメータ」に、スクリプトのフルパスをパラメータとともに入力します。たとえば: /home/opc/fsdrscripts/wdp_restart.sh。
6. 「Run as user」に、opcと入力します。
7. 「ステップの追加」をクリックします。
図:ステップ・アプリケーションを作成するパラメータ- 再起動- VM1

「ステップの追加」をクリックして、VM2でアプリケーションを再起動する2番目のステップを追加します。

図:ステップ・アプリケーションの追加- 再起動- VM2

「プラン・グループ・ステップの追加」に、次の情報を入力します。
1. 単純でわかりやすいステップ名を入力します。この例では、Application - Start - VM2を使用します。
2. このステップが実行されるインスタンスを含むリージョンを選択します。この例では、スクリプトはリージョン1のWordPressアプリケーションVM2で実行されます。
3. 「ローカル・スクリプトの実行」を選択します。
4. リージョン1のWordPressアプリケーションVM2である「ターゲット・インスタンス」を選択します。
5. 「スクリプト・パラメータ」に、スクリプトのフルパスをパラメータとともに入力します。たとえば: /home/opc/fsdrscripts/wdp_restart.sh。
6. 「Run as user」に、opcと入力します。
7. 「ステップの追加」をクリックします。
図:ステップ・アプリケーションを作成するパラメータ- 再起動- VM2

「追加」をクリックします。

図:プラン・グループの追加: アプリケーション- 再起動

フェイルオーバー・プランのカスタマイズが正常に完了しました。

プラン・カスタム・フォー・オー complete.png

タスク7: リージョン2での事前チェックの実行

スイッチオーバーとフェイルオーバーの両方のDR計画が、スタンバイ・リージョン2で正常に作成されました。これらの計画により、OCI Full Stack DRはワークロードをリージョン1からリージョン2に移行できます。後続のタスクでは、スイッチオーバー計画とフェイルオーバー計画の両方に対する事前チェックを実行して、移行プロセスの準備と検証を確実に行います。

タスク7.1: スイッチオーバー計画の事前チェックの開始

スイッチオーバーDR計画の事前チェックを実行します。

リージョン・コンテキストがスタンバイ・リージョン2に設定されていることを確認します。
リージョン2で正しいDR保護グループが選択されていることを確認し、スタンバイ・ロールである必要があります。
スイッチオーバー計画の名前をクリックします。
「事前チェックの実行」をクリックします。

事前チェック-so-auh-begin.png
図:スイッチオーバー計画の事前チェックの実行方法の表示

事前チェック-so-auh-complete.png
図:スイッチオーバー計画の完了済事前チェックの表示

タスク7.2: フェイルオーバー計画の事前チェックの開始

フェイルオーバーDR計画の事前チェックを実行します。

リージョン・コンテキストがスタンバイ・リージョン2に設定されていることを確認します。
リージョン2で正しいDR保護グループが選択されていることを確認し、スタンバイ・ロールである必要があります。
フェイルオーバー・プランの名前をクリックします。
「事前チェックの実行」をクリックします。

図:フェイルオーバー計画の事前チェックの実行方法を示します。

図:フェイルオーバー計画の完了済事前チェックの表示

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

スイッチオーバーDR計画を実行して、Oracle HeatWave MySQLでリージョン1からリージョン2にWordPressアプリケーションを移行するプロセスを開始します。

リージョン・コンテキストがスタンバイ・リージョン2に設定されていることを確認します。
リージョン2で正しいDR保護グループが選択されていることを確認し、スタンバイ・ロールである必要があります。
スイッチオーバー計画の名前をクリックします。
「プランの実行」をクリックします。

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

タスク7ですでに実行されているため、「事前チェックの有効化」の選択を解除します。
「DR計画の実行」をクリックして開始します。

exec-so-auh begin.png
図:スイッチオーバー計画の実行方法の表示

図:スイッチオーバー計画の進行中の表示

ワークロード全体がリージョン1からリージョン2に完全に移行されるまで、スイッチオーバー計画をモニターします。

スイッチオーバー計画の実行は、約52分で正常に完了しました。

図:完了したスイッチオーバー計画実行の表示。

タスク9: リージョン1でのDR計画の作成およびカスタマイズ

OCI Full Stack DRによるスイッチオーバーが正常に完了すると、リージョン2はプライマリ・リージョンの役割を引き継ぎ、リージョン1はスタンバイ・リージョンとして機能するように移行しました。

タスク1から8で説明した同じアプローチに従って、リージョン1のDR保護グループ内のスイッチオーバーおよびフェイルオーバー計画を作成し、カスタマイズします。この計画は、スタンバイ・ピア・リージョンとして機能します。

計画- 作成-dxb.png
図:リージョン1で作成されたプランを示すスクリーンショット

プラン・ソ・カスタマイズ-dxb.png
図:リージョン1のスイッチオーバー計画を示すスクリーンショット

プラン-FO- カスタマイズ-dxb.png
図:リージョン1のフェイルオーバー計画を示すスクリーンショット

次のステップ

詳細は、「関連リンク」の項のOCI Full Stack DRおよびOracle HeatWave MySQLのドキュメントを参照してください。

Oracle Cloud Infrastructure (OCI)フル・スタック・障害時リカバリ
Oracle HeatWave MySQL
OCIフル・スタック・災害復旧
HeatWave MySQL
#full-stack-drスラックチャネルに参加する

承認

著者 - Antoun Moubarak (ハイパースケーラからOCIスペシャリスト)
コントリビュータ - Suraj Ramesh (OCI Full Stack DRの製品マネージャー)

その他の学習リソース

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

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

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

Automate Cold Disaster Recovery for Oracle HeatWave MySQL using OCI Full Stack Disaster Recovery

G24412-01

January 2025

Oracle and/or its affiliates.