次の方法で共有

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

  • [アーティクル]

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

注意事項

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

一般的な質問

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

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

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

どの移行オプションを使用するかを決定する際に、次の情報を考慮してください。

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

エージェントレスのレプリケーション オプションは、VMware VM と Hyper-V VM で使用できます。

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

エージェントベースの移行オプションは、次のような場合に使用できます。

エージェントベースの移行では、移行においてマシンを物理サーバーとして扱います。

エージェントレス移行は、VMware や Hyper-V VM のエージェントベースのレプリケーション オプションよりも便利で、かつシンプルです。 ただし、次のようなユース ケースでは、エージェントベースのシナリオを使用することを検討することが必要になる可能性があります。

  • 1 秒あたりの入出力操作 (IOPS) の制約付き環境: エージェントレス レプリケーションでは、スナップショットを使用するため、ストレージの IOPS/帯域幅を消費します。 ご使用の環境でストレージ/IOPS に制約がある場合は、エージェントベースの移行方法が推奨されます。

  • VCenter Server がない場合: 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 プロジェクトを使用して複数のサブスクリプションに移行することはできますか?

はい。同じ Azure Migrate プロジェクトを使用して、同じターゲット リージョン内の同じ Azure テナントがある複数のサブスクリプションに移行できます。 1 台のマシンまたは一連のマシンのレプリケーションを有効にするときに、ターゲット サブスクリプションを選択することができます。

ターゲット リージョンがロックされるのは、次のような場合です。

  • エージェントレス VMware 移行の最初のレプリケーション後。
  • エージェントベースの移行用のレプリケーション アプライアンスのインストール中。
  • エージェントレス Hyper-V 移行用の Hyper-V プロバイダーのインストール中。

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

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

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

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

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

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

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

テスト移行オプションでは、実際の移行前に移行をテストして検証できます。 テスト移行は、実際の移行前に Azure のサンドボックス環境を使って VM をテストできるようにするしくみです。 指定したテスト仮想ネットワークによってサンドボックス環境が区切られます。 テスト移行操作は、テスト仮想ネットワークが十分に分離されている限り、中断なしで実行できます。 不要な接続を避けるために受信接続ルールと送信接続ルールを設計した場合に、仮想ネットワークは十分に分離されます。 例: オンプレミス マシンへの接続が制限されている。

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

テスト移行と実際の移行の違いを示すスクリーンショット。

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

テスト移行オプションを使用して、Azure におけるアプリケーションの機能とパフォーマンスを検証できます。 任意の数のテスト移行を実行し、テスト移行操作を通じて信頼を確立した後で最終的な移行を実行できます。

テスト移行を行ってもオンプレミスのマシンに影響はなく、実際の移行を実行するまで、稼働状態が維持され、レプリケーションが続行されます。 テスト移行のユーザー受け入れテスト (UAT) 中にエラーが発生した場合は、最終的な移行を延期し、ソース VM/サーバーが稼働して Azure にレプリケートし続けるようにすることを選択できます。 エラーを解決した後で、最終的な移行を再試行できます。

Note

Azure への最終的な移行を完了し、オンプレミスのソース マシンがシャットダウンされると、Azure からオンプレミス環境へのロールバックを実行することはできません。

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

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

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

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

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

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

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

テスト移行では、レプリケートされたデータを使用してテスト用の Azure VM を作成することによって、実際の移行をシミュレートします。 サーバーは、レプリケートされたデータの特定の時点のコピーを使用してターゲット リソース グループ (レプリケーションを有効にするときに選択したもの) に -test というサフィックスを付けてデプロイされます。 テスト移行は、移行後の問題を最小限に抑えるために、サーバー機能を検証することを目的としています。

テスト移行がテスト後にクリーンアップされない場合、テスト VM は 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 2025、2022、2019、2016、2012 R2、2012 年 対応 Y
Windows 11 Pro、Windows 11 Enterprise 年 対応 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 22.04 LTS、20.04 LTS、18.04 LTS、16.04 LTS 年 対応 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 9、8、7.7-CI、7.7、6 年 対応 Y

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

