はじめに
アマゾン ウェブ サービス(以下 AWS)EC2 インスタンスは、他の仮想化基盤からインポートしたイメージに限ってエクスポートが可能です。AWS 上のギャラリーからデプロイした EC2 インスタンスを他の環境へエクスポートすることは出来ません。ベンダー ロックインがされています。
VM Import/Export を使用して VM としてインスタンスをエクスポート
https://docs.aws.amazon.com/ja_jp/vm-import/latest/userguide/vmexport.html
制約事項
インスタンスとボリュームのエクスポートには、次の制限事項があります。
以前に別の仮想化環境から Amazon EC2 にインポートしたインスタンスでない限り、Amazon EC2 からインスタンスをエクスポートすることはできません。
概要
上記の制約を受けて、本記事では下記ドキュメントの補足として AWS 基盤のエクスポート機能でなく、オンプレミスの物理マシンを仮想イメージに吸い上げる手法で EC2 インスタンスを Azure へマイグレーションする方法を解説しています。
アマゾン ウェブ サービス (AWS) VM を Azure に移行する
https://docs.microsoft.com/ja-jp/azure/site-recovery/migrate-tutorial-aws-azure
Azure リソースの準備
移行先の Azure リージョンに、下記3つの Azure リソースをデプロイしておきます。 ストレージアカウントに関しては現在で v1 のみサポートしています。
構成サーバーの用意
移行元 AWS VPC 内に Recovery Services の構成サーバー (Configuration/Process Server) として EC2 インスタンスをデプロイします。
構成サーバー | 推奨スペック |
---|---|
OS | Windows Server 2012 R2 |
CPU | 8 Core |
RAM | 16 GB |
DISK | 1 TB |
以下は、移行対象の EC2 インスタンスが2台ある VPC 環境へ、構成サーバー (Configuration/Process Server) をデプロイした状態を示しています。
※(非常に重要) Mobility Service エージェントは、構成サーバーにより移行対象の EC2 へプッシュ インストールされます。その際 EC2 側で構成サーバーからの内部通信を FW 等で許可する必要があります。EC2 側で FW を開けるのが難しい場合には手動で Mobility Service エージェントをインストールする事も可能です。
参考資料:Azure Site Recovery (ASR) Mobility Service のインストール
https://www.cloudou.net/azure-site-recovery/asr003/
その他、レジストリ設定など前提条件もクリアしていることを確認します。
https://docs.microsoft.com/ja-jp/azure/site-recovery/migrate-tutorial-aws-azure#prerequisites
構成サーバーの構築手順
1.AWS VPC 内にデプロイした 構成サーバー上でブラウザを起動し、下記の Azure ポータルを開きます。非仮想化/その他を選択し [OK] を押します。
2.デプロイ計画は今回は省略しますので、完了か後で実施するとして次に進みます。
3.自己解凍形式のセットアップファイルと登録キーを、EC2 の構成サーバー上にダウンロードします。
そのまま EC2 構成サーバー上でダウンロードした自己解凍形式のセットアップファイルを実行します。
事前にダウンロードした登録キーを指定します。
一部警告が出ていますが、今回はこのまま続行します。ディスク容量不足など内容によっては対応が必要な場合があります。
インストールが成功すると下記のようになります。
[Finish] 後に、移行元 EC2 インスタンスにインストールする Mobility Service エージェントの為のパスフレーズをクリップボードへコピーするか確認されるので、必要に応じてコピーして保存しておきます。
その後、設定画面が表示されるので Mobility Service エージェントのインストールに利用する管理者アカウントを登録します。
- Linux VM の場合、アカウントは、ソース Linux サーバーの root である必要があります。
- Windows VM の場合、ドメイン アカウントを使用していなければ、移行元 EC2 インスタンスでリモート ユーザー アクセス制御をレジストリで無効にします。
レジストリで、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System の下に DWORD のエントリ LocalAccountTokenFilterPolicy を追加し、値を 1 に設定します。
その他の設定は不要のためアカウント登録後に上記設定画面をクローズします。
構成サーバーの設定が完了したら、再度 Azure ポータルに戻り、作成したサーバーを [構成サーバー] として選択します。
4.移行先ターゲットに、手順1で作成した Azure リソース(ストレージアカウント、仮想ネットワーク)の設定を行います。
5.レプリケーションポリシーを既定値で作成して、構成サーバーに関連付けします。
すべての設定が完了したら最後にOKを押して終了します。
レプリケーションを有効にする
次にレプリケーションを有効にし、下記図のように AWS 側から Azure 側へ仮想マシンイメージの同期を開始します。初期同期には数時間を要しますが、その後は差分のみを短時間で同期し、常に最新の同期状態が継続的に保持されていきます。
作業手順
1.AWS からの移行では、ソースを [オンプレミス] 、マシンの種類を [物理マシン] として選択します。
2.移行先 Azure リソース(ストレージアカウント、仮想ネットワーク、etc)を設定します。
3.この段階で初めて移行元である EC2 インスタンスを設定します。
正常に検出されると以下のように表示されてきます。
4.Mobility Service エージェントのインストールアカウントやレプリケーションするディスクなどの設定をします。
5.最終確認で問題なければOKとします。
最後にレプリケーションを有効にするとレプリケーションが開始されます。初期レプリケーションの完了まで数時間程度は要します。実際には複製する EC2 のディスクサイズに依存します。
Azure への移行
初期レプリケーションが完了したら、最後のステップとして Azure ストレージの保護済みデータより仮想マシンをデプロイします。この処理は Recovery Services ではフェールオーバーと呼ばれています。
作業手順
初期レプリケーションが完了すると [レプリケートされたアイテム] で、該当サーバーが [保護済み] の状態となります。
下記のように [保護済み] の状態になると [...] をクリックして表示されるポップアップメニューで、[フェールオーバー] や [テスト フェールオーバー] が選択できるようになります。ここから対象サーバーを Azure へ移行(フェールオーバー)します。
最初にテスト フェールオーバーを実施し成功したら、実際の移行(フェールオーバー)を実施します。具体的な操作手順は、下記の公式ドキュメントをご参照ください。
1.テスト フェールオーバーの実行
https://docs.microsoft.com/ja-jp/azure/site-recovery/migrate-tutorial-aws-azure#run-a-test-failover
2.フェールオーバーの実行
https://docs.microsoft.com/ja-jp/azure/site-recovery/migrate-tutorial-aws-azure#migrate-to-azure
※ フェールオーバー実施の際に、移行元サーバーをシャットダウンする必要はありません。[フェールオーバー] という操作名になっていますが、実際には移行元サーバーに依存することなく、Azure ストレージに同期済みの復旧ポイントから Azure VM のイメージ(管理ディスク)が作成されます。
移行の完了
移行が完了すると、最初に用意した 3つの Azure リソース以外に、仮想マシンおよび仮想マシンにアタッチされているディスク、NIC といったリソースが生成されているのが分かります。
この後、リモートデスクトップや SSH で仮想マシンにアクセスする場合は、Public IP アドレスをデプロイし仮想マシンにアタッチする等のカスタム作業が必要となります。Recovery Services のマイグレーション操作で自動生成されるのは、仮想マシン、ディスク、NIC の3種類のみとなります。
後始末
移行が正常に完了した後、移行に際し変更・追加した箇所を元に戻します。