案件で、CloudEndureを利用しそうだったので、ちょっとテストしてみました。
設定の仕方DR側での起動確認は下記のページを参考にしました。
http://blog.serverworks.co.jp/tech/2020/03/18/cloudendure-dr-01
http://blog.serverworks.co.jp/tech/2020/03/25/cloudendure-dr-02/
http://blog.serverworks.co.jp/tech/2020/04/17/cludendure-dr-03/
手順書を見れば、操作はでき、簡単にDR先にコピーを作れます。
CloudEndure DRの機能はC2のEBSのブロック単位で変化を検知し、変化分をコピー先に変更分の情報をコピーします。
CloudEndure側でプロジェクトを作るとプロジェクト単に、コピー元のリージョン、コピー先のリージョンを選ぶことができます。また、このプロジェクト単位に転送先にコピーを管理するEC2サーバが立ちます。
CloudEndure DRでプロジェクトを作成し、DR元サーバにCloudEndure DRのエージェントを追加すると下記のような構成になります。コピー管理サーバには、サーバAのEBSと同じサイズのEBSが追加され、コピーが作成されます。
例えば、同じプロジェクトに新規に2つのEBSボリュームを持つサーバを立てると下記のように、コピーを管理するサーバにEBSボリュームが作成されます。
CloudEndureではDRサイトを作るときに、どの時間帯のスナップショットに戻るか決めることができるのですが、AWSにすごく溶け込んでいて、そのスナップショットはEBSのスナップショットに対応しているように動作していました。公式文書はないので想像の域をでませんが、管理上は下記のようになっていると考えられます。SnapShotなので、DR元の変化が激しくなければ、比較的容量は抑えられる構成になっていると思います。
EBSボリュームのBlok単位のコピーなので、メモリ上の情報はなくなる、DBのチェックポイントを作る機能と連携していないので、DBなどは不向きです。そのため、連携できるサーバはバスっと落ちても大丈夫なサーバのDRコピーには向いていそうだと感じました。
検証では、DR元をAmazonLinux2で実施しました。ArmのAmazon Linux2でもやってみたのですが、CloudEndureのエージェントがx64でできているみたいで、失敗していました。Diskサイズの小さいVMでと思いMimimalで実施したときは、モジュールが足らなそうで、DR先で起動に失敗して終わりました。
