はじめに
この記事はAWS Elastic Disaster Recovery Workshopをやった際のメモ書きです。
リンク先のWorkshopは英語で書かれています。もし、英語を読むことが大変である方はこの記事をぜひ参考にしてください。
ただし、リンク先の情報を全てこちらに記載しているわけではないため、詳細な情報を得たい方は本家Workshopを実施してみてください。
Introduction
AWS Elastic Disaster Recovery（DRS）は、OS、データベースやアプリケーションなどのマシンを、低コストなステージングエリアに継続的にレプリケートするサービスです。
災害発生時にDRSに指示することで、レプリケートしていたマシンをリカバリーインスタンスとして、数分で自動的に起動することができます。
以下はDRSの基本的なネットワーク図です。
左手のオンプレデータセンターにあるサーバにはAWS Replication Agentがインストールされています。
そして、サーバから継続的にブロックレベルのレプリケーションが行われます。レプリケーションのデータは圧縮、暗号化されます。
右手のステージングエリアには軽量なEC2インスタンスがレプリケーションサーバとして起動されており、ここにレプリケーションデータが蓄積されます。
DRSへの指示により、リカバリーサブネットにリカバリーインスタンスを起動させることができます。
Workshop
このWorkshopでは次のことを行います。
- AWS Replication Agentのインストールとサーバのレプリケーション設定
- 起動テンプレートの設定
- レプリケーションのモニタリング
- フェールオーバーの実施とそれが成功したか確認
1. Account Setup
自己学習のためのCloudFormationテンプレートをここからダウンロードし、CloudFormationスタックを作成してください。(入力は全てデフォルト値で構いません)
使用するリージョンはバージニア北部（us-east-1）とします。
以下の認証情報をメモっておいてください。
Bastion Host
user = Administrator
password = Adm1nP@s
Linux Hosts
password = SshPass1
3. Connect to the Bastion Host
BastionにRDPで接続してみます。
当方Macを使用しているためMicrosoft Remote Desktopでアクセスしてみます。
BastionのIPアドレスはCloudFormationで作成したスタックの出力から確認します。
ネストされていないスタックを選択し、出力のBastionRDPの値を確認します。
続いて、EC2の画面に移動します。
Bastionインスタンスを選択し、セキュリティグループのインバウンドルールを確認します。
タイプがRDPのもののソースをマイIPに変更します。
Microsoft Remote DesktopでBastionにRDPで接続します。
ユーザー名、パスワードは1. Account Setupでメモしたものを入力してください。
4. Configure DRS Settings
AWS Elastic Disaster Recovery (DRS)のコンソールを表示します。
ここでは、ステージングエリアをどこにするかや、レプリケーションサーバのキャパシティなどの設定を行います。
-
画面に表示されている
Set default replication settingsボタンを押下します。
-
Stagin area subnetでCloudEndure Stagingを選択、Replication server instance typeでt3.smallを選択し、Nextボタンを押下します。
-
レプリケーションを保存するEBSのタイプや暗号化有無、また、ステージングエリアへのアクセスを制御するセキュリティグループを選択します。今回は全てデフォルト設定で構いません。
-
レプリケーショントラフィックのルーティング設定やポイントインタイムリカバリの設定を行います。今回は全てデフォルト設定で構いません。
-
Create defaultボタンを押下します。このデフォルト設定はAWS Replication Agentがインストールされたサーバのデフォルト設定となります。
-
AWS Replication Agentはまだどのサーバにもインストールされていないため、現時点で
Source serversには1件も表示されません。
5. Configure DRS Agent IAM User
AWS Replication AgentはAWSアカウントと対話するため、IAMクレデンシャルを必要とします。
ここでは、IAMユーザーとクレデンシャルを設定します。
IAMコンソールを表示し、ユーザー、ユーザーを追加ボタンを押下します。
スクショのCloudEndureUserはCloudFormationで自動的に作成されるようです。
ユーザー名drs-agent-user、アクセスキー-プログラムによるアクセスをチェックし、次のステップ：アクセス権限ボタンを押下します。
既存のポリシーを直接アタッチを選択、フィルタにdisasterを入力し、ポリシー名AWSElasticDisasterRecoveryAgentInstallationPolicyをチェック。次のステップ：タグボタンを押下します。
次のステップ：確認、ユーザーの作成ボタンを押下し、ユーザーを作成します。
作成後、アクセスキーIDとシークレットアクセスキーがCSVでダウンロードできるので、ダウンロードしておきます。
6. Installing the Agent
各マシンにAWS Replication Agentをインストールし、各マシンからステージングエリアのインスタンスへのレプリケーションを開始します。
RDPでBastionインスタンスにログインします。
デスクットップのPuttyアイコンをダブルクリックし、HostNameにAWS Replication AgentをインストールするサーバのFQDNを入力し、Openボタンを押下します。
AWS Replication Agentインストール対象
| Server Name | FQDN | OS | Username | Password |
|---|---|---|---|---|
| wordpress-web | wordpress-web.onpremsim.env | Linux | user |
1. Account SetupのLinux Hostsのpassword
|
| wordpress-db | wordpress-db.onpremsim.env | Linux | user |
1. Account SetupのLinux Hostsのpassword
|
ユーザー名とパスワードが求められるので、上記の通り入力します。
ログインできたら、以下のコマンドを実行します。
wget -O ./aws-replication-installer-init.py https://aws-elastic-disaster-recovery-us-west-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py
次に以下のコマンドを実行します。
sudo python3 aws-replication-installer-init.py
途中入力が求められます。
AWS Region NameはBastionインスタンスを起動しているリージョン(us-east-1など)を入力してください。
AWS Access Key IDは5. Configure DRS Agent IAM Userの手順でダウンロードしたCSVに記載されているAccess Key IDを入力してください。
AWS Secret Access Keyは5. Configure DRS Agent IAM Userの手順でダウンロードしたCSVに記載されているSecret Access Keyを入力してください。
最後にディスクについて質問されますがそのままエンターしてください。
完了まで体感5分かかります。
以上の手順を2つのサーバ（wordpress-web, wordpress-db）に対して実施してください。
Agentインストール完了後、AWS Elastic Disaster Recovery（DRS）のSource serversに戻り、Source ServerにAgentをインストールした2サーバが表示されていることを確認します。
登録した直後はReady for recoveryがInitial syncになっており、初回同期を実行しています。
初回同期では、以下のタスクを実行しています。
- セキュリティグループの作成
- レプリケーションサーバーの起動
- レプリケーションサーバーのBoot
- サービスとの認証
- レプリケーションソフトウェアのダウンロード
- ステージングディスクの作成
- ステージングディスクのアタッチ
- レプリケーションサーバとAWS Replication Agentのペアリング
- AWS Replication Agentとレプリケーションサーバを接続
- データ転送の開始
初回同期が完了すると、Data replication statusがHealthy に変わります。
7. Configure Launch Settings
リカバリーインスタンスを起動するため、EC2の起動テンプレートの設定を行います。
AWS Elastic Disaster Recovery（DRS）コンソールで、Source serversを表示し、Source Serverの1つをクリックします。
Launch settingsタブを選択し、General launch settingsのEditボタンを押下します。
Instance type right sizingでNoneを選択し、Save settingsボタンを押下します。
続いて、EC2 launch templateのEditボタンを押下します。
EC2の起動テンプレートボックスで、Editを押下します。
テンプレートバージョンの説明にWorkshopTemplateと入力します。
インスタンスタイプにt3.smallを選択します。
ネットワーク設定のサブネットでTargetPrivateを選択します。
また、ファイアウォール（セキュリティグループ）で、既存のセキュリティグループを選択するを選択します。
そして、共通のセキュリティグループの欄でTargetSecurityGroupを名前に含んだセキュリティグループを選択します。
ストレージの設定でボリュームの種類をgp3に変更します。
それ以外はデフォルトのまま、テンプレートのバージョンを作成ボタンを押下します。
作成した起動テンプレートIDを押下します。
アクションでデフォルトバージョンを設定を押下します。
テンプレートのバージョンでWorkshopTemplateを選択し、デフォルトバージョンとして設定ボタンを押下します。
以上を2サーバに対して実行してください。
8. Failing Over
DRSコンソールで、Source Serverの1つを選択し、Server infoを表示します。
画面右上にあるInitiate recovery jobボタンを押下し、Initiate Drillを選択します。
Use most recent dateを選択し、Initiate drillボタンを押下します。
画面左のRecovery job historyメニューを選択し、Job IDを選択します。
Job logでRecoveryが成功したことを確認します。
以上を2サーバに対して実行してください。
9. Validating Fail Over
EC2コンソールでインスタンスwordpress-web.onpremsim.env、wordpress-db.onpremsim.envが新たに起動されていることを確認します。
wordpress-web.onpremsim.envのプライベート IPv4 アドレスをメモしておきます。
Bastionサーバにログインし、PuTTyします。
Saved Sessionsでwordpress-webを選択し、Loadボタンを押下します。
Host Name(or IP address)のwordpress-webの部分を先ほどメモしたプライベート IPv4 アドレスに変更し、Openボタンを押下します。
以下のコマンドを実行し、インスタンスのDNSレコードを更新します。
ADDR=`hostname -I`
HOST=`hostname`
sudo touch /tmp/nsupdate.txt
sudo chmod 666 /tmp/nsupdate.txt
echo "server dns.onpremsim.env" > /tmp/nsupdate.txt
echo "update delete $HOST A" >> /tmp/nsupdate.txt
echo "update add $HOST 86400 A $ADDR" >> /tmp/nsupdate.txt
echo "update delete $HOST PTR" >> /tmp/nsupdate.txt
echo "update add $HOST 86400 PTR $ADDR" >> /tmp/nsupdate.txt
echo "send" >> /tmp/nsupdate.txt
sudo nsupdate /tmp/nsupdate.txt
以上を2サーバ実行してください。
最後にBastionサーバのChromeブラウザを起動し、http://wordpress-web.onpremsim.envにアクセスしてください。
以下のように表示されれば成功です。
後片付け
CloudFormationでネストされたスタック以外のスタックを選択し、削除を実行してください。
スタックの削除に失敗する場合があります。私の場合、再度削除を実施することで解決しました。
それでも削除に失敗するリソースがある場合、CloudFormationからではなく、手動で直接削除してください。
EC2コンソールにを表示し、Recoveryしたサーバ2台を終了します。
EC2コンソールでボリュームメニューを選択し、本ハンズオンで生成した2つのボリュームをチェックします。アクションのボリュームの削除を選択します。
EC2コンソールでスナップショットメニューを選択し、本ハンズオンで生成した1つのスナップショットをチェックします。アクションのスナップショットの削除を選択します。
DRSコンソールでRecovery instancesを選択し、表示されているサーバをチェックし、ActionsのDisconnect from AWSを押下してください。
ダイアログでDisconnectボタンを押下してください。
続いて、再度サーバをチェックし、Delete recovery instancesを押下してください。ダイアログでDeleteボタンを押下してください。
DRSコンソールでSource serversを選択し、表示されているサーバをチェックし、ActionsのDisconnect from AWSを押下してください。
続いて、再度サーバをチェックし、Delete serverを押下してください。ダイアログでPermanently deleteボタンを押下してください。
