【OCI】フルスタックディザスタリカバリについて検証してみた（3/4）

2025年7月28日 Infrastructure(IaaS)

はじめに
（おさらい）フルスタックディザスタリカバリとは
検証内容について
- 検証内容
- 検証環境の構成
DR計画の作成
ユーザ定義計画グループの作成
DR計画事前チェック
おわりに

はじめに

皆さん、こんにちは、Oracle Cloud Infrastructure検証チームです。

こちらの記事は、「【OCI】フルスタックディザスタリカバリについて検証してみた（2/4）」の続きの記事となります。
今回もフルスタックディザスタリカバリについて検証していきます。
よろしくお願いします！

今回の執筆者は Oracle Cloud Infrastructure 2024 Certified Architect Associate、ORACLE MASTER Silver DBA 2019を取得しました！に登場しています！

（おさらい）フルスタックディザスタリカバリとは

フルスタックディザスタリカバリ（以下、フルスタックDR)とは、システムを構成する様々なOCIリソースに対して、包括的なリカバリ機能を提供するサービスです。
システム全体に影響するような障害発生時に、フルスタックDRが別のリージョンで同等のリソースを起動したり、作成してくれる機能です。

今回の記事では、リージョン間でのリカバリを扱いますが、可用性ドメインが複数ある場合は、可用性ドメイン間でもリカバリ可能です。

検証内容について

検証内容

以下が大まかな検証内容となります。今回の記事では赤字になっている部分を扱います。
それ以外は次回の記事で扱います。

フルスタックディザスタリカバリの前提となる設定（済)
保護グループの構成（済）
DR計画の作成（今回）
ユーザ定義計画グループの作成（今回）
DR計画事前チェック（今回）
リカバリ実行（次回）

検証環境の構成

今回の検証環境は以下の図のように、東京リージョンと大阪リージョンの2リージョンにまたがります。
東京リージョンがプライマリのリージョン、大阪リージョンがスタンバイのリージョンとなります。
そして、東京リージョンで障害が起こったと想定し、フルスタックDRの機能で大阪リージョンへとリソースをリカバリできるかを検証していきます。

詳細は初回の記事をご覧ください。

DR計画の作成

DR計画はスタンバイのリージョンで作成する必要があります。
そのため、まずは大阪リージョンの保護グループの詳細画面にアクセスし、「計画」タブを選択します。

DR計画の一覧画面が表示されるので、「計画の作成」ボタンをクリックします。

「計画の作成」画面で以下のように入力し、「作成」ボタンを押します。

名前任意のDR計画の名前。今回は「TEST_FAILOVER_PLAN」とします。
プラン・タイプ DR計画のタイプを指定します。今回は想定外の障害が発生した際のリカバリを想定して、「フェイルオーバ(計画外)」を指定します。

「作成」ボタンを押すとDR計画の一覧画面に戻ります。
一覧画面で今作成したDR計画が存在していることを確認します。

DR計画の詳細な内容も見てみましょう。
DR計画一覧の中から、作成された計画をクリックするとDR計画の詳細画面が表示されます。

DR計画の詳細画面からは、上記のようにDR計画に含まれている「計画グループ」を確認できます。
計画グループとは、「コンピュートの起動」、「ボリュームグループのフェイルオーバ」など個別のリソースに対するリカバリ処理を表すリソースです。

計画グループはさらに、「計画ステップ」というより細かい単位から構成されており、OCIコンソール上では計画グループの左端にある矢印ボタンを押すことで、個々の計画グループに含まれる計画ステップを表示できます。

ユーザ定義計画グループの作成

新規作成されたDR計画には、上記のようにデフォルトでいくつかの計画グループが含まれています。しかし、DR計画にはこうしたデフォルトの計画グループだけでなく、ユーザが独自に作成した計画グループも含めることができます。

そうすることで、デフォルトの計画グループだけでは対応しきれないユーザ独自のリカバリ要件を満たすことができます。
そして、今回の検証でもこうしたユーザ定義の計画グループを作成し、コンピュート上で動作するWEBアプリケーションのリカバリ処理を実装してみたいと思います。

