E. -Elastic Disaster Recoveryの運動について-

AWS re:Invent 2022でAutomate operations management on AWSというworkshopを受けてみました。
Elastic Disaster Recovery(DRS)使うよとなり、ドキュメント読んでみないとわからないなと思って読んでみると...

参考
https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.htm

AWS Elastic Disaster Recoveryを使用して、サポートされているオペレーティングシステムで実行されているオンプレミスまたはクラウドベースのアプリケーションを複製すると、ITの回復力を高めることができます。AWSマネジメントコンソールを使用して、レプリケーションと起動設定を構成し、データレプリケーションを監視し、ドリルまたはリカバリのインスタンスを起動します。
ソースサーバーにAWS Elastic Disaster Recoveryを設定して、安全なデータレプリケーションを開始します。データは、選択したAWSリージョンのAWSアカウントのステージングエリアサブネットに複製されます。ステージングエリアの設計は、手頃な価格のストレージと最小限のコンピューティングリソースを使用して継続的なレプリケーションを維持することで、コストを削減します。

「？」

簡単に説明すると

誤解を恐れずに言うと、「DRSはハイブリッドクラウドやマルチクラウドにおいてバックアップを取ることでAWSへフェイルオーバーできる」です。
もちろん、AWS上だけでも使えます。
下の動画にあるようにCloudEndure Disaster RecoveryがDRSへアップグレードするように勧められており、CloudEndureはAWSへの移行するためのサービスです。
そのため、AWSへの移行機能を被災時のフェイルオーバー機能として改良したのかなという邪推ができますね。

目標

参考
https://docs.aws.amazon.com/drs/latest/userguide/Network-diagrams.html

上で挙げた動画やドキュメントにもあるようにどうやらデータセンターまたはクラウドにあるサーバからAWSへ矢印が出ているのでそんな動きができると仮定しましょう。
するとGCPからAWSへ矢印が引っ張れるはずです。

とはいえ、まずはAWSだけでやってみます。

AWS上だけでDRSの動きを確認する

大きな流れとしては以下です。

1. EC2インスタンスを作成する
2. DRSでの設定を入れる
3. エージェントのインストールを行ってレプリケーション開始する
4. フェイルオーバーを実施する

エージェントのインストールをEC2にログインして手を動かすのではなく、SystemsManagerを使って行うようにしているのでエージェントインストール準備をしてます。
sysopsの試験だとパッチ適用をSystemsManagerから行うように言われますが、エージェントのインストールもできます。

1. 基本的な構成の作成

まずはアーキテクチャ図の通りにVPC1つ,2つのAZにパブリックサブネットとプライベートサブネットを1つずつ、EC2をプライベートサブネットに1つ,パブリックサブネットに1つ、NAT Gatewayを作成します。
(エンドポイントの工夫次第でNAT Gateway要らない気がしますね。。)

2. DRSのレプリケーションサーバの設定を入れます。

ステージングエリアサブネットは作成したVPC上ではなく、専用のVPCを使うのが良いそうです
が今回は検証なのでデフォルトでいきます。
また、同じ理由でインスタンスタイプはt2.microに変更してます。
その他は特に変更なく設定しました。

参考
https://docs.aws.amazon.com/drs/latest/userguide/replication-server-settings.html
目的のステージング領域サブネットを選択します。 をクリックして、すべてのレプリケーションサーバーのステージング領域サブネットとして割り当てます。
ベスト プラクティスは、すべてのユーザーに対して 1 つの専用の個別のサブネットを作成することです。

3. 以下2つのポリシーをもったIAMロール「DRS-agent-install」を作成し、2つのEC2に割り当てる

• AmazonSSMManagedInstanceCore
  SystemsManagerでEC2インスタンスへ操作するのに必要なポリシー
• AWSElasticDisasterRecoveryEc2InstancePolicy
  レプリケーションエージェントを使用するのに必要なポリシー

設定例

レプリケーションエージェントのポリシーが最初はよくわからずにやってましたがGCPとの比較でわかるかと思いますのでその時に再度説明します。

4. エンドポイントを作成する

プライベートインスタンスはSystemsManagerのエンドポイントがないとSystemsManagerから操作できなかったようなので作成しました。

