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

2025年7月24日 Infrastructure(IaaS)

はじめに
フルスタックディザスタリカバリとは
フルスタックディザスタリカバリの概念について
検証内容について
フルスタックディザスタリカバリの前提条件
おわりに

はじめに

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

今回は、OCIの障害対策サービスであるフルスタックディザスタリカバリについて検証してみました。
この記事では、フルスタックディザスタリカバリの概要、および検証した内容についてご紹介させていただきます。

なお、記事が少し長くなってしまったので4回にわたってフルスタックディザスタリカバリについて紹介させていただければと思います。

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

フルスタックディザスタリカバリとは

まずは、フルスタックディザスタリカバリ（以下、フルスタックDR)の概要について説明します。

フルスタックDRは、システムを構成する様々なOCIリソースに対して、包括的なリカバリ機能を提供するサービスです。
OCI上に構築されるシステムは、コンピュート、データベース、ロードバランサ、オブジェクトストレージ、など様々な種類のリソースから構成されている場合が多いかと思います。
OCIのリージョン障害などで、これらのリソースの複数あるいはすべてが使えなくなってしまったとき、フルスタックDRが別のリージョンで同等のリソースを起動したり、作成してくれます。
つまり、システム全体に影響するような障害発生時に、別リージョンでリソースをリカバリしてくれる機能が、フルスタックDRとなります。

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

フルスタックディザスタリカバリの概念について

次に、フルスタックDRで登場するいくつかの概念について説明します。

保護グループ

保護グループは、リカバリの対象となるリソースをまとめたOCIリソースです。
例えば、システムがコンピュート、データベース、オブジェクトストレージで構成されているため、障害発生時はフルスタックDRによって、これらをまとめて別リージョンでリカバリするとします。
その場合、まずこれらのリソースを保護グループとしてグループ化します。

そして、リカバリ時に使われる別リージョン側(スタンバイのリージョン側)でも、同様に保護グループを作成し、商用のリージョン側(プライマリのリージョン側）の保護グループと紐づけます（この保護グループ間の紐づけをアソシエーションと呼びます)。

こうすることで、障害発生時は商用のシステムをプライマリの保護グループからスタンバイの保護グループへ切り替え、業務を継続することができます。
また、コンピュートやデータベースなど、保護グループに追加されるリソースのことはメンバーとも呼ばれます。

ロール

ロールは、あるリージョンで稼働するシステムが、商用システムとして稼働しているか、それとも障害対策用の予備のシステムとして稼働しているか、ということを表す概念です。
商用システムとして稼働している場合はプライマリのロール、障害対策用として稼働している場合はスタンバイのロールということになります。

DR計画

DR計画は、プライマリからスタンバイへとリカバリする際に、どのようにしてリカバリするか、というリカバリの手順を定義するOCIリソースです。
「プライマリでのコンピュートの停止」、「スタンバイでのコンピュートの起動」などのようにリカバリする際の操作を定義します。
そして、障害発生時にはこのDR計画を実行することで、フルスタックDRサービスがリカバリ操作を行います。

また、DR計画には以下4つの種類が存在します。

フェイルオーバ(計画外)
プライマリ側で想定外の障害が発生したときに、スタンバイ側でシステムを起動するための計画タイプです。
スイッチオーバ(計画済み)
メンテナンスやパッチ適用などでプライマリのシステムを計画的に停止する際に、スタンバイ側でシステムを起動するための計画タイプです。フェイルオーバとの違いとして、スイッチオーバではプライマリ側のリソースを停止してからスタンバイ側のリソースを起動します。
ドリルの開始
スタンバイ側で正常にシステムを起動できるかをチェックするための計画タイプです。このタイプの計画を実行すると、スタンバイの保護グループにリソースのレプリカが作成されます。
ドリルの停止
「ドリルの開始」でスタンバイ側に作成されたリソースのレプリカを削除するための計画タイプです。

検証内容について

それでは、フルスタックディザスタリカバリの概要について説明したところで、さっそく実機検証に移っていきたいと思います。

検証内容

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

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

検証環境の構成

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

以下、検証環境についてのより詳細な説明です。

■各リージョンには以下のリソースが存在します。

ネットワークロードバランサ(以下、NLBと省略します)
2台のコンピュートインスタンス(※1)
オブジェクトストレージのバケット

これらのリソースが、DR保護グループにメンバーとして追加されることになります。

※1 もっとも、コンピュートインスタンスは通常運用時(障害が発生していないとき)はプライマリリージョンにしか存在しません。スタンバイリージョンには障害が発生したときにのみ新規で作成されます。これについては記事の中でこれから説明していきます。

■コンピュートインスタンスのOSは、Oracle Linux 8.10となります。

■2台のコンピュートインスタンス上では検証用の簡易的なWEBアプリケーションが稼働しています。エンドユーザはインターネットからNLBを介してこのアプリケーションにアクセスするものと想定します。

■また、このアプリケーションはオブジェクトストレージのバケットへファイルを出力する機能を持っています。

検証用WEBアプリケーションの仕様

先ほど説明した通り、コンピュートインスタンス上では検証用のWEBアプリケーションが稼働しています。このアプリケーションの仕様についても見ておきましょう。

まず、検証用WEBアプリケーションのトップ画面が以下のような画面になります。

トップ画面では、現在このアプリケーションがプライマリとスタンバイ、どちらのリージョンのコンピュートインスタンス上で動いているかを示すメッセージが表示されます。

