この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
いわさです。
先日 AWS Elastic Disaster Recovery（AWS DRS）がGAになりましたね。
ドキュメントを斜め読みした感じ、DRに使える何かということがわかりましたが、ちゃんと見ていくと結構機能が多くて、フワッとした印象を受けやすいなと感じたので、実際に動かしてみてポイントをまとめてみました。
ただ、シンプルにAWS->AWSなどで最初は試せばいいものを、最初からAzure->AWSに挑戦してしまって苦しみました。
最初にElastic Disaster Recoveryの概念とポイント、気になる点
Network diagrams - AWS Elastic Disaster Recovery より引用
- ソースサーバーにエージェントインストールが必要で、AWS上のレプリケーションサーバーへ非同期レプリケーション通信を行います。
- レプリケーションサーバーはアタッチされたEBSのデータを最新に保ちながら定期的にスナップショットを作成します。
- 復元時はレプリケーションに使っているEBSではなくスナップショットからの復元となります。（バックアップリストアとパイロットの中間のような印象）
- 1分ごとにEBSスナップショットを取得しており以下のように保持されるので以下の単位でEC2のポイントインタイムリカバリが可能です。
- 最新（レプリケーションのラグにもよるがドキュメント上はRPO1秒未満とされている）
- 過去1時間は10分ごと
- 過去24時間は1時間に1回
- 過去7日間は1日1回（保持日数は1~365日で指定可能）
- リストア機能はマネージドで、ざっくりいうとやってることは起動テンプレートからの起動＋αをしている感じです。
- RTOはEC2のスタートアップ時間によります。OSやアプリケーションによってはRTOは数十分になりそうです。
- DNSなどネットワーク転送までやってくれるものではありませんでした。上記のRPO、RTOでEC2上へリストア出来る機能となります。
- CloudEndure Disaster Recovery(CDR)を使って実現していますが互換性はありません。DRSが対応していないリージョンやサポートされていないOS/バージョンの場合は引き続きCDRを利用しましょう。
- リストア操作時に、Conversionサーバーが前処理としてAWS仮想マシンに必要なドライバーなどをセットアップしてくれています。
- フェイルオーバー後にフェイルバックさせるデータを逆方向に同期させる機能もあります。（今回は試していない）
- ライセンスに気をつける必要がありそう。ドキュメントによるとRHELはBYOL前提になるみたいです。Windowsなども気になるので、ライセンス周りは改めて確認してみたいです。(がちょっと怖いところでもある)
- レプリケーションサーバーやEBSの料金に加えてDRSの利用料金も時間課金で発生しますが、アクティブDR構成より安くなるんじゃないかなと思います。仮想マシンに限りますが。
全然まとまってないですね。
これでも機能としていくつは削ってまとめたのですが...
やってみた
Azureの仮想マシンをAWSへリストアさせてみたいと思います。
ライセンスの問題が絡むと更に複雑になりそうなのでUbuntu(18.04)をターゲットにしました。
Elastic Disaster Recoveryの設定自体はなかなか簡単
実際にはネットワーク要件を気にする必要があるのですが、パブリックIPアドレスを使ってインターネット経路であればかなり簡単に設定が出来ます。
Azure仮想マシン上でDRSエージェントをインストール・セットアップします。
セットアップ時にIAMユーザーのアクセスキーとシークレットが必要となります。
AWSElasticDisasterRecoveryAgentInstallationPolicyをアタッチしておきましょう。
エージェントのインストール手順はこちらです。
AWS Replication Agent installation instructions - AWS Elastic Disaster Recovery
iwasa@hoge-linux:~$ 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
--2021-11-18 21:40:28-- 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.0.181
Connecting to aws-elastic-disaster-recovery-ap-northeast-1.s3.amazonaws.com (aws-elastic-disaster-recovery-ap-northeast-1.s3.amazonaws.com)|52.219.0.181|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 13398 (13K) [binary/octet-stream]
Saving to: ‘./aws-replication-installer-init.py’
./aws-replication-installer-init 100%[=========================================================>] 13.08K --.-KB/s in 0s
2021-11-18 21:40:28 (141 MB/s) - ‘./aws-replication-installer-init.py’ saved [13398/13398]
iwasa@hoge-linux:~$ 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: HOGEHOGEHOGEHOGEHOGE
AWS Secret Access Key:
Identifying volumes for replication.
Choose the disks you want to replicate. Your disks are: /dev/sdb,/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/sdb of size 4 GiB
Identified volume for replication: /dev/sda of size 31 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-664f4c0a9582bacff.
The AWS Replication Agent was successfully installed.あとは、マネジメントコンソール上でDRSの初期設定だけ済んでいればすぐにレプリケーションが開始されます。
前述のとおりレプリケーションサーバーを介してレプリケーションが行われるのでEC2インスタンスが起動されます。
通信経路にもよりそうですが、最初は数10GB~数100GBの全体の同期を行うので少し時間がかかりますので完了まで待ちましょう。
リストア
ではリストアしてみますが、今回はドリル（訓練）まで試しています。
AWSドキュメントやマネジメントコンソール上では日本語表記がまだ見当たりませんが、他クラウドのディザスターリカバリー関係のドキュメントでは「訓練」と記述がありましたのでこの記事では「訓練」という表現にしておきたいと思います。
AWSのドキュメントに何箇所か記載がありましたが、安定したDR運用を行うために定期的にドリルを行いなさいと記述がありました。
リストアの仕組みですが、ソースサーバーの準じたスペックで自動で起動テンプレートが作成されます。
そして前述のとおりレプリケーションサーバーが定期的にスナップショットを作成しているのでそれを使ってリストアを行う形となります。
※最新からリストアするように選択した場合でも、スナップショット一度作成してからの復元となります。
なお、EBSスナップショットは増分バックアップになるため、上記検証では1分ごとに31GB+4GBのストレージが消費されているわけではありません。
リストアの際には復元ポイントを選択するだけです。
Azureからリストアさせるとステータスチェックに失敗
Azure仮想マシンをリストアしたところEC2インスタンスのステータスチェックに失敗しました。
この記事では検証のためにステータスチェックの問題を解決することを目的にトラブルシューティングしていますが、対応の妥当性については確認が必要です。 こういうエラーが出るのでこう対応しましょうねというガイドではありませんのでその点だけご注意ください。
A start job is running for Wait for…e Configured
EC2のシステムログを見てみると、「A start job is running for Wait...」が永遠と繰り返されています。
[ 96.993222] cloud-init[709]: Cloud-init v. 21.3-1-g6803368d-0ubuntu1~18.04.4 running 'init-local' at Fri, 19 Nov 2021 00:54:30 +0000. Up 96.75 seconds.
[[0;32m OK [0m] Started Initial cloud-init job (pre-networking).
[[0;32m OK [0m] Reached target Network (Pre).
Starting Network Service...
[[0;32m OK [0m] Started Network Service.
Starting Network Name Resolution...
Starting Wait for Network to be Configured...
[[0;32m OK [0m] Started Network Name Resolution.
[[0;32m OK [0m] Reached target Network.
[[0;32m OK [0m] Reached target Host and Network Name Lookups.
[ [0;31m*[0;1;31m*[0m[0;31m*[0m] A start job is running for Wait for…e Configured (1min 36s / no limit)
[K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Wait for…e Configured (1min 37s / no limit)
[K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Wait for…e Configured (1min 37s / no limit)
[K[[0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Wait for…e Configured (1min 38s / no limit)スタートアップのcloud-initでネットワーク待ち続けてしまっているみたい。 対応の妥当性は置いておいて、今回はElastic Disaster Recoveryの評価を優先したいので、このような形で対応しました。
iwasa@hoge-linux:~$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
eth0:
dhcp4: true
dhcp4-overrides:
route-metric: 100
dhcp6: false
match:
driver: hv_netvsc
macaddress: 00:0d:3a:cd:42:ac
set-name: eth0
optional: true
version: 2
iwasa@hoge-linux:~$ sudo netplan applyERROR Daemon /proc/net/route contains no routes
AzureのLinux仮想マシンは専用エージェントがセットアップされており、それを使って様々な処理や自動化を行っています。
AWSへ持ち込むにあたってこのエージェントが上記エラーを出力し続けているのでエージェントの無効化（削除）を行います。
手順は以下へ記載があります。
今回はAzure上で削除したものをレプリケーションさせて復元に利用しましたが、起動テンプレートの初期化処理などで割り込めそうであればその対応のほうが良いかもしれません。
今回は削除してしまったのですが、フェイルバック後にAzureポータル上で逆同期して稼働させることを考えると削除はいけてない気がします。
AWSへフェイルオーバーする際に無効化し、Azureへフェイルバックする際に再度有効化出来れば良いですが...
もう少し調査が必要ですがDRSの検証から少し外れてしまうのでまたいつか深堀りしたいと思います。
iwasa@hoge-linux:~$ sudo apt -y remove walinuxagent
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
linux-headers-4.15.0-162
Use 'sudo apt autoremove' to remove it.
The following packages will be REMOVED:
walinuxagent
0 upgraded, 0 newly installed, 1 to remove and 9 not upgraded.
After this operation, 1190 kB disk space will be freed.
(Reading database ... 82220 files and directories currently installed.)
Removing walinuxagent (2.2.45-0ubuntu1~18.04.1) ...modinfo: ERROR: Module ena not found.
シリアルコンソールからアクセスして確認してみるとENAモジュールがインストールされていないことに気づきました。
Conversion Serverがドライバなどのセットアップをしてくれるので、Nitroに必要なもの一式を入れてくれそうなものなのですが。ここも掘り下げが必要ですね。
hoge-linux login:
Ubuntu 18.04.6 LTS hoge-linux ttyS0
hoge-linux login: iwasa
Password:
Last login: Thu Nov 18 21:27:33 UTC 2021 from 120.51.74.235 on pts/0
Welcome to Ubuntu 18.04.6 LTS (GNU/Linux 5.4.0-1063-azure x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
System information as of Fri Nov 19 02:48:39 UTC 2021
System load: 0.17 Memory usage: 4% Processes: 105
Usage of /: 6.4% of 29.87GB Swap usage: 0% Users logged in: 0
* Super-optimized for small spaces - read how we shrank the memory
footprint of MicroK8s to make it the smallest full K8s around.
https://ubuntu.com/blog/microk8s-memory-optimisation
7 updates can be applied immediately.
5 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable
New release '20.04.3 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
iwasa@hoge-linux:~$ ls
aws-replication-installer-init.py hoge.txt
aws_replication_agent_installer.log
iwasa@hoge-linux:~$ modinfo ena
modinfo: ERROR: Module ena not found.
iwasa@hoge-linux:~$結論からいうとAzureからレプリケーションしたままの状態ではNitroインスタンスで動きませんでした。
今回はc5.largeではなくc4.largeで起動されるように起動テンプレート関係を変更しました。
注意点としては、起動テンプレートはデフォルトバージョンが使用されるのでデフォルト設定を忘れないようにすることと、Instance type right sizingがOnだと適正なサイズで起動テンプレートが自動修正されます。
上記の場合だと、c5.largeに自動変更されてしまいます。
なので、起動テンプレートを手動修正するこちらの設定をOffにするのを忘れないようにしましょう。
ちなみに、初回起動は失敗したので、停止→起動を行うと起動するようになりました。
さいごに
ということでなんとか起動まで出来ましたが、根本的な解決方法をもっとしっかり考えないといけない気がします。
エージェント入れてレプリケーションすれば安心というわけではなくて、しっかり事前検証することが重要だと感じました。
特にマルチクラウドでDR構成を組む場合は仮想マシンの仕様の差をどう吸収するのか検討が必要そうです。
2
