☰

VMWareコンバータのパフォーマンス

tag-icon • tag-icon vmware-esx vmware-vsphere jumboframes
VMWareコンバータのパフォーマンス

テスト ラボについて質問があります。これは、本番環境に適用するというよりも、概念を理解することの方が重要です。

いくつかの VM Linux/Windows が構成された ESXi があり、VMWare コンバーターを使用してバックアップを作成したいと考えています。

プロセスを高速化するために、Windows 7 と VMWare Converter をインストールした同じ ESXi ホスト上に Windows VM を作成することにしました。

ホストにはギガビット カードがありますが、現在は 100Mb FD ポートに接続されています。Windows 7 では 1GB カードが接続されていると認識されます。

VMWare コンバータを使用してバックアップを行うときは、ソースと宛先としてホスト IP を指定するので、ネットワーク経由でラップトップを使用するよりもコピーが速くなると考えました。

まあ、長い話を短くすると、パフォーマンスはひどいです (4Mb/秒)。ホストが 100Mb で動作しているにもかかわらず、VM とホスト間の通信には (間違っていたら訂正してください) 制限がないはずなので、この点については少し混乱しています。

ネットワーク パフォーマンスを最適化するために Windows 7 を微調整しましたが、改善はわずかでした。50 GB (シン) VM をバックアップするには、まだ 4 時間かかります。

さらに、次のことをお聞きしたいです。ジャンボ フレームはこれに役立ちますか? ジャンボ フレームはエンドツーエンドでサポートされる必要があることは承知していますが、ホストが現在接続されているネットワーク スイッチはこれをサポートしていません。しかし、次の疑問がありました。

1) ESXi ホストはジャンボ フレームをサポートしていますか?

2) 何らかの方法で有効にできますか?

3) そうすると、VM とホスト間の一括転送が改善されると思いますが、ジャンボ転送は実行されないため、実際のスイッチを通過する通信に影響しますか?

読んでくれてありがとう

答え1

ジャンボフレームは多少の違いをもたらすかもしれませんが、スループットの問題はより深刻な問題を示しています。ESXiでジャンボフレームを有効にすることができますが、vCLIコマンドラインツールを使用する必要があります。具体的な手順については、こちらを参照してください。VMware ESXi 構成ドキュメント。

いくつか原因が考えられます。

データが ESXi ホストに出入りしている可能性があります。その場合、Converter は ESXi ホストの VM 内から物理ネットワーク経由で管理インターフェイスにデータをコピーします。100 メガビットのアップリンクであることを考えると、報告されている 4 メガビット/秒ではなく、数メガバイト/秒の速度が得られると予想されます。

ESX ホスト NIC が実際にはスイッチと 100Mbps/全二重設定を正しくネゴシエートしていない可能性があります。スイッチと ESXi ホストの pNIC 設定の両方が正しく設定されていることを確認してください。

コンバータはスループットの点ではそれほど効率的ではありませんが、ブロック ベースのディスク コピー (ファイル レベルではなく) を使用している場合は問題ありません (転送速度はリンク帯域幅の最大値の 50% 以上になります。たとえば、100 Mbps ネットワークでは 4 MB/秒、GigE では 40 MB/秒)。コピーでファイル レベルのコピーを使用している場合は、速度が大幅に低下します。

こうしたアクティビティはすべて、VM が保存されているディスク サブシステムにかなりの負荷をかけます。これらすべてをかなり低速なストレージ (たとえば、RAID 5 内の少数の SATA ドライブ) で実行している場合は、ディスクがスラッシング状態になっている可能性がありますが、健全なストレージ設定では、このようなことはストレスにはなりません。

ただし、問題は仮想ネットワークにあると思います。そうだと仮定すると、次の点を考慮する必要があります。

ESXi 管理ポートが VM の運用ネットワーク ポート グループと同じ仮想スイッチ上にある場合、トラフィックは仮想スイッチ内で内部的にループバックします。ループバックしない場合は、ポート\ポート グループで VLAN が構成されているかどうか、または IP アドレス指定によってトラフィックがスイッチから出てから戻ってくると認識していないかどうかを確認します (たとえば、管理ポートが VM ネットワークとは異なるサブネット上にあり、通信を可能にするために外部ルーターに依存している場合など)。ネットワークが上記の処理を正しく実行していないと思われる場合は、ソース VM とターゲット VM を管理ポートと同じサブネットに配置し、管理ポートと同じ vSwitch 上の VM ポート グループに接続します。これにより、さまざまなシステム (ソース、コンバータ VM、および ESX ホスト) 間のトラフィックが vSwitch の範囲内に収まるようになります。管理ポートを変更するのではなく、VM ポート グループを移動します。管理ポートを変更するときに間違いを犯した場合は、ESXi の物理コンソールに戻って修正する必要があり、リスクを回避するのが最善です。

また、バックアップ プロセスなどが管理ポートのネットワーク帯域幅をすべて占有している場合などに備えて、開始する前にできる限りシャットダウンしてください。

答え2

SSL 暗号化をオフにすると、この問題を回避できます。手順は次のとおりです。

Open the converter-worker.xml configuration file. It is located in

"%ALLUSERSPROFILE%\VMware\VMware vCenter Converter Standalone"

folder for Windows Vista or newer or in

"%ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter Converter Standalone"

for older Windows versions.

Set the key Config/nfc/useSsl to false and save the configuration file.
Restart "VMware vCenter Converter Standalone Worker" service.

つまり、次のようになります。

...
<nfc>
   <readTimeoutMs>120000</readTimeoutMs>
   <useSsl>false</useSsl>
...

「「VMware vCenter Converter Standalone Worker」サービスを再起動します。」

関連情報