はじめに

皆さん、こんにちは、Oracle Cloud Infrastructure検証チームです。 こちらの記事は、「【OCI】フルスタックディザスタリカバリについて検証してみた（3/4）」の続きの記事となります。 長かったフルスタックディザスタリカバリの検証もついに最後となりました。 どうぞ最後までお付き合いください。 よろしくお願いします！

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

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

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

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

検証内容について

検証内容

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

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

検証環境の構成

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

リカバリ実行

実際にDR計画を実行して、フェイルオーバできるか試してみましょう。

リカバリ前のスタンバイ側の状態

まずは、リカバリ実行の前後で何が変化したかを確認できるように、リカバリ前のスタンバイリージョンのリソースの状態を確認しておきましょう。

スタンバイのDR保護グループ

まずスタンバイのDR保護グループには現状ではNLBしかメンバーが追加されていません。

  コンピュートインスタンス

コンピュートインスタンスですが、こちらはリカバリ実行時に移動インスタンスとして作成されるため、まだ存在していません。

  ネットワークロードバランサ(NLB)

NLB自体は存在していますが、バックエンドセットにはコンピュートインスタンスが一つも含まれていない状況です。 なぜなら、バックエンドセットのバックエンドとなるコンピュートは、DR計画の実行時に移動インスタンスとしてスタンバイで新規作成されるインスタンスのためです。 リカバリ前の現段階ではスタンバイ側ではコンピュート自体が作成されていないので、NLBのバックエンドセットにも含まれていないというわけです。

オブジェクトストレージ

スタンバイ側にもプライマリ側と同じ名前のバケットが存在しています。 そして、このバケットはプライマリのバケットからのレプリケーションの宛先となっています。 ただし、このバケットはレプリケーションの宛先なので読み取り専用となります。

  アプリケーション

検証用WEBアプリケーションの状態も確認しておきましょう。 まずトップページにアクセスすると、現在はプライマリ側のコンピュートで稼働中なので、「プライマリで稼働中」と表示されます。 また、ファイル出力機能を使った際も現在はプライマリ側のバケットにファイルが出力されるはずです。 プライマリ側のバケットにファイルが出力されています。 もっとも、現在はプライマリ側とスタンバイ側のバケットでレプリケーションを設定しているため、以下画像の様にスタンバイ側のバケットにもファイルが出力されています。 ですのでアプリケーションからは、プライマリ側のバケットにファイルを出力していることがいまいちわかりにくいです。 しかし、スタンバイ側のバケットは現在レプリケーションの宛先となっているため、読み取り専用の状態でありファイルのアップロードはできません。 したがって、スタンバイのバケットにファイルを出力しようとしていたら、エラーになっているはずです。 現在アプリケーションのファイル出力機能でエラーが発生していないなら、プライマリ側のバケットにファイルを出力していることでしょう。 試しにOCI SDKの設定ファイルを、スタンバイリージョン接続用の設定ファイルに切り替えてファイル出力機能を使ってみると、以下の様にエラーが発生します。

