🔖

Azure Migrate のエージェントベースアプライアンスとプライベートエンドポイントを使って VMware の仮想マシンを移行する

Tsubasa Nomura

2023/12/19に公開

Azure

tech

TL;DR

Azure Migrate のエージェントベースアプライアンスとプライベートエンドポイントを使って VMware の仮想マシンを移行する方法を紹介します。
ドキュメントではエージェントベース、プライベートエンドポイントのそれぞれの展開方法は説明されていますが、両方を組み合わせたドキュメントが無かったため手順を整理してみました。

オンプレミス環境でプロキシサーバーがあり、インターネットに接続できない環境も想定しています。
今回の想定は以下のような構成です。

オンプレミス環境からインターネット宛の通信はプロキシサーバーを通します。プライベートエンドポイントは閉域網経由で仮想ネットワークに通信します。

エージェントベースでなくエージェントレスの方法や全体の流れ等は以下の記事をご覧ください。

重要なこと

この記事はかなり長いので初めに重要なポイントをまとめます。
Azure Migrate を閉域化環境で使うには、オンプレミス環境へのコンポーネントの展開、ネットワークの到達性、プロキシの設定等、いろいろと考慮するポイントがあります。
チェックリスト的にまとめてみたので展開するときの参考にしてみてください。

事前準備/要件の確認
- プライベートエンドポイントが作成できるサービスとプロキシサーバーを通す通信の確認
- プロキシサーバーに対する必要な URL の許可設定と名前解決の設定
  (Azure Migrate に必要なネットワークの要件の確認)
- ストレージアカウントの作成とプライベートエンドポイントの作成
- レプリケーションアプライアンスの要件の確認(ESXi のアクセス権、ストレージ容量等)
Azure Migrate のプロジェクト作成
- プライベートエンドポイントを有効にして作成
- プライベートエンドポイントの名前解決の設定(DNS サーバー/hosts の設定)
- ストレージアカウントに対するマネージド ID のアクセス権限の設定
レプリケーションアプライアンスの展開
- プロキシサーバーの設定/除外設定
移行対象サーバーの設定
- レプリケーションアプライアンスからのアクセス許可
  (モビリティエージェントのプッシュインストールに利用)

Tips: Azure Site Recovery と Azure Migrate の違い

Azure Migrate は、Azure のサービスのバックエンドでは Azure Site Recovery のコンポーネントを使っており、混乱しやすいサービスです。
ただ、利用用途は明確に分かれており、Azure Migrate はあくまでも移行用のサービスであり、Azure Site Recovery はディザスターリカバリー用のサービスです。

Azure Migrate からレプリケーション方法を選択するとそれに応じて必要な Recovery Services Vault が作成され、またその Recovery Services Vault によってプライベートエンドポイントやプライベート DNS ゾーンが作成されます。

以下のような関係です。

ちなみに、Azure Migrate を作成したリソースグループを見てみると以下のように、Azure Migrate は非表示のリソースになっています。

非表示リソースを表示していない時:
非表示リソースを表示した時:

Azure のサービスだけでなく、アプライアンスにも違いがあります。Azure Migrate のエージェントベースの移行は、Azure Site Recovery のクラシックのレプリケーションアプライアンスを使用します。

VMware に対する Azure Migrate のアプライアンスは2つあるので、それぞれの違いを整理しましょう。

	Azure Migrate アプライアンス	レプリケーションアプライアンス
VMware の移行方法	エージェントレス	エージェントベース
機能	検出/評価/移行	移行
アプライアンスのファイル名	MicrosoftAzureMigration.ova	MicrosoftAzureSiteRecoveryConfigurationServer.ova
要件	Azure Migrate アプライアンス	レプリケーションアプライアンス Azure に VMware をディザスターリカバリーするための構成サーバーの要件(ASR のドキュメント)
OS	Windows Server 2022	Windows Server 2016

上記の表から、エージェントベースでは検出/評価の機能は存在しないということになります。
これはつまり、エージェントベースの場合、検出/評価に必要な Key Vault やストレージアカウント、Recovery Services Vault、また、それらのリソースに対するプライベートエンドポイント、プライベート DNS ゾーンが作成されないということです。

