CloudEndure Migration を使ったAWS移行を計画する
ネクストモードの韓です。 CloudEndure Migration を使った案件を幾つか携わらせて頂いたので、そのナレッジを忘備録として残します。
- CloudEndure シリーズには継続的なデータ同期を含むBCP環境を実現するで "CloudEndure Disaster Recovery" というサービスもありますが本エントリでは触れません。
- 本エントリで "CloudEndure" とだけ記載した場合は ”CloudEndure Migration" を指すものとします。
CloudEndure Migration とは
"CloudEndure Migration" はAWSが提供するサービスで、いわゆる「イメージ転送」にて移行ができるものです。 元々は有償サービスで、AWSを始めとした各種クラウドへの移行が行えるサービスでしたが、AWSが買収したことにより無償提供されAWSへの移行専用サービスとなりました。
AWSが提供するサーバーイメージ移行サービス(ツール)としては、VMImport や Server Migration Service がありますが、前述のサービスより手軽で幅広いシーンに対応できることから非常に使い勝手がよく、個人的には第一選択とすべきと考えています。
サービス名 | 特徴 | データ同期 |
---|---|---|
VMImport | VMwareからエクスポートしたサーバーイメージをインポートしEC2に変換 | なし |
Server Migration Service | 仮想化基盤(VMware, Hyper-V)からサーバイメージを抽出し EC2 へ変換 | なし |
CloudEndure Migration | 移行元サーバーに導入したエージェントを介してディスクイメージを転送し EC2に変換 | 有り 条件付(後述) |
特徴を知る
制約の確認
- 対応OSに縛りがある
- Supported Operating Systemsを参照し対応しているか確認する必要がある
- 移行対象サーバー全てに エージェント導入が必要
- 制御系とデータ転送の2つの通信経路がある
- 前者の制御系はクラウドにある CloudEndure のサービス本体と通信する必要があり インターネット通信が必須 となる
- データ転送はインターネットと閉域網の双方が利用できる。閉域網の場合は Direct Connect や VPN を事前に張っておく必要がある
- 無償利用できるがライセンス期間は90日である
動作機序
ざっくりとした動作は以下となります。
- CloudEndure は移行元サーバー導入したエージェントを介してディスクイメージを転送する
- データ転送制御のためクラウド上のCloudEndureサービスと通信を行う
- データ転送を開始するとディスクイメージを受け取るレプリケーションサーバーが立ち上がり、移行元サーバーと同数のEBSが作成されデータ転送される。
この際、移行元サーバーとレプリケーションサーバー間は 継続的なデータ同期 が行われている点に着目。 - 移行先サーバーの設定は BluePrint と呼ばれるパラメータにてインスタンスタイプや所属サブネットやセキュリティグループ等を指定して行う。
- 移行先環境にサーバーを立ち上げる(=カットオーバーという)際はBluePrintを元にAMIが作成されEC2が立ち上がる
- レプリケーションサーバにアタッチされ転送されたディスクイメージはスナップショットが取られ、それを元に移行先サーバーに新たなEBSとしてアタッチされる
カットオーバーで同期は失われる
レプリケーションサーバーは移行元サーバーのディスクイメージを継続的に受け止め同期が行われるが、移行先サーバーのディスクはカットオーバーした時点のスナップショットを元に構築される点です。
つまり、カットオーバーした段階で移行元サーバーと移行先サーバーのデータの乖離が始まると言うことになります。
テストモードとカットオーバー
CloudEndureで移行先サーバーを構築するのはカットオーバーだけでなく「テストモード」というものがあります。 これは動作としてBluePrintどおりに移行先のEC2が立ち上がるかどうかを確認するもので、ほぼカットオーバーと同じです。 CloudEndureの設計思想としてはこのテストモードを利用して動作確認を行う位置づけとなります。
このテストモードで十分な動作確認が取れたのであれば本番用のカットオーバーとなりますが注意すべき点があります。 テストモードで立ち上げたサーバーは削除される という点です。
せっかく設定変更やチューニングを施しても、カットオーバーでレプリケーションサーバー上にある同期されたディスク情報で新たにサーバーが立ってしまうため、これらの作業は「無かったこと」となります。
手順を明確にし設定変更をスクリプト化する等の準備を行い、カットオーバーがスピーディに行われるよう準備する必要があります。
移行元環境への考慮
前図では単一サーバーとしましたが、実際はデータ転送は複数サーバーを同時に実行することが可能です。 これは非常に有用な機能なのですが、移行元環境に過度の負荷をかける可能性があり、計画を建てる上で重要なファクターとなります。
- データ転送初期はディスク全体をスキャンするためCPU負荷が高くなる可能性があります。特にシングルコアのサーバーの場合はサービス影響が大きく出る可能性があります。
- 複数サーバーを一括で同期をとった際に移行元環境のネットワーク出口のトラフィック逼迫し既存サービスに影響が出る可能性があります。この場合は転送時間帯や帯域制御を考慮する必要があります。
計画を立てる
計画を立てる上で以下のことを考慮するとスムーズにいくかと主ます。
移行期間
ライセンスの期間は90日ですがアカウントは再発行は可能なためそれほどシビアではありません。とはいえデータ転送の期間を考慮したライセンス取得を行う必要があります。
またデータ転送の時間や移行後の動作確認等も必要となるため十分な期間の考慮が必要となります。
通信経路
CloudEndureはエージェントがインターネット通信が必要となるため、移行元サーバーの配置によっては通信経路の穴開けが必要となります。 既存環境の変更が必要な場合、様々な調整や費用が発生するケースも考えられますので、十分な考慮をしておきましょう。
データ転送経路についても考慮が必要です。インターネット経由でのデータ転送でも十分なケースもありますが、データ転送期間をなるべく短くしたいのであれば高品質な専用線が必要となってきます。この場合はデータ量(全サーバーのディスク容量の和)と回線品質を考慮し、専用線が必要かどうかを判断する必要があります。
また、インターネット経由でのデータ転送の場合、既存サービスの通信を圧迫しないかの考慮も必要となってきますので、併せて確認をしましょう。
システム切替え
CloudEndureはサーバー移行を行うサービスであり、エンドポイントを切り替えは別途考慮する必要があります。主にDNS切替えが主となる戦略となると思いますが、閉域網の場合はルーティング等も考慮する必要がでてきますので、計画に漏れがないようにしましょう。
移行先環境
CloudEndure は移行元サーバーのイメージをそのまま転送するため、アプリケーション設定やOSユーザーもそのまま引き継がれます。
そのためネットワーク設定をそのまま引き継いだ場合、そのまま動作すると考えられます。逆にネットワーク設定を変更したのであれば、各サーバーのアプリケーション設定を見直す必要があります。サーバー転送後の作業として設定変更と動作確認が必要となってきますので注意が必要です。
なお、移行先環境(VPC,サブネット等)はカットオーバーに先立ち構築しておく必要がありますので、計画の際には考慮が必要です。
人手がかかる作業の考慮
移行先サーバーのパラメターは CloudEndure コンソール の Blue Print にて入力を行います。 これはコンソールのGUIでの実施であるため一括入力・一括確認ができません。対象のサーバー台数が数~十数台程度であれば「気合でなんとかなる」レベルですが、数十台以上のオーダーとなるとそうもいきません。 幸いなことに CloudEndure には複数ユーザーを登録することが可能ですので複数人で分担して並列作業が可能となります。
移行対象台数を考慮し人員と十分な工期の確保をしましょう。
カットオーバー後作業の考慮
「テストモードとカットオーバー」の項で述べたように、カットオーバー後の作業はなるべく自動化を行う必要があります。 テストモード時にしっかりと確認することが必要で、このフェーズに十分な工数を掛けておく必要があります。
テストモードは何度も実行することが可能ですので、事後作業のスクリプト化や省力化の確認を何度も行うことが出来るため、カットオーバーの前の最終確認はここで担保することとなります。
なおこの期間も移行元サーバーとレプリケーションサーバー間は継続的なディスク同期が行われています。 ライセンス期間も気をつけて十分な工期をとるよう考慮しましょう。
マネージドサービスの考慮
せっかくクラウドに移行するのでロードバランサーやデータベースをマネージドサービスに変更したいといった要望があるかもしれません。 CloudEndureはサーバー移行のみ担当するため、マネージドサービスは別途構築が必要となります。
例えばロードバランサーだと、Application Loadbalancer の構築とサーバー証明書設置およびEC2へのアタッチ作業が必要となります。マネージドDBのRDSを採用した場合ですと、既存DBからのデータ移行も考慮が必要となります。
動作確認
動作確認はエンドポイント切替え前に実施するものとなるため、その方式や経路について十分な考慮が必要となります。
データ同期
AWS環境にサーバーを立ち上げるカットオーバー後には、設定内容変更や動作確認が必要になるケースが多々有りえます。「カットオーバーをすると移行元サーバーとデータの乖離が生じる」ため、その期間が長ければ何らかのデータ同期を考慮する必要があります。
データ同期については静止点が取れ十分なダウンタイムが取れるのであればあまり考慮は必要有りません。
一方で無停止やそれに準じる必要がある場合、既存サーバーとのデータ同期を考慮する必要があります。CloudEndure Migration 単体で解決出来ないので何らかの方策を考える必要があります。
逆に言えばデータ同期戦略がはっきりしていれば、システム切替えについて慌てる必要がなくなるとも言えます。
参考:
- データベース
- データベースのレプリケーション機能を用いる
- Database Migration Service を用いる
- ファイルシステム
- AWS DataSyncを用いる
- rsync等の従来的な手法を利用する
まとめ
CloudEndure は非常に有用でいわゆる「リフト&シフト」の リフト を簡易に行えるサービスですが考慮すべき点が幾つかあります。
とくに初めてクラウド移行を検討するといったケースで用いられるサービスであるため、AWSだけではなくこのツールも全然ワカラナイといった状況は十分にありえるケースだと思います。
「ぶっつけ本番であれもこれも考慮漏れたった」という事が無いよう、このエントリが参考になれば幸いです。