前回ご説明したように、このアプリケーションはオブジェクトストレージへのファイル出力機能を持っています。また、アプリケーションのトップページで、現在プライマリリージョン、スタンバイリージョンのどちらで稼働しているかを表示するようになっていました。
ですので、フルスタックDRによってスタンバイリージョンへリカバリした際には、アプリケーションについても以下のような処理を行いたいです。

ファイル出力先のオブジェクトストレージのバケットを、東京リージョンのものから大阪リージョンのものにする
トップページにスタンバイリージョンで稼働している旨のメッセージが表示されるようにする

これらの処理を、ユーザ定義の計画グループを作って実現していきたいと思います。また、ユーザ定義の計画グループでは実行したい処理を、以下3つのいずれかの方法で行います。

オブジェクト・ストレージ・スクリプト 実行したい処理をスクリプトとして実装し、そのスクリプトをオブジェクトストレージに格納します。そして、コンピュートインスタンスのコマンド実行(※1)機能を使って、オブジェクトストレージ内のスクリプトをリカバリ操作の際に実行します。
ローカルスクリプト スクリプトを作成し、それをコマンド実行機能で実行するところはオブジェクトストレージと同じです。ただし、スクリプトはコンピュートインスタンス内のファイルとして保存されます。
Oracle Functions リカバリ操作で実行したい処理をOCIのFunctionsサービスで実装します。 Functionsとはサーバなどを用意することなくアプリケーションコードを実行できるOCIのサービスのことです。

今回の検証では、この中の「ローカル・スクリプト」を使います。

※1 「コマンド実行」機能は、OCIのコンピュートインスタンスに対して、リモートでコマンドを実行できる機能です。コンピュートにSSH接続やRDP接続ができない状況でも、OCIコンソールなどからコンピュートに対してコマンドを発行し、その実行結果を確認することができます。

ローカル・スクリプトの作成

まずは、計画グループの中で実行されるローカル・スクリプトを作成します。
今回の検証では、このスクリプトはアプリケーションが稼働しているコンピュート上に格納します。

そして、コンピュートのOSはOracle Linuxなので、bashのシェルスクリプトとしてスクリプトを書いていきます。スクリプトで実装したい処理は以下の通りです。

アプリケーションがスタンバイリージョンのオブジェクトストレージへ接続するようにする →OCI SDKの設定ファイルを、スタンバイリージョン用のものに置き換える
アプリケーションのトップページにスタンバイリージョンで稼働している旨のメッセージを表示させる →トップページのHTMLをスタンバイリージョン用のものに置き換える

そして、これらの処理を盛り込んだ実際のスクリプトが以下となります。

#!/bin/bash

#スクリプト実行ログ
RECOVERY_LOG="/var/log/FSDR_test/$(date +%Y%m%d_%H%M%S)_recovery_standby.log"

#OCI SDKの設定ファイルをスタンバイ用のものに置き換える
cp -p /home/apuser/.oci/config_sby /home/apuser/.oci/config
RC=${?}

if [ ${RC} -ne 0 ] ; then
    echo "$(date +%Y%m%d_%H%M%S) OCI SDK設定ファイル切り替え失敗" >> "${RECOVERY_LOG}"
    echo "$(date +%Y%m%d_%H%M%S) スタンバイへのリカバリ操作を異常終了します。" >> "${RECOVERY_LOG}"
    exit 1
else
    echo "$(date +%Y%m%d_%H%M%S) OCI SDK設定ファイル切り替え成功" >> "${RECOVERY_LOG}"
fi

#トップページのhtmlファイルをスタンバイ用のものに置き換える
cp -p /usr/ap/ap_venv/fdrTest/fdrTestApp/templates/fdrTestApp/index.html_sby /usr/ap/ap_venv/fdrTest/fdrTestApp/templates/fdrTestApp/index.html
RC=${?} 