ドキュメントを読むときはどちらのアプライアンスのことを指しているのか理解しながら読む必要があります。
発見、移行のセクションそれぞれに、Azure Migrate アプライアンスとレプリケーションアプライアンスのドキュメントがあります。

エージェントレスとエージェントベースの機能的な違いが書かれているのでこちらも確認しておきましょう。

要件

プライベートエンドポイントを使う時の要件が記載されているドキュメントです。

以下はレプリケーションアプライアンスの要件です。

ドキュメント

Azure Migrate をエージェントベースで展開する手順です。

プライベートエンドポイントを構成する手順です。

展開の手順

それでは実際の展開の手順を見てみましょう。大まかな流れは以下のようになります。

1. Azure Migrate プロジェクトの作成とストレージアカウントの作成

Azure Migrate プロジェクトの作成

プロジェクトの作成時に、接続方法をプライベートエンドポイントに設定し、プライベートエンドポイントを展開する仮想ネットワークを指定します。

作成が完了すると、プライベートエンドポイントとprivatelink.prod.migration.windowsazure.comのプライベート DNS ゾーンが作成されます。

A レコードには、*.<region>.hub.privatelink.prod.migration.windowsazure.com.のような FQDN が登録されます。

ストレージアカウントとプライベートエンドポイントの作成

プロジェクトを作成したらここでストレージアカウントの作成とプライベートエンドポイントも作成しておきましょう。

2. Recovery Services Vault の作成

Recovery Services Vault の作成

では Site Recovery Vaults を作成します。検出のメニューからウィザードを開始します。

次の画面の最初の選択肢(仮想化されているかどうか？)で3つのオプションがあるので、VMware vSphere Hypervisorを選択します。

さらに次の選択肢(どのようにレプリケーションするか？)でエージェントベースを選択し、リソースを作成します。

ちなみに、エージェントレスを選択すると以下のような画面になります。

ここでキーの生成をすると、Key Vault やストレージアカウント、Recovery Services Vault、また、それらのリソースに対するプライベートエンドポイント、プライベート DNS ゾーンが作成されます。

すると、Azure Migrate のリソースグループに、新しい Recovery Services Vault が作成されます。

privatelink.siterecovery.windowsazure.com のプライベート DNS ゾーンの A レコード

Azure Site Recovery でプライベートエンドポイントを構成したことがある方は同じようなリソースが展開されていることに気づくと思います。

改めて Azure Migrate の画面に戻ると、レプリケーションのメニューが有効になっていることが確認できます。

3. レプリケーションアプライアンスの展開

1. レプリケーションアプライアンスのダウンロード

もう一度、検出のメニューからウィザードを開始します。すると、今度はレプリケーションアプライアンスのダウンロード画面に遷移するのでダウンロードします。

ダウンロードした OVA ファイルを vCenter にデプロイします。

(参考)OVA デプロイのスクリーンショット

展開された仮想マシンの構成を見てみましょう。

2. 起動時の設定画面

最初に、仮想マシン名の設定やテナントへの接続を行います。インターネットへの接続が出来ない場合、プロキシの設定画面になり先に進むことができません。

設定が完了するとレプリケーションアプライアンスが再起動します。

レプリケーションアプライアンスの設定画面

3. ブラウザベースの Site Recovery/OS への設定

次に、仮想マシンへログイン後、ブラウザベースの設定画面でプロキシサーバーや Site Recovery Vault への接続を行います。OS の設定もします。
ブラウザベースの設定画面は自動的に立ち上がってきますが、https://<レプリケーションアプライアンスのIPアドレス>:44315にアクセスすることで手動で開くこともできます。

今回のシナリオでは、プロキシサーバーの存在とプライベートエンドポイントが前提です。ブラウザベースの設定だけでは完結しないので注意しましょう。
レプリケーションアプライアンスに対して以下を設定します。

