エージェントレス VMware 移行におけるレプリケーションの遅さや移行の停止に関する問題をトラブルシューティングする
この記事は、Azure Migrate: Server Migration エージェントレス方式を使用してオンプレミスの VMware VM をレプリケートするときに発生する可能性のある、レプリケーションの遅さや移行の停止の問題のトラブルシューティングに役立ちます。
VM のレプリケーションが遅いか停止している
レプリケーションの実行中に、特定の VM のレプリケーションが期待したペースで進行していないことに気付く場合があります。 一般に、この問題の根本的な理由は、レプリケーションに必要な一部のリソースが利用できないか、不足している場合です。 リソースは、レプリケートしている他の VM やデータセンター内のアプライアンスで実行されている他のプロセスによって消費される可能性があります。
一般的にこの問題が発生する原因とその解決策を次に示します。
NFC バッファー サイズが小さい
Azure Migrate アプライアンスは、ESXi ホスト上で 8 つのディスクを同時にレプリケートするために 32 MB の NFC バッファーを使用するという制約の下で動作します。 NFC バッファー サイズが 32 MB 未満の場合、レプリケーションが遅くなる可能性があります。 次の例外が発生する場合もあります。
例外: GatewayErrorHandling.GatewayServiceException: 'メモリ割り当てに失敗しました。 メモリ不足です。' というエラーが表示され、操作が失敗しました。
Remediation
NFC バッファー サイズを 32 MB を超えて増やして、コンカレンシーを増やすことができます。 この設定は、ESXi ホストとアプライアンスの両方で行う必要があります。 そうでない場合は、レプリケーションのパフォーマンスがさらに低下する可能性があります。
注意事項
サイズを 32 MB を超えるように増やすと、環境内でリソースの制約が発生する可能性があります。 続行する前に、システム管理者に問い合わせて、その影響を理解してください。
ESXi ホストでの変更
ルートとして ESXi ホストに SSH 接続します。
vi エディタを使用して “/etc/vmware/hostd/config.xml” を開きます。
以下のようなセクションを見つけます。
<nfcsvc> <enabled>true</enabled> <maxMemory>134217728</maxMemory> <maxStreamMemory>10485760</maxStreamMemory> <path>libnfcsvc.so</path> </nfcsvc>
maxMemory
の値を編集して、NFC バッファー用に構成する値 (バイト単位) にします。 この例では、128 MB (128 * 1024 * 1024) に設定されています。保存して終了します。
次のコマンドを使用して、シェルから管理エージェントを再起動します。
- /etc/init.d/hostd restart
- /etc/init.d/vpxa restart
アプライアンスでの変更
- リモート デスクトップを使用して、管理者として Azure Migrate アプライアンスにサインインします。
- "%programdata%\Microsoft Azure\Config" フォルダー内の GatewayDataWorker.json ファイルを開きます。
- 空の json ファイルが存在しない場合は作成し、作成された新しいファイルに次のテキストを貼り付けます。
{ "HostBufferSizeInMB": "32", }
HostBufferSizeInMB
の値を ESXi ホストで設定した値に変更します。- 保存して終了します。
- アプライアンスで実行されている Azure Migrate ゲートウェイ サービスを再起動します。 PowerShell を開き、次を実行します。
- net stop asrgwy (サービスが停止するまで待ちます)
- net start asrgwy
ESXi ホストの使用可能な RAM が少ない
レプリケート VM が存在する ESXi ホストがビジー状態の場合、RAM が使用できないため、レプリケーション プロセスが遅くなります。
Remediation
VMotion を使用して、レプリケーションが遅い VM をビジー状態ではない ESXi ホストに移動します。
ネットワーク帯域幅
Azure Migrate アプライアンスで使用できるネットワーク帯域幅が低いため、レプリケーションが遅くなる可能性があります。 帯域幅が低い場合は、他のアプリケーションが帯域幅を使い切ったり、帯域幅調整アプリケーションが存在したり、プロキシ設定によってレプリケーション アプライアンスの帯域幅の使用が制限されたりしている可能性があります。
Remediation
帯域幅が低い場合は、まず、ネットワーク帯域幅を使用するアプリケーションの数を減らすことができます。 調整アプリケーションまたはプロキシ設定が存在するかどうかをネットワーク管理者に確認してください。
ディスク I/O
レプリケーションが遅くなる可能性があります。これは、レプリケートされるサーバーの負荷が多すぎて、接続されているディスクに対して高い I/O 操作が発生しているためです。 レプリケーション速度を上げるには、サーバーの負荷を軽減することをおすすめします。 次のエラーが発生する場合もあります。
仮想マシンの ‘VM 名’ の最後のレプリケーション サイクルが失敗しました。 タイムアウト イベントが発生しました。
アクションが実行されない場合は、レプリケーションが続行され、遅延が発生して完了します。
ディスクの書き込み速度
レプリケーションを有効にするときに選択したディスクの書き込み速度よりもデータのアップロード速度が高い場合、レプリケーションは予想よりも遅くなる可能性があります。 同じアップロード速度でより良い速度を得るには、レプリケーションを再起動し、レプリケーションのディスクの種類を選択するときに Premium を選択する必要があります。
注意事項
評価中に推奨されるディスクの種類は、特定の VM に対して Premium ではない可能性があります。 この場合、移行後にこの VM に Premium ディスクを接続する必要がない可能性があるため、レプリケーション速度を向上させるために Premium ディスクに切り替えることはおすすめできません。
VM での移行操作が停止している
特定の VM に対して移行をトリガーしているときに、移行が何らかの段階 (キューまたは差分同期) で予想よりも長く停止している場合があります。 一般に、この問題の根本的な理由は、移行に必要な一部のリソースが利用できないか、不足している場合です。 リソースは、レプリケートしている他の VM やデータセンター内のアプライアンスで実行されている他のプロセスによって消費される可能性があります。 一般的にこの問題が発生する原因とその解決策を次に示します。
NFC バッファー サイズが小さい
2 つ目の VM に対して移行がトリガーされている間に、大容量のディスクを備えたサーバーの IR サイクルが進行中の場合、2 番目の VM の移行ジョブが停止する可能性があります。 移行ジョブの優先度が高くても、NFC バッファーを移行に使用できない場合があります。 この場合は、大規模なディスクを使用するサーバーの初期レプリケーションを停止または一時停止し、2 つ目の VM の移行を完了することをおすすめします。
進行中の差分同期サイクルが完了していない
進行中の差分レプリケーション サイクル中に移行がトリガーされると、キューに入れられます。 最初に VM の差分レプリケーション サイクルが完了し、その後に移行が開始されます。 移行をトリガーするために必要な時間は、1 つの差分同期サイクルを完了するのにかかった時間によって異なります。
オンプレミス VM のシャットダウンに通常よりも時間がかかる
VM をシャットダウンせずに移行するか、VM を手動でオフにしてから移行してください。
次のステップ
VMware VM の移行に関する詳細について説明します。