if [ ${RC} -ne 0 ] ; then 
    echo "$(date +%Y%m%d_%H%M%S) トップページのHTMLの置き換えに失敗" >> "${RECOVERY_LOG}" 
    echo "$(date +%Y%m%d_%H%M%S) スタンバイへのリカバリ操作を異常終了します。" >> "${RECOVERY_LOG}" 
    exit 1 
else 
    echo "$(date +%Y%m%d_%H%M%S) トップページのHTMLの置き換えに成功" >> "${RECOVERY_LOG}" 
fi

#アプリケーションはApacheと統合されており、Apacheの再起動でアプリケーションも起動するため、Apacheを再起動
apachectl restart
RC=${?}

if [ ${RC} -ne 0 ] ; then 
    echo "$(date +%Y%m%d_%H%M%S) Apache再起動に失敗" >> "${RECOVERY_LOG}" 
    echo "$(date +%Y%m%d_%H%M%S) スタンバイへのリカバリ操作を異常終了します。" >> "${RECOVERY_LOG}" 
    exit 1 
else 
    echo "$(date +%Y%m%d_%H%M%S) Apache再起動に成功" >> "${RECOVERY_LOG}" 
fi

echo "$(date +%Y%m%d_%H%M%S) スタンバイへのリカバリ操作が正常終了しました。" >> "${RECOVERY_LOG}" 
exit 0

このスクリプトを、アプリケーションが動くコンピュート(AP_PRM_1、AP_PRM_2)内に「/usr/ap/script/recovery_standby.sh」というファイル名で保存しておきます。

計画グループの追加

スクリプトが作成できたら、既存のDR計画にユーザ定義の計画グループを追加していきます。
DR計画の詳細画面で「グループの追加」ボタンをクリックします。

「計画グループの追加」画面では、既存の計画グループの中の、どの位置にこの計画グループを挿入するかを指定できます。
「グループ名」に計画グループの名前を入力します。
ここでは「Application Launch」とします。
その後、「後に追加」にチェックを入れ、「グループ」に「Compute Instances – Launch」を選択します。

これで、この計画グループがコンピュートインスタンスが起動した後に実行されるようになります。

次に、「ステップの追加」ボタンをクリックします。
すると、「計画グループ・ステップの追加」画面が表示されるので、以下のように入力していきます。

ステップ名 この計画ステップの名前を入力します。「Run Recovery Script 1」としておきましょう。
ユーザ定義のステップ・タイプ 「ローカル・スクリプトの実行」を指定します。
インスタンスリージョン スクリプトが格納されているコンピュートインスタンスのリージョンを指定します。現在はまだリカバリ操作を行っていないため、プライマリリージョンにしかコンピュートインスタンスは存在しません。なので、東京リージョンを指定します。
ターゲットインスタンス スクリプトが格納されているコンピュートインスタンスを指定します。ここでは「AP_PRM_1」を指定します。
スクリプト・パラメータ 実行したいスクリプトを指定します。先ほど作った/usr/ap/script/recovery_standby.shを指定します。
実行ユーザ スクリプトを実行するユーザを指定します。recovery_standby.shはrootユーザでの実行を想定しているので、「root」と入力します。
エラー・モード この計画グループがエラーになった場合の、後続の計画グループの挙動を指定します。ここでは、デフォルトの「エラー時に停止」のままにしておきましょう。
タイムアウトを秒単位で指定 計画グループのタイムアウト時間を指定します。デフォルトの3600秒(1時間)のままにしておきます。
ステップの有効化 チェックを入れて、リカバリ操作時にこの計画ステップが実行されるようにします。

ここまで入力出来たら「ステップの追加」ボタンをクリックします。

すると、計画グループの作成画面に戻るので、計画ステップが追加されていることを確認します。

また、今のはコンピュートのうち1台目に対するスクリプト実行の計画ステップです。
2台目のコンピュートに対してスクリプトを実行する計画ステップも追加していきます。