• com.amazonaws.[リージョン名].ssm
• com.amazonaws. [リージョン名].ec2messages
• com.amazonaws. [リージョン名].ssmmessages

設定例

5.EC2のタグを作成(ターゲットグループの作成)

SystemsManagerはタグベースでコマンド実行先を選んで実行できます。
対象となるEC2インスタンス2つにKey:DRS,Valu:TRUEを入力してタグの追加を選択します。

6.SystemsManagerから各EC2にAgentをインストールする

SysytemManagerの画面に映り、左側のメニューからRun commandを選択。
コマンドドキュメント選択でAWSDisasterRecovery-InstallDRAgentOnInstanceを実行したいので選択する。
このコマンドドキュメントの内容はDRSに必要なAgentのインストールをEC2に向けて行うもの。
コマンドパラメータは東京リージョンで作業しているならap-northeast1を選択。

インスタンスのタグ指定でKey:DRS,Valu:TRUEを入力してAdd

その他は設定なしで実行すると実行されます。

SystemsManager用のエンドポイントが作成されていないとpublicのEC2一台しか実行されません。

7.DRSに同期が始まっていることを確認する

DRSのソースサーバ画面からリカバリ準備の進行状況が確認できます。

DRSのレプリケーションサーバの設定とエージェントのインストールが完了していれば勝手にリカバリの準備完了ステータスが進行します。
DRSのレプリケーションサーバの設定が済んでいて、進行できていないようであればどちらかがうまくいっていないです。

8.起動テンプレートの設定

先ほどのソースサーバの画面からチェックボックスにチェックを入れてアクションを選択します。
アクション→起動設定を編集で開くと、デフォルトでインスタンスタイプがC5.largeになっています。
t2.microに変更しておきましょう。
インスタンスタイプをt2.micro、キーペアを既存のもの、起動先のサブネット、セキュリティグループをデフォルトで選択。パブリックインスタンスの場合は高度なネットワーク設定からパブリックIPの自動割り振りをオンにするします。

EC2の起動テンプレート画面に行き、設定したテンプレートを選択して「アクション」→「デフォルトバージョンを設定」→2を選択します。(何度も作り直していれば、それを選択します。)

9.フェイルオーバー訓練の実施

まずはElastic Disaster Recoveryのソースサーバ画面に行き、２つのソースサーバを選択し、「リカバリジョブを開始」→「リカバリドリルを開始」の順で実行します。
ポイントインタイムリカバリのため、インスタンスの状態を見ると以下の通り。

• ip-*.ap-northeast-1.compute.internal
  フェイルオーバー先のインスタンス
• AWS Elastic Disaster Recovery Replication Server
  レプリケーション先のインスタンス
• AWS Elastic Disaster Recovery Conversion Server
  フェイルオーバー実施時のみ起動してくるインスタンス

参考
https://aws.amazon.com/jp/blogs/news/scalable-cost-effective-disaster-recovery-in-the-cloud/
AWS Elastic Disaster Recovery Conversion Server という名前のこれらの一時インスタンスは、PIT スナップショットを実際の復旧インスタンスに処理するために使用され、ジョブが完了すると終了します。

これでAWSでのフェイルオーバーの実施が完了です。
RecoveryAreaにEC2インスタンスが起動されました。

長かったので一旦AWS上でのフェイルオーバーの実施についてまとめます。
やったことはざっくり以下の通りです。

1. EC2インスタンスを作成する
2. DRSでの設定を入れる
3. エージェントのインストールを行ってレプリケーション開始する
   SystemsManagerでエージェントのインストールをタグベースで一気に行うため、EC2にタグを設定した。
   プライベートインスタンスはエンドポイントの設定がないとSystemsManagerでのコマンド実行が不可能だったので、エンドポイントを作成した。
4. フェイルオーバーを実施する

GCPからAWSへのフェイルオーバー

ここからはGCPを使ってAWS上にフェイルオーバーします。

1.エージェントのインストールに必要なIAMユーザーを作成します。

下記のポリシーを持ったユーザを作成し、アクセスキーを作成します。

• AWSElasticDisasterRecoveryAgentInstallationPolicy
• AmazonSSMManagedInstanceCore

アクセスキーは以下の設定です。

