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

# FSDRのLB対応について

[OCI Full Stack Disaster Recovery (FSDR)](https://docs.oracle.com/ja-jp/iaas/disaster-recovery/index.html)は、2022年11月からOCIで利用ができるようになった Disaster Recovery as a Service (DRaaS)です。

https://blogs.oracle.com/oracle4engineer/post/ja-oci-full-stack-disaster-recovery-launch

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/407e60cd-dab0-7cfb-651c-4a08956ab1aa.png)

# 事前準備

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)**
https://qiita.com/Assemble_EX-80/items/09d552f69e8b60e6f804

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

- **コンピュートVMの準備**

プライマリ・リージョンでコンピュートのVMをプロビジョニングします。VMをDR保護グループの**メンバー**として追加するとき、[**移動インスタンス**](https://docs.oracle.com/ja-jp/iaas/disaster-recovery/doc/add-moving-instance.html) として追加するか、[**非移動インスタンス**](https://docs.oracle.com/ja-jp/iaas/disaster-recovery/doc/add-non-moving-instance.html) としてメンバーに追加するかを選択する必要があります。

[**移動インスタンス**](https://docs.oracle.com/ja-jp/iaas/disaster-recovery/doc/add-moving-instance.html
)としてメンバーに追加する場合は**スタンバイリージョンにはVMインスタンスを用意しておく必要はありません**。**DR計画を実施**することによりVMはスタンバイリージョンに移動し、指定のLoad Balancerのバックエンドセットに追加されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/1aea2bd8-e812-5c29-e193-2f620fb0798b.png)

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