コンピュート2台目のための計画ステップも追加できたら、「追加」ボタンをクリックします。

DR計画の詳細画面に戻るので、ユーザ定義の計画グループ、及び計画ステップが追加されたことを確認しましょう。

コマンド実行用動的グループの設定

先ほどご説明したように、ユーザ定義の計画グループでローカル・スクリプトを実行する際は、コンピュートインスタンスのコマンド実行機能が内部的に使用されます。

コマンド実行機能を使うためには新しい動的グループを作成し、この動的グループにスクリプトが実行されるコンピュートを追加する必要があります。
そして、この動的グループにコマンド実行機能を使うためのポリシーを付与する必要もあります。

ここでは、こちらの動的グループとポリシーの設定についてご説明します。
まず今回は以下のような動的グループを作成しました。ここでは一致ルールを「Any{instance.compartment.id = ‘xxxxxxxxxxxxxxxxxxx’}」としました。

これは、「インスタンスが存在するコンパートメントのOCIDが「xxxxxxxxxxxxxxxxxxx」であれば、そのインスタンスをこの動的グループに追加する」という意味の一致ルールになります。

具体的なコンパートメントのOCIDは伏せていますが、実際には検証用のコンピュート(AP_PR_1、AP_PRM_2)が存在するコンパートメントのOCIDを指定していますので、AP_PRM_1、AP_PRM_2の2台がこの動的グループに追加されることになります。

そしてこの動的グループに対してコマンド実行機能を利用するためのポリシーを付与します。
そのポリシーが以下の3つとなります。以上がコマンド実行機能を使うための動的グループとポリシーの設定となります。

コマンド実行のためのsudo設定

今作成したユーザ定義の計画グループでは、rootユーザでローカル・スクリプトを実行するようになっていました。

rootユーザでローカル・スクリプトを実行するためには、コンピュートインスタンス上のocarunというユーザが、パスワードなしでsudoコマンドを実行できる必要があります。

こちらの設定も行っていきます。

まず、rootユーザでプライマリリージョンのコンピュートインスタンスにログインします。
そして、以下の手順でocarunユーザにsudo権限を付与していきます。

#コマンド実行用のsudoers設定ファイルを作成
[root@ap-prm-1 ~]# vi ./101-oracle-cloud-agent-run-command

↓↓↓↓↓以下の行を記載↓↓↓↓↓
ocarun ALL=(ALL) NOPASSWD:ALL

[root@ap-prm-1 ~]# 
[root@ap-prm-1 ~]# 
#作成したsudoers設定ファイルの構文をチェック
[root@ap-prm-1 ~]# visudo -cf ./101-oracle-cloud-agent-run-command
./101-oracle-cloud-agent-run-command: parsed OK
[root@ap-prm-1 ~]#
[root@ap-prm-1 ~]#
#作成したsudoers設定ファイルを、sudoersの所定の設定ファイル格納用ディレクトリにコピー
[root@ap-prm-1 ~]# cp ./101-oracle-cloud-agent-run-command /etc/sudoers.d
[root@ap-prm-1 ~]# 
[root@ap-prm-1 ~]# ls -l /etc/sudoers.d
total 20
-r--r-----. 1 root root 746 May 14 02:33 090-oca-vss-plugin-commands
-r--r-----. 1 root root 4884 May 14 02:33 100-oracle-cloud-agent-users
-rw-r--r-- 1 root root 31 May 30 07:38 101-oracle-cloud-agent-run-command
-r--r-----. 1 root root 131 May 27 07:12 90-cloud-init-users
[root@ap-prm-1 ~]# 
[root@ap-prm-1 ~]# cat /etc/sudoers.d/101-oracle-cloud-agent-run-command
ocarun ALL=(ALL) NOPASSWD:ALL

[root@ap-prm-1 ~]#

※なお、上記の手順はAP_PRM_1で実施した手順ですが、AP_PRM_2でも同じ手順を実施する必要があります。コマンド自体は同じなので割愛させていただきます。