移行およびモダン化: 一般的な質問

この記事では、移行およびモダン化ツールに関する一般的な質問の回答を示します。 その他の質問については、次のリソースを確認してください。

• Azure Migrate に関する一般的な質問
• Azure Migrate アプライアンスに関する一般的な質問
• 検出、評価、依存関係の視覚化 に関する質問
• Azure Migrate フォーラムで質問の回答を示します。

注意事項

この記事では、サービス終了 (EOL) 状態となっている Linux ディストリビューションである CentOS について説明します。 適宜、使用と計画を検討してください。 詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。

一般的な質問

移行およびモダン化の移行オプションとは何ですか?

移行およびモダン化 ツールに用意されているソース サーバーと仮想マシンを Azure に移行するための 2 つのオプションが、エージェントレスの移行とエージェントベースの移行です。

選択した移行オプションにかかわらず、移行およびモダン化ツールを使用してサーバーを移行する最初のステップ が、サーバーのレプリケーションを開始することです。 これにより、Azure への VM/サーバー データの初期レプリケーションが実行されます。 初期レプリケーションが完了すると、進行中のレプリケーション (進行中の差分同期) が確定され、増分データが Azure に移行されます。 操作が差分同期ステージに達したら、いつでも Azure に移行することを選択できます。

移行オプションを決める際の考慮事項をいくつか次に示します。

エージェントレスの移行では、移行されるソース VM/サーバー上にソフトウェア (エージェント) を展開する必要はありません。 エージェントレスのオプションは、仮想化プロバイダーによって提供される機能と統合することによってレプリケーションを調整します。 エージェントレスのレプリケーション オプションは、VMware VM と Hyper-V VM で使用できます。

エージェントベースの移行では、移行されるソース VM/マシンに Azure Migrate ソフトウェア (エージェント) をインストールする必要があります。 エージェントベースのオプションは、レプリケーション機能に仮想化プラットフォームを使用しません。 したがって、x86/x64 アーキテクチャを実行している任意のサーバーと、エージェントベースのレプリケーション方法でサポートされているオペレーティング システムのバージョンで使用できます。

エージェントベースの移行オプションは、VMware VM、Hyper-V VM、物理サーバー、AWS で実行されている VM、GCP で実行されている VM、または別の仮想化プロバイダーで実行されている VM に使用できます。 エージェントベースの移行では、移行においてマシンを物理サーバーとして扱います。

エージェントレスの移行は、サポートされているシナリオ (VMware と Hyper-V) でのエージェントベースのレプリケーション オプションよりも利便性とシンプルさに優れていますが、次のユース ケースではエージェントベースのシナリオの使用をご検討ください。

• IOPS の制約付き環境: エージェントレス レプリケーションでは、スナップショットを使用するため、ストレージの IOPS/帯域幅を消費します。 ご使用の環境でストレージ/IOPS に制約がある場合は、エージェントベースの移行方法が推奨されます。
• VCenter Server がない場合は、VMware VM を物理サーバーとして扱い、エージェントベースの移行ワークフローを使用することができます。

詳細については、こちらの記事を参照して、VMware 移行の移行オプションを比較してください。

Azure Migrate を使用した移行はどの地域でサポートされていますか?

パブリックと Government クラウドでサポートされている地域を確認してください。

同じ Azure Migrate プロジェクトを使用して複数のリージョンに移行することはできますか?

Azure Migrate プロジェクト内の複数のリージョンに対して評価を作成することはできますが、1 つの Azure Migrate プロジェクトを使用してサーバーを移行できるのは 1 つの Azure リージョンに対してのみです。 移行先のリージョンごとに追加の Azure Migrate プロジェクトを作成できます。

• エージェントレスの VMware 移行では、最初のレプリケーションを有効にすると、ターゲット リージョンがロックされます。
• エージェントベースの移行 (VMware、物理サーバー、および他のクラウドからのサーバー) では、レプリケーション アプライアンスの設定中にポータルで [リソースの作成] ボタンを選択すると、ターゲット リージョンがロックされます。
• エージェントレスの Hyper-V 移行では、Hyper-V レプリケーション プロバイダーの設定中にポータルで [リソースの作成] ボタンを選択すると、ターゲット リージョンがロックされます。

