OCI Full Stack Disaster Recovery (FSDR) が Load Balancer 対応になったので試してみた

FSDRのLB対応について

OCI Full Stack Disaster Recovery (FSDR)は、2022年11月からOCIで利用ができるようになった Disaster Recovery as a Service (DRaaS)です。

2023年12月からはこのFSDRがLoad Balancer対応になり、DR対象のメンバとしてLoad Balancerが追加できるようになったのでLoad BalancerとコンピュートVM2台構成のシステムをFSDRのメンバーに追加し東京とソウルのリージョンを使って実際にDRさせて使ってみます。

事前準備

FSDRについては

フル・スタックの障害時リカバリを使用したOCIリージョン間での仮想マシンの移動
https://docs.oracle.com/ja/learn/full-stack-dr-to-move-vm/#introduction

などを参照し、事前にプライマリ・リージョン、スタンバイ・リージョンの両方で

• コンパートメント
• VCN
• サブネット
• セキュリティ・リスト
• オブジェクト・ストレージ・バケットの作成
• Load Balancer
• DR保護グループ

を準備する必要があります。
加えて、

• コンピュートVMの準備
• ボリューム・グループの準備

が必要です。

ちょっと準備が面倒だなと思った人は
こちらをこのまま実行していただければ、準備が整いますのでやってみてください。
OCI Load Balancer と Oracle Linux 9 でロードバランシングを体験
https://qiita.com/Assemble_EX-80/items/09d552f69e8b60e6f804

DR保護グループに関しては次のセクションで記述します。ここではコンピュートVMの準備とボリュームグループの準備について少し触れます。

• コンピュートVMの準備

プライマリ・リージョンでコンピュートのVMをプロビジョニングします。VMをDR保護グループのメンバーとして追加するとき、移動インスタンス として追加するか、非移動インスタンス としてメンバーに追加するかを選択する必要があります。

移動インスタンスとしてメンバーに追加する場合はスタンバイリージョンにはVMインスタンスを用意しておく必要はありません。DR計画を実施することによりVMはスタンバイリージョンに移動し、指定のLoad Balancerのバックエンドセットに追加されます。

• ボリュームグループの準備（とレプリケーション）

移動インスタンスを利用する場合は、事前にプライマリ・リージョンで、ボリュームグループを作成しておき、移動インスタンスとするVMのブートボリュームをボリュームグループに追加、ボリュームグループはスタンバイ・リージョンに向けてレプリケーションさせておく必要があります。

ボリューム・グループ・レプリケーション に関しての詳細は、こちらのマニュアルを参照
https://docs.oracle.com/ja-jp/iaas/Content/Block/Concepts/volumegroupreplication.htm

実際の設定はこちらを参照
その５ オブジェクト・ストレージ、ブロック・ボリューム 作成・設定
https://qiita.com/Assemble_EX-80/items/b846a3ac8aa8de71301a

ボリューム・グループ設定

ボリューム・グループ

名前: vg_01
クロス・リージョン・レプリケーション: オン
ターゲット・リージョン: South Korea Central (Seoul)
ターゲット可用性ドメイン: TGjA:AP-SEOUL-1-AD-1
ブート・ボリューム
 instance-A1-01 (Boot Volume)   <--- instance-01 のブートボリュームを追加
 instance-E4-02 (Boot Volume)   <--- instance-02 のブートボリュームを追加

移動インスタンスとLoad Balancerを含むDR構成

今回は、上位に Load Balancerを配置、Load Balancerのバックエンドセットに2台のWebサーバのコンピュートVMが配置され動作しているWebシステムのDRを想定します。

東京とソウル、2つのリージョン利用のDR構成で、コンピュートVMは移動インスタンス としてFSDRのメンバに追加、DRaaS機能を動作させてみます。

VCN、オブジェクトストレージ、VM、Load Balancerの作成方法についてはここでは触れませんが、事前に以下のような設定がされている想定です。

ここで用いるVCN、オブジェクトストレージ、VM、Load Balancerをステップバイステップで準備ができるような記事をこちらに用意しましたのでご参照ください。
OCI Load Balancer と Oracle Linux 9 でロードバランシングを体験
https://qiita.com/Assemble_EX-80/items/09d552f69e8b60e6f804

Tokyo Region 設定情報

VCN
名前: vcn01
 IPv4 CIDRブロック: 10.0.0.0/16
public_subnet
 IPv4 CIDRブロック: 10.0.0.0/24
private_subnet
 IPv4 CIDRブロック: 10.0.1.0/24