移行およびモダン化ツールは、アプリケーションに依存しないため、ほとんどのアプリケーションで機能します。 移行およびモダン化ツールを使用してサーバーを移行すると、そのサーバーにインストールされているすべてのアプリケーションが一緒に移行されます。 ただし、一部のアプリケーションでは、別の移行方法が適している場合もあります。

Active Directory の場合は、環境の種類が要因になる可能性があります。 オンプレミス サイトが Azure 環境に接続されているハイブリッド環境では、別のドメイン コントローラーを追加し、Active 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 VM に移行すると、サポート終了後 3 年間、VM の実行コストを上回る追加料金なしで、拡張セキュリティ更新プログラムを取得できます。 移行およびモダン化ツールを使用して、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 VM を移行するためのエージェントレスのレプリケーション オプションが用意されています。 ツールには、Windows および Linux サーバー用の別のエージェントベースのレプリケーション オプションが用意されています。 この他のオプションは、VMware、Hyper-V、AWS、GCP などのプロバイダー上の物理サーバーや x86/x64 VM の移行に使用できます。

エージェントベースのレプリケーションでは、移行先の VM/サーバーにエージェント ソフトウェアをインストールする必要があります。 エージェントレス オプションは便利でシンプルであるため、VM にソフトウェアをインストールする必要はありあせん。

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

VM に対してレプリケーションが構成されている場合、VM では最初に初期レプリケーション フェーズが実行されます。 初期レプリケーション中に、VM スナップショットが作成され、スナップショット ディスクからのデータの完全なコピーがサブスクリプション内のマネージド ディスクにレプリケートされます。 VM の初期レプリケーションが完了すると、レプリケーション プロセスは増分レプリケーション (差分レプリケーション) フェーズに移行します。

増分レプリケーション フェーズでは、前回完了したレプリケーション サイクル以降に発生したデータ変更に対処します。 これらの変更は定期的にレプリケートされ、レプリカ マネージド ディスクに適用されます。 このプロセスでは、VM 上の変更とレプリケーションの同期が保持されます。

VMware VM のレプリケーション サイクル間の変更を追跡するために、VMware の変更ブロック追跡テクノロジが使用されます。 レプリケーション サイクルの開始時に、VM スナップショットが作成され、変更ブロック追跡を使用して、現在のスナップショットと最後に正常にレプリケートされたスナップショットの間の変更が取得されます。 VM のレプリケーションを同期した状態に保つには、最後に完了したレプリケーション サイクル以降に変更されたデータのみをレプリケートする必要があります。

各レプリケーション サイクルの最後に、スナップショットが解放され、VM に対してスナップショットの統合が実行されます。 同様に、Hyper-V VM の場合は、Hyper-V レプリカの変更追跡エンジンで連続するレプリケーション サイクル間の変更が追跡されます。

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

作業を開始するには、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 のスケジュールされたタスクを利用し、必要に応じて帯域幅をスケールします。 あるタスクでは帯域幅が減少し、別のタスクでは帯域幅が増加します。

Note

次のコマンドを実行する前に、前述の NetQosPolicy を作成する必要があります。

#Replace with an account that's 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) is 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 ストレージ帯域幅が必要になります。 ご利用の環境内でストレージまたは IOPS に制約がある場合は、エージェントレス レプリケーションを使用しないことをお勧めします。

電源オフの VM をレプリケートできますか?

VMware VM の電源がオフになっている間のレプリケーションは、エージェントレス アプローチでのみサポートされています。

重要

レプリケーション前にその操作状態を確認することはできないため、電源オフの VM が正常に起動することは保証できません。

実際の移行中にすべてがスムーズに進むよう、テスト移行を実行することを強くお勧めします。 この方法は、初期レプリケーション プロセスが長い場合や、データベース サーバーやその他のディスク負荷の高いワークロードなど、チャーンの多い VM の場合に便利です。

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

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

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

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