同じ Azure Migrate プロジェクトを使用して複数のサブスクリプションに移行することはできますか?

はい。1 つの Azure Migrate プロジェクトの同じターゲット リージョン内の複数のサブスクリプション (Azure テナント) に移行できます。 1 台のマシンまたは一連のマシンのレプリケーションを有効にするときに、ターゲット サブスクリプションを選択することができます。 ターゲット リージョンは、エージェントレスの VMware 移行での最初のレプリケーション後、エージェントベースの移行でのレプリケーション アプライアンスのインストール中、およびエージェントレスの Hyper-V 移行での Hyper-V プロバイダーのインストール中にロックされます。

Azure Migrate は Azure Resource Graph をサポートしていますか?

現在、Azure Migrate は Azure Resource Graph と統合されていません。 ARG 関連のクエリの実行はサポートされています。

オンプレミス環境から Azure にはどのようにしてデータが送信されますか? 送信前に暗号化されますか?

エージェントレス レプリケーションの場合の Azure Migrate アプライアンスでは、アップロード前にデータを圧縮して暗号化します。 データはセキュリティで保護された通信チャネルを介して HTTPS で送信され、TLS 1.2 以降を使用します。 さらに、Azure Storage では、データはクラウドに永続化されるときに自動的に暗号化されます (保存時暗号化)。

Azure Migrate で作成した Recovery Services コンテナーをディザスター リカバリーのシナリオに使用することはできますか?

ディザスター リカバリーのシナリオでは、Azure Migrate で作成した Recovery Services コンテナーは使用しないことをお勧めします。 これにより、Azure Migrate でレプリケーションの開始が失敗する可能性があります。

テスト移行操作と移行操作の違いは何ですか?

テスト移行は、実際の移行前に移行をテストして検証する方法を提供します。 テスト移行は、実際の移行前に Azure のサンドボックス環境を使って仮想マシンをテストできるようにするしくみです。 サンドボックス環境は、指定したテスト仮想ネットワークによって区切られます。 テスト移行操作は、テスト VNet が十分に分離されていれば、中断なしで実行できます。 ここでいう分離された VNet とは、受信および送信の接続規則が不要な接続を避けるように設計されていることを意味します。 たとえば、オンプレミス マシンへの接続が制限されています。

ソース側のアプリケーションを引き続き実行しながら、分離されたサンドボックス環境内のクローン コピー上でテストを実行できます。 必要に応じて複数のテストを実行して、移行を検証し、アプリのテストを実行して、実際の移行前に問題に対処することができます。

Azure Migrate のロールバック オプションはありますか?

テスト移行オプションを使用して、Azure におけるアプリケーションの機能とパフォーマンスを検証できます。 任意の数のテスト移行を実行し、テスト移行操作を通じて信頼を確立した後で最終的な移行を実行できます。 テスト移行を行ってもオンプレミスのマシンに影響はなく、実際の移行を実行するまで、稼働状態が維持され、レプリケーションが続行されます。 テスト移行の UAT 中にエラーが発生した場合は、最終的な移行を延期し、ソース VM/サーバーが稼働して Azure にレプリケートし続けるようにすることを選択できます。 エラーを解決したら、最終的な移行を再試行できます。 注: Azure への最終的な移行を完了し、オンプレミスのソース マシンがシャットダウンされている場合は、Azure からオンプレミス環境へのロールバックを実行することはできません。

テスト移行に使用する仮想ネットワークとサブネットを選択できますか?

テスト移行用の仮想ネットワークは選択できます。 サブネットは、次のロジックに基づいて自動的に選択されます。

• レプリケーションを有効にするときにターゲット サブネット (既定以外) が入力として指定されていた場合、Azure Migrate ではテスト移行用に選択された仮想ネットワーク内の同じ名前を持つサブネットを優先的に使用します。
• 同じ名前のサブネットが見つからない場合、Azure Migrate ではゲートウェイ/Application Gateway/ファイアウォール/Bastion サブネットではない、アルファベット順に使用可能な最初のサブネットを選択します。

自分のサーバーで [テスト移行] ボタンが無効になっているのはなぜですか?