ネットワークルーティング
- 当然ですがプライベートエンドポイントへアクセスできるようにレプリケーションアプライアンスからネットワーク的な到達性を確認しておきます。
名前解決
- プライベートエンドポイントの FQDN の名前解決ができるようにします。
- アプライアンス 1台のみであれば hosts ファイルに書いてしまうのが簡単かもしれません。
- プライベートエンドポイントの FQDN 以外のエンドポイントについてはプロキシサーバーで名前解決ができるようにします。
プロキシサーバーの指定と除外
- インターネットへ直接アクセスできない前提なので、プロキシサーバーを指定します。
- ただし、プライベートエンドポイントへはプロキシサーバーを経由せずにアクセスする必要があるため、プライベートエンドポイントの FQDN を除外します。

順番を間違えると設定に失敗するので整理します。

以下重要なポイントをまとめます。

名前解決

hosts や DNS サーバーに登録するレコードは、Azure Migrate のページからダウンロードができます。

ストレージアカウントの FQDN は、ここに含まれないので別途取得しておきます。

hosts の例

10.200.0.11 1507176682766216089-asr-pod01-id1.jpe.privatelink.siterecovery.windowsazure.com
10.200.0.12 1507176682766216089-asr-pod01-rcm1.jpe.privatelink.siterecovery.windowsazure.com
10.200.0.13 1507176682766216089-asr-pod01-srs1.jpe.privatelink.siterecovery.windowsazure.com
10.200.0.4  1507176682766216089-asr-pod01-tel1.jpe.privatelink.siterecovery.windowsazure.com
10.200.0.5  1507176682766216089-asr-pod01-prot2.jpe.privatelink.siterecovery.windowsazure.com
10.200.0.6  saforazuremigrate.blob.core.windows.net

プロキシサーバーの指定と除外

レプリケーションアプライアンス起動時の設定画面でプロキシサーバーを指定したため、ブラウザベースの設定画面では既にプロキシサーバーが指定されています。
ただし、除外設定は入っていないので、プライベートエンドポイントの FQDN を除外します。

除外設定ができる箇所は以下の3点あります。

ブラウザベースの設定画面
システムアカウントのプロキシ設定
レジストリ

以下のようにプロキシの設定をいれて、Saveします。

1507176682766216089-asr-pod01-id1.jpe.privatelink.siterecovery.windowsazure.com;1507176682766216089-asr-pod01-rcm1.jpe.privatelink.siterecovery.windowsazure.com;1507176682766216089-asr-pod01-srs1.jpe.privatelink.siterecovery.windowsazure.com;1507176682766216089-asr-pod01-tel1.jpe.privatelink.siterecovery.windowsazure.com;1507176682766216089-asr-pod01-prot2.jpe.privatelink.siterecovery.windowsazure.com;192.168.1.151;saforazuremigrate.blob.core.windows.net

システムアカウントのプロキシ設定

システムアカウントのプロキシ設定は、インターネットオプションの設定画面から行います。ただし、システムアカウントの設定画面を開くために、PsExec を使う必要があります。
コマンドプロンプトから、以下のコマンドを実行します。

psexec -i -s control inetcpl.cpl

除外対象の FQDN を入力します。

レジストリ

以下のキーに対して値を設定します。

キー: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure Site Recovery\ProxySettings
値: ProxyAddress(プロキシサーバーの IP アドレス/FQDN)
値: ProxyBypassUrls(除外対象の FQDN)

アプライアンスの構成チェック

ウィザードの中で、アプライアンスの構成チェックがあります。
ここで、プロキシサーバーのの設定の確認等もあります。

vCenter / 対象サーバーの資格情報の登録

移行対象サーバーを検出するために、vCenter を登録します。
vCenter を使うことで対象サーバーの検出が vCenter 経由で出来るので対象サーバーの情報登録、モビリティエージェントのインストールを手動で登録する必要がありません。

vCenter の情報を登録する

サーバーの資格情報を登録する

Azure Migrate(Recovery Services Vault) への登録

ここまでの設定が完了すると、レプリケーションアプライアンスが Azure Migrate(Recovery Services Vault) に登録されます。

レプリケーションアプライアンスの登録完了

Azure Migrate の確認

Configuration Server
Configuration Server > Process Server
Configuration Server > vCenter
Configuration Server > Master Target server

Azure Site Recovery の確認

Site Recovery infrastructure > Configuration Server (Classic)