セキュリティーリスト
 イングレスルール 追加
  ソースCIDR: 0.0.0.0/0
  宛先ポート範囲: Port 80,433
インターネット・ゲートウェイ
 internet_gw01
デフォルトルート
 internet_gw01

オブジェクト・ストレージ
 バケット 名前: bucket-01

VM
 instance-01
  Private IP: 10.0.0.101  
 instance-02
  Private IP: 10.0.0.102

Load Balancer
 名前: lb_01
 バックエンド・セット: bs_lb_01
 バックエンド: instance-01, instance-02

Seoul Region 設定情報

VCN
名前: vcn01_icn
 IPv4 CIDRブロック: 192.168.0.0/16
public_subnet
 IPv4 CIDRブロック: 192.168.0.0/24
private_subnet
 IPv4 CIDRブロック: 192.168.1.0/24
セキュリティーリスト
　イングレスルール 追加
　　ソースCIDR: 0.0.0.0/0
　　宛先ポート範囲: Port 80,433
インターネット・ゲートウェイ
 internet_gw01_icn
デフォルトルート
 internet_gw01

オブジェクト・ストレージ
バケット 名前: bucket-01-icn

VM
 instance-0
  Private IP: 10.0.0.203 
 instance-04
  Private IP: 10.0.0.204

Load Balancer
 名前: lb_01
 VCN: vcn01_icn
 バックエンド・セット: bs_lb_01_icn

VMの設定、Load Balancerの設定をテスト

VMにWebサーバ（apache+php等）を設定して、Load Balancerのバックエンドに配置、簡単にテストしてみましょう。トラフィック・分散ポリシーを 重み付けラウンド・ロビンにして、Load BalancerのパブリックIPにアクセスすると、アクセスするたびに違うサーバへアクセスに行っているのが確認できます。

プライマリリージョンの東京リージョンに、ネットワーク、VM、Load Balancerを配置して、アクセスして接続をテストしてみました。
移動インスタンスを利用する場合は、スタンバイ・リージョンとなるソウルリージョンにはVMはスタンバイさせる必要はありませんが、念のためLoad Balancerの動作テストは実施しました。（テスト後は不要なVMはLoad Balancerバックエンドから削除等しておきます。）

ブラウザで Load Balancer パブリック IP 131.186.61.113（例） にアクセスし、リロードすると Server IP が 10.0.0.101と、10.0.0.102 と交互に表示されトラフィック・分散ポリシーの設定通りバックエンドサーバにアクセスしていることがわかります。

ここまでが事前準備となります。

FSDRのDRメンバーに、Load BalancerとVMを移動インスタンスとして追加する。

DR保護グループ設定

プライマリ・リージョン、スタンバイ・リージョン両方でDR保護グループを作成する

DR保護グループ作成時に、ロールを指定する必要はありません。プライマリ・リージョン、スタンバイ・リージョン両方でDR保護グループを作成します。

Tokyo Region（プライマリ側）DR保護グループ名: FSDR01_NRT
Seoul Region（スタンバイ側）DR保護グループ名: FSDR01_ICN

としてDR保護グループを作成します。

Tokyo Region（プライマリ側）

Seoul Region（スタンバイ側）

DR保護グループ関連付けをする

プライマリ・リージョン、スタンバイ・リージョンどちらかのDR保護グループから [関連付け] ボタンを押し、ロール や ピア・リージョン、ピアDR保護グループを指定し、お互いの関連付けを行います。プライマリ・リージョン、スタンバイ・リージョンのどちら側からでもこの操作は可能なようでした。

ここでは、東京リージョンから、DR保護グループFSDR01_NRTを選び、[関連付け] ボタンを押します。

次に保護グループ FSDR01_NRT のロール、ピア・リージョン、ピア保護グループを選択、設定を行います。

ロール: プライマリ
ピア・リージョン: South Korea Central(Seoul)
ピアDR保護グループ FSDR01_ICN

として、関連付けを完了します。
最後にダイアログの下の方にある [関連付け] ボタンを押すと関連付けが行われます。

関連付け完了

関連付けが完了しDR保護グループの詳細を見ると、ピアDR保護グループ に対になるDR保護グループ、ピア・リージョン に対になるリージョンが表示されていることが確認できます。

DR保護グループからも対になっているDR保護グループやリージョンが確認できます。

ボリュームグループ、VM、Load Balancerリソース追加

こちらのドキュメントを参考にDR保護グループのメンバーにリソースを追加します。

ディザスタ・リカバリ保護グループへのメンバーの追加
https://docs.oracle.com/ja-jp/iaas/disaster-recovery/doc/add-members-protection-group.html