次のシナリオでは、[テスト移行] ボタンが無効状態になっている可能性があります。

• VM の初期レプリケーション (IR) が完了するまで、テスト移行を開始することはできません。 [テスト移行] ボタンは、IR プロセスが完了するまで無効になります。 VM が差分同期ステージに入ると、テスト移行を実行できます。
• テスト移行が既に完了していても、その VM に対してテスト移行のクリーンアップが実行されなかった場合は、このボタンが無効になっている可能性があります。 テスト移行のクリーンアップを実行して、操作を再試行してください。

テスト移行をクリーンアップしないとどうなりますか?

テスト移行では、レプリケートされたデータを使用してテスト用の Azure VM を作成することによって、実際の移行をシミュレートします。 サーバーは、レプリケートされたデータの特定の時点のコピーを使用してターゲット リソース グループ (レプリケーションを有効にするときに選択したもの) に "-test" というサフィックスを付けてデプロイされます。 テスト移行は、移行後の問題を最小限に抑えるためにサーバーの機能を検証することを目的としています。 テスト後にテスト移行がクリーンアップされない場合、テスト用の仮想マシンが引き続き Azure で実行され、料金が発生します。 テスト移行後にクリーンアップするには、移行およびモダン化ツールの [マシンのレプリケート] ビューに移動し、そのマシンに対して [テスト移行をクリーンアップ] 操作を使用します。

VM が正常に移行されたかどうかを確認するにはどうすればよいですか?

VM/サーバーを正常に移行したら、[仮想マシン] ページで VM を表示して管理できます。 移行された VM に接続して検証します。 あるいは、この操作の "ジョブの状態" をレビューして、移行が正常に完了したかどうかを確認することもできます。 エラーが発生した場合は、それらを解決してから、移行操作を再試行してください。

移行後にレプリケーションを停止しないとどうなりますか?

レプリケーションを停止すると、移行およびモダン化ツールによって、レプリケーション用に作成されたサブスクリプション内のマネージド ディスクがクリーンアップされます。

移行後に移行を完了しないとどうなりますか?

移行を完了すると、移行およびモダン化ツールによって、レプリケーション用に作成されたサブスクリプション内のマネージド ディスクがクリーンアップされます。 移行後に [移行の完了] を選択しない場合は、これらのディスクに対して引き続き料金が発生します。 移行の完了は、既に移行されているマシンに接続されているディスクには影響しません。

UEFI ベースのマシンを Azure Generation 1 VM として Azure に移行するにはどうすればよいですか?

移行およびモダン化ツールでは、UEFI ベースのマシンは Azure Generation 2 VM として Azure に移行されます。 それらを Azure Generation 1 VM に移行する場合は、レプリケーションを開始する前にブートの種類を BIOS に変換してから移行およびモダン化ツールを使用して Azure に移行してください。

Azure Migrate では、UEFI ベースのマシンは BIOS ベースのマシンに変換されて Azure Generation 1 VM として Azure に移行されますか?

移行およびモダン化ツールでは、UEFI ベースのマシンのすべてが Azure Generation 2 VM として Azure に移行されます。 UEFI ベースの VM から BIOS ベースの VM への変換はサポートされなくなりました。 すべての BIOS ベースのマシンは、Azure Generation 1 VM としてのみ Azure に移行されます。

Azure への UEFI ベースのマシンの移行がサポートされているオペレーティング システムはどれですか?

Note

エージェントレス移行でオペレーティング システムのメジャー バージョンがサポートされている場合、すべてのマイナー バージョンとカーネルは自動的にサポートされています。

UEFI ベースのコンピューターがサポートされているオペレーティング システム	エージェントレスの VMware から Azure	エージェントレスの Hyper-V から Azure	エージェントベースの VMware、物理およびその他のクラウドから Azure
Windows Server 2022、2019、2016、2012 R2、2012	年	年	Y
Windows 10 Pro、Windows 10 Enterprise	Y	年	Y
SUSE Linux Enterprise Server 15 SP1、SP2、SP3、SP4、SP5、SP6	年	年	Y
SUSE Linux Enterprise Server 12 SP4	Y	年	Y
Ubuntu Server 16.04、18.04、19.04、19.10	Y	年	Y
RHEL 9.x、8.1、8.0、7.8、7.7、7.6, 7.5、7.4、7.0、6.x	年	年	Y
CentOS Stream	年	年	Y
Oracle Linux 7.7、7.7-CI	Y	年	Y

