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

2025年7月25日 Infrastructure(IaaS)

はじめに
（おさらい）フルスタックディザスタリカバリとは
検証内容について
- 検証内容
- 検証環境の構成
保護グループの構成
おわりに

はじめに

皆さん、こんにちは、Oracle Cloud Infrastructure検証チームです。こちらの記事は、「【OCI】フルスタックディザスタリカバリについて検証してみた（1/4）」の続きの記事となります。前回のおさらいをしつつ、今回もフルスタックディザスタリカバリについて検証していきます。よろしくお願いします！

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

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

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

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

検証内容について

検証内容

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

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

検証環境の構成

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

保護グループの構成

DR保護グループ作成(プライマリ)

まずは、プライマリリージョンで保護グループを作成します。リージョンを東京リージョンにして、OCIコンソールのメニューから「移行とディザスタ・リカバリ」→「ディザスタ・リカバリ」→「DR保護グループ」を選択します。保護グループの一覧画面が表示されるので、「DR保護グループの作成」ボタンをクリックします。 DR保護グループの作成画面が表示されますので、次のように各設定値を入力し、最後に「作成」ボタンをクリックします。

名前任意の名前を入力します。今回は「PRM_GRP」とします。
コンパートメント 保護グループを作成するコンパートメントを指定します。
オブジェクト・ストレージ・バケット リカバリ時の操作ログ格納用のバケットを指定します。ここでは、先ほど作成した「fullStackDR_LOG」を指定します。
ロール この保護グループが、プライマリ側のものか、スタンバイ側のものかを指定します。ここでは一旦「未構成」のままにしておきます。なぜなら、このあとプライマリの保護グループを、スタンバイの保護グループと関連付ける操作(アソシエーション)を行いますが、この関連付けはロールが未構成の保護グループでないと行えないためです。
メンバーの追加 保護グループ作成時点でメンバーを追加することもできますが、今回は後から追加するため、何も指定しないままにしておきます。

正常に作成されると、以下のように保護グループの詳細画面が表示され、ライフサイクルステートが「アクティブ」となっているはずです。

DR保護グループ作成(スタンバイ)

スタンバイリージョンでも保護グループを作成します。大阪リージョン側の保護グループの一覧画面にアクセスして、「DR保護グループの作成」をクリックします。作成画面で各種設定値を入力し、「作成」ボタンをクリックします。保護グループが作成されたことを確認します。

保護グループの関連付け

続いて、プライマリとスタンバイの保護グループ同士の関連付けを行います。プライマリリージョン(東京)の保護グループのページへアクセスし、画面上部の「アクション」から「関連付け」ボタンをクリックします。「保護グループの関連付け」画面が開くので、以下のように入力します。

ロール 「プライマリ」を指定します
ピア・リージョン 大阪リージョンを指定します。
ピアDR保護グループ 先ほど作った大阪リージョン側の保護グループを指定します。

入力出来たら「関連付け」ボタンをクリックします。関連付けを行うと、プライマリの保護グループの詳細画面に「プライマリ」と表示されるようになります。また、「ピアDR保護グループ」がスタンバイ側の保護グループとなっていることがわかります。また、スタンバイ側の保護グループも見てみると、こちらはロールが「スタンバイ」になっており、「ピアDR保護グループ」がプライマリ側の保護グループになっているのがわかります。これで、保護グループ間の関連付けができました。

保護グループへのメンバー追加(プライマリ)

次に、各保護グループにコンピュート、オブジェクトストレージなどのメンバーを追加していきます。まずはプライマリの保護グループからメンバーを追加していきましょう。

コンピュートインスタンスの追加

最初に、コンピュートインスタンス2台を追加していきます。保護グループの詳細画面で、「メンバー」タブを選択します。メンバーの一覧画面が表示されるので、「メンバーの追加」ボタンをクリックします。「メンバーの追加」画面で、以下のように入力します。

リソース・タイプ 「コンピュート」を指定します。
インスタンス 「AP_PRM_1」を指定します。
コンピュート・インスタンス・タイプ この項目は、リカバリ操作中にどのようにしてスタンバイリージョンでコンピュートを起動するかを指定します。設定値として「移動インスタンス」か「非移動インスタンス」を選択します。「移動インスタンス」を選ぶと、リカバリ時にスタンバイリージョンでコンピュートが新規作成されて起動します。「非移動インスタンス」を選ぶと、リカバリ時に新規作成はされず、スタンバイリージョンの既存のインスタンスがプライマリリージョンの代替として起動されます。なので、普段はスタンバイ側にはコンピュートは存在せず、障害発生時のみスタンバイで起動したいというような場合は、「移動インスタンス」を使うことができます。それに対して、通常時もスタンバイリージョンにコンピュートが存在するので障害発生時はそれを使用したい、という場合は「非移動インスタンス」を使うこともできます。今回の検証ではスタンバイ側には事前にコンピュートを作成していないので「移動インスタンス」を選択します。
VNICマッピングの追加 これはインスタンス・タイプを「移動インスタンス」にした場合に、設定する項目です。この項目では、移動インスタンスのコンピュートをスタンバイ側で作成する際、コンピュートのVNICが配置されるVCN、サブネットを指定します。