[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ #プライマリ用OCI SDK設定ファイル
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ cat /home/apuser/.oci/config_prm
[DEFAULT]
user=＜API接続用ユーザのOCID＞
fingerprint=＜APIキーのフィンガープリント＞
key_file=/home/apuser/.oci/oci_api_key.pem
tenancy=＜OCIのテナンシのOCID＞
region=ap-tokyo-1
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ #スタンバイ用OCI SDK設定ファイル
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ cat /home/apuser/.oci/config_sby
[DEFAULT]
user=＜API接続用ユーザのOCID＞
fingerprint=＜APIキーのフィンガープリント＞
key_file=/home/apuser/.oci/oci_api_key.pem
tenancy=＜OCIのテナンシのOCID＞
region=ap-osaka-1
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ #現在のOCI SDK設定ファイル
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ cat /home/apuser/.oci/config
[DEFAULT]
user=＜API接続用ユーザのOCID＞
fingerprint=＜APIキーのフィンガープリント＞
key_file=/home/apuser/.oci/oci_api_key.pem
tenancy=＜OCIのテナンシのOCID＞
region=ap-tokyo-1
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ diff /home/apuser/.oci/config /home/apuser/.oci/config_prm
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ diff /home/apuser/.oci/config /home/apuser/.oci/config_sby
6c6
< region=ap-tokyo-1
---
> region=ap-osaka-1
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ #OCI SDK設定ファイル切り替え
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ cp -p /home/apuser/.oci/config_sby /home/apuser/.oci/config
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ cat /home/apuser/.oci/config
[DEFAULT]
user=＜API接続用ユーザのOCID＞
fingerprint=＜APIキーのフィンガープリント＞
key_file=/home/apuser/.oci/oci_api_key.pem
tenancy=＜OCIのテナンシのOCID＞
region=ap-osaka-1
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ diff /home/apuser/.oci/config /home/apuser/.oci/config_prm
6c6
< region=ap-osaka-1
---
> region=ap-tokyo-1
[apuser@ap-prm-1 ~]$

エラーメッセージには「Bucket ‘TEST_BUCKET’ in namespace ‘xxxxxxxxxxxxx’ is in read-only state」とあり、ファイル出力先のバケットが読み取り専用であることからエラーが起きてるようです。 反対に、OCI SDKの設定ファイルをプライマリリージョン接続用の設定ファイルに切り替えてみると、以下のようにファイル出力機能が正常に機能します。

[apuser@ap-prm-1 ~]$ #OCI SDK設定ファイルをプライマリのものに切り替え
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ cp -p /home/apuser/.oci/config_prm /home/apuser/.oci/config
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ cat /home/apuser/.oci/config
[DEFAULT]
user=＜API接続用ユーザのOCID＞
fingerprint=＜APIキーのフィンガープリント＞
key_file=/home/apuser/.oci/oci_api_key.pem
tenancy=＜OCIのテナンシのOCID＞
region=ap-tokyo-1
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ diff /home/apuser/.oci/config /home/apuser/.oci/config_prm
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ diff /home/apuser/.oci/config /home/apuser/.oci/config_sby
6c6
< region=ap-tokyo-1
---
> region=ap-osaka-1
[apuser@ap-prm-1 ~]$

このことからも、アプリケーションから直接ファイルを出力しているのはプライマリ側のバケットであることがわかりそうです。

プライマリ停止

次に、疑似的に障害が発生したと想定し、プライマリ側のインスタンスを停止します。 ブラウザでNLBのIPにアクセスしても、WEBアプリケーションに接続できないことを確認します。

DR計画実行

では、DR計画を実行し、スタンバイリージョンへのリカバリ操作を行います。 スタンバイ側のDR計画の詳細画面に行き、「アクション」→「計画の実行」をクリックします。 「計画の実行」画面が表示されますので、各設定値を入力し「計画の実行」ボタンをクリックします。 すると、DR計画の事前チェックを行ったときと同様に、「計画実行」リソースが作成され計画グループ、計画ステップの進捗状況を確認できます。 また、計画事前チェックを行ったときと同様に計画ステップの実行状況のログを表示することもできます。 しばらくすると、すべての計画実行グループの進捗状況が「成功」に変わるはずです。 これで、DR計画によるリカバリが正常に完了したということになります。

リカバリ後の確認

それでは、各リソースがきちんとリカバリできているかを確認していきましょう。

スタンバイのDR保護グループ

まずは、スタンバイのDR保護グループのメンバーを見てみます。 すると、リカバリ実行前はメンバーがNLBしかいませんでしたが、リカバリ実行後はコンピュートインスタンス、オブジェクトストレージ、ボリュームグループなども追加されていることがわかります。

コンピュートインスタンス

次に、コンピュートインスタンスの一覧画面に行くと、プライマリ側のものと同じ名前のインスタンスが作成され、起動中になっているのがわかります。

 ネットワークロードバランサ(NLB)

そして、スタンバイ側のNLBのバックエンドセットを確認すると、作成されたコンピュートがバックエンドとして追加されています。

オブジェクトストレージ

また、オブジェクトストレージのバケットはレプリケーションポリシーの方向が逆になり、スタンバイ側のバケットがソース、プライマリ側のバケットが宛先となっています。 なので、リカバリ後はスタンバイ側のバケットに書き込みが可能で、プライマリ側のバケットは読み取り専用ということになります。

アプリケーション

では、アプリケーションのリカバリはできているでしょうか？ スタンバイ側のNLBのIPアドレスにブラウザからアクセスしてみます。 トップページにスタンバイで稼働している旨のメッセージが表示されています。 トップページのHTMLの切り替えは問題なくできていそうですね。 オブジェクトストレージへのファイル出力機能も確認します。 適当なファイルを出力し、それがスタンバイ側のバケットに格納されているかを見てみましょう。 スタンバイ側のバケットに対象のファイルが出力できていますね。 また、このファイルをダウンロードして中身を見てみると先ほど入力したメッセージが記載されています。 ただし、リカバリ前と同じように現在もスタンバイとプライマリのバケットでレプリケーションが設定されているため、プライマリ側のバケットにもファイルは格納されています。 しかし、先ほど確認したようにリカバリ後はプライマリ側がレプリケーションの宛先で読み取り専用状態になっているので、プライマリ側にファイルを出力しようとした場合、エラーになるはずです。 エラー無くファイル出力機能が使えているなら、スタンバイ側のバケットにファイルを出力できていそうですね。 実際、リカバリ前に確認したときと同様に、OCI SDKの設定ファイルをプライマリへの接続用のものに切り替えてファイル出力機能を試してみると以下の様にエラーが出力されます。

[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ #現在のOCI SDK設定ファイル
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ cat /home/apuser/.oci/config
[DEFAULT]
user=＜API接続用のOCIユーザのOCID＞
fingerprint=＜APIキーのフィンガープリント＞
key_file=/home/apuser/.oci/oci_api_key.pem
tenancy=＜OCIのテナンシのOCID＞
region=ap-osaka-1
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ diff /home/apuser/.oci/config /home/apuser/.oci/config_prrm
6c6
< region=ap-osaka-1
---
> region=ap-tokyo-1
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ diff /home/apuser/.oci/config /home/apuser/.oci/config_sbby
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ cp -p /home/apuser/.oci/config_prm /home/apuser/.oci/conffig
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ cat /home/apuser/.oci/config
[DEFAULT]
user=＜API接続用のOCIユーザのOCID＞
fingerprint=＜APIキーのフィンガープリント＞
key_file=/home/apuser/.oci/oci_api_key.pem
tenancy=＜OCIのテナンシのOCID＞
region=ap-tokyo-1
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ diff /home/apuser/.oci/config /home/apuser/.oci/config_prrm
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ diff /home/apuser/.oci/config /home/apuser/.oci/config_sbby
6c6
< region=ap-tokyo-1
---
> region=ap-osaka-1
[apuser@ap-prm-1 ~]$

反対にOCI SDKの設定ファイルをスタンバイへの接続用のものに戻すと、正常にファイル出力ができるようになります。

[apuser@ap-prm-1 ~]$ #現在のOCI SDK設定ファイル
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ cat /home/apuser/.oci/config
[DEFAULT]
user=＜API接続用のOCIユーザのOCID＞
fingerprint=＜APIキーのフィンガープリント＞
key_file=/home/apuser/.oci/oci_api_key.pem
tenancy=＜OCIのテナンシのOCID＞
region=ap-tokyo-1
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ diff /home/apuser/.oci/config /home/apuser/.oci/config_prm
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ diff /home/apuser/.oci/config /home/apuser/.oci/config_sby
6c6
< region=ap-tokyo-1
---
> region=ap-osaka-1
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ #OCI SDK設定ファイルをスタンバイのものに切り替え
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ cp -p /home/apuser/.oci/config_sby /home/apuser/.oci/config
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ cat /home/apuser/.oci/config
[DEFAULT]
user=＜API接続用のOCIユーザのOCID＞
fingerprint=＜APIキーのフィンガープリント＞
key_file=/home/apuser/.oci/oci_api_key.pem
tenancy=＜OCIのテナンシのOCID＞
region=ap-osaka-1
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ diff /home/apuser/.oci/config /home/apuser/.oci/config_prm
6c6
< region=ap-osaka-1
---
> region=ap-tokyo-1
[apuser@ap-prm-1 ~]$ 
[apuser@ap-prm-1 ~]$ diff /home/apuser/.oci/config /home/apuser/.oci/config_sby
[apuser@ap-prm-1 ~]$

このようなことからも、リカバリ後はアプリケーションからはスタンバイリージョンのバケットにファイルを出力するようになっていると判断できるでしょう。 このように、フルスタックディザスタリカバリの機能によって、コンピュートやオブジェクトストレージなどのOCIのインフラストラクチャからアプリケーションまでを障害発生時にリカバリすることができます。

おわりに

以上が今回フルスタックディザスタリカバリについて検証した内容となります。 ご覧いただきありがとうございました。 フルスタックディザスタリカバリでは、コンピュート、オブジェクトストレージ、ロードバランサ、アプリケーションなどシステムを構成する諸々のコンポーネントを、障害発生時にまとめてリカバリすることができます。 そのため、コンピュートやロードバランサなど個々のコンポーネントを別々にリカバリするよりも作業が効率化されるし、リカバリ作業におけるオペレーションミスも防げるのではないでしょうか。

OCIに関するお問い合わせはこちら

投稿者プロフィール

技術チーム

DBひとりでできるもんを盛り上げるべく、技術チームが立ち上がり早8年。ひとりでできるもんと言いつつ、技術者が読んでプッとなるような、極めてピンポイントでマニアックな技術ネタを執筆しています！
最新技術情報や資格情報をチェックしたいアナタ！毎日遊びに来てください。きっとお役に立てます。

• Infrastructure(IaaS)2025年7月29日【OCI】フルスタックディザスタリカバリについて検証してみた（4/4）
• Infrastructure(IaaS)2025年7月28日【OCI】フルスタックディザスタリカバリについて検証してみた（3/4）
• Infrastructure(IaaS)2025年7月25日【OCI】フルスタックディザスタリカバリについて検証してみた（2/4）
• Infrastructure(IaaS)2025年7月24日【OCI】フルスタックディザスタリカバリについて検証してみた（1/4）