[クラウド移行] CloudEndureを使ったEC2への移行を計画する前に考慮しておきたいポイント

クラウド移行を支援するツール CloudEndure を使ってオンプレミスサーバーから EC2 へ移行を計画する際に考慮しておくポイントを考えてみます。
2020.01.07

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

多くの方がすでにクラウドをご利用頂いているかと思います。
全てのシステムをクラウド上で稼働させている企業もあれば、
一部のシステム、そして、これからクラウド移行を考えている企業もあります。

本エントリでは、クラウド移行を支援するツール CloudEndure を使って
オンプレミスサーバーから EC2 へ移行を計画する際に考慮しておくポイントを考えてみます。

CloudEndure ライセンス

90日間無料で CloudEndure を使用可能です。

90日を過ぎるとレプリケートが停止します。
ライセンスを取り直すことは可能ですが、延長ではなく新規になります。
どういうことかというと、「180日間レプリケーションしたい」という使い方はできないということです。
90日でレプリケーションを完了させるよう計画しましょう。

ライセンス発行は以下 URL から。
無料の CloudEndure Migration ライセンスに登録する

OS/MW ライセンス

オンプレミスで利用している OS やミドルウェアのライセンスが
AWS でそのまま利用可能であるかを販売店に確認しておきます。

CloudEndure で移行する場合、Red Hat Enterprise Linux は Red Hat Cloud Access が必要です。

Windows Server の場合、EC2 利用料金にライセンス料金が含まれる方式と
BYOL の何れかを選択することになります。
BYOL を選択する場合には、Dedicated Host を使用することになります。

ミドルウェアのライセンスには CPU コア数で計算するものが多く存在します。
オンプレミスとクラウドで計算式が変わってくるパターンもあるので注意が必要です。
また、AWS にライセンスを持ち込むには Dedicated Host の使用を強制される場合もあります。
必ず事前に販売店へ確認するようお願いします。

サポート OS

CloudEndure がサポートしている OS は Supported Operating Systems に記載されています。

OS バージョンの他に細かい前提条件も記載されています。
自身が管理しているシステムが CloudEndure でサポートされているかを
前提条件も含めて確認しておきます。
特に Kernel バージョンや追加ソフトウェアが既存アプリケーションに影響しないことは重要な判断基準です。

Red Hat Enterprise Linux と CentOS は 5.x もサポート対象になっていますが、
ServerManager Agent、CloudWatch Agent のサポートは 6.x 以上です。
移行後に AWS 最適化を行うために 5.x のサーバーは新しい OS での新規インストールを検討します。
(古すぎてサポート終了日を迎えている/迫っている OS はリプレースをおすすめします。)

通信要件

オンプレミスネットワークが CloudEndure の通信要件を満たしていることを確認します。
AWS 側も通信要件を満たすように VPC 等を作成します。

オンプレミス側

コピー元サーバー → CloudEndure Service Manager

コピー元サーバーから CloudEndure Service Manager へ TCP-443 の通信が発生します。
CloudEndure Service Manager は SaaS であり CloudEndure が管理しています。

オンプレミスネットワークを完全に閉じているシステムにおいては CloudEndure が利用できません。
Firewall の設定を変更するか、Proxy サーバーを介するなどの考慮が必要です。
CloudEndure Service Manager の IP アドレスは こちら に記載があります。

コピー元サーバー → CloudEndure Replication Server

コピー元サーバーから CloudEndure Replication Server へ TCP-1500 の通信が発生します。
CloudEndure Replication Server は EC2 上に構成されます。
ここの通信は Direct Connect や VPN を通すことが可能です。
暗号化と圧縮されたレプリケーションデータ用の通信です。

AWS 側

業務で使う VPC と CloudEndure レプリケーションに使う VPC を別々に用意します。
必須ではありませんが、ルートテーブル・セキュリティグループ・NACL など
CloudEndure 向けに構成することになります。あくまでレプリケーション用途です(一時的)。
業務で使う VPC に影響が及ばないよう別途 VPC を用意するのが安全だと思います。

VPC が分けられない場合でも、サブネット・ルートテーブル・セキュリティグループ・NACL は別途用意しておきます。

CloudEndure Replication Server → CloudEndure Service Manager

CloudEndure Replication Server から CloudEndure Service Manager へ TCP-443 の通信が発生します。
インターネットへの経路を設定しておきます。

CloudEndure Replication Server → S3

CloudEndure Replication Server から S3 への通信が発生します。
コピー元サーバーから送られてきたレプリケーションデータは CloudEndure Replication Server を経由して S3 へ保存されます。
インターネットへの経路、または。S3 Endpoint を設定しておきます。

ネットワーク帯域

必要最低限帯域

レプリケーションに必要な最低限のネットワーク帯域は
「同時にレプリケーションするサーバーのディスク更新量 (bytes per sec) 合計」になります。

ネットワーク帯域より更新量が多いと、どんどんレプリケーションラグが溜まっていき
いつまでたってもレプリケーションが完了しません。

コピー元サーバーのディスク更新量の平均と最大は事前に取得しておきます。

帯域制限

CloudEndure のレプリケーション速度は以下に依存します。

  • コピー元サーバーと CloudEndure Replication Server 間の帯域幅
  • コピー元サーバーの I/O 性能

CloudEndure のデフォルト設定では帯域コントロールをしていません。
レプリケーション用のネットワークがあれば気にしなくてよいですが、
既存の業務 LAN、運用 LAN を用いてレプリケーションデータを行う際には
CloudEndure で帯域制限を設定します。

ここで注意しないとならないのは、帯域制限をかけるとしても
前述の必要最低限帯域を下回ってはいけないということです。

適切な帯域制限値を事前に見積もるのは困難なので
事前検証を実施して、どの程度の帯域制限であれば
通常業務とレプリケーションのバランスが取れるのかを判断ください。

CloudEndure より他サービスを検討したほうが良いケース

仮想化基盤が VMware または Hyper-V で自身のコントロール下

オンプレミスが仮想化されており VMware vSphere または Microsoft Hyper-V/SCVMM を基盤して採用、
かつ、自身のコントロール下にある場合は AWS Server Migration Service を検討ください。

Server Migration Service ならサーバーに手を加える必要がない分、
安全に移行が行える可能性が高いと考えています。

Write Heavy なサーバー

書き込みが多いサーバーでは、レプリケーションデータの転送がが追いつかず
レプリケーションが完了しない可能性があります。
DB サーバーの移行は AWS Server Migration Service/Database Migration Service を検討ください。

まとめ

CloudEndure を使用する前に考慮しておくポイントを考えてみました。
パワフルなツールではありますが、何でも叶う魔法のツールではありません。
計画より前の検討する段階で色々な考慮しておくことが
安心安全に移行を完遂させるためには大切だと改めて感じました。

参考

CloudEndure Migration
ツールを使ったAWSへのサーバー移行の考察
【わーい】CloudEndureが無料で利用できるようになりました【タダダヨー】

以上、吉井 亮 がお届けしました。