AWS MGNでオンプレサーバをクラウド移行

AWS
この記事は約9分で読めます。
記事内に広告が含まれています。

今更感はありますが、AWS MGN(AWS Application Migration Service)を試したので個人的な備忘録を含めて発信していきたいと思います。

※2023年8月時点の内容で記載しております。

以下、目次となります。

全体の流れ

全体の流れです。

  1. 移行元にエージェントインストール
  2. 移行元 → ステージングエリアに転送
    ※レプリケーションEC2が構築されます。
  3. ステージングエリア → 指定エリアにカットオーバー(テスト)
    ※レプリケーションEC2から変換用EC2を経由してテストEC2が作成されます。
  4. ステージングエリア → 指定エリアにカットオーバー(本番)
    ※レプリケーションEC2から変換用EC2を経由して本番EC2が作成されます。

※レプリケーションEC2 = AWS Application Migration Service Replication Server

※変換用EC2 = AWS Application Migration Service Conversion Server

※ステージングエリアは条件を満たしたVPCです。

プライベートネットワーク経由でアプリケーション移行サービスのデータおよびコントロールプレーンに接続 - AWS 規範的ガイダンス
インターフェイス VPC エンドポイントを使用して、セキュリティで保護されたプライベートネットワーク上のアプリケーション移行サービス (MGN) データプレーンとコントロールプレーンに接続します。

上記の公式サイトに書かれていますが、基本的な条件を抜粋すると次の内容です。

  • ソース → 外部通信(Port443)
  • ソース → ステージングエリアのサブネット(Port1500)
  • ステージングエリアの作業用EC2 → AWSリソースへのアクセス(Port443)

AWSリソースへのアクセスは、次の内容です。

  • mgn.ap-northeast-1.amazonaws.com 443
  • ec2.ap-northeast-1.amazonaws.com 443
  • s3.ap-northeast-1.amazonaws.com 443

これらの条件さえ満たせば、楽に移行出来そうな気がします。

Cloud Endureとは少し違う

Cloud Endureの場合、以下のように企業プロキシ経由でステージングEC2からS3等へアクセス出来ましたが、MGNは出来ないように見えます。

★これが出来ない★
ステージングEC2 → Direct Connect → 自社プロキシ → AWSリソースアクセス

便利になるかと思ったら個人的には敷居があがっていた・・・。

MGNを使った移行(ステージングEC2からAWSリソースへのアクセス)は、次の何れかを選択しましょう。

  • ステージングEC2 → VPCエンドポイント → AWSリソース
  • ステージングEC2 → IGW → AWSリソース

※2023年8月時点であって将来的には他にも手段出来ているかもしれません。

あと、あまり重要じゃないですが、テストを飛ばして本番カットオーバーってのも出来なそうです。律儀にステップに沿って進めましょう!

移行してみます。

では早速、オンプレから移行してみます。

前提

◇ 通信経路

  • 移行元 → Direct Connect → 移行先(ステージングエリア)
  • 移行先(ステージングエリア) → IGW(インターネット) → AWSリソース

※最終的にカットオーバーするエリアは、ステージングエリアじゃなくてOKです(IGWが存在しないプライベートなサブネットを指定可能です!)。

今回は、テンプレート設定における「データのルーティング」では「パブリックIP&プライベートIPを利用」を選択します。

→ データはDirect Connect経由なプライベートな通信で送ります。ステージングEC2 → AWSリソースアクセスという部分はPublicなアクセス(IGW経由)とします。

※この選択肢なら移行元データはPrivateな通信のようです。VPCエンドポイントは個人的な諸事情により作れなかったので、ステージングエリアEC2 → AWSリソースのアクセスはPublicIPなIGW経由としています。

◇ 移行元OS

Windows Server

エージェント実行

事前にエージェント(exe)を移行元に格納しておき、powershellで以下を実行します。

# エージェント実行
.\AwsReplicationWindowsInstaller.exe --region XXX --aws-access-key-id YYY --aws-secret-access-key ZZZ --no-prompt
# エージェントインストール結果(失敗例)
The installation of the AWS Replication Agent has started.
Verifying that the source server has enough free disk space to install the AWS Replication Agent (a minimum of 2 GB of free disk space is required).