[**移動インスタンス**](https://docs.oracle.com/ja-jp/iaas/disaster-recovery/doc/add-moving-instance.html)を利用する場合は、事前に**プライマリ・リージョンで、ボリュームグループを作成**しておき、[**移動インスタンス**](https://docs.oracle.com/ja-jp/iaas/disaster-recovery/doc/add-moving-instance.html)とするVMの**ブートボリュームをボリュームグループに追加**、**ボリュームグループはスタンバイ・リージョンに向けてレプリケーションさせておく**必要があります。

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

実際の設定はこちらを参照
**[その５ オブジェクト・ストレージ、ブロック・ボリューム 作成・設定 ](https://qiita.com/Assemble_EX-80/private/b846a3ac8aa8de71301a)**
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 のブートボリュームを追加
```


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/3cb0eb52-fe60-d4f9-8b82-321dca831f5d.png)


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

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

東京とソウル、2つのリージョン利用のDR構成で、コンピュートVMは[**移動インスタンス**](https://docs.oracle.com/ja-jp/iaas/disaster-recovery/doc/add-moving-instance.html) としてFSDRのメンバに追加、DRaaS機能を動作させてみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/121c6818-dfae-d0f1-a542-666032694020.png)

**VCN**、**オブジェクトストレージ**、**VM**、**Load Balancer**の作成方法についてはここでは触れませんが、事前に以下のような設定がされている想定です。
<!--（設定手順に関しては後日）-->

ここで用いる**VCN**、**オブジェクトストレージ**、**VM**、**Load Balancer**をステップバイステップで準備ができるような記事をこちらに用意しましたのでご参照ください。
**[OCI Load Balancer と Oracle Linux 9 でロードバランシングを体験](https://qiita.com/Assemble_EX-80/items/09d552f69e8b60e6f804)**
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バックエンドから削除等しておきます。）
<!-- （この設定に関しても後日別記事で） -->
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/92bf03c7-2223-0bc4-6f74-5a2274b37676.png)

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/0520c064-02bf-d183-cdc8-526abc7ed1ad.png)

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

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



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

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

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

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

### Tokyo Region（プライマリ側）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/e409237d-67da-80bf-a7ec-c3fe30e53f50.png)
### Seoul Region（スタンバイ側）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/70983433-72ba-789e-1aca-1975dfcebf9c.png)
### DR保護グループ関連付けをする
プライマリ・リージョン、スタンバイ・リージョンどちらかのDR保護グループから **[関連付け]** ボタンを押し、**ロール** や **ピア・リージョン**、**ピアDR保護グループ**を指定し、お互いの関連付けを行います。プライマリ・リージョン、スタンバイ・リージョンのどちら側からでもこの操作は可能なようでした。

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/4b939d55-7894-be83-611f-609d4c588477.png)

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

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/2f14ce6b-9958-a6d7-0bf4-800b0e4f1c47.png)

### 関連付け完了
関連付けが完了し**DR保護グループの詳細**を見ると、**ピアDR保護グループ** に対になるDR保護グループ、**ピア・リージョン** に対になるリージョンが表示されていることが確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/ca4776a0-f741-8ddb-f5f2-f39fbb373479.png)

**DR保護グループ**からも対になっているDR保護グループやリージョンが確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/b6b9157c-b37f-4af6-cee4-1b4c0b5dc8d7.png)

# ボリュームグループ、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** リソースを追加していきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/08953542-7dc9-63bc-186b-7c65a06efa51.png)


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

### メンバーの追加
リソース・タイプ:**[ボリューム・グループ]** を選択

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/00e94ad6-0f9e-867c-a281-7b9d3ecf2fb7.png)

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

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

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

を選択します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/3f855cc2-f1c1-9fa3-a610-002a6f09d530.png)

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/441304d1-1bbd-c836-e67e-bc06ee6ed7cb.png)

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

### メンバーの追加
リソース・タイプ: **コンピュート**
を選択

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/1ab6bace-f938-48ce-c03e-cdc2f91d4220.png)

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

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

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

を選択する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/d1219b53-1db4-99d1-6a43-e0f302805f9e.png)


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

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/f489f5cd-d208-5726-58f2-7f884a77e7b9.png)

#### 設定確認とVM追加
必要な情報が問題なく設定されている事を確認し **[追加]** ボタンを押してVMの追加を行います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/5038f293-1b74-0fde-f863-b9d6fd8287ac.png)

### 2つ目のVMをメンバーに追加（移動インスタンス）
追加の手順は1つ目と同じなので省略します。

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

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

**設定確認とVM追加**
必要な情報が問題なく設定されている事を確認し **[追加]** ボタンを押してVMの追加を行います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/6df2061f-312d-2fcf-96da-695eb3f60ed6.png)

<!--
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/317b1073-19cc-7d15-000d-e6f551ca70fc.png)
-->

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/f297e6f3-08b3-2152-a615-c4889da96caf.png)


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

### メンバーの追加
リソース・タイプ: **[ロード・バランサー]** を選択


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/ec112867-28e1-e262-49d8-401ee946c6a8.png)


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

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

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

 **[追加]** ボタンを押してLoad Balancerの追加を行います。
 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/77602b50-ffb5-cff7-6d99-7d3db779da76.png)

<!--
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/e183c702-65e4-3c3c-de33-707b915d5c1c.png)
-->

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/c5b3ceed-49df-d612-cca1-639d1c139912.png)

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

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/f45a8e2f-ed1b-fb42-a150-dbe8c5139df0.png)

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

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

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

<!--![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/257da542-9ab3-b732-410d-02072af2a194.png) -->
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/81867dc9-01be-31c1-8398-394356aa3e34.png)

### メンバーの追加
リソース・タイプ: **[ロード・バランサー]** を選択

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/ec112867-28e1-e262-49d8-401ee946c6a8.png)

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

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

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

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

 最後に **[追加]** ボタンを押してLoad Balancerの追加を行います。
 
<!--
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/0a294366-8dc4-a17b-fa69-6d78ced94a4b.png)
-->

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/a78f9048-ec01-78c2-0f7b-6abe5ea9448c.png)

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/3662eac0-04f1-dbea-4be8-e4d42e11e00d.png)

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

# DR計画

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

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/b7096a39-af49-7c00-edf8-6ca048a7f347.png)

## 計画の作成

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/3a6c1f72-9598-fe13-ca45-277a8e1e768e.png)

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/24d5187c-3f8b-7d7e-8542-e54a1b165028.png)


ディザスタ・リカバリ計画の[プラン・タイプ](https://docs.public.oneportal.content.oci.oraclecloud.com/ja-jp/iaas/disaster-recovery/doc/dr-plans-type.html#GUID-C36FF3CC-4702-40E3-B41C-38F53199A492)に関しては下記マニュアルを参照ください。

ディザスタ・リカバリ計画のタイプ
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）をクリックすると、計画の詳細を確認することができます。計画の詳細では、[事前チェックの実行](https://docs.public.oneportal.content.oci.oraclecloud.com/ja-jp/iaas/disaster-recovery/doc/prechecks-dr-plan-executions.html)、[DR計画の実行](https://docs.public.oneportal.content.oci.oraclecloud.com/ja-jp/iaas/disaster-recovery/doc/perform-dr-operations.html)が可能です。

計画グループ の [グループの追加] からは [ユーザー定義の計画グループおよびステップの追加](https://docs.oracle.com/ja-jp/iaas/disaster-recovery/doc/add-user-defined-plan-groups.html#GUID-0589C9DA-9E61-4850-92E6-E9D4BD820EF4)が可能です。

<!--
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/f654a555-0adc-a10d-62c4-484efa8ef3f2.png)
-->
### 計画作成確認
計画作成が正常に完了すると、状態が「アクティブ」になります。
もし、計画作成がエラーで終了したら、エラーログを手掛かりに設定を見直します。
# DR計画の実行

## DR計画の詳細画面から実行
計画の名前(Name)をクリックし、DR計画の詳細画面から [**DR計画の実行**](https://docs.public.oneportal.content.oci.oraclecloud.com/ja-jp/iaas/disaster-recovery/doc/perform-dr-operations.html)  ボタンを押すことで、[**計画の実行**](https://docs.public.oneportal.content.oci.oraclecloud.com/ja-jp/iaas/disaster-recovery/doc/perform-dr-operations.html) することができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/f7b02d3d-f539-ffae-4903-2421ea441eed.png)

## 「3つのドット」メニューから実行
計画の右端にある「3つのドット」メニューをクリックすることで、[**DR計画の実行**](https://docs.public.oneportal.content.oci.oraclecloud.com/ja-jp/iaas/disaster-recovery/doc/perform-dr-operations.html) をクリックし計画を実行をすることも可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/9d0faf0a-cac0-71f3-feec-75c692f079a3.png)

### 事前チェックの有効化

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/e7c8ce8c-c916-4cd2-9a9e-577b3b1a8087.png)

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/9ebd1383-c533-6775-fbc6-df90495764f0.png)

# DR計画完了

### DR計画完了状態

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


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/7b0e3018-86a2-3e6c-f259-2664459c1bfb.png)

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/967b5646-2e83-8019-882f-b490edfb1584.png)

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

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/d2060567-cead-da9e-2468-fb1c6e18f64f.png)

# サービス復旧確認
## リカバリサイト側の Load Balancer にアクセス
### リカバリサイト側 Load Balancer 情報を確認
リカバリサイト側の Load Balancerの状態を確認します。

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/13301788-737f-5fc8-a45f-a3d4323ddc7c.png)

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/ad455881-b1b5-4c78-d4e6-46a0b3d8d872.png)

# まとめ

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

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

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

<!--
Disaster発生時に手動でインスタンスを他のリージョンに移行をし、短時間でサービスを回復させるのは簡単ではありませんよね。手順書があっても人の手を介すと誤りが発生しうまくいかないのはよくあること。DRって構築や運用コストがかかりすぎてハードルが高いし無理と言うのもよく聞く話です。DRサイトが構築できていても、日頃からDR切り替えドリル（演習）を定期的に実施しないとうまく災対側に切り替わるか確信が持てず不安と言うケースも多いのはないでしょうか。
-->

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

2024/3/11
<!--
:smiley: 
-->

<!---
### ディザスタ・リカバリとは
https://www.oracle.com/jp/cloud/backup-and-disaster-recovery/what-is-disaster-recovery/
--->
<!---
FSDRでは複雑なステップを人の手で実施することはないのでヒューマンエラーを防ぐことができますし、事前チェックなども自動で実施することができます。RTOという面においても、今回はVM2台と、Load Balancer1台という非常にシンプルな構成で試してみましたが、同じことを人の手を介して別のサイトにDR、サービス復旧させるとなったら、自動化ツールやレプリケーションなどの力を借りたとしても、FSDRが実施したように10分と少しで別のリージョンでサービスを復旧するという事は難しいのではと思います。

利用すれば、複雑なステップを人の手で実施することはないのでヒューマンエラーを防ぐことができますし、事前チェックなども自動で実施することができます。
RTOという面においても、今回はVM2台と、Load Balancer1台という非常にシンプルな構成でしたが、これをエンジニアの手を介して別のサイトにDR、サービス復旧させるとなれば、例え既存のクラウドやオンプレミスで動作する自動化ツール、レプリケーションなどの力を借りたとしても、FSDRが実施したように10分40秒程度で別のリージョンでサービスを完全に復旧することは難しいのではないでしょうか。

FSDRでスイッチオーバーやフェイルオーバーを計画しておけば、事前のチェックのみを実行することもできあらかじめ問題を修正しておくことができますし、DRドリル機能を使いスタンバイ・スタックが正常に起動できるかどうかを定期的にチェックすることも可能です。FSDRの機能をうまく使いこなすことができれば、いざという時役立つのは間違いと思います。

-->




<!-- 
移動インスタンス、非移動インスタンスの違いについては以下のBlogが参考になります。
https://blogs.oracle.com/oracle4engineer/post/ja-fsdr-nonmoving-compute-enhancements

コンピュートVMを**移動インスタンス** としてDR保護グループのメンバーに登録するか、**非移動インスタンス** としてメンバーに登録するかで、DR計画実施時に、Load Balancerに加えられる変更内容も変わってきます。

詳細はこちらを参考にしてください。

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

-->

[](　コメントアウト　)
<!-- コメントアウト -->
<!-- 



|header1|header2|header3|
|:--|--:|:--:|
|align left|align right|align center|
|a|b|c|

-->