Azure Migrate を使用して Active Directory ドメイン コントローラーを移行できますか?

移行およびモダン化ツールは、アプリケーションに依存しないため、ほとんどのアプリケーションで機能します。 移行およびモダン化ツールを使用してサーバーを移行すると、そのサーバーにインストールされているすべてのアプリケーションが一緒に移行されます。 ただし、一部のアプリケーションでは、移行およびモダン化以外の代替移行方法が移行に適している場合があります。 Active Directory の場合、オンプレミス サイトが Azure 環境に接続されているハイブリッド環境では、別のドメイン コントローラーを Azure に追加し、Active Directory レプリケーションを設定することによって、ご利用の Directory を Azure に拡張できます。 独自のドメイン コントローラーを必要とする Azure の分離環境に移行する (またはサンドボックス環境でアプリケーションをテストする) 場合は、移行およびモダン化ツールを使用してサーバーを移行できます。

移行中に OS をアップグレードできますか?

移行およびモダン化ツールで、移行中の Windows OS のアップグレードがサポートされるようになりました。 Linux では、このオプションは現在使用できません。 Windows OS のアップグレードの詳細を参照してください。

Vmware VM を移行するには VMware vCenter が必要ですか?

Vmware エージェントベースまたはエージェントレス移行を使用して VMware Vm を移行するには、VM が配置されている ESXi ホストを vCenter Server で管理する必要があります。 VCenter Server がない場合は、物理サーバーとして移行することで VMware VM を移行できます。 詳細情報 を参照してください。

移行中に複数のソース VM を 1 つの VM に統合することはできますか?

移行およびモダン化機能では現在、既存のものと同じ移行がサポートされています。 移行の一環としてサーバーの統合はサポートされていません。

Windows Server 2008 および 2008 R2 は、移行後に Azure でサポートされますか?

オンプレミスの Windows Server 2008 および 2008 R2 サーバーを Azure 仮想マシンに移行すると、サポート終了後 3 年間、仮想マシンの実行コストを上回る追加料金なしで、拡張セキュリティ更新プログラムを取得できます。 移行およびモダン化ツールを使用して、Windows Server 2008 および 2008 R2 のワークロードを移行できます。

VMware/Hyper-V で動作している Windows Server 2003 を Azure に移行するにはどうすればよいですか?

Windows Server 2003 の延長サポートは、2015 年 7 月 14 日に終了しました。 Azure サポート チームでは、Azure での Windows Server 2003 の実行に関係する問題のトラブルシューティングを引き続き支援します。 ただし、このサポートは、OS レベルのトラブルシューティングや修正プログラムを必要としない問題に限定されます。 Azure クラウドの柔軟性と信頼性を効果的に使用できるようにするため、新しいバージョンの Windows Server が動作している Azure インスタンスにアプリケーションを移行することをお勧めします。

それでも、Windows Server 2003 を Azure に移行することを選択した場合は、移行およびモダン化ツールを使用できます (Windows Server が VMware または Hyper-V で実行されている VM の場合)。Windows Server 2003 マシンを移行用に準備する場合は、こちらの記事をご覧ください。

エージェントレスの VMware 移行

エージェントレスの移行はどのようなしくみになっていますか?

移行およびモダン化ツールには、Windows または Linux が動作している VMware 仮想マシンと Hyper-V 仮想マシンを移行するためのエージェントレスのレプリケーション オプションが用意されています。 さらに、このツールには、物理サーバー、さらには VMware、Hyper-V、AWS、GCP などでの x86/x64 仮想マシンの移行に使用できる Windows および Linux サーバー用の別のエージェントベースのレプリケーション オプションも用意されています。エージェントベースのレプリケーション オプションでは、移行されるサーバーや仮想マシンにエージェント ソフトウェアをインストールする必要があるのに対し、エージェントレスのオプションでは、仮想マシン自体にソフトウェアをインストールする必要がないため、エージェントベースのレプリケーション オプションよりも利便性とシンプルさに優れています。

