AWS Elastic Disaster Recovery(DRS)を使って大阪-東京間でEC2をレプリケートしてみた

こんにちは、AWS事業本部の荒平(@0Air)です。
AWS Elastic Disaster Recovery(DRS)を触ってみたい季節になってきたので、手順を確認しながら触ってみることにしました（再入門的な記事ですが、私は初入門です）

弊社DevelopersIOでは、多種多様な記事が投稿されているのですが、「AWS Elastic Disaster Recovery」とタグの付いた記事はあまりありません。
プロジェクト等で目にする機会は殆どありませんが、便利なサービスですし、きっと需要はあると思いましたので基本的な手順からさらっていきます。

AWS Elastic Disaster Recovery(DRS)とは？

オンプレミスおよびクラウドの仮想マシンをAWS上に復旧させるためのサービスです。
前身のサービスとして、CloudEndure Disaster Recovery(CEDR)がありました。
ただし、CEDRについては既にサービス終了がアナウンスされており、一部のリージョンを除いて2024/3/31に廃止されます。現時点で、新規のデプロイもできません。
（参考：AWS Elastic Disaster Recovery を利用すべき場合）

CEDRとDRSを比較すると、料金こそ変わりませんが、パブリックインターネットアクセスが不要になっていたり、無停止のフェイルバックテストが可能になっていたりするので、単純に機能強化が図られている模様です。

サポートOS

AWS Elastic Disaster Recovery(DRS)がサポートしているOSは執筆時点で以下の通りです。
ただし、この記事を参照にする時期により異なる場合がありますので、最新情報を必ずご確認ください。

AWS Replication Agentをインストールするための要件は、以下ドキュメントに記載があります。

構成図

超シンプルですが、本エントリの構成図です。
※記載のサービスの他、S3に配置されたスクリプトを取得しています。詳しくはこちらもご覧ください。

初期設定

AWS DRSを利用したことの無い方は、まず初期設定から必要です。
以下のURLから、WELCOME画面を表示します。
https://ap-northeast-1.console.aws.amazon.com/drs/home?region=ap-northeast-1#/welcome

「設定と初期化」メニューから、初期設定を開始します。

セットアップページが表示されます。どうやら6ステップあるようです。

ステップ1. レプリケーションサーバーを設定

レプリケーションサーバのデプロイ先を指定します。
ここで、レプリケーションサーバという単語が出ていますが、これはDR対象のサーバをレプリケーションしておくための、データをコピーする宛先のEC2です。

このあたりはAWS Application Migration Service(MGN) と仕組みが同様で、TCP:1500ポートを介してレプリケーションサーバへ到達します。(参考)
そのため、インターネット、DirectConnect、VPNなど到達可能な要件に併せてサブネットを指定しましょう。
オンプレミス側のファイアウォールで制限している場合はそのあたりも要チェックです。

また、初回セットアップ時に、サービスアクセス用に以下のIAMロールが作成・リンクされます。

• AWSServiceRoleForElasticDisasterRecovery
• AWSElasticDisasterRecoveryReplicationServerRole
• AWSElasticDisasterRecoveryConversionServerRole
• AWSElasticDisasterRecoveryRecoveryInstanceRole
• AWSElasticDisasterRecoveryAgentRole
• AWSElasticDisasterRecoveryFailbackRole
• AWSElasticDisasterRecoveryRecoveryInstanceWithLaunchActionsRole

ステップ2. ボリュームとセキュリティグループを指定

次にEBSのボリュームとセキュリティグループを指定します。
ボリュームに関しては、gp3, gp2, st1を手動で指定することができますが、自動選択にしておくことがベストプラクティスのようです。

セキュリティグループは、DRSが作成したデフォルトセキュリティグループを利用することができます。
但し、0.0.0.0:1500のインバウンドが開放されているため、AWS ConfigやSecurity Hubにより検知される可能性があります。その場合は、手動でセキュリティグループを作成することをお勧めします。
(参考: Why is 0.0.0.0:1500 added to inbound rules in the Staging Area?)

ステップ3. その他のレプリケーションを設定

データルーティング、スロットリング、Point-In-Time ポリシーをそれぞれ設定します。

インターネット経由でない場合はプライベートIPを使用するにチェックを入れます。
要件に応じて、ネットワーク帯域幅を制限します。

ポイントインタイムポリシーですが、これはスナップショットの保持期間を入力します。検証のため最小の1日としていますが、デフォルトは7日です。

MAPファンドを利用している場合は、ここでMAPタグを設定することで自動的にmap-migratedのタグが付与されます。

ステップ4. デフォルトのDRS起動設定

DR対象のソースサーバをどのようにAWS上で立ち上げるかを指定します。
AWS DRSにインスタンスタイプ選択を任せることで、ソースサーバのスペックから自動的に最適なインスタンスタイプが割り当てられます。(AWS間の場合はEC2設定の踏襲が可能)
自身で指定したい場合は、「非アクティブ」を選択し、起動テンプレートにて設定します。

Windows Serverに適用するライセンスを選択します。既にライセンスの用意がある場合は、BYOLを選択します。
(Linux, WIndowsのデスクトップ版はデフォルトでBYOLを利用)

ステップ5. デフォルトのEC2起動テンプレートを設定

DR対象のソースサーバをAWSで起動するためのEC2起動テンプレートを設定します。
項目は通常の起動テンプレート設定と同じため割愛します。

ステップ6. 確認と初期化

最後に設定を確認します。問題なければ、「設定と初期化」ボタンより初期設定を完了します。

