Azure Site Recoveryを使って東西日本リージョンのDR構成を検証した

Azure Site RecoveryはVMの災害対策が可能なサービスです。
東日本リージョンのVMをプライマリーとし、西日本リージョンにフェールオーバーできるかを検証してみました。

# 前提
* 東日本リージョンにVMが作成されていること

# レプリケーション設定
* VMの左バーより[ディザスタリカバリー]を選択します。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/2c43bc2d-5e3e-87e8-6c69-b8bdfb84fb40.png)

* レプリケーション先のペアリージョンが選択されているためそのまま[次へ]を選択します。
※このときターゲットリージョンを別リージョンに変えることもできますが、このままだとできません。一度次の画面にいって、前の画面に戻ると選択できるようになります（ポータルのバグかな？）  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/44fd9f19-973f-4222-7b1c-54cfdba163d3.png)

* ターゲットの情報を入力します。今回はデフォルトのままいきます。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/62e962ef-5beb-8028-c835-f3025c554fe5.png)

* レプリケーション設定なども必要に応じて変更しますが、今回はデフォルトでいきます。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/0eb40e69-166e-e7bb-6b32-741e4b4a96c3.png)

* 全て入力したらレプリケーションを開始します。

# レプリケーション状態確認
* レプリケーション構成は以下のようになります。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/64eec07b-f6ba-718d-83f0-aa41a534f4ac.png)

* [ソースのリソースグループ名]-1というリソースグループに2つのリソースが作成されます。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/21fadad9-2a7c-458a-2f44-364b86c97746.png)

* site-recovery-vault-rgというリソースグループに3つのリソースが作成されます。
Automationアカウントは復旧ポイントの保持期限を制御しているようです。Site Recoverはデフォルトだと24時間分の復旧ポイントを保持しますが、そのあたりを制御してるのかな？  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/a1a07507-f1e9-cd9d-98b8-9d5e1b6a8b70.png)

* 同期状態を確認します。まだ同期されてないですね。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/07efbb5a-847f-a6fa-c59d-003260fdd326.png)

* 同期されました。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/a3eb4cfa-5e2c-385d-7895-47617bd99f16.png)

# テストフェールオーバー

* 擬似的にフェールオーバーさせて動作確認をしてみます。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/80c22cab-4a28-3fed-b32d-837b0b494674.png)

* [テストフェールオーバー]を選択します。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/9e58f0bf-eff7-78c7-79e3-fe4cfb3ad4e4.png)

* 整合性によって復旧ポイントが選べるようです。今回は最後に処理された時点を選択します。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/6db772fb-7ee5-9129-aed7-6f2e0f5f7c45.png)

* 復旧ポイントの違いが分からなかったので調べてみると [公式ページ](https://docs.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-common-questions) に書いてました。

```
最新 (最低 RPO) の復旧ポイントとは何ですか?
[最新 (最低 RPO)] オプションではまず、Site Recovery に送信されているすべてのデータが処理されます。 サービスでデータが処理された後、VM にフェールオーバーする前に、VM ごとに復旧ポイントが作成されます。 このオプションは、最も低い目標復旧ポイント (RPO) を提供します。 フェールオーバー後に作成された VM には、フェールオーバーのトリガー時に Site Recovery にレプリケートされたすべてのデータが含まれます。
```

```
復旧ポイントの [最後に処理があった時点] オプションは何を意味しますか?
[最後に処理があった時点] オプションでは、計画内のすべての VM が、Site Recovery によって処理された最新の復旧ポイントにフェールオーバーされます。 特定の VM の最新の復旧ポイントを参照するには、VM 設定の [Latest Recovery Points] (最新の回復ポイント) を確認します。 このオプションを使用すると、未処理のデータの処理に時間がかからないため、RTO を低くできます。
```

なるほど。最新にするか、最後にASRが処理した時点にするかでRTOに違いがあると。

* アプリ整合性は以下の通り。

```
アプリケーション整合性復旧ポイントとは何ですか?
アプリケーション整合性復旧ポイントは、アプリケーション整合性スナップショットから作成されます。 アプリケーション整合性復旧ポイントでは、クラッシュ整合性スナップショットと同じデータがキャプチャされますが、さらに、メモリに入っていたデータと処理中のすべてのトランザクションもキャプチャされます。
これらの追加コンテンツのため、アプリケーション整合性スナップショットは最も複雑となり、時間がかかります。 アプリケーション整合性の復旧ポイントは、SQL Server などのデータベース オペレーティング システムで推奨されます。
```

なるほど。VSS連動したアプリケーションがある場合はアプリケーション整合性を意識しないといけないと。
ちなみに、アプリケーション整合性スナップショットの頻度は、デフォルトで4時間。1～12時間の間で設定できるようです。

* フェールオーバー先のvNetを指定します。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/a7cbcb38-eb25-ec67-52d1-974277c15429.png)

* しばらくすると西日本リージョンでテストVMが立ち上がります。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/bdb457a5-c62c-65fe-0ba7-4f139769af5e.png)

* パブリックIPが付与されていない状態なので、パブリックIPを付与してOSログインして問題なくデータが復元されていることを確認できました。

* 問題なく西日本にVM作成されたことが確認できたので、[テストフェールオーバーのクリーンアップ]を実行します。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/78a3abc8-87f7-492f-2f9c-dd427f0c18f1.png)

* チェックボックスにチェックを入れ、テスト用サーバーを削除します。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/df7e0fbe-1df7-016c-09e6-66966439f15b.png)

# フェールオーバー
* [フェールオーバー]を選択します。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/ec511368-9d17-debf-7fea-4dca74f14d48.png)

* テストフェールオーバーと同様に復旧ポイントを選んでフェールオーバーします。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/2d3b7d4b-02c1-a20c-9fa6-18e4e2f73e9b.png)

* 東日本のVMはシャットダウンされ、西日本のVMが起動しました。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/2a634180-4a15-c4d5-ac01-03691d755a95.png)

* 西日本VMにアクセスしてデータを確認したところ、5分前のデータまで復元できていました。このあたりは、復旧ポイント次第で変わってくるかと思います。アプリ整合性まで求めるともっと前の時間になるなど。

# 復旧ポイントの変更
* 復旧ポイントを変更してみます。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/8c89869b-c95f-12cb-2b8f-9159d92523e2.png)

* より最新にしてみましょう。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/f9ae31c4-6bcb-547e-0417-9f33c0f670bb.png)

* 西日本のVMが停止して、再度起動してきます。東日本のVMは停止状態のまま変化なし。

* 西日本VMにアクセスしてデータを確認したところ、最新のデータまで復元できていました。

# コミット
* データも問題なさそうなのでこの復旧ポイントでコミットします。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/daf4e1d1-ed36-5a10-08c5-faa9de2a3151.png)

* 注意事項が出てくるのでOKを押します。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/da1a67f7-f7c0-d5a7-2621-98192bacffb8.png)

# 再保護
* 再度この西日本のVMをレプリケーションさせてみます。[再保護]を選択します。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/c9cf1e8b-ba0b-bc99-5ee9-c8a03bf5b3ff.png)

* 再保護の条件が出るので問題なければOKを選択します。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/08847785-29d6-dfc8-abeb-a95c9fc69905.png)

* 再度同期処理が走ります。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/83d67e1d-fa38-0ebe-4ec8-18e3d5257635.png)

* 同期が完了したら、今度は西日本をプライマリーとしたDR構成が組めました。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/180335/7e49f021-37ca-f973-9c55-1807b00712fa.png)

以上