1. はじめに
オンプレミス環境からAmazon EC2に移行する際に利用するツールとして、AWS Application Migration Service (MGN)はよく検討される選択肢かと思います。
VMware Cloud on AWSからもAmazon EC2への移行でも同様にAWS MGNが活用できるので、実際に試してみた手順を備忘録として残します。
ざっくりとしたイメージとしては、VMware Cloud on AWSを「オンプレミスVMware仮想環境」のように扱って、Amazon EC2に移行していると想像いただければと思います。
今回はInternet Gateway(IGW)経由で移行元VM(のAWS Replicaiton Agent)とAWS MGNをパブリックアクセスさせています。
ENIを経由したプライベートアクセスでのAWS MGN利用パターンは続編記事もご参考ください。
ちなみに: Amazon EC2 から VMware Cloud on AWS に移行の場合
Amazon EC2からVMware Cloud on AWSに移行(変換)するというアプローチもVMware vCenter Converter Standalone 6.4 (2023年5月GA)で可能になっています。次のブログ記事が非常にわかりやすいのでぜひご参考ください。
2. 「AWS Application Migration Service (MGN)」 について
「AWS BlackBelt AWS Application Migration Service (AWS MGN) 概要」をご参照ください。
AWS MGN エージェント版とエージェントレス版の違い
AWS MGNにはエージェント版とエージェントレス版の２パターンあるのですが、特別な要件がない場合はエージェント版が推奨となっています。今回の記事でもエージェント版についてご紹介します。 (下図はAWS BlackBeltの抜粋)
AWS MGNエージェントレス版は現在VMware vCenterバージョン6.7系、7.0系、8.0系をサポートしています。
https://docs.aws.amazon.com/mgn/latest/ug/agentless-mgn.html
一方AWS MGNエージェント版は移行対象のOSに直接エージェントをインストールするため、VMware仮想環境 (vCenter)バージョンおよび物理環境には依存しません。
AWS MGNでサポートされる対象OSについては次のAWS公式ガイドをご参照ください。
3. やってみた
次のような構成で試してみました。(下図は再掲)
今回は移行元環境に依存しないAWS MGNエージェント版を利用しています。
VMware Cloud on AWS上で稼働するCentOS 7系とWindows Server 2019の仮想マシンを移行対象としています。
次から手順の概要をご紹介します。詳細な手順および利用条件については次のAWS公式ガイドおよび最下部の参考資料まとめをご参照ください。
(1) AWS MGN の有効化 (初回のみ)
初回利用の場合、まずはAWS MGNサービスを有効化します。
この際には必要なIAMロールも合わせて作成されます。
(2) レプリケーションテンプレートの設定
必要に応じてレプリケーションテンプレートの設定を変更します。
レプリケーションサーバー(下図中央)は、AWS MGNが移行元サーバーをAmazon EC2に移行(変換)する際に「一時的に」作成されるEC2インスタンスです。MGNによる各移行フェーズ毎に自動で作成・削除されるためそこまで意識することはないのですが、私は今回レプリケーションサーバー用にStaging VPCを別途新規作成しています。
作成されたレプリケーションサーバーは次のように確認できます。
(3) 起動テンプレートの設定
MGNでの移行先VPC、サブネット、セキュリティグループ、使用ライセンスなどを設定します。
これにより移行後のEC2がどのVPCで稼働するかが決まるため重要な事前ステップとなります。
移行先のVPCは任意ですが、今回私はVMware Cloud on AWSとは無関係のVPCを移行先としています。
(上述のStanging VPCでも、Connected VPCでもよいです。)
(4) Systems Manager (SSM) Agent のインストール (任意)
任意ですが、MGNでの意向ではSSMエージェントのインストールまで含めることができ、移行後のアクションまで指定することができます。(便利！)
https://docs.aws.amazon.com/mgn/latest/ug/post-launch-settings-editing.html
(5) 移行対象のサーバーでAWS MGN エージェントを起動
Linux OS、Windows OSそれぞれで手順がありますが、VMware Cloud on AWS 環境で実施するにあたってのつまづきポイントのみ簡単にご紹介します。
詳細な手順はAWS公式ガイドをご参照ください。
Linux / Windows 共通
S3 endpointsへのTCP:443(HTTPS)アクセス許可
VMware Cloud on AWS環境上の移行対象仮想マシンは、S3 endpointsにアクセスする必要あります。
https://docs.aws.amazon.com/mgn/latest/ug/installing-agent-blocked.html
今回私はMGN用に新規S3 endpointsの作成をせず、またConnected VPC経由でのS3 endpontsへのアクセスもさせず、over Internetの経路でS3 endpointsにアクセスさせています。
MGN Service へのTCP:1500 アクセス許可
VMware Cloud on AWS環境上の移行対象仮想マシンがMGN Serviceにアクセスする際、TCP:1500およびTCP:443で通信する必要があります。
https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html
TCP:1500は事前定義されたサービスではないので、新規に作成する必要があります。
TCP:443(HTTPS)は事前定義されていますが、今回はわかりやすいようにMGNとして１つにまとめています。
Linux の場合
AWS MGNを実行するために、Python 3のインストールが必要となります。
Linux環境でエージェントを実行した際にエージェントのインストールが途中で止まってしまう場合、必要なkernel packagesがインストールされていない可能性があります。
「aws_replication_agent_installer.log」のログファイルを確認してみましょう。
例えば次の場合には、”yum -y ***”で必要なパッケージをインストールしようとしているのが確認できます。
今回この移行元Linux仮想マシンにはインターネットアクセスがないためパッケージをダウンロードできておらず、エージェントの実行に必要なパッケージがインストールできていないため途中で止まるということが起きています。
今回は移行元Linux仮想マシンに一時的にバブリックインターネットアクセスを許可して必要なパッケージをダウンロードしました。パッケージのインストールが完了したらアクセス許可する通信ポートを最低限に閉じています。
Windows の場合
Amazon Root CAsのインストール
Amazon trust servicesが提供するルート証明書のインストールが必要となります。
https://www.amazontrust.com/repository/
(私が一番手こずったポイントなのですが、AWS re:Postで海外のエンジニアが同様な投稿をしているのを発見して対処できました。5つのRoot CAsを全てダウンロードしてインストールしました。)
(6) AWS MGNでカットオーバーを実行
AWS MGNではテスト、カットオーバーと大きく２つのフェーズで移行を進めます。
今回は検証なので細かなレプリケーション差分の確認は省略し、カットオーバーの成功および簡単な動作検証だけ実施しました。
いずれもID/Passwordは移行元の環境と同じとなります。
AWSマネジメントコンソールから各フェーズの確認 (AWS MGN)
AWS MGNから各フェーズごとの進捗を確認できます。
Linux (カットオーバー完了後)
VMware Cloud on AWS上で稼働させていたCentOS7の仮想マシンを無事Amazon EC2に移行させることができました。
Windows (カットオーバー完了後)
VMware Cloud on AWS上で稼働させていたWindows Server 2019の仮想マシンを無事Amazon EC2に移行させることができました。
(検証環境なので贅沢にVMware仮想マシンとしてRAM 32GBを割り当てていたのをすっかり忘れていて、Amazon EC2ではm5.2xlargeとしてデプロイされています。Amazon EC2への移行後はパフォーマンスを考慮しつつリサイズした方が良いかもしれません。)
4. さいごに
今回はAWS MGNを活用したVMware Cloud on AWS環境からAmazon EC2への移行を試してみました。
オンプレミスVMware仮想環境からクラウドに移行するに際して、アプリケーションの変更やIPアドレスの変更が難しい仮想マシンなどに対してはVMware HCXやL2延伸などを活用し移行期間を大幅に短縮し、VMware Cloud on AWSに移行(クラウドリフト)するという手法は非常に有効かと思います。
そのあと徐々に時間をかけてアプリケーションを改修していき準備ができた仮想マシンから、あるいはライセンスの観点からAmazon EC2での利用が適する一部の仮想マシンに対しては、今回のように個別にEC2に移行(シフト)していくアプローチもあると知っていただければ幸いです！
補足など (CloudEndureとの比較)
Amazon EC2への移行って「CloudEndure」が使えたような・・？ とか、 AWS Server Migration Service (SMS) があったような・・？などの場合はこちらのAWS re:PostやAWS公式サイトもご参考ください。
いずれの場合も現在は AWS Application Migration Service (MGN) が推奨となっています。
CloudEndure Migration を使用して、サーバーまたは仮想環境を AWS に移行したいと考えています。どうすればよいですか?
A: 2022 年 12 月 30 日以降、CloudEndure Migration はすべての商用 AWS リージョンで利用できなくなりました。CloudEndure Migration は、中国、AWS GovCloud (米国) リージョン、および AWS Outposts で引き続きご利用いただけます。2022 年 12 月 31 日以降、商用リージョンのお客様は AWS Application Migration (MGN) を使用できます。
(余談) 「AWS Application Migration Service」の略称が「AWS MGN」なのは若干こじつけみを感じるのですが、AWS公式ではそのように略記しているのでそのまま受け入れています。ちなみに「AWS AMS」は「AWS Managed Service (AMS)」を指すようです。
5. 続編
6. 参考にさせていただいた資料
7. そのほか関連資料