FSDR Load Balancer の追加についての Document
https://support.oracle.com/knowledge/Oracle%20Cloud/2984602_1.html

OCI Full Stack Disaster RecoveryによるOCI Load Balancerのサポート
https://blogs.oracle.com/oracle4engineer/post/ja-fullstackdr-support-load-balancer

プライマリ・リージョンのDR 保護グループの詳細 画面上、左側のメニューの Resources から [メンバー] をクリックし、[メンバーの追加] をクリックでリソース追加ができます。

ここでは先程作成した DR 保護グループ FSDR01_NRT を選び 左下の [メンバー] メニューをクリック。

[メンバーの追加] ボタンをクリックし ボリューム・グループ、VM、Load Balancer リソースを追加していきます。

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

メンバーの追加

リソース・タイプ:[ボリューム・グループ] を選択

画面が下のように遷移する

☑ チェックボックス を チェック
すべての既存プランが削除されることを承認します に同意する。

リソース・タイプ: ボリューム・グループ
ボリューム・グループ: vg_01

を選択します。

ボリューム・グループ追加確認

ボリューム・グループ が正しくメンバーとして追加されていることを確認します。

VM追加

1つ目のVMをメンバーに追加（移動インスタンス）

メンバーの追加

リソース・タイプ: コンピュート
を選択

画面が下のように遷移する

☑ チェックボックス を チェック
すべての既存プランが削除されることを承認します に同意する。

リソース・タイプ: コンピュート
インスタンス: instance-01
コンピュート・インスタンス・タイプ: 移動インスタンス

を選択する。

VNIC マッピング

[VNICマッピング] ボタンを押す。
VNICマッピングのダイアログが表示される。

VNIC: instance-01
宛先VCN: vcn01_icn
宛先のサブネット: public_subnet(リージョナル)
宛先のプライマリ・プライベートIPアドレス: 192.168.0.101

[追加] ボタンを押してVNIC情報の追加を行います。

設定確認とVM追加

必要な情報が問題なく設定されている事を確認し [追加] ボタンを押してVMの追加を行います。

2つ目のVMをメンバーに追加（移動インスタンス）

追加の手順は1つ目と同じなので省略します。

☑ チェックボックス を チェック
リソース・タイプ: コンピュート
インスタンス: instance-02
コンピュート・インスタンス・タイプ: 移動インスタンス

VNIC マッピング
VNIC: instance-02
宛先VCN: vcn01_icn
宛先のサブネット: public_subnet(リージョナル)
宛先のプライマリ・プライベートIPアドレス: 192.168.0.102

設定確認とVM追加
必要な情報が問題なく設定されている事を確認し [追加] ボタンを押してVMの追加を行います。

VM追加確認

2つのVMが コンピュート・インスタンス(移動) メンバーとして正しく追加されていることを確認します。

プライマリ・リージョンで Load Balancer 追加

メンバーの追加

リソース・タイプ: [ロード・バランサー] を選択

画面が下のように遷移する

☑ チェックボックス を チェック
すべての既存プランが削除されることを承認します に同意する。

リソース・タイプ: [ロード・バランサー]
ロード・バランサ: lb_01
宛先ロード・バランサ: lb_01_icn
ソース・バックエンド・セット: bs_lb_01
宛先バックエンド・セット: bs_lb_01_icn

[追加] ボタンを押してLoad Balancerの追加を行います。

Load Balancer 追加確認

Load Balancer が正しくメンバーとして追加されていることを確認します。

必要なリソースがメンバーに追加されているか確認

lb_01 ロード・バランサ
vg_01 ボリューム・グループ
instance-02 コンピュート・インスタンス(移動)
instance-01 コンピュート・インスタンス(移動)

全てリソースが登録されており、状態に問題ないことを確認します。

ここまで問題なければ、スタンバイ・リージョンに移動して、スタンバイ・リージョン側の DR保護グループのメンバー設定に入ります。

スタンバイ・リージョンで Load Balancer 追加

リージョン: South Korea Central(Seoul) に行き
左上のナビゲーションメニューから [移行とディザスタ・リカバリ] をクリック
DR保護グループ: FSDR01_ICN
をクリックして開きます。

メンバーの追加

リソース・タイプ: [ロード・バランサー] を選択

画面が下のように遷移する

☑ チェックボックス を チェック
すべての既存プランが削除されることを承認します に同意する。

リソース・タイプ: [ロード・バランサー]
ロード・バランサ: lb_01_icn