また、「すべての既存プランをリフレッシュし、検証する必要があることを理解しています」というチェックボックスにチェックを入れます。このチェックボックスはコンピュートに限らず、何らかのメンバーを保護グループに追加する際にチェックする必要があります。ここまで入力出来たら「追加」ボタンをクリックします。すると、メンバーの一覧画面にコンピュートが追加されます。同じようにして、2台目のコンピュートインスタンスもメンバーに追加していきます。これでコンピュート2台が保護グループのメンバーとして追加されました。

ネットワークロードバランサの追加

次は、ネットワークロードバランサ(NLB)をメンバーに追加します。 NLBをメンバーに追加する際は、プライマリ側NLBのバックエンドセットと、スタンバイ側NLBのバックエンドセットをマッピングします。なので、最初にプライマリ、スタンバイそれぞれのNLBのバックエンドセットを確認しておきます。まず、プライマリのNLBが以下の「NLB_PRM」で、「NLB_BS_PRM」というバックエンドセットを持っています。そして、スタンバイ側のNLBが以下の「NLB_SBY」で、「NLB_BS_SBY」というバックエンドセットを持っています。以上を踏まえてNLBを保護グループのメンバーに追加していきます。メンバーの追加画面で以下のように入力します。

リソースタイプ 「ネットワーク・ロードバランサ」を指定します。
ネットワーク・ロード・バランサ 対象のNLBの名前を入力します。
宛先ネットワーク・ロード・バランサ スタンバイリージョンのNLBを指定します。
ソース・バックエンド・セット プライマリのNLBのバックエンドセットである「NLB_BS_PRM」を指定します。
宛先バックエンド・セット プライマリのバックエンドセットに対応する、スタンバイのバックエンドセットを指定します。なので今回は「NLB_BS_SBY」を指定します。リカバリの際には、ソース・バックエンド・セット内のバックエンドサーバが、宛先バックエンド・セットに追加されることになります。
移動不可能なコンピュート・インスタンスのみ対象 これは、バックエンドセット内のサーバが非移動インスタンスのみの場合にチェックする項目です。今回、バックエンド内のサーバはすべて移動インスタンスなのでチェックは外したままにしておきます。

以上のように入力したら、「追加」ボタンを押します。 NLBがメンバーに追加されていることを確認します。

ボリュームグループの追加

次に、コンピュートのブートボリュームが含まれているボリュームグループをメンバーに追加します。メンバーの追加画面で以下のように入力し、「追加」ボタンをクリックします。

リソースタイプ 「ボリューム・グループ」を選択します。
ボリューム・グループ メンバーに追加するボリュームグループの名前を指定します。
宛先のバックアップ・ポリシー 今回は特にバックアップポリシーの設定を行っていないため何も指定しません。
暗号化タイプ デフォルトの「このボリューム・グループに存在するボリュームの暗号化キーを更新しない」のままにしておきます。

ボリュームグループがメンバーに追加されたことを確認します。

バケットの追加

続いて、オブジェクトストレージのバケットをメンバーに追加します。メンバーの一覧画面から「メンバーの追加」をクリックします。メンバーの追加画面で以下のように入力し、「追加」ボタンをクリックします。

リソースタイプ 「オブジェクト・ストレージ・バケット」を選択します。
オブジェクト・ストレージ・バケット メンバーに追加するバケットの名前を入力します。

バケットがメンバーに追加されていることを確認します。以上で、プライマリへのメンバー追加が完了となります。

保護グループへのメンバー追加(スタンバイ)

スタンバイの保護グループにもメンバーを追加します。なお、スタンバイの保護グループに追加するメンバーは、NLBのみとなります。その他のリソースはリカバリを行った際に、スタンバイの保護グループにメンバーとして追加されるためここでは追加しません。リージョンを大阪リージョンにして、メンバーの追加画面を開きます。メンバー追加画面でネットワークロードバランサを追加していきます。スタンバイの保護グループにも、NLBがメンバーとして追加されたことを確認します。これで、プライマリ、スタンバイともに保護グループにメンバーを追加することができました。