「サービスが正常に構成され、初期化されました。」と表示されれば、初期設定は完了です。

ソースサーバの追加

下記のドキュメントに沿って、ソースサーバを追加していきます。
本エントリでは、大阪リージョンに立てたAmazon Linux 2023を東京リージョンにレプリケーションしてみます。
Windowsをレプリケーションする場合は手順が異なるため以下ドキュメントをご参照ください。

オンプレミスサーバをレプリケートする場合、AWSElasticDisasterRecoveryAgentinstallationPolicy ポリシーを使用してIAMロールを作成し、AWS STS経由でセキュリティ認証情報をリクエストします。

EC2をレプリケートする場合は、上記手順が必要ない代わりに、インスタンスプロファイルを利用します。

ステップ1. (Optional) IAMインスタンスプロファイルにポリシーをアタッチする

本エントリではEC2をレプリケートするため、IAMインスタンスプロファイルを新規作成したものか、既存のインスタンスプロファイルにポリシーをアタッチします。
アタッチするポリシーはAWSElasticDisasterRecoveryEc2InstancePolicyで、AWSにて用意されたマネージドポリシーです。

ステップ2. ソースサーバOS上でReplication Agentをインストールする

aws-replication-installer-init をAWS提供のリンクからダウンロードします。(東京リージョンの例)
なお、TLS1.2を利用できないレガシーサーバの場合は、踏み台サーバなどで代理ダウンロードします。

wget -O ./aws-replication-installer-init https://aws-elastic-disaster-recovery-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/linux/aws-replication-installer-init

インストールスクリプトを実行し、レプリケートするディスクを選択します。特に指定しない(全部のディスク)場合は、Enterを1回押下します。
※ ここで指定するリージョンは、DRSをセットアップしたリージョンを指定します。

chmod +x aws-replication-installer-init; sudo ./aws-replication-installer-init --region ap-northeast-1

標準出力には以下のように出力されます。ソースネットワークID, ソースサーバIDが払い出されれば、同期が開始しています。
逆に、このIDが出力されない場合は、何かしらの原因でコケている可能性があります（「おわりに」参照）

# ./aws-replication-installer-init --region ap-northeast-1
The installation of the AWS Replication Agent has started.
Identifying volumes for replication.
Choose the disks you want to replicate. Your disks are: /dev/xvda,/dev/nvme0n1
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/nvme0n1 of size 8 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 Network ID: sn-6ec9ecf6dd78b5223.
The following is the source server ID: s-6b23dbdc5af457bb9.
The AWS Replication Agent was successfully installed.

インストールに成功した場合、実行ログは以下のように出力されます。

# tail -n 1 aws_replication_agent_installer.log
2024-01-27 14:50:09,495 INFO       The AWS Replication Agent was successfully installed.                            [installation_id: f6a3df10-3110-4d51-97a2-281b365d18a9, agent_version: 5.21.0.2024.010.1410, aws_instance_id: i-0b2a882d4c260c96c, mac_addresses: 16327478253619, _origin_client_type: installer, account_id: xxxxxxxxxxxxx, _origin_instance_id: i-0b2a882d4c260c96c, _origin_agent_id: s-6b23dbdc5af457bb9]

ステップ3. レプリケーションを確認する

数分すると、東京リージョン側のDRSコンソールに表示されました。

初回同期は、レプリケーション開始のため以下のステップが実行されます。
検証環境では、インストールからここまでおよそ5分掛かっています。

前章のステップ1で構成したレプリケーションサーバ設定に応じたインスタンスが立ち上がります。

ステータスが「準備完了」になっていれば、レプリケーションが完了しています。
検証環境では、8GBの仮想マシンをレプリケーションするのに約10分、プラスでスナップショット処理の時間？に5分くらい要しました。
勿論、通信環境や利用状況に応じて時間は変動するため、参考値と捉えてください。

おわりに

AWS Elastic Disaster Recovery(DRS)について、触ったことがなかったので触ってみました。

AWS Replication Agentのインストールは、経験上一発で上手く行ったことがあまりありません（笑）
大体の原因は以下のトラブルシュートページに記載があるので、1つずつ潰していくのが良いと思います。

私が検証中に出会した事象1：
/tmp 領域が足りず、Replication Agentのインストールができない。ドキュメントによると、最低でも500MBは必要。（トラブルシュートページには2GBと記載あり、挙動が怪しい場合は2GBを推奨します）
Amazon Linux 2023を最小の8GBでデプロイした場合、/tmpは200MBほどしかなかったので、以下コマンドを実施して2GBに拡張しました。

sudo mount -o remount,size=2G /tmp

私が検証中に出会した事象2：

当初、ソースサーバをt3.mediumで試していたのですが、インスタンス単純なスペック不足なのか、初回同期にコケることがありました。そのため、今回はc6i.largeで検証しています。

直接影響があったか分からないが一応施した内容：
python=python3 のエイリアスを通しました。

[root@ip-172-31-39-177 ssm-user]# python --version
-bash: python: command not found
[root@ip-172-31-39-177 ssm-user]# python3 --version
Python 3.9.16
[root@ip-172-31-39-177 ssm-user]# alias python=python3
[root@ip-172-31-39-177 ssm-user]# python --version
Python 3.9.16

（追記） 以下、リカバリの記事も執筆しました。

このエントリが誰かの助けになれば幸いです。

それでは、AWS事業本部 コンサルティング部の荒平(@0Air)がお送りしました！