皆さんお疲れ様です！椎名です。
クラウドエンジニアとしてキャリアを築いていく上で、絶対と言っていいほどオンプレミからクラウドへの移行案件に関わる機会があります。
AWSでは様々な移行サービスが提供されており、移行戦略において7つのRを提唱しています。
移行パスによって、移行にかかる費用と時間が大幅に変わりますので、実験的にAWSへの移行を試みる場合や、移行の費用と時間を最小限に抑えたい場合は、「リホスト」を採用するケースが多いようです。
今回は、Application Migration Serviceを利用して、オンプレミス環境の仮想WindowsサーバーとLinuxサーバーをEC2へのリホストを検証していきます。
1. はじめに
1.1. 前提条件
1.1.1 Site-to-SiteVPN接続
今回の検証では、オンプレミス環境とAWS VPC間でSite-to-SiteVPNを構築している必要があります。
Site-to-SiteVPNの構築について以前のブログで紹介しています。
パブリックIPのみを利用して移行する方法も合わせて紹介しますので、VPN構築が難しい場合はそちらを参照してください。
1.1.2 VPCの構築
Site-to-SiteVPNブログからやってきている方は、新たにパブリックサブネットを異なるAZに作成し、プライベートサブネットのルートテーブルのルート伝播を無効にします。また、両方のルートテーブルに送信先がオンプレ環境のCIDR、ターゲットが仮想プライベートゲートウェイのルートを追加してください。
パブリックIPのみを利用する場合は、新規でVPCを作成し、パブリックサブネットとプライベートサブネットを異なるAZで作成します。
1.1.3 移行用IAMユーザー作成
新規IAMユーザーを作成し、「AWSApplicationMigrationAgentPolicy」管理ポリシーをアタッチします。
アクセスキーを生成し、IDとキーを控えておきます。
1.1.4 仮想マシン
ソースサーバーは、前回のブログで作成したVMを使います。
1.2. 構成イメージ
1.2.1 プライベートIPとパブリックIPを利用する場合
- この構成では、Site-to-SiteVPNを通して、プライベートIPを利用して1500ポートでセキュアにステージングサブネットにソースサーバーのレプリケーションを継続します。ソースサーバーと各サービスのパブリックエンドエンドポイントとの通信には、インターネットを通して443ポートで行われます。
- レプリケーションサーバーは、パブリックIP+インターネットゲートウェイで各サービスのパブリックエンドエンドポイントと通信を行います。
1.2.2 パブリックIPのみを利用する場合
- この構成では、インターネット通して、パブリックIPを利用して1500ポートでセキュアにステージングサブネットにソースサーバーのレプリケーションを継続し、443ポートで各サービスのパブリックエンドポイントと通信します。
- レプリケーションサーバーは、パブリックIP+インターネットゲートウェイで各サービスのパブリックエンドポイントと通信を行います。
1.2.3 移行の全体的な流れ
①MGNのセットアップ及び各種テンプレートの設定
②ソースサーバーにレプリケーションエージェントをインストール
③レプリケーションテンプレートの設定に従って、レプリケーションサーバーが起動するのを確認
④レプリケーションが完了したら、テストサーバーを起動し、中身をチェック
⑤テストサーバーが問題なければ、カットオーバーして本番サーバーを起動する
⑥レプリケーションをアーカイブ化
1.2.4 各サービスエンドポイントとの通信方法について
今回ご紹介する二つの構成は、いずれもソースサーバーはインターネット経由で、各サービスのパブリックエンドポイントと通信を行います。
移行要件などで、インターネットを経由せず、プライベートな接続のみで移行したい場合は、VPNやDirect Connect接続を確立した上で、各サービスのVPCエンドポイントを作成する必要があります。
今回はあくまでも移行に関する検証を行うため、プライベートIPとパブリックIP両方を利用する方針でやっていきます。
1.2.5 ステージングとターゲットサブネットの環境について
移行先のVPC内は異なるAZにステージングとターゲットサブネットを構築していますが、レプリケーションやテストサーバーの起動で既に稼働中のVPCに影響を与えたくないなどの場合、カットオーバーサーバーのみを稼働中のVPCで起動することもできます。要件に沿って様々な組み合わせが可能です。
1.3. 各種テンプレートの設定
1.3.1 サービスのセットアップ
はいじめてApplication Migration Serviceを使う場合は、セットアップが必要です。関連する権限を許可します。
1.3.2 レプリケーションテンプレートの設定
レプリケーションテンプレートは、レプリケーションサーバー起動時のデフォルトの設定になります。
ステージングサブネットは作成したパブリックサブネットに、インスタンスタイプは[t3.small]に指定します。
データのルーティングとスロットリングは、VPNを利用する場合はパブリックIPとプライベートIP両方を作成し、VPNを利用しない場合はパブリックIPのみ作成します。
1.3.3 起動テンプレートの設定
起動テンプレートは、テストとカットオーバーサーバー起動時のデフォルトの設定になります。
「インスタンスタイプの適切なサイズ設定を起動」のチェックを外し、ターゲットサブネットをプライベートサブネットに指定します。
セキュリティグループは、すべてのトラフィックを許可します。
デフォルトのインスタンスタイプは、Windowsサーバーにリモートアクセス時のパフォーマンスを考慮してmediumに指定しましたが、無料枠のmicroでも構いません。
2. AWS Replication Agent のインストール
2.1. Windowsサーバー
「5.」のインストーラーをローカルPCにダウンロードし、VMのpowershell起動時のディレクトリ（前回作成したものであればC:\Users\Administratorになっているはず）にコピーします。
「6.」のコマンドは、アクセスキーIDとシークレットキーを入力したら更新されますので、更新後のコマンドをコピーし、VMのpowershellに流します。
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 15 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-644fbc6da5cb78586.
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.エージェントのインストールが実行され、インストール完了と同時にレプリケーション開始の準備が始まります。
ソースサーバーのページに戻ると、アクティブなソースサーバーが追加されていることを確認できます。
「次のアクション」が同期完了待ち状態になっています。
レプリケーション開始の準備が自動で進み、準備が完了するとレプリケーションが開始されます。
ここでEC2インスタンスのページを確認してみると、「AWS Application Migration Service Replication Server」という名前のインスタンスが自動で起動され、レプリケーションを継続してくれます。
2.2. Linuxサーバー
ターミナルで、「5.」「6.」のコマンドを順番に流します。
The installation of the AWS Replication Agent has started.
Identifying volumes for replication.
Identified volume for replication: /dev/sda of size 15 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-6ab25433838d8ddbd.
You now have 2 active source servers 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.同様にエージェントがインストールされますと、レプリケーション開始の準備が始まります。
コンソールでサーバーが追加されたことを確認し、レプリケーションの完了を待ちます。
3. テストサーバーの起動
3.1. テストインスタンスの起動
レプリケーションが完了すると、「次のアクション」が「テストインスタンスを起動」に変わります。
「テストおよびカットオーバー」から「テストインスタンスを起動」を実行します。
ここでEC2のインスタンスページを確認してみると、
- 「AWS Application Migration Service Conversion Server」の名前のインスタンスが起動→終了
- 「ソースサーバーコンピュータ名」の名前のインスタンスが起動→停止→起動
がバックで実行されていることがわかります。
3.2. テストサーバーの確認
テストインスタンス起動の完了を確認します（「カットオーバーの準備完了」はまだ押さずに）。
VPN利用であれば、テストインスタンスのプライベートIPをブラウザでアクセスして、webページの表示を確認できます。
インスタンスにリモートデスクトップ接続して、作成したファイルが移行できていることを確認できます。
起動完了してからアクセスできるまでは、10分以上かかる場合ありますので、気長に待ちましょう。
VPN接続がなければ、踏み台サーバーで確認を実施してください。
Linuxサーバーのページもちゃんと表示されています。
3.3. カットオーバーの準備
最後に、「カットオーバーの準備完了」としてマークをします。
テストインスタンスの確認が問題なければ、そのまま本番サーバーとしても利用できます。
その場合はアクションから「サービスから切断」を実行すればインスタンスがそのまま残ります。
3. カットオーバーサーバーの起動
3.1. カットオーバーインスタンスの起動
カットオーバーインスタンスの起動を実行します。
テスト時と同様に、インスタンスの起動と停止が繰り返されます。
3.2. カットオーバーの最終処理
カットオーバーインスタンスにアクセスし、移行結果の確認を行います。
特に問題なければ、「カットオーバーを最終処理」を実行します。
3.3. ソースサーバーのアーカイブ化
カットオーバーが完了したら、レプリケーションを停止し、ソースサーバーをアーカイブ化します。
これでApplication Migration Serviceによる移行が完了しました。
カットオーバーインスタンスは起動したままなので、終了を忘れずに！
4. 終わりに
Application Migration ServiceはApplicationが名前についていますが、データベースサーバーやファイルサーバーの移行も可能です。
また、今回の検証では触れませんでしたが。起動後テンプレートを設定することで、テスト＆カットオーバーインスタンスの起動と同時に、OSのアップデートや、エージェントのインストールも自動化できますので、移行後の処理に費やす労力を大幅に削減できるため、非常に便利です。
今回のご紹介は以上となります。
では皆さん、よいクラウドライフを！