※サーバーの項目の詳細は、Azure Migrate と同じです。
Site Recovery jobs

4. レプリケーション

Recovery Services Vault にアプライアンスが登録されたら、Azure Migrate の画面に戻って、レプリケーションのウィザードを開始します。

まずはレプリケーションアプライアンスの登録の完了をします。このウィザードを完了すると、レプリケーションポリシーの作成とマッピングが行われます。

レプリケーションのウィザード(初回)

サーバーもしくは VM を選択して次に進みます。

アプライアンスの設定画面で登録した vCenter の情報を指定し、一番下の青い部分をクリックします。

Discover の画面が開くので登録を完了します。

完了するとグリーンになります。

レプリケーションポリシーが作成されます。

レプリケーションアプライアンスの登録が完了したら改めてレプリケーションのウィザードを開始します。

レプリケーションのウィザード(2回目以降)

下の青い部分が消えています。
Guest credentials は、アプライアンスの設定画面のサーバーの資格情報を選択します。(vCenter の資格情報ではない)

レプリケーション対象の VM を選択して次に進みます。

移行先のネットワークやストレージアカウントを指定します。

仮想マシンの設定をします。

ジョブの画面でレプリケーションが完了したことを確認します。

レプリケーションは、ソースからアプライアンスサーバー、アプライアンスサーバーから Azure への通信が発生します。
レプリケーションの登録で失敗する場合、そのどこかで問題が発生している可能性があるため、ネットワークや権限を確認します。

エラーの例

ゲスト OS の資格情報が間違っている場合

レプリケーションが完了した状態を見てみます。

Azure Migrate > Overview > Replicating machines
仮想マシンの選択

仮想マシンの各スクリーンショット

Compute and Network
Edit:
Disks

5. 移行

レプリケーションが完了したら、移行のウィザードを開始します。と言ってもほぼ Migrate のボタンを押すだけです。
事前に Test migration はしておきましょう。

ちなみに、エージェントベースの移行では、データの移行は移行対象の仮想マシンにインストールされたエージェントによって行われます。
エージェントレスのように移行時に最新のデータはレプリケーションされず、直前の回復ポイントからの移行になります。

補足

エージェントのアップデート

レプリケーションアプライアンスにインストールされている Azure Migrate のエージェントはバージョンが最新化されていきます。
最新のエージェントは以下のページで確認できます。

Azure Migrate の用途として長期間の運用は想定していないと思いますが、サポートされているバージョンは N-4バージョンなので、サポートが切れる前にアップデートする必要があります。

また、エージェントをアップデートすると、ブラウザベースの設定画面がなくなり、専用の UI を持ったプログラムに置き換わります。

Azure のアカウントでログインする方法ではなく、Registration key をインポートする方法になるので、予めダウンロードしておきます。

OS のインプレースアップグレード

2023年12月現在、Azure Migrate を使って Windows Server をインプレースアップグレードする機能がプレビューになっています。

インプレースアップグレードはなかなかハードルは高いので利用できるシナリオは限られると思いますが、テスト移行で試してみることは簡単に出来るのでとりあえず最新化してみるのはいいかもしれません。
ただし、今のところ英語 OS だけなので日本の環境にはなかなか適用できないと思いますが。。

手順としては簡単です。テスト移行もしくは移行のウィザードの画面内で OS のアップグレードのオプションが出てくるので希望の OS を選択します。

リソースグループを見ると、アップグレード用のディスクが作成されて、仮想マシンにアタッチされていることが分かります。

アップグレード後にログインすると E: ドライブに Windows Server 2022 のインストーラーの一式が展開されています。

エージェントレスのように一時的な仮想マシンによるハイドレーションプロセスが走るわけでは無くて、古い OS の起動後にセットアップが走るようなプロセスになっているようです。

対応している OS のバージョンはドキュメントに書かれています。今のところ以下の通りです。

Microsoft (有志)Publication

Microsoft Azureをはじめとする最新技術情報をお届けします。 ※このPublicationは日本マイクロソフトまたは米Microsoft所属社員による個人の見解であり、所属する組織の公式見解ではありません。 ※Publicationに参加希望の社員は @07JP27までご連絡ください。