「アマゾン ウェブ サービス (AWS) の VM を検出して評価し、Azure に移行する」を参照してください。

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

移行およびモダン化ツールには、物理サーバー上で実行されている Windows サーバーおよび Linux サーバー、または VMware、Hyper-V、AWS、GCP などのプロバイダー上でx86/x64 VM として実行されている Windows サーバーおよび Linux サーバーを移行するためのエージェントベースの移行オプションが用意されています。

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

Note

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

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

レプリケーション アプライアンスは、専用のマシンにインストールする必要があります。 レプリケーション アプライアンスは、レプリケート対象のソース マシン、または検出および評価に使用される Azure Migrate アプライアンスにはインストールしないでください。 詳細については、「マシンを物理サーバーとして Azure に移行する」を参照してください。

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

エージェントベースのレプリケーション方法では、環境をプロファイリングしてデータ変更頻度を求めたり、必要な帯域幅の要件を予測したりするのに Azure Site Recovery Deployment Planner が役立ちます。 詳細については、「VMware のデプロイを計画する」をお読みください。

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

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

移行およびモダン化ツールには、Windows または Linux が動作している VMware と Hyper-V VM を移行するためのエージェントレスのレプリケーション オプションが用意されています。 ツールには、Windows および Linux サーバー用の別のエージェントベースのレプリケーション オプションが用意されています。 この他のオプションは、VMware、Hyper-V、AWS、GCP などのプロバイダー上の物理サーバーや x86/x64 VM の移行に使用できます。

エージェントベースのレプリケーション オプションでは、移行先の VM/サーバーにエージェント ソフトウェアをインストールする必要があります。 エージェントレス オプションは便利でシンプルであるため、VM にソフトウェアをインストールする必要はありあせん。

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

VM に対してレプリケーションが構成されている場合、VM では最初に初期レプリケーション フェーズが実行されます。 初期レプリケーション中に、VM スナップショットが作成され、スナップショット ディスクからのデータの完全なコピーがサブスクリプション内のマネージド ディスクにレプリケートされます。 VM の初期レプリケーションが完了すると、レプリケーション プロセスは増分レプリケーション (差分レプリケーション) フェーズに移行します。

増分レプリケーション フェーズでは、前回完了したレプリケーション サイクル以降に発生したデータ変更に対処します。 これらの変更は定期的にレプリケートされ、レプリカ マネージド ディスクに適用されます。 このプロセスでは、VM 上の変更とレプリケーションの同期が保持されます。

VMware VM のレプリケーション サイクル間の変更を追跡するために、VMware の変更ブロック追跡テクノロジが使用されます。 レプリケーション サイクルの開始時に、VM スナップショットが作成され、変更ブロック追跡を使用して、現在のスナップショットと最後に正常にレプリケートされたスナップショットの間の変更が取得されます。 VM のレプリケーションを同期した状態に保つには、最後に完了したレプリケーション サイクル以降に変更されたデータのみをレプリケートする必要があります。

各レプリケーション サイクルの最後に、スナップショットが解放され、VM に対してスナップショットの統合が実行されます。 同様に、Hyper-V VM の場合は、Hyper-V レプリカの変更追跡エンジンで連続するレプリケーション サイクル間の変更を追跡するために使用されます。

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

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

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

Azure へのデータ レプリケーションに必要な帯域幅には、さまざまな要因が影響します。 帯域幅の要件は、オンプレミスの Azure Migrate アプライアンスがデータを読み取り、Azure にレプリケートできる速度に依存します。 レプリケーションには、初期レプリケーションと差分レプリケーションの 2 つのフェーズがあります。

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

必要な帯域幅は、次の条件に基づいて計算できます。

  • 波動に必要なデータ量。
  • 初期レプリケーション プロセスに割り当てる時間。

初期レプリケーションは、実際の移行期間の少なくとも 3 - 4 日前に完了するのが理想的です。 このタイムラインでは、実際の期間前にテスト移行を実行し、期間中のダウンタイムを最小限に抑えるのに十分な時間が提供されます。

関連するコンテンツ