宛先ロード・バランサ: lb_01
ソース・バックエンド・セット: bs_lb_01_icn
宛先バックエンド・セット: bs_lb_01

最後に [追加] ボタンを押してLoad Balancerの追加を行います。

Load Balancer 追加確認

Load Balancer が正しくメンバーとして追加されていることを確認します。

ここまで問題なければ、プライマリ・リージョン、スタンバイ・リージョンでのメンバーの追加は完了で、次は DR計画 の設定に入ります。

DR計画

スタンバイ・リージョンで、スタンバイロールの、DR保護グループを確認します。
（先ほど、スタンバイ・リージョンで、Load Balancer をメンバーに追加したDR保護グループです）

リージョン: South Korea Central(Seoul)
ピアDR保護グループ FSDR01_ICN

をクリックして開きます。

計画の作成

[計画の作成] ボタンを押し、DR計画を作成します。

計画の作成
名前: SwitchOverPlan01
プラン・タイプ: スイッチオーバー（計画済み）

名前を付け、プラン・タイプを選択したら、
[作成] ボタンを押し計画作成を完了します。

ディザスタ・リカバリ計画のプラン・タイプに関しては下記マニュアルを参照ください。

ディザスタ・リカバリ計画のタイプ
https://docs.public.oneportal.content.oci.oraclecloud.com/ja-jp/iaas/disaster-recovery/doc/dr-plans-type.html#GUID-C36FF3CC-4702-40E3-B41C-38F53199A492

計画の詳細

計画の名前（Name）をクリックすると、計画の詳細を確認することができます。計画の詳細では、事前チェックの実行、DR計画の実行が可能です。

計画グループ の [グループの追加] からは ユーザー定義の計画グループおよびステップの追加が可能です。

計画作成確認

計画作成が正常に完了すると、状態が「アクティブ」になります。
もし、計画作成がエラーで終了したら、エラーログを手掛かりに設定を見直します。

DR計画の実行

DR計画の詳細画面から実行

計画の名前(Name)をクリックし、DR計画の詳細画面から DR計画の実行 ボタンを押すことで、計画の実行 することができます。

「3つのドット」メニューから実行

計画の右端にある「3つのドット」メニューをクリックすることで、DR計画の実行 をクリックし計画を実行をすることも可能です。

事前チェックの有効化

DR計画実行時に、☑事前チェックの有効化 にチェックボックスがされていると事前にチェックを実施、問題がなければ 計画を実行 します。

DR計画実行中のステータス

DR計画実行中は、DR計画実行の詳細画面より、計画実行グループの実行状況が随時アップデートされます。

DR計画完了

DR計画完了状態

問題なくDR計画が完了すると成功のステータスが表示されます。

計画の実行からDR計画完了状態確認

Resourcesの計画の実行メニューより、計画実行のサマリーを見ることができます。計画実行の記録はここからたどれます。

スタンバイロールだったDR保護グループが、プライマリロールになっていることを確認

リージョン: South Korea Central(Seoul)
DR保護グループ: FSDR01_ICN
ロール: プライマリ

になっていることを確認します。

サービス復旧確認

リカバリサイト側の Load Balancer にアクセス

リカバリサイト側 Load Balancer 情報を確認

リカバリサイト側の Load Balancerの状態を確認します。

リージョン: South Korea Central(Seoul)
名前: lb_01_icn
IPアドレス: 129.154.209.20（パブリック）
状態: アクティブ

問題なく動作しているようです。

Load Balancerの パブリックIPアドレスにブラウザからアクセス

ソウルリージョンの Load Balancer IP 129.154.209.20 にブラウザからアクセスしてみます。
東京の Load Balancer にアクセスした時と同じように、ブラウザをリロードするたびに、192.168.0.101、192.168.0.102 と別のプライベートIPアドレスを返してきていることから、期待通りの処理をしていることが確認できました。

まとめ

Disaster発生時、手動で他リージョンにVM等を移行を実施し、短時間でサービスを回復
させるのは容易な事ではありません。人手を介せば誤りが発生しスタンバイサイトを興
すことが難しくなるなるのはよくある事です。

DRサイトを構築していても、日頃からDR切り替えドリル(演習)を定期的に実施せずただ祈
るだけでは災対側にきちんと切り替わるか確信は持てません。自動で切替わってくれと願
うケースも多いのはないでしょうか。

DRは構築や運用コストがかかりすぎてハードルが高いし無理と言うのもよく聞く話です。

FSDRなどのDRaaSの利用はそのような現状に一石を投じるソリューションとなるかもしれません。未来に備えるために。

2024/3/11