はじめに
クラウドインテグレーション部クラウドソリューション2課の田村です。
クラウドリフトを検討する際、IaaSとPaaSを利用してクラウド上に基盤を構築し、
データのみをクラウド上に移行する方法が一般的かと思いますが、
オンプレミス環境のサーバを、IaaSとして丸ごと移行することが出来るツールがAzureに存在します。
それが Azure Migrateというツールです。
直近の業務で利用する機会があったため、ナレッジとして本記事を作成しています。
本記事では「閉域網での移行」、「プロキシ経由の通信環境」を考慮したエージェントベースでのAzure Migrateについて記載します。
なお、以下3点の注意点がありますためご留意ください。
・本記事ではエージェントベースでのAzure Migrateについて記載します。エージェントレスでのAzure Migrateは動作の仕組みや要件など異なります。
・AWS EC2で構築した環境をオンプレミス環境と見立てて移行を行っています。
移行のオンプレミス環境という表記は本記事内ではAWS環境で実施しています。
・プロキシ経由での移行の場合、Azure Migrateに対する設定だけでなく、環境に応じた移行元での設定調整が必要となる可能性が高いです。
それら設定調整については本記事では記載しておりません。
Azure Migrateとは？
Azure Migrateは、オンプレミスの環境からAzureクラウドへの移行を支援するツール群を提供するMicrosoftのサービスです。
このツールは、さまざまな移行シナリオに対応しており、仮想マシンや物理サーバー、データベース、アプリケーションなどをAzureに移行する際に役立ちます。
主に次の機能があります。
・評価：適切なVMサイズの提案や、Azureでのランニングコストを見積
・移行：サーバーの状態をAzureにコピーし、スムーズに移行
本記事では評価機能は利用しません。移行機能はディザスタリカバリ用サービスであるAzure Site Recoveryが利用されています。
Azure Migrateを構築すると、Azure Site Recoveryで利用される以下のリソースが自動的に構築されます。
・Recovery Services コンテナー
・ストレージアカウント（プライベートエンドポイント接続の場合は、自動構築されないため、注意が必要です）
・（プライベートエンドポイント接続の場合）プライベートエンドポイント（Azure Migrate用、Recovery Services コンテナー用）
・（プライベートエンドポイント接続の場合）プライベートDNSゾーン（Azure Migrate用、Recovery Services コンテナー用）
Azure Migrateでの移行ではオンプレミス環境に移行用アプライアンス（以下、レプリケーションアプライアンス）の構築が必要となります。
アプライアンスの要件としてCPU8コア、メモリ16GBと少なくないスペックが要求されるため、注意が必要です。
レプリケーションアプライアンスの詳細な要件は公式ドキュメントをご確認ください。
レプリケーションアプライアンスの要件
レプリケーションアプライアンスは以下2つの機能を実行します。
・Config Server：Azure Migrateに接続し、レプリケーションを調整します。
・Process Server：サーバーデータをエージェントから受信し、それを圧縮して暗号化し、Azureに送信します。
レプリケーションアプライアンスは移行元サーバ情報の集約点と、Azureへのデータのやり取りの窓口として機能します。
通信の流れは、以下のようになっています。
- 移行対象サーバにインストールしたエージェントと、レプリケーションアプライアンスの受信ポート443／9443上で、レプリケーション管理通信／レプリケーションデータ通信
- Azure Migrateで移行設定／レプリケーション開始することで、レプリケーションアプライアンスから、アウトバウンドポート443経由でAzureにレプリケーションデータ送信
- Recovery Services コンテナーが、ストレージアカウントにレプリケーションデータをキャッシュ
- Azure Migrateで移行を実行することで、ストレージアカウントのキャッシュから仮想ディスクが作成され、移行設定を元にしたVMが作成される
詳しくは公式ドキュメントをご確認ください。
エージェントベースの移行アーキテクチャ
AzureSiteRecoveryプライベートエンドポイント接続アーキテクチャ
前提条件
以下の環境が構築済となっています。
・AWS-Azure間 S2S VPN環境
・AWS EC2 移行対象サーバ（Windows Server 2019）
・AWS EC2 プロキシサーバ（Amazon Linux 2023）
- Squidインストール、ホワイトリスト設定
- 以下のドメインをワイルドカードで通信許可
・.migration.windowsazure.com
・.siterecovery.windowsazure.com
・.blob.core.windows.net
・.login.windows.net
・*.login.microsoftonline.com
・AWS EC2 レプリケーションアプライアンス用サーバ（Windows Server 2016 言語:en-us）
- 移行対象サーバからのHTTPSインバウンド許可（TCPポート443、9443）規則追加済
※レプリケーションアプライアンスのOS要件がWindows Server 2016（言語:en-us）となっています。
※レプリケーションアプライアンスがポート443／9443経由でレプリケーション管理／レプリケーションデータ受信を行うため、セキュリティグループ受信規則を追加しています。
・Azure ネットワーク環境（VNet、サブネット、ネットワークセキュリティグループ）
- プライベートサブネット
- AWS側セグメントからのHTTPSインバウンド許可（TCPポート443）規則追加済
※レプリケーションアプライアンスがポート443経由でAzureにデータレプリケーションを行うためネットワークセキュリティグループ受信規則を追加しています。
AWSリソースはバージニア北部リージョン、Azureリソースは東日本リージョンに構築しています。
簡単な前提環境の構成イメージは以下になります。
展開手順
Azure Migrate構築と移行の流れを説明します。
〇手順1: Azureリソース構築
まず、Azure Migrateに必要なAzureリソースを構築します。具体的には以下となります。
・ストレージアカウント
・ストレージアカウント用プライベートエンドポイント
・ストレージアカウント用プライベートDNSゾーン
・Azure Migrateプロジェクト
前述のように、Recovery Services コンテナーとコンテナー用プライベートエンドポイント／プライベートDNSゾーンは、Azure Migrate構築時に自動構築されます。
パブリックアクセス設定の場合は、ストレージアカウントも自動構築されます。
注意点として、以下作業も必要となります。
・レプリケーションアプライアンスインストーラ等ダウンロード
・Recovery Services コンテナーにマネージドIDを用いたストレージアカウントへのアクセス権割り当て
〇手順2: レプリケーションアプライアンス展開
次に、オンプレミス環境にレプリケーションアプライアンスを展開します。以下作業を実施します。
・HostsファイルにプライベートエンドポイントFQDN追記
・プライベートエンドポイントFQDNのプロキシ除外設定
・レプリケーションアプライアンスインストール
・レプリケーションエージェントインストール
〇手順3: Azure移行
最後に、Azureにサーバを移行します。以下作業を実施します。
・データレプリケーション
・テスト移行
・本番移行
・データレプリケーション停止
・レプリケーションエージェントアンインストール
次項より手順を進めていきます。
Azureリソース構築
ストレージアカウントを構築します。
今回は閉域網での移行を考慮し、ネットワーク設定では「パブリックアクセスを無効にし、プライベートアクセスを使用する」を選択し、プライベートエンドポイントとプライベートDNSゾーンを作成します。
プライベートエンドポイントの設定の考慮事項はないため、適宜設定します。
データ保護設定では大項目「復旧」をすべてチェックオフにします。
こちらが1つでもオンになっているとデータレプリケーション時にエラーとなるためです。
他の設定は考慮事項はないため、適宜設定します。
続いて、Azure Migrateプロジェクトを構築します。
Azureポータル検索ウィンドウに「Azure Migrate」と入力し、表示された「Azure Migrate」を選択します。
以下のようなAzure Migrateコンソール画面が表示されます。
Azure Migrateコンソール画面左のタブ「サーバー、データベース、Webアプリ」を選択し、「プロジェクトの作成」をクリックします。
※既にAzure Migrateプロジェクト作成済の場合、作成済のプロジェクトが表示され、「プロジェクトの作成」の位置は変わっているため、ご注意ください。
Azure Migrateプロジェクト設定画面に遷移するため、設定していきます。
今回は閉域網での移行を考慮し、接続方法設定では「プライベートエンドポイント」を選択し、プライベートエンドポイントとプライベートDNSゾーンを作成します。
※パブリックネットワークアクセスの無効化設定が「いいえ」となっていますが、本設定はAzure Migrate以外の移行ツールによるサーバー利用状況データのAzureへのアップロードに利用される設定です。
本記事で利用するAzure Migrateは問題なくプライベートエンドポイント経由でデータ通信を行います。
また、公式ドキュメントによる設定手順では「いいえ」のままとすることが推奨されていたため、そのままとしています。
プライベートエンドポイント接続を使用してプロジェクトを作成する
他の設定は考慮事項はないため、適宜設定します。
続いて、Azure Migrateプロジェクト作成後、Azure Migrateコンソールに戻り、
タブ「サーバー、データベース、Webアプリ」を選択し、ウィンドウ「移行およびモダン化」の「検出」をクリックします。
検出設定では以下の設定値を入力します。
【設定値】
移行先を指定してください。：Azure VM
マシンは仮想化されていますか？：物理またはその他
ターゲットリージョン：Japan East
※設定「マシンは仮想化されていますか?」では他の移行元環境としてVMware、Hyper-Vを指定できます。
なお、Azure環境間で移行を行うことはできません。
移行元となるAzure仮想マシンにレプリケーションエージェントインストールする際にエラーとなり失敗するためです。
設定入力後、画像赤枠内のチェックボックスをオンにし、「リソースの作成」をクリックします。
デプロイが完了するまで数分待ちます。
この間にAzure MigrateとリンクしたRecovery Services コンテナー、Recovery Services コンテナー用プライベートエンドポイント／プライベートDNSゾーンが自動作成されています。
デプロイが完了すると以下画面のように「新しいレプリケーションアプライアンスをインストールしますか？それとも～」という設定項目が画面に表示されるため、「レプリケーションアプライアンスのインストール」を選択します。
以下のような画面が表示されるため、「ダウンロード」をクリックしてレプリケーションアプライアンスインストーラをダウンロードします。（ファイル容量は約1.5GBです）
引き続き必要なファイルのダウンロードを行います。以下のような画面が表示されるため、「ダウンロード」をクリックして、レプリケーションアプライアンスのAzure登録キーをダウンロードします。
登録キーはレプリケーションアプライアンスをAzure Migrateプロジェクトに登録するために、アプライアンスOS上で利用します。
Azure Migrateコンソールに戻り、タブ「サーバー、データベース、Webアプリ」を選択し、
ウィンドウ「移行およびモダン化」の「概要」をクリックします。
画面左タブ「設定」-「プロパティ」を選択し、「DNS設定のダウンロード」をクリックします。
以下のような内容のプライベートエンドポイントのIPアドレスとFQDN一覧ファイルがダウンロードされます。
このファイルの内容はレプリケーションアプライアンスのHostsファイルに追記する際に利用します。
※通常プライベートエンドポイントの名前解決は、パブリックIP168.63.129.16を介して行われますが、168.63.129.16にはAzure 内部のリソースからしかアクセスできません。
そのため、今回のAzure Migrateのように、オンプレミスからAzureのプライベートエンドポイントに通信する場合、そのままではプライベートエンドポイントの名前解決できません。
名前解決の対応方法はいくつかありますが、今回はHostsファイルにレコードを追記する方法を取っています。
Azureとプライベートエンドポイントの名前解決を利用した通信を行う機材がレプリケーションアプライアンス1台のみのため、Hostsファイル追記であれば、オンプレミス環境の他機材に手を加えず、
Azure側の追加リソースも不要となるためです。
続いてAzureポータル検索ウィンドウに「Private Link」と入力し、表示された「Private Link」を選択します。
「プライベートエンドポイント」タブにて、ストレージアカウント用プライベートエンドポイントにチェックオンし、「ホストファイルの生成」をクリックします。
「hostfileのダウンロード」をクリックします。
以下のような内容のストレージアカウント用プライベートエンドポイントのIPアドレスとFQDN情報ファイルがダウンロードされます。
ストレージアカウントは別途作成しており、Azure Migrateとリンクしていないため、このように別途ダウンロードの必要があります。
Recovery Services コンテナーにストレージアカウントへのアクセス権を割り当てます。
※Recovery Services コンテナーが、Azureに送信されたレプリケーションデータをストレージアカウントにキャッシュする仕組みとなっているため、ストレージアカウントへのアクセス権が必要となります。
本環境のストレージアカウントは手動で作成したため、手動で上記のアクセス権割り当てが必要となります。
Azureポータルで、Azure Migrateによって自動作成されたRecovery Services コンテナーに移動し、 画面左ペイン「設定」の「Identity」をクリックし、「Azureロールの割り当て」をクリックします。
※Recovery Services コンテナー名は、「Azure Migrateプロジェクト名-MigrateVault-ランダムな数字」に自動命名されます。
「ロールの割り当ての追加」をクリックします。
以下の設定値を選択して、「保存」をクリックします。
【設定値】
スコープ：ストレージ
サブスクリプション：契約されているサブスクリプション名
リソース：作成したストレージアカウント名
役割：共同作成者
先程のAzureロールの割り当て画面に戻るので、再度「ロールの割り当ての追加」をクリックします。
以下の設定値を選択して、「保存」をクリックします。
【設定値】
スコープ：ストレージ
サブスクリプション：契約されているサブスクリプション名
リソース：作成したストレージアカウント名
役割：ストレージBLOBデータ共同作成者
先程の2つのロールが割り当てられていることを確認します。
※割り当てが反映されるまで数分かかる場合があります。
続いて、MySQLインストーラをダウンロードします。
※レプリケーションアプライアンスの内部データベースとしてMySQLが使用されています。
レプリケーションアプライアンスインストールウィザード上でダウンロードできるのですが、事前にインストーラを所定のフォルダに配置する形でもインストール可能なため、
閉域網かつプロキシ経由での通信の要件を考慮し、インストーラを事前配置する手順を取っています。
以下のURLからMySQLインストーラをダウンロードします。
MySQLインストーラURL
バージョン5.7.20.0を利用しています。
PSToolsをダウンロードします。
※システムアカウントのプロキシ設定を行うために、アプライアンスOS上で利用します。
レプリケーションアプライアンスはインストールウィザード上でのプロキシ設定とシステムアカウントのプロキシ設定両方を利用してインターネットアクセスを試みるため、
後述するプライベートエンドポイントのFQDNプロキシ除外設定を適用させる場合、PSToolsを用いたシステムアカウントのプロキシ設定作業が必要となります。
以下のURLからPSToolsのzipファイルをダウンロードします。
PSToolsのzipファイルURL
次項よりレプリケーションアプライアンス展開手順を進めていきます。
レプリケーションアプライアンス展開
前項でダウンロードした各種インストーラ等をレプリケーションアプライアンス用サーバに配置します。
具体的には以下ファイルを配置します。
・レプリケーションアプライアンスインストーラ（ファイル名：MicrosoftAzureSiteRecoveryUnifiedSetup.exe）
・レプリケーションアプライアンスAzure登録キー（ファイル名：Azure Migrateプロジェクト名-MIgrateVault-ランダムな数字_ダウンロード日付.VaultCredentials.txt）
・プライベートエンドポイントFQDN情報ファイル（ファイル名：DNSSettings_Azure Migrateプロジェクト名-MigrateVault-ランダムな数字_ダウンロード日付.txt）
・ストレージアカウント用プライベートエンドポイントFQDN情報ファイル（ファイル名：hostfile.txt）
・PSToolszipファイル（ファイル名：PSTools.zip）
・MySQLインストーラ（ファイル名：mysql-installer-community-5.7.20.0.msi）
配置場所は基本的に任意の場所で問題ないため、今回はログインユーザAdministratorのデスクトップに配置しています。
MySQLインストーラのみ、以下の場所に配置する必要があります。
・C:\temp\ASRSetup
続いて、HostsファイルにプライベートエンドポイントのIPアドレスとFQDNを追記します。
以下のフォルダにあるHostsファイルを開きます。
・C:\Windows\System32\drivers\etc\
デスクトップに配置した以下2つのFQDN情報ファイルに記載されたIPアドレスとFQDNをHostsファイルに追記します。
・DNSSettings_Azure Migrateプロジェクト名-MigrateVault-ランダムな数字_ダウンロード日付.txt
・hostfile.txt
Hostsファイルの内容は以下のようになります。
続いて、PSToolsを利用してシステムアカウントのプロキシ設定を行います。
デスクトップに配置したPSTools.zipを解凍し、コマンドプロンプトを管理者として実行します。
PSToolsを解凍したフォルダに移動し、以下のコマンドを実行してPsExec（PSToolsに含まれるプロキシ設定ツール）を実行します。
・psexec -i -s control inetcpl.cpl
インターネットプロパティ画面が表示されるので、「Connections」タブにて、「LAN settings」をクリックします。
※PsExec初回実行時のみLicence Agreement画面が表示されるため、「Agree」をクリックします。
「Use a proxy server for your LAN」にチェックオンして、プロキシサーバのIPアドレスとHTTPポート番号を入力します。
ここでは事前構築したSquidプロキシサーバをポート番号変更を行わずに利用しているため、以下のように設定しています。
※HTTPポート番号で設定するのは、レプリケーションアプライアンスがHTTPポートのみサポートしているためです。
プロキシ除外設定を行うため、「Advanced」をクリックします。
「Exceptions」の記入欄に、Hostsファイルに追記したプライベートエンドポイントのFQDNのみをセミコロン区切りで以下のように入力し、「OK」をクリックして設定を保存します。
※クライアントがプロキシ経由での通信を行う場合、クライアントのHostsファイルは名前解決の際に参照されません。
クライアントからの通信の名前解決はプロキシに委任され、プロキシ自身のHostsファイルまたはDNSサーバを参照するためです。
そのままだと名前解決に失敗してプライベートエンドポイントに到達できないため、プロキシの除外設定に該当のFQDNを追加して、
プロキシを経由せずに通信させる（クライアントのHostsファイルを参照して名前解決を行う）ようにしています。
※ただ、プロキシ除外設定を行っても環境によって通信に失敗する可能性はあります。
例えば、外部通信の際必ずプロキシを通る必要がある設計となっており、プロキシ除外設定をしてもファイアウォール等で遮断されるケースです。
冒頭でも記載していますが、実際にプロキシ環境でAzure Migrateを導入する際は、Azure Migrate以外の部分での設定調整が必要となる可能性が高いと思われます。
続いて、レプリケーションアプライアンスをインストールします。
デスクトップに配置したレプリケーションアプライアンスインストーラ（MicrosoftAzureSiteRecoveryUnifiedSetup.exe）を管理者として実行します。
インストールウィザードが起動するため、画面の表示に従ってインストールを進めます。
「Before You Begin」タブで、「Install the configuration server and process server」が選択されていることを確認し、「Next」をクリックします。
「Registration」タブで、「Browse」をクリックしてデスクトップに配置したAzure登録キー（Azure Migrateプロジェクト名-MIgrateVault-ランダムな数字_ダウンロード日付.VaultCredentials.txt）を選択します。
その後、「Next」をクリックします。
「Internet Settings」タブで、「Connect to Azure Site Recovery using a proxy server」を選択し、プロキシサーバのIPアドレスとHTTPポート番号を入力します。
※HTTPポート番号で設定するのは、前述のように、レプリケーションアプライアンスがHTTPポートのみサポートしているためです。
「Bypass the proxy server for the following URLs/IP addresses」の記入欄に、システムアカウントのプロキシ除外設定で入力したFQDNを同様に入力して、「Next」をクリックします。
各FQDNは同様にセミコロンで区切って入力します。
「Prerequisites Check」タブで要件チェックが行われるため、完了したら「Next」をクリックします。
※Warningが表示される場合がありますが、動作に問題はありません。
「MySQL Configuration」タブで、MySQLパスワードを任意の値入力して「Next」をクリックします。
※レプリケーションアプライアンスの内部データベースに使用され、移行の際には使用せず、通常アクセスすることもありません。
「Environment Details」タブで、「No」を選択して「Next」をクリックします。
※VMware移行の場合は、「Yes」を選択します。
「Install Location」タブで、「Next」をクリックします。
以下のようにDドライブにインストールされます。
※警告が出ている場合がありますが、動作に問題はありません。
「Network Selection」タブで、赤枠内をクリックしてIPアドレスが表示されている選択肢を選びます。
その後、「Next」をクリックします。
「Summary」タブで、「Install」をクリックしてインストールを開始します。
インストール完了には30分ほどかかります。
インストール完了後、「Finish」をクリックします。
画面に表示されている全てのStatusがDoneになっていればインストール完了です。
「Finish」をクリックするとインストールウィザードが終了し、以下のウィンドウが表示されます。
「Yes」をクリックします。
※「Yes」をクリックするとクリップボードにパスフレーズがコピーされます。
このパスフレーズは、移行対象サーバにインストールしたレプリケーションエージェントをレプリケーションアプライアンスに登録する際に使用します。
直前の手順でクリップボードにコピーされたパスフレーズを任意の名前のテキストファイルとして保存します。
本記事ではRepPass.txtとして保存します。
自動的に「Microsoft Azure Site Recovery Configuration Server」が起動し以下のようなウィンドウが表示されます。 「Add Account」をクリックします。
以下の設定値を入力して「OK」をクリックし、ダミーアカウントを作成します。
※この手順はVMware環境移行の際にサーバーデータを収集するためのvCenterアカウント情報をレプリケーションアプライアンスに登録する作業ですが、
データレプリケーション時にAzure Migrateプロジェクトで指定する必要があるパラメータのため、VMware環境移行でない場合でも実行する必要がある手順となっています。
そのため、vCenter環境ではない本記事の環境では、ダミーアカウントを作成しています。
【設定値】
Friendly Name:dummy
User name:dummy
Password:password
アカウントが作成できたら、「Close」をクリックして「Microsoft Azure Site Recovery Configuration Server」を終了します。
続いて、レプリケーションアプライアンスをAzure Migrateプロジェクトに登録します。
Azureポータルにログインし、Azure Migrateコンソールにて、「サーバー、データベース、Webアプリ」タブにて、「移行およびモダン化」の「検出」をクリックします。
以下の設定値を入力します。
【設定値】
移行先を指定してください。：Azure VM
マシンは仮想化されていますか？：物理またはその他
ターゲットリージョン：Japan East
新しいレプリケーション アプライアンスをインストールしますか？ それとも既存のセットアップをスケールアウトしますか？：レプリケーションアプライアンスのインストール
画面をスクロールして、以下の画面でプルダウン「Configuration Serverを選択します」から、構築したレプリケーションアプライアンスを選択します。
「登録の最終処理」をクリックします。
以下の画面のように表示され、登録が完了されたことを確認します。
続いて、移行対象サーバにエージェントをインストールします。
エージェントインストーラはレプリケーションアプライアンスの以下のフォルダに含まれています。
・%ProgramData%\ASR\home\svsystems\pushinstallsvc\repository
以下の名前のWindows用インストーラをコピーします。
・Microsoft-ASR_UA_XXXX_Windows_XXXX_Release
※ファイル名のXXXXの値はReplication Applianceのバージョンによって異なります。
コピーしたインストーラを移行対象サーバの以下フォルダに配置します。
・C:\Program Files (x86)¥Microsoft Azure Site Recovery
エージェントインストールを実行します。
コマンドプロンプトを管理者として実行し、インストーラを配置したフォルダに移動します。
以下コマンドを実行してインストーラを配置したフォルダに抽出します。
・Microsoft-ASR_UA_9.63.0.0_Windows_GA_21Oct2024_Release.exe /q /x:"C:\Program Files (x86)\Microsoft Azure Site Recovery"
※コマンド内の.exeファイルの名前は、Replication Applianceのバージョンによって異なります。
以下コマンドを実行して抽出したインストーラを実行します。
・UnifiedAgent.exe /Role "MS" /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery" /Platform "VmWare" /Silent /CSType CSLegacy
「Unified agent installation has succeeded.」と表示されればインストールは完了です。
エージェントをレプリケーションアプライアンスに登録します。
コマンドプロンプトを管理者として実行し、登録ツールが配置されている、移行対象サーバの以下フォルダに移動します。
・C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
以下のコマンドを実行し、エージェントをレプリケーションアプライアンスに登録します。
・UnifiedAgentConfigurator.exe /CSEndPoint <レプリケーションアプライアンスのIPアドレス> /PassphraseFilePath <エージェント登録用パスフレーズファイルのパス>
「Validating configuration」と表示されれば、Agent登録は完了です。
これでレプリケーションアプライアンス展開は完了です。
引き続き、Azure移行手順を進めていきます。
Azure移行
データのレプリケーションを開始します。
Azureポータルにログインして、Azure Migrateコンソールにて、「サーバー、データベース、Webアプリ」タブの「移行およびモダン化」に戻り、サーバが検出されていることを確認します。
「レプリケート」をクリックします。
以下の設定値を選択し、画面左下の「続行」をクリックします。
【設定値】
何を移行しますか。：サーバーまたは仮想マシン
移行先を指定してください。：Azure VM
マシンは仮想化されていますか？：物理またはその他
オンプレミスのアプライアンス：構築したReplication Applianceのホスト名（レプリケーションアプライアンス）
「基本」タブで、以下の設定値を選択します。
【設定値】
Process Server：Replication Applianceのホスト名
ゲストの資格情報：dummy（Replication Appliance設定時に作成したダミーアカウント）
「仮想マシン」タブで、以下の設定値を選択し、移行対象サーバをチェックオンします。
【設定値】
評価から移行設定をインポートしますか？：いいえ。移行設定を手動で指定します
「ターゲット設定」タブで、作成したストレージアカウントや移行先VNet指定等、適宜設定を行います。
「コンピューティング」タブで、Azure VM名やVMサイズ等、適宜設定を行います。
「ディスク」タブで、ディスクの種類等、適宜設定を行います。
「タグ」タブで、適宜設定を行います。
「レプリケーションの確認と開始」タブで、画面左下の「レプリケート」をクリックしてレプリケートを開始します。
レプリケーション状況は、Azure Migrateコンソールにて、「サーバー、データベース、Webアプリ」タブの「移行およびモダン化」の概要をクリックし、
「レプリケーション」をクリックすることで確認できます。
「レプリケーションの状態」が「Protected」になっていればレプリケーションは完了です。
レプリケーションが完了したら、テスト移行作業を行います。
Azureポータルにログインして、Azure Migrateコンソールにて、「サーバー、データベース、Webアプリ」タブの「移行およびモダン化」の「概要」をクリックします。
画面左の「移行」タブ内の「レプリケーション」をクリックし、レプリケーションされたサーバ一覧に移動します。
テスト移行を行う対象サーバ項目の右端にある「・・・」をクリックして、「テスト移行」をクリックします。
対象サーバのテスト移行先の仮想ネットワークを選択し、「テスト移行」をクリックします。
Azure Migrateコンソールのレプリケーションされたサーバ一覧に戻り、テスト移行を実行したサーバの「レプリケーションの状態」が「テストフェールオーバーのクリーンアップが保留中」になっていれば、テスト移行は完了です。
※Azure仮想ネットワーク上にVM名「テスト移行したサーバ-test」の仮想マシンが作成されています。
テスト移行されたサーバで動作確認を行います。
動作確認が完了したら、テスト移行されたサーバを削除します。
Azure Migrateコンソールのレプリケーションされたサーバ一覧に戻り、テスト移行を実行したサーバ項目の右端にある「・・・」をクリックして、「テスト移行をクリーンアップ」をクリックします。
「テストが完了しました。テスト仮想マシンを削除します。」にチェックオンして、「テストのクリーンアップ」をクリックします。
Azureポータルで「操作を正常に完了しました。」という通知が表示されたら、テストサーバの削除は完了です。
続いて、本番移行作業を実行します。
Azure Migrateコンソールのレプリケーションされたサーバ一覧に戻り、本番移行を実施するサーバ項目の右端にある「・・・」をクリックして、「移行」をクリックします。
「移行」をクリックします。
Azure Migrateコンソールのレプリケーションされたサーバ一覧に戻り、本番移行を実行したサーバの「レプリケーションの状態」が「Failover completed」になっていれば、移行は完了です。
※Azure仮想ネットワーク上に移行対象サーバと同じホスト名の仮想マシンが作成されています。
その後、静的IPアドレスの割り当てや動作確認などを適宜実行します。
動作確認実行後、レプリケーション停止を実行します。
Azure Migrateコンソールのレプリケーションされたサーバ一覧に戻り、本番移行を実施したサーバ項目の右端にある「・・・」をクリックして、「レプリケーションの停止」をクリックします。
「OK」をクリックします。レプリケーション停止作業は完了です。
最後に、移行対象サーバからエージェントをアンインストールします。
移行対象サーバのアプリ一覧から「Microsoft Azure Site Recovery Mobility Service/Mastar Target Server」を右クリックして、「Uninstall」をクリックします。
ポップアップが表示されるので、「Yes」をクリックします。
「Microsoft Azure Site Recovery Mobility Service/Mastar Target Server」がアンインストールされたことを確認します。
エージェントベースでのAzure Migrateは以上となります。
まとめ
今回は、プライベートエンドポイントとプロキシ経由のAzure Migrate（エージェントベース）を実施しました。
Azure Migrateそのものの仕組みはそこまで複雑ではないのですが、プライベートエンドポイントとプロキシの2つの制限の仕組みの理解が難しく、対応が大変に感じました。
特にプロキシは、冒頭で述べたように実環境での実施の場合、プロキシ自体の調整など本記事よりも複雑な対応が必要となる可能性が高いため、時間があればプロキシ自体の勉強をしたいと感じました。
ここまでお読みいただきありがとうございました。