Unexpected Error
Installation failed.
Learn more about installation issues in our documentation at https://docs.aws.amazon.com/mgn/latest/ug/Troubleshooting-Agent-Issues.html#Error-Installation-Failed

あれ・・・?

実行ファイルと同じ場所に作成されたログを確認したところ、通信関係でした。システム環境変数やインターネットオプションのプロキシを設定して再実行したところうまくいきました。

# エージェントインストール結果(成功例)
The installation of the AWS Replication Agent has started.
Verifying that the source server has enough free disk space to install the AWS Replication Agent (a minimum of 2 GB of free disk space is required).
Identifying volumes for replication.
Disk to replicate identified: c:0 of size 100 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 Application Migration Service Console... Finished.
The following is the source server ID: s-1234567890.
You now have 1 active source server out of a total quota of 150.
Learn more about increasing source servers limit at https://docs.aws.amazon.com/mgn/latest/ug/MGN-service-limits.html
The AWS Replication Agent was successfully installed.

初回転送

エージェントが無事に動き出したため、問題なければ初回転送完了までノンストップで動くはずです。マネジメントコンソール上のステップを確認してみます。

・・・oops!

データレプリケーションが停止しました。
サービスでの認証に失敗しました。

構築されたレプリケーションサーバー(AWS Application Migration Service Replication Server)のシステムログをEC2メニューから確認する限り、AWSサービスへ通信できていないようです。

IGW割当が正常に出来ていなかったため、見直して再実行します。
→ 無事にエラーが解消したため、待ちます。

・・・うーん?

データレプリケーションが停止しました
AWS Replication Agent を Replication Server に接続できませんでした。

色々とログを確認したところ、移行元からステージングサーバに対するポート1500が空いていなかったようでした。

見直して無事に初回転送が開始されました。

テスト&本番カットオーバー

転送が完了したため、テストEC2を作成していきます(Skip可)。

カットオーバー先はプライベートなサブネットにします。
→ 該当EC2の「起動テンプレート」を編集して、サブネットだけではなく、インスタンスタイプなども好みに合わせて変更します。

起動テンプレートです。

※この起動テンプレートはMGNのデフォルト設定から派生した該当EC2に特化した起動テンプレートです。最終的に移行対応が全て完了すれば削除されます。

ところで「一般的な起動設定」では「インスタンスタイプの適切なサイズ設定」をオフにしておかないと、起動テンプレートでインスタンスタイプを指定しても無視されてしまいます。

明示的にしたいなら適切なサイズ設定はオフにする。

準備が整ったためいざテスト実施します。

たまたまなのか「変換に失敗しました」という表示が気になりますが、レプリケーションEC2が自動で再実行してくれたようです。無事に終わりました。

※変換作業用のEC2として「AWS Application Migration Service Conversion Server」が一時的に起動されますが、変換後は自動的に停止&終了します。

続いての流れは次の通りです。

  • テスト完了
    → テスト用のEC2は終了となります。
  • 本番カットオーバー
    → 問題なければ該当移行プロジェクトをアーカイブすれば、レプリーケーションEC2含めたリソースが全て削除されます。

無事に終わりました。

ここまで移行元は起動させっぱなしです。本番カットオーバーの直前まで最新のデータを移行先に同期してくれていました!(ただ、DBのようなアプリケーションによっては確実な整合性のため、直前にサービスを停止させたほうが良いでしょう)。

その他補足事項

移行に関する補足事項です(2023年8月時点)

  • VMWareはイメージがあればインポート可能です。
  • Windows10は持込ライセンス(BYOL)で移行可能です。
    → けど占有ホストじゃないとカットオーバーできません!
  • AWS移行後、オンプレに戻せるインタフェースは今のところなさげです(クラウドロックイン!)

まとめ

従来はCloud Endureによる移行になれていたため、最初はMGNに戸惑いました。MGNであればAWS環境で基本的に完結し、次に何を実施すればよいのか見やすかったため、すぐに慣れることが出来ました。

通信関係でエラーに遭遇することもありますが、ログを見たり、ログ情報をサポートに相談したりすることで解決できるはずです。ただ、AWSリソースへのアクセス部分は環境によっては大変かもしれないなぁと思います。

MGNを使ってクラウド移行をささっと進めましょう!

最後までご覧頂きありがとうございました!

コメント

Top
タイトルとURLをコピーしました