今回の検証では、フルスタックDRでリカバリを行い、スタンバイリージョンでアプリケーションが稼働するようになった際には、このメッセージが「スタンバイで稼働中」と表示されるよう設定します。

また、トップ画面のテキストボックスに何らかのメッセージを入力して「ファイル出力」ボタンを押すと、入力したメッセージがファイルに出力され、さらにそのファイルがオブジェクトストレージに格納されます。試しにファイルを一つ出力してみましょう。

「ファイル出力ボタン」を押すと、画面が遷移して出力されたファイル名が表示されます。

このファイルがオブジェクトストレージのバケットに格納されているかを確かめてみましょう。

格納されていますね。
テキストエディタでファイルを開いて、ファイルの中身が先ほど入力したメッセージ通りであるかも確認しておきます。

先ほど入力したメッセージが記載されているので、ファイル出力はきちんとできていそうです。

しかし、アプリケーションは普段はプライマリリージョン(東京リージョン)のオブジェクトストレージに接続するようになっています。

ですので、フルスタックDRによってスタンバイリージョン(大阪)へリカバリした際には、アプリケーションが大阪リージョンのオブジェクトストレージに接続するようにする必要があります。
今回は、これを実現する方法についても検証していきます。

フルスタックディザスタリカバリの前提条件

コンピュートやオブジェクトストレージなどのリソースを保護グループのメンバーとして追加するには、これらのリソースに対していくつか事前に行うべき設定があります。

コンピュートインスタンスの前提条件

まず、コンピュートインスタンスの場合、ブートボリューム(※1)を含むボリュームグループが必要ですので、作成していきます。
※1 今回はボリュームグループに追加するのはブートボリュームだけですが、コンピュートに追加のブロックボリュームなどがアタッチされている場合、それもボリュームグループに含める必要があります。

対象となるコンピュートインスタンスは、以下のAP_PRM_1、AP_PRM_2の2台です。

そして、それぞれのインスタンスのブートボリュームが以下となります。

ボリュームグループを作成し、これらのブートボリュームを追加します。
OCIコンソールのメニューから、「ストレージ」→「ボリュームグループ」をクリックします。

ボリュームグループの一覧画面が表示されたら、「ボリューム・グループの作成」ボタンをクリックします。

ボリュームグループの作成画面が表示されるので、名前、コンパートメント、可用性ドメインに任意の値を入力し、「次」ボタンをクリックします。

次に、このボリュームグループに追加するボリュームの選択画面が現れます。
先ほど確認した、2台のコンピュートのブートボリュームを選択しましょう。

次に、クロスリージョンレプリケーションの設定画面が表示されます。
ここでは、レプリケーションを「オン」にして、有効化します。
なぜなら、このボリュームグループも後でフルスタックDRの保護グループにメンバーとして追加するためです。

そして、DR保護グループのメンバーにブロックストレージを追加する場合、プライマリリージョンとスタンバイリージョン間でレプリケーション(※2)する必要があります。
そのため、ここでもボリュームグループを東京リージョンから大阪リージョンへとレプリケーションします。
※2 今回はボリュームグループを、DR保護グループのメンバーに追加するため、リージョン間レプリケーションを設定しましたが、レプリケーションではなくリージョン間のバックアップでも可能です。

次の「バックアップ・ポリシー」の画面は、デフォルト値のまま特に設定せずに進みます。

「サマリー」の画面で、ボリュームグループの設定内容を確認し、「作成」ボタンをクリックします。

ボリュームグループが作成されていること、および、対象のコンピュートインスタンスのブートボリュームが含まれていることを確認しましょう。

オブジェクトストレージの前提条件

次に、オブジェクトストレージのバケットを保護グループに追加するための設定を行います。
なお、オブジェクトストレージのバケットは、プライマリリージョンのバケットと、スタンバイリージョンのバケットでレプリケーションを行う必要があります。

OCIコンソールのメニューから「ストレージ」→「オブジェクト・ストレージとアーカイブ・ストレージ」→「バケット」を選択します。

バケットの一覧画面が表示されるので、対象のバケットを選択します。

バケットの詳細画面が現れたら、画面右の「リソース」から「レプリケーション・ポリシー」を選択し、「ポリシーの作成」ボタンをクリックします。

「レプリケーション・ポリシーの作成」画面で以下のように入力し、「作成」ボタンをクリックします。

名前
任意のレプリケーションポリシーの名前
宛先リージョン
レプリケーションの宛先となるバケットがあるリージョン
今回は、スタンバイリージョンである大阪リージョンとなります
～（コンパートメント名）の宛先バケット
レプリケーションの宛先となるバケットの名前
スタンバイリージョン側にあるバケットを指定します。

その後、バケットの詳細画面に遷移しますので、レプリケーション・ポリシーが作成され有効になっていることを確認しましょう。

リカバリ操作ログ用バケットの作成

フルスタックDRではリカバリを行った際に、リカバリ操作の実行結果などのログが出力されます。
このリカバリ操作ログは、オブジェクトストレージのバケットに格納されます。
そのため、事前にリカバリ操作ログ用のバケットを作成しておく必要があります。

なお、操作ログ用バケットを作成する際のガイドラインが以下のOCIのマニュアルに記載されています。作成時はこのガイドラインに注意しましょう。
https://docs.oracle.com/ja-jp/iaas/disaster-recovery/doc/object-storage-for-logs.html

このガイドラインをまとめると以下のようなものになります。これに準拠してバケットを作成していきます。