エージェントレスのレプリケーション オプションは、仮想化プロバイダー (VMware、Hyper-V) によって提供されるメカニズムを使用して機能します。 VMware 仮想マシンの場合、エージェントレスのレプリケーション メカニズムでは、VMware スナップショットと VMware の変更ブロック追跡テクノロジを使用して、仮想マシンのディスクからデータをレプリケートします。 このメカニズムは、多くのバックアップ製品で使用されているものと似ています。 Hyper-V 仮想マシンの場合、エージェントレスのレプリケーション メカニズムでは、VM スナップショットと、Hyper-V レプリカの変更追跡機能を使用して、仮想マシンのディスクからデータをレプリケートします。

仮想マシンに対してレプリケーションが構成されている場合、最初に初期レプリケーション フェーズが実行されます。 初期レプリケーション中に、VM スナップショットが作成され、スナップショット ディスクからのデータの完全なコピーがサブスクリプション内のマネージド ディスクにレプリケートされます。 VM の初期レプリケーションが完了すると、レプリケーション プロセスは増分レプリケーション (差分レプリケーション) フェーズに移行します。 増分レプリケーション フェーズでは、最後に完了したレプリケーション サイクル以降に発生したデータ変更が定期的にレプリケートされて、レプリカ マネージド ディスクに適用されるため、レプリケーションは VM 上で発生する変更と同期した状態に保たれます。 VMware 仮想マシンの場合は、レプリケーション サイクル間の変更を追跡するために、VMware の変更ブロック追跡テクノロジが使用されます。 レプリケーション サイクルの開始時に、VM スナップショットが作成され、変更ブロック追跡を使用して、現在のスナップショットと最後に正常にレプリケートされたスナップショットの間の変更が取得されます。 このようにして、最後に完了したレプリケーション サイクル以降に変更されたデータのみをレプリケートして、VM のレプリケーションを同期した状態に保つ必要があります。各レプリケーション サイクルの最後に、スナップショットが解放され、仮想マシンに対してスナップショットの統合が実行されます。 同様に、Hyper-V 仮想マシンの場合は、連続するレプリケーション サイクル間の変更を追跡するために、Hyper-V レプリカの変更追跡エンジンが使用されます。

レプリケートする仮想マシンで移行操作を実行するときに、オンプレミスの仮想マシンをシャットダウンして、最後の増分レプリケーションを実行することを選択すれば、データ損失を防ぐことができます。 移行を実行すると、仮想マシンに対応するレプリカ マネージド ディスクが Azure での仮想マシンの作成に使用されます。

作業を開始するには、VMware のエージェントレスの移行と Hyper-V のエージェントレスの移行のチュートリアルをご覧ください。

移行のための帯域幅の要件はどのように判断したらよいでしょうか?

Azure へのデータ レプリケーションのための帯域幅は、さまざまな要因によって決まり、オンプレミスの Azure Migrate アプライアンスがデータを読み取って Azure にレプリケートできる速度と関係しています。 レプリケーションには、初期レプリケーションと差分レプリケーションの 2 つのフェーズがあります。

VM のレプリケーションが開始されると、初期レプリケーション サイクルが発生し、ディスクの完全なコピーがレプリケートされます。 初期レプリケーションが完了すると、前回のレプリケーション サイクル以降に発生したすべての変更を転送するために、増分レプリケーション サイクル (差分サイクル) が定期的にスケジュールされます。

初期レプリケーションが実行される波長と期間内で移動する必要のあるデータ量に基づいて帯域幅の要件を決めることができます (理想的には、実際の期間より前にテスト移行を行ったり、その期間中にダウンタイムを最小限に抑えたりするための十分な時間を確保するために、初期レプリケーションを実際の移行期間の少なくとも 3 - 4 日前に終わらせるとよいでしょう)。

次の数式を使用して、エージェントレスの VMware VM の移行に必要な帯域幅または時間を見積もることができます。

初期レプリケーションを完了するまでの時間 = {ディスクのサイズ (入手できる場合は使用サイズ) * 0.7 (控えめに見積もって圧縮率の平均を 30% とします)}/レプリケーションに使用できる帯域幅。

