TL;DR
オンプレミスから Azure への移行の方法はいくつかありますが、今回は Azure Migrate のエージェントレスアプライアンスを使って VMware の仮想マシンを移行する方法を紹介します。
ポイント1: エージェントベースとエージェントレスのどちらを使うべきか
VMware の移行にはエージェントレスとエージェントベースがあります。どちらの方法も出来ること・出来ないことがあるため、要件に応じて選択します。
- エージェントベース
ESXi 上の仮想マシンにエージェントをインストールし、OS 内から OS のデータをレプリケーションサーバーを通して Azure に送信します。
vCenter へのアクセス権がない場合や、物理サーバー、他社クラウドからの移行で利用できます。それぞれの VM にエージェントをインストールする必要があります。 - エージェントレス
vCenter からディスクのデータをアプライアンスを通して Azure を送信します。
vCenter へのアクセス権がある場合に利用でき、エージェントをインストールする必要はありません。
例えば、VMware のみの環境であれば、エージェントレスの方式を利用することが簡単でしょう。
VMware 以外にも Hyper-V や物理サーバーがある場合はエージェントベースの方式を利用すると一貫した操作で移行できます。
ただし、エージェントベースの方式では、移行時にシャットダウンした上でデータの同期ができないため、移行時のデータが失われる可能性があります。
ポイント2: Azure Migrate の移行を成功させるには
オンプレミスを含む他環境からの Azure への仮想マシンの移行は、その環境のネットワーク構成や権限に依存するため、いくつかの課題に直面することがあります。
一方でオンプレミス環境から Azure Migrate を利用した移行は、多く行われているシナリオでもあるためドキュメント化が進んでおり、トラブルシューティングのページも充実しています。
Azure Migrate のドキュメントを一通り確認することをおすすめします。
また、FastTrack チームが作っている Azure Migrate のチェックリストがあり、こちらも参考になります。Excel ベースの資料で、移行のステップやチームの役割分担などの言及もあります。
特に、7. Checklist シートにある Incident Root Cause Alert でフラグの立っている項目は、サポートへの問い合わせを分析した結果から必要とされる項目がリストアップされているため、必ず確認しておきましょう。
インシデントのフラグが立っている項目を日本語に翻訳したものを抜粋(All environments/SQL Server/VMware/VMware Agentlessでフィルタ)して以下に記載しますので参考にしてください。
Azure Migrate の利用で注意すべきポイント
| タイトル | 説明 |
|---|---|
| Azure Migrate プロジェクトを作成する際、および/または VM を移行する際に、拒否の効果を持つ Azure ポリシー が問題を引き起こす可能性があることに留意してください。 | 問題を解決するために、影響を受ける範囲をポリシーから除外することを検討してください。 |
| 移行範囲に対してターゲットサブスクリプションを計画し、それに応じて TARGET SUBSCRIPTION(S) でアクセスを構成します。 | VM の作成、マネージドディスクへの書き込み、TARGET SUBSCRIPTION(s) の VNET への参加に対する権限の欠如は、サポートケースにおいて頻繁に見られる根本原因です。 |
| VMwareホストとゲストVMの要件がエージェントレス移行に適合していることを確認します。 | VMware vCenter Server v5.5、6.0、6.5、または 6.7 と VMware vSphere ESXI host v5.5, 6.0, 6.5, 6.7 または 7.0 はサポートされています。ゲストVMの対応状況は、こちらのURLをご参照ください。 |
| Azure Migrate アプライアンスと Azure、Azure Migrate アプライアンスとホストマシン (ESX, Hyper-V) およびゲスト移行元マシンの間で DNS の名前解決が機能することを確認します。 | |
| Azure Migrate アプライアンスの前提条件とサポート要件がすべて満たされていることを確認します。 | Azure Migrate Discovery and Assessment ツール (アプライアンス) は、移行対象を発見 (そして評価) するために利用できるツールです。 |
| Azure Migrate アプライアンスでインターネット アクセスを許可し、必要な URL へのアクセス権がプロビジョニングされていることを確認します。 | プライベートまたはパブリックエンドポイントに関係なく、特定の URL/FQDN の送信を許可する必要があります。 |
| Azure ポータル で Azure Migrate の「プロジェクト」を作成するために、適切な権限を持つアカウントが利用可能であることを確認します。 | サブスクリプションの Owner または Contributor さらに User Access Administrator(UAA) 権限が必要です。注：UAAのない Contributor アカウントによる操作は、サポートケースで頻繁に発生する根本原因です。 |
| 既存の環境でツールを実行するために必要なセキュリティ承認と管理者アクセス権が利用可能であることを確認します。 | |
| Azure Migrate プロジェクトの接続方法としてプライベートエンドポイントを選択した場合、Recovery Services vault にキャッシュストレージアカウントへのアクセス権を付与します。 | |
| プライベート ピアリングで ExpressRoute を使用してレプリケートするには、キャッシュ ストレージ アカウントのプライベート エンドポイントを作成します。 | |
| Azure 移行プロジェクトの接続方法としてプライベートエンドポイントを選択した場合、DNS の名前解決を確認します。 | DNSの名前解決が必要なリソースのリストについては、AzureポータルのAzure Migrateプロジェクトのプロパティを参照してください。 |
| 計画された移行アクティビティに対するネットワークの準備状態を評価します。 | ストレージの容量は、初期レプリケーション時の帯域幅要件に直接影響します。ただし、ストレージのドリフトは、レプリケーションの時点からリリースまで継続します。予想される移行速度に到達するために必要な帯域幅を計算します。 |
| サブネットに関連付けられたネットワークセキュリティグループのセキュリティルールは、サブネット内のVM間の接続に影響を与える可能性があることに留意してください。 | サブネット内のセキュリティグループは Azure VM上のSQL Serverへのフェールオーバークラスターインスタンスの移行において、根本的な原因となることがあります。 |
| 移行前に、目的のVM SKU がターゲットリージョンで利用可能であることを確認します。また、Azure ポリシーが VM SKUをブロックしていないこと、およびサブスクリプションに十分な利用可能なクォータがあることを確認します。 | |
| SQL クラスタを使用していて、新しい VM に移行する場合で、Windows ファイアウォールが使用されている場合は、Windows ファイアウォール ルールを開いて、フェイルオーバー クラスタリングが VM 間で通信できるようにする必要があります。 | |
| SQL クラスタを使用する場合、Network Security Groups にフェールオーバークラスター通信ポートの許可ルールがあることを確認します。 | |
| テストと検証を通じて、一般的なレプリケーションのボトルネックを確認します。 | 初期マイグレーションのレプリケーション速度には、考慮すべき要素が多くあります。通常、アプライアンスはVMとしてvCenterにあり、そのディスクはデータストアに存在します。ボトルネックになり得るものとして、アプライアンスとAzure/ストレージアカウント間のレプリケーション帯域幅や ESXi ホストとアプライアンス間のレプリケーション帯域幅、アプライアンスのパフォーマンス等があります。(詳細はチェックリスト参照) |
| レプリケーションを許可しない期間を定義するために、ブラックアウトウィンドウが必要かどうかを決定します。 | お客様は、営業時間外やオフピーク時にレプリケーションをスケジュールすることを希望されるかもしれません。リソースが競合する時間帯にレプリケーションの問題が発生することは、サポート・インシデントの根本原因としてよく知られています。 |
| レプリケーションの停止時間を、変更管理およびコストの考慮事項に含めます。 | ベストプラクティスとして、中間管理ディスク（シードディスク）のストレージトランザクションの追加料金が発生しないように、VMがAzureに正常に移行した後に必ず移行を完了させてください。 場合によっては、レプリケーションの停止に時間がかかることに留意してください。レプリケーションが停止されるたびに、進行中のレプリケーションサイクルが完了してから（VMがデルタ同期している場合のみ）成果物が削除されるためです。レプリケーションの停止に時間がかかると、サポートインシデントが多発します。 |
技術的な課題のみでなく、他部署、ベンダーとの連携が必要になることがあります。誰が、何を、いつまでに行うかを計画時に明確にしておきます。
以下は過去の日本マイクロソフトのイベントで紹介された日本のお客様の事例です。エージェントベースの事例ですが、移行までのステップが紹介されており参考になります。 スライド:
全体の流れ
Azure Migrate のステップは、検出、評価、移行の 3 ステップに分かれています。
- 検出
vCenter から仮想マシンの情報を取得して Azure Migrate として認識します。 - 評価
パフォーマンスや設定をチェックし、Azure に移行する際のリスクを評価します。 - 移行
Azure に移行します。OS のデータが Azure 上に移動されるタイミングはこのタイミングです。
検出/評価
ドキュメント
1. セットアップ
プロジェクトの作成とアプライアンスのダウンロード
プロジェクトの作成後の画面から[検出]をクリックします。
プロジェクト キーの生成とアプライアンスのダウンロードをします。
アプライアンスの設定
ダウンロードした OVA ファイルを vCenter からインポートして起動します。起動すると設定画面がブラウザで開きます。
生成したプロジェクト キーの入力と Azure へのログインを行います。
View details をクリックすると、登録情報が確認できます。
VMware Virtual Disk Development Kit のインストール
VMware のサイトから zip ファイルをダウンロードします。
ダウンロードした zip の中身を C:\Program Files\VMware\VMware Virtual Disk Development Kit に展開します。
Verify すると、グリーンになります。
資格情報の設定
Step 1: Provide vCenter Server credentials で vCenter へのアクセスのための資格情報を設定します。
Step 2: Provide vCenter Server details で vCenter の IP アドレスもしくは FQDN を設定します。
正常にアクセスできるとStatusグリーンになります。
Step 3: Provide server credentials to perform software inventory, agentless dependency analysis, discovery of SQL Server instances and databases and discovery of ASP.NET web apps in your VMware environment. でソフトウェアインベントリや依存関係分析のために OS の資格情報を入力します。
[Start discovery] をクリックして検出を介します。
完了すると、ソースの Status が [Discovery initiated] になります。
検出の仕組み
以下はドキュメントからの抜粋です。
- 1 つのアプライアンスに追加された 10 台の vCenter Server でサーバーを検出するには、約 20 - 25 分かかります。
- サーバーの資格情報を指定してある場合は、vCenter Server で実行されているサーバーの検出が完了すると、ソフトウェア インベントリ (インストールされているアプリケーションの検出) が自動的に開始されます。 ソフトウェア インベントリは、12 時間ごとに実行されます。
- ソフトウェア インベントリでは、サーバー上で実行されている SQL Server インスタンスを特定します。 そこで収集された情報を使用し、アプライアンスで指定された Windows 認証資格情報または SQL Server 認証資格情報を介して、アプライアンスから SQL Server インスタンスへの接続が試行されます。 次に、SQL Server データ> ベー- スとそのプロパティに関するデータが収集されます。 SQL Server の検出は 24 時間ごとに実行されます。
- ソフトウェア インベントリにより、サーバー上で Web サーバーの役割が識別されます。 そこで収集された情報を使用し、アプライアンスで提供された Windows 認証資格情報を介して、アプライアンスから IIS Web サーバーへの接続が試行されます。 次に、Web アプリ上でデータが収集されます。 Web アプリ検出は 24 時間ごとに実行されま> - す。
- インストールされているアプリケーションの検出には、15 分以上かかることがあります。 期間は検出されたサーバーの数によって異なります。 500 台のサーバーでは、検出されたインベントリがポータルの Azure Migrate プロジェクトに表示されるまで約 1 時間かかります。
- ソフトウェア インベントリの間、エージェントレスの依存関係分析のために、追加されたサーバー資格情報がサーバーに対して繰り返され、検証されます。 サーバーの検出が完了すると、ポータルでサーバーに対するエージェントレスの依存関係分析を有効にできます。 エージェントレスの依存関係分析を有効にするよう選択できるのは、検証が成功したサ> ー- バーだけです。
- 検出を開始してから 24 時間以内に、SQL Server インスタンス、データベースのデータ、Web アプリのデータがポータルに表示され始めます。
2. 検出
セットアップが終わったら、Azure ポータルで ESXi 上の仮想マシンが検出されたことが確認できます。
[検出済みサーバー] で検出されたサーバーの一覧が確認できます。
[アプライアンス] でアプライアンスの状態が確認できます。
3. 評価
評価の作成
評価を作成します。必要に応じて、設定を変更します。
評価名や評価対象の仮想マシンを選択します。
作成を完了すると、評価が開始されます。
評価結果
パフォーマンスベースの評価が完了するまではしばらく時間がかかります。
依存関係の分析
依存関係の分析にはエージェントレスとエージェントベースがあります。
エージェントレスの依存関係の分析を有効にするには Azure Migrate での有効化を行います。
エージェントベースの依存関係の分析は仮想マシンに Log Analytics エージェントをインストールします。
設定後しばらくすると依存関係が確認できます。
移行
ドキュメント
0. Azure へのリソースの展開
事前に Azure 上に仮想ネットワークを作成しておきます。
1. レプリケーションの設定
概要ページから[レプリケート]をクリックします。
[基本]画面でアプライアンスを選択します。
レプリケーションの対象を選択します。作成した評価から選択することもできます。
[ターゲット設定]で移行後の Azure の仮想ネットワークを選択します。
仮想マシンの性能、可用性ゾーンを選択します。評価から選択した場合、評価に基づいた推奨サイズが自動的に設定されます。
ディスクの種類を選択します。
ウィザードが完了するとレプリケートが開始されます。
レプリケーションが完了するとレプリケーションの正常性が[正常]になります。
VMをクリックすると詳細が確認できます。
サイズやネットワーク情報の変更もこの画面から行います。
ジョブ
進行状況は[ジョブ]から確認できます。
Azure に展開されるリソース
レプリケートを有効にすると、Azure Migrate のプロジェクトがあるリソース グループには、ストレージ アカウント、Service Bus、Key Vault が展開されます。
以下は、評価とレプリケートを有効にしているためストレージ アカウントと Key Vault が2つずつあります。
仮想マシンの移行先のリソース グループには、管理ディスクが作成されます。
リソースの使用状況
アプライアンス
アプライアンスによって vCenter からデータの受信と Azure へのデータ送信が行われていることが分かります。
vCenter からアプライアンス仮想マシンのリソース状況を確認してみます。(1/23 5:30 PM 頃がレプリケートしていたタイミングです)
vCenter
ESXi ホスト側のリソースです。
2. テスト移行の実行
レプリケーションが完了するとテスト移行が可能になります。
テスト移行を実行すると、Azure に移行された仮想マシンが作成され起動されます。
テスト移行で仮想マシンの動作を確認後、テスト移行のクリーンアップを行うと作成されたリソースが削除されます。
参考: ハイドレーション プロセス
Azure 上の仮想マシンは、Azure 上で動作するためのドライバやエージェントが必要です。Azure Migrate を実行するとそれらのインストールが自動的に行われます。
詳細は以下のドキュメントを参照してください。
ドキュメント内の上図のように、テスト移行/移行時には、レプリケーションされたディスクデータから管理ディスクが作成され、その管理ディスクが一時的に作成される作業用仮想マシンにデータディスクとしてアタッチされます。
その後、作業用仮想マシン内で自動的にドライバやエージェントがインストールされ、Azure 上で動作するための設定が行われます。
この作業用仮想マシンは Azure Migrate によって完全に管理されており、仮想ネットワークの展開も含めて自動的に行われます。また、ハイドレーションプロセスが完了した後は自動的に削除されます。
ハイドレーションプロセスは、ジョブの[移行の準備中]のステップで作成されます。
移行中に移行先のリソース グループを確認すると、作業用の仮想マシンやリソースが存在することが分かります。
また、作業用の仮想マシンに移行対象の VM のディスクがデータディスクとしてアタッチされていることが分かります。
NSG ではアウトバウンドの許可としてストレージ アカウントと GitHub への接続が設定されています。
3. 移行の実行
移行の実施
テスト移行が完了したらいよいよ本番移行を開始します。
エージェントレスの移行では、移行時に仮想マシンをシャットダウンできます。それによってデータの損失を防ぎつつ、移行を進められます。移行時にシャットダウンするかどうかはプルダウンから選択します。
移行自体は 25 GB の OS ディスク(90GB の管理ディスク) が 15 分程度で完了しました。
移行の完了
移行が完了したら、完了操作を行い、移行設定を削除します。
よくある質問
FAQ のドキュメント
Q. 移行直前に操作した変更はレプリケーションされますか？
はい、前回レプリケート後の差分が移行操作時にレプリケートされた上で、ディスクが作成されます。
レプリケートする仮想マシンで移行操作を実行する際、前回のレプリケーション サイクル以降の残りの変更をレプリケートするオンデマンド差分レプリケーション サイクルがあります。 オンデマンドのサイクルが完了すると、仮想マシンに対応するレプリカ マネージド ディスクが Azure での仮想マシンの作成に使用されます。
尚、Azure への移行後は仮想マシンは起動状態となるため、必要に応じてサービスが自動起動等しない様に設定いただく必要があります。
ただし、テスト移行はレプリケーションされたデータからディスクが作成されるため、直前の操作が反映されていない可能性があります。
テスト移行では、レプリケートされたデータを使用してテスト用の Azure VM を作成することによって、実際の移行をシミュレートします。 サーバーは、レプリケートされたデータの特定の時点のコピーを使用してターゲット リソース グループ (レプリケーションを有効にするときに選択したもの) に "-test" というサフィックスを付けてデプロイされます。
Q. 移行した後の仮想マシンは起動状態になっていますか？
はい。停止状態の仮想マシンを移行した場合であっても、Azure 上では起動されます。
Q. オンプレミスの仮想マシンの IP アドレスを固定にしています。移行時に IP アドレスを維持/指定できますか？
はい。ネットワーク構成の画面から、IP アドレスの種類 を Static に変更することで、IP アドレスを固定できます。
この設定を行うと、移行時にOSの NIC 設定が DHCP に変更され、Azure の NIC リソースの設定で静的割り当てが行われます。
Azure Migrate による移行前にオンプレミス環境で DHCP に変更する必要はありません。
以下は移行前のネットワーク構成です。
以下は、Static として移行した場合の設定です。IP アドレス、DNS サーバーアドレスの設定も含めて設定が削除されます。
DNS の設定を維持したい場合は、仮想ネットワークに DNS の設定をしておくか、移行後に NIC リソースの設定を変更する必要があります。
ネットワーク構成は以下の画面から行います。
移行後に NIC リソースを確認すると、静的割り当てとなっていることが分かります。
Discussion