【その２：フェイルオーバー編】CloudEndure Disaster RecoveryでEC2をAZ間DR

CSM課の佐野です。
前回の記事では、CloudEndure Disaster Recoveryを使い始めるまでのセットアップを中心に手順をご紹介しました。
本記事では、実際にフェイルオーバーがどのように動くのか、手順とともにご紹介したいと思います。

やりたいこと
BLUEPRINTの設定
無停止フェイルオーバーテスト
本番フェイルオーバー
フェイルオーバー編のおわりに

やりたいこと

以下のDRシナリオを仮定し、VPC内の別AZに作成したサブネットへのDRを手動で実行してみます。

EC2「Windows2016」はシングル構成で、東京リージョンのAZ「ap-northeast-1a」で稼働している
「ap-northeast-1a」がAZ障害などで利用不可になった場合、同じVPC内の「ap-northeast-1c」のAZに作られたサブネットにEC2をフェイルオーバーする

これからの手順を実施する前に、まずはフェイルオーバーの準備ができているかを確認しましょう。
準備編で初期同期が完了したあと、以下の画面のように「Continuous Data Protection」と表示されていれば、継続的レプリケーションが実行できている状態になっています。「Ready For Testing」と表示もできているので、フェイルオーバーもテスト実行できますね。さっそくこの「Windows2016」の行をクリックして次に進みましょう。

BLUEPRINTの設定

BLUEPRINTとは、名前のとおり「青写真」＝「フェイルオーバー先の設定」のことです。
以下の画面に移ったら、「BLUEPRINT」タブをクリックして、フェイルオーバー先でのEC2の設定を登録します。

今回は仮定したDRシナリオに合わせ、このように入力してみました。デフォルトから変更箇所を抜粋しています。入力が完了したら、「SAVE BLUEPRINT」をクリックしてください。
（BLUEPRINTの画面は下半分しかスクロールできないので、ブラウザのウィンドウサイズを大きくして設定をおすすめします）

設定項目	設定値	説明
Machine Type	Copy Source	DR元のインスタンスタイプとDR先も同様にします。
Subnet	DR先にしたいap-northeast-1cのサブネット	DR先の既存VPCのサブネットを指定します。
Security groups	現在「Windows2016」に設定しているセキュリティグループ	DR元と同様にします。
Private IP	Create new	既存の別サブネット内なので、プライベートIPアドレスは新しく自動作成します。 Customにすると、利用IPアドレスを指定可能です。
Public IP (ephemeral)	Yes	今回はパブリックIPアドレスを使用しているため、同じように付与しています。
IAM Role	現在「Windows2016」に設定しているIAMロール	DR元と同様にします。
Initial Target Instance State	Started	フェイルオーバーしたDR先でEC2が起動しているようにします。
Disks	SSD	DR元のEBSがgp2のため、それと同様にします。

参考：Configuring a Machine's Blueprint

無停止フェイルオーバーテスト

BLUEPRINTの設定が認識と合っているか、実際にDR先で利用可能な状態になっているかを確かめるために、フェイルオーバーテストが必ず必要になります。未テストだと、CLoudEndureコンソールに「Never tested!」と出ているので、テスト実行してみましょう。
「LAUNCH TARGET MACHINE」をクリックして、「Test Mode」をクリックしてください。

フェイルオーバー先のターゲットマシンを作成する確認画面が出てきます。
もしすでにDRテストなどでターゲットマシンとなるEC2を作っていた場合、古いほうは削除されてしまいますので、ご注意ください。
今回は初めて実施するため、そのまま「NEXT」をクリックします。

リカバリポイントの画面が出てきますので、復旧したい時点に合わせて選択します。
リカバリポイントは以下のように選択できます。

Latest：現在の時点でEBSスナップショットを取得し、それをリカバリポイントとしてフェイルオーバー先に反映する
1時間以内：10分ごとにリカバリポイントを選択可能
24時間以内：1時間ごとのリカバリポイントを選択可能
30日以内：1日ごとのリカバリポイントを選択可能

実際にAWSコンソールではどうなっているか見てみましょう。
EBSスナップショットの画面を開くと、CloudEndureのレプリケーションサーバによって、DR対象EC2のEBSスナップショットがリカバリポイントに合わせて取得されているのがわかります。ここから復旧させるのですね。
容量の多いEBSをレプリケーションする場合はEBSスナップショット料金が結構かかりそうですね。。。

ここでは直近の状態から戻すことを想定して、「Latest」を選択して「CONTINUE WITH LAUNCH」をクリックし、テストフェイルオーバーを実施します。
実施中のログはCloudEndureコンソールの「Job Progress」から確認可能です。ステータスが「Complete Successfully」になればフェイルオーバーテストが無事に完了できています。

AWSコンソールでEC2を確認してみると、おお！ちゃんと指定したVPC内のサブネットに起動されています！30GBのディスクでDR先のEC2起動まで約6分、これは早いですね。
念のため、想定している設定になっているか（BLUEPRINTの設定が合っているか）、ログインしてシステムが利用可能かを確認してください。

注意していただきたい点は、フェイルオーバーしたEC2はキーペアの設定がないため、WindowsのAdministratorのパスワードをキーペアのままにしている場合、ログインパスワードの復号はDR元のEC2側でしかできなくなってしまいます。Administratorのパスワードはあらかじめ変更しておき、別途管理しておくなどの準備が必要になります。
Linuxも同様にキーペアの設定がAWSマネージドコンソール上でないように見えますが、鍵認証およびパスワード認証には変更ありませんので、DR前と同じユーザとキーペアでログインできます。

ここまで読んでいただいた方は「結局何が無停止フェイルオーバーテストなのか？」とお思いかもしれません。
そこでAWSマネージドコンソールを確認してみると、DR元となるEC2はもちろん停止していないのに加えて、テスト中もDR元からのリカバリポイントとなる、EBSスナップショットが継続的に取得され続けていることが画面からわかります。
つまり、常にレプリケーションを維持したままテストができるので、テスト中のデータロスはありません。安心ですね。

CloudEndureコンソールに戻ると、テスト用EC2が「TARGET」として反映されています。
テストが完了してフェイルオーバーテストしたEC2が不要になりましたら、「ACTIONS」から「Delete Target Machine」を選択することでterminateすることができます。

参考：Testing a Failover

本番フェイルオーバー

フェイルオーバーテストを経て、設定と動作に影響がないことを確認したら、ここからが実際にDR発動した場合の手順となります。
テスト済みのEC2であること、BLUEPRINTの内容を確認して、「LAUNCH TARGET MACHINE」から「Recovery」を選択すると、実際のフェイルオーバーが実行されます。

ここからの手順はフェイルオーバーテストと同様です。リカバリポイントを選択して、EC2の復旧を実施してください。
ここではテストと同じく、「Latest」を選択してフェイルオーバーを実施しました。テストと同様、BLUEPRINTで設定した内容に沿ってターゲット側にEC2が復元されているかを確認してください。

参考：Performing a Failover

フェイルオーバー編のおわりに

CloudEndure Disaster Recoveryのフェイルオーバー動作、イメージがつきましたでしょうか。
何度でも無停止でテスト実行が可能なので、実際にテストして「もしも」のときに対応できる設定にしておきましょう。
次回は、DR発動後にフェイルバックする際の操作についてご紹介したいと思います。