エージェントレス VMware レプリケーションに対する Azure Migrate アプライアンスの使用においてレプリケーションを調整するにはどうすればよいですか?

NetQosPolicy を使用して調整できます。 この調整は、Azure Migrate アプライアンスからの送信接続にのみ適用されることに注意してください。 次に例を示します。

NetQosPolicy で使用する AppNamePrefix は "GatewayWindowsService.exe" です。 Azure Migrate アプライアンスで次のようなポリシーを作成することによって、アプライアンスからのレプリケーション トラフィックを調整できます:

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

スケジュールに基づいてレプリケーションの帯域幅を増減させるには、Windows のスケジュールされたタスクを利用し、必要に応じて帯域幅をスケールします。 帯域幅を減らすために 1 つのタスクを使用し、別のタスクを使用して帯域幅を増やします。 注: 以下のコマンドを実行する前に、上記で説明した NetQosPolicy を作成する必要があります。

#Replace with an account part of the local Administrators group
$User = "localVmName\userName"

#Set the task names
$ThrottleBandwidthTask = "ThrottleBandwidth"
$IncreaseBandwidthTask = "IncreaseBandwidth"

#Create a directory to host PowerShell scaling scripts
if (!(Test-Path "C:\ReplicationBandwidthScripts"))
{
 New-Item -Path "C:\" -Name "ReplicationBandwidthScripts" -Type Directory
}

#Set your minimum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 10 MBps
New-Item C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 10MB'
$ThrottleBandwidthScript = "C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1"

#Set your maximum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 1000 MBps
New-Item C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 1000MB'
$IncreaseBandwidthScript = "C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1"

#Timezone set on the Azure Migrate Appliance (VM) will be used; change the frequency to meet your needs
#In this example, the bandwidth is being throttled every weekday at 8:00 AM local time
#The bandwidth is being increased every weekday at 6:00 PM local time
$ThrottleBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 8:00am
$IncreaseBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 6:00pm

#Setting the task action to execute the scripts
$ThrottleBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $ThrottleBandwidthScript"
$IncreaseBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $IncreaseBandwidthScript"

#Creating the Scheduled tasks
Register-ScheduledTask -TaskName $ThrottleBandwidthTask -Trigger $ThrottleBandwidthTrigger -User $User -Action $ThrottleBandwidthAction -RunLevel Highest -Force
Register-ScheduledTask -TaskName $IncreaseBandwidthTask -Trigger $IncreaseBandwidthTrigger -User $User -Action $IncreaseBandwidthAction -RunLevel Highest -Force

チャーン レートはエージェントレス レプリケーションにどのように影響しますか?

エージェントレス レプリケーションでは日付が折りたたまれるため、チャーン レートよりチャーン パターンが重要です。 ファイルが繰り返し書き込まれる場合、そのレートはあまり影響を与えません。 ただし、セクターが 1 つおきに書き込まれるパターンでは、次回のサイクルでチャーンが高くなります。 転送するデータの量を最小限に抑えるため、次回のサイクルをスケジュールする前に、できるだけ多くのデータを折りたためるようにします。

レプリケーション サイクルはどのくらいの頻度でスケジュールされますか?

次のレプリケーション サイクルをスケジュールする数式は、(以前のサイクル時間/2) または1時間のいずれか長い方です。

たとえば、VM で差分サイクルに 4 時間かかった場合、次回のサイクルは次の 1 時間ではなく、2 時間後にスケジュールされます。 このプロセスは、最初のレプリケーションの直後とは異なります。その場合は、最初の差分サイクルがすぐにスケジュールされます。

VCenter Server 内の VM を検出するために、2 つ (またはそれ以上) のアプライアンスをデプロイしました。 しかし、VM を移行しようとすると、いずれかのアプライアンスに対応する VM のみが表示されます。

複数のアプライアンスがセットアップされている場合は、指定された vCenter アカウントの VM 間に重複がないことが必要です。 このような重複が検出されるのは、サポートされていないシナリオです。

エージェントレス レプリケーションは VMware サーバーにどのように影響しますか?