2.GCP上でCompute Engineを起動

GCPはCompute Engine(EC2にあたるもの)さえあればいいので手順はこちらを参考にやっています。

マシンタイプはe2-midiumを指定してます。
AWSの感覚だと無料枠なのか少し焦ってmicroをして実施しましたが、e2-midiumで問題なかったです。

GCP専用のインスタンス起動するのではなく、Ubuntu18.04LTSをAWSへフェイルオーバーすることにしました。

上記の赤枠にあるボタンでサーバにログインできます。
SSHログインしたら以下の要領でエージェントをインストールしていきます。

実行結果

<アカウント名>@instance-1:~$ wget -O ./aws-replication-installer-init.py https://aws-elastic-disaster-recovery-ap-northeast-1.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py
--2023-01-03 10:40:37--  https://aws-elastic-disaster-recovery-ap-northeast-1.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py
Resolving aws-elastic-disaster-recovery-ap-northeast-1.s3.amazonaws.com (aws-elastic-disaster-recovery-ap-northeast-1.s3.amazonaws.com)... 52.219.152.149, 52.219.197.85, 52.219.195.105, ...
    Connecting to aws-elastic-disaster-recovery-ap-northeast-1.s3.amazonaws.com (aws-elastic-disaster-recovery-ap-northeast-1.s3.amazonaws.com)|52.219.152.149|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 27442 (27K) [binary/octet-stream]
    Saving to: ‘./aws-replication-installer-init.py’

    ./aws-replication-installer-init.py             100%[=====================================================================================================>]  26.80K  --.-KB/s    in 0.004s  

<アカウント名>@instance-1:~$ sudo python3 aws-replication-installer-init.py
The installation of the AWS Replication Agent has started.
AWS Region Name: ap-northeast-1
AWS Access Key ID: (new_user_credentials.csvの内容を入力)
AWS Secret Access Key: 
Identifying volumes for replication.
Choose the disks you want to replicate. Your disks are: /dev/sda
To replicate some of the disks, type the path of the disks, separated with a comma (for example, /dev/sda, /dev/sdb). To replicate all disks, press Enter:
Identified volume for replication: /dev/sda of size 10 GiB
All volumes for replication were successfully identified.
Downloading the AWS Replication Agent onto the source server... Finished.
Installing the AWS Replication Agent onto the source server... Finished.
Syncing the source server with the Elastic Disaster Recovery Console... Finished.
The following is the source server ID: s-6df1aa81980691f05.
The AWS Replication Agent was successfully installed.
<アカウント名>@instance-1:~$ 

個人的にはこの時に色々情報が整理されました。

• このエージェントのインストール作業は対象サーバが多ければSystemsManagerで一気にタグベースで実施する方が楽で、作業漏れも起きない。
• エージェントはCloudWatchでもDatasyncでも出てくるので、AWS外のオンプレ等といい感じにするときによく使う。

少し余談ですが、DRSの
インストールが終わると同期が始まりますが、GCPなのにオンプレミス判定してますね。

3.リカバリの開始と確認

下はDRSの画面からリカバリを開始した画面です。
　
EC2の画面を見に行くとinstance-1が出力されています。
かなり待機したらinstance-1も起動してきました。

DRSのリカバリジョブを確認します。
8分くらいかけてリカバリ(instance-1を起動)していますね。

という訳でAWSへのフェイルオーバーが完了しました。
AWS上フェイルオーバーするとt2.microでも7分はかかってます。
GCPからフェイルオーバーについてはVPN接続設定を入れていないのであまり参考にならないかもですが、8分が参考値になるかなという感じです。
RPOとRTOの要件次第で選択肢に入るかどうかだとは思います。

おまけ

Elastic Diasster Recoveryの略称がDRSっておかしいと思って調べてみました。
これがいたから避けてDRSになったんですね。

参考
https://aws.amazon.com/jp/what-is/endpoint-security/
Endpoint Detection and Response (EDR) ソフトウェアは、高度なリスク検出、調査、および修復の機能を備えています。これは、エンドユーザーのデバイスを継続的にモニタリングして、セキュリティインシデントをより迅速に検出して対応するエンドポイントセキュリティソリューションです。EDR は、次のように機能します。