エージェントレス レプリケーションでは、VMware vCenter Server と VMware ESXi ホストのパフォーマンスに一部影響が生じます。 エージェントレス レプリケーションではスナップショットが使用されるので、ストレージに対する IOP が消費され、一部の IOPS ストレージ帯域幅が必要になります。 ご利用の環境内でストレージまたは IOP に制約がある場合は、エージェントレス レプリケーションを使用しないことをお勧めします。

Azure Migrate を使用して Web アプリを Azure App Service に移行できますか?

VMware 環境の Windows OS でホストされている IIS Web サーバーで実行されている ASP.NET Web アプリの大規模なエージェントレス移行を実行できます。 詳細情報 を参照してください。

エージェントベースの移行

AWS EC2 インスタンスを Azure に移行するにはどうすればよいですか?

AWS EC2 インスタンスを検出、評価、および Azure に移行する場合は、こちらの記事をご確認ください。

エージェントベースの移行はどのようなしくみになっていますか?

VMware 仮想マシンと Hyper-V 仮想マシン用のエージェントレスの移行オプションに加えて、移行およびモダン化ツールには、物理サーバーで動作している Windows および Linux サーバー、または VMware、Hyper-V、AWS、Google Cloud Platform などで x86/x64 仮想マシンとして動作している Windows および Linux サーバーを移行するためのエージェントベースの移行オプションも用意されています。

エージェントベースの移行方法では、移行されるサーバーにインストールされているエージェント ソフトウェアを使用して、サーバー データを Azure にレプリケートします。 レプリケーション プロセスでは、エージェントがレプリケーション アプライアンスまたは構成サーバーと呼ばれる専用のレプリケーション サーバー (またはスケールアウト プロセス サーバー) にレプリケーション データをリレーするオフロード アーキテクチャを使用します。 エージェントベースの移行オプションのしくみの詳細をご覧ください。

注: レプリケーション アプライアンスは、Azure Migrate の検出アプライアンスとは異なり、個別/専用のマシンにインストールする必要があります。

エージェントベースの移行用のレプリケーション アプライアンスはどこにインストールすればよいですか?

レプリケーション アプライアンスは、専用のマシンにインストールする必要があります。 レプリケート対象のソース マシン、または以前にインストールした Azure Migrate アプライアンス (検出および評価に使用される) に、レプリケーション アプライアンスをインストールすることはできません。 詳細については、チュートリアルをご覧ください。

Amazon Linux オペレーティング システムが動作している AWS VM を移行できますか?

Amazon Linux OS は AWS でのみサポートされているため、Amazon Linux を実行する VM をそのまま移行することはできません。 Amazon Linux で実行されているワークロードを移行するには、Azure で CentOS/RHEL VM を起動し、関連するワークロード移行方法を使用して、AWS Linux マシンで実行されているワークロードを移行します。 たとえば、ワークロードによっては、移行を支援するためのワークロード固有のツール (Web サーバーの場合のデータベースやデプロイのツールなど) が存在する場合もあります。

移行のための帯域幅の要件はどのように判断したらよいでしょうか?

Azure へのデータ レプリケーションのための帯域幅は、さまざまな要因によって決まり、オンプレミスの Azure Migrate アプライアンスがデータを読み取って Azure にレプリケートできる速度と関係しています。 レプリケーションには、初期レプリケーションと差分レプリケーションの 2 つのフェーズがあります。

VM のレプリケーションが開始されると、初期レプリケーション サイクルが発生し、ディスクの完全なコピーがレプリケートされます。 初期レプリケーションが完了すると、前回のレプリケーション サイクル以降に発生したすべての変更を転送するために、増分レプリケーション サイクル (差分サイクル) が定期的にスケジュールされます。

エージェントベースのレプリケーション方法では、環境をプロファイリングしてデータ変更頻度を求めたり、必要な帯域幅の要件を予測したりするのに Deployment Planner が役立ちます。 詳細については、こちらの記事をご覧ください。

エージェントレスの Hyper-V 移行

エージェントレスの移行はどのようなしくみになっていますか?

移行およびモダン化ツールには、Windows または Linux が動作している VMware 仮想マシンと Hyper-V 仮想マシンを移行するためのエージェントレスのレプリケーション オプションが用意されています。 さらに、このツールには、VMware、Hyper-V、AWS、GCP などでの x86/x64 仮想マシンだけでなく、物理サーバーの移行にも使用できる Windows および Linux サーバー用の追加のエージェントベースのレプリケーション オプションも用意されています。エージェントベースのレプリケーション オプションでは、移行されるサーバー/仮想マシンにエージェント ソフトウェアをインストールする必要があるのに対し、エージェントレスのオプションでは、仮想マシン自体にソフトウェアをインストールする必要がないため、エージェントベースのレプリケーション オプションよりも利便性とシンプルさに優れています。

エージェントレスのレプリケーション オプションは、仮想化プロバイダー (VMware、Hyper-V) によって提供されるメカニズムを使用して機能します。 Hyper-V 仮想マシンの場合、エージェントレスのレプリケーション メカニズムでは、VM スナップショットと、Hyper-V レプリカの変更追跡機能を使用して、仮想マシンのディスクからデータをレプリケートします。

仮想マシンに対してレプリケーションが構成されている場合、最初に初期レプリケーション フェーズが実行されます。 初期レプリケーション中に、VM スナップショットが作成され、スナップショット ディスクからのデータの完全なコピーがサブスクリプション内のマネージド ディスクにレプリケートされます。 VM の初期レプリケーションが完了すると、レプリケーション プロセスは増分レプリケーション (差分レプリケーション) フェーズに移行します。 増分レプリケーション フェーズでは、最後に完了したレプリケーション サイクル以降に発生したデータ変更が定期的にレプリケートされて、レプリカ マネージド ディスクに適用されるため、レプリケーションは VM 上で発生する変更と同期した状態に保たれます。 VMware 仮想マシンの場合は、レプリケーション サイクル間の変更を追跡するために、VMware の変更ブロック追跡テクノロジが使用されます。 レプリケーション サイクルの開始時に、VM スナップショットが作成され、変更ブロック追跡を使用して、現在のスナップショットと最後に正常にレプリケートされたスナップショットの間の変更が取得されます。 このようにして、最後に完了したレプリケーション サイクル以降に変更されたデータのみをレプリケートして、VM のレプリケーションを同期した状態に保つ必要があります。各レプリケーション サイクルの最後に、スナップショットが解放され、仮想マシンに対してスナップショットの統合が実行されます。 同様に、Hyper-V 仮想マシンの場合は、連続するレプリケーション サイクル間の変更を追跡するために、Hyper-V レプリカの変更追跡エンジンが使用されます。

レプリケートする仮想マシンで移行操作を実行するときに、オンプレミスの仮想マシンをシャットダウンして、最後の増分レプリケーションを実行することを選択すれば、データ損失を防ぐことができます。 移行を実行すると、仮想マシンに対応するレプリカ マネージド ディスクが Azure での仮想マシンの作成に使用されます。

作業を開始するには、Hyper-V のエージェントレスの移行のチュートリアルをご覧ください。

移行のための帯域幅の要件はどのように判断したらよいでしょうか?

Azure へのデータ レプリケーションのための帯域幅は、さまざまな要因によって決まり、オンプレミスの Azure Migrate アプライアンスがデータを読み取って Azure にレプリケートできる速度と関係しています。 レプリケーションには、初期レプリケーションと差分レプリケーションの 2 つのフェーズがあります。

VM のレプリケーションが開始されると、初期レプリケーション サイクルが発生し、ディスクの完全なコピーがレプリケートされます。 初期レプリケーションが完了すると、前回のレプリケーション サイクル以降に発生したすべての変更を転送するために、増分レプリケーション サイクル (差分サイクル) が定期的にスケジュールされます。

初期レプリケーションが実行される波長と期間内で移動する必要のあるデータ量に基づいて帯域幅の要件を決めることができます (理想的には、実際の期間より前にテスト移行を行ったり、その期間中にダウンタイムを最小限に抑えたりするための十分な時間を確保するために、初期レプリケーションを実際の移行期間の少なくとも 3 - 4 日前に終わらせるとよいでしょう)。

次のステップ

VMware VM、Hyper-V VM、物理サーバーの移行の詳細について確認します。