OpenNebula (KVM) + OpenvSwitch、高帯域幅使用時の CPU 負荷が高い

Question

私たちは、仮想インターフェイスのブリッジと 2 つの Gbit ポートの LACP トランキングに OpenvSwitch 2.5 を使用して、Ubuntu 16.04 上で OpenNebula 5.0.2 環境を実行しており、これは完璧に動作しています。

しかし、VM とそのホスト間で iperf3 帯域幅テストを実行すると、htop ではその VM を実行している qemu の CPU 負荷が 100 % と表示され、帯域幅を大量に消費する他の VM が実行されていないにもかかわらず、iperf3 は 100 ～ 200 Mbps しか得られません。2 つの VM ホスト間で iperf3 を実行すると、ほぼ 1 Gbps が得られ、CPU 負荷は発生しません。

まだ 2.0.2 を使用していた頃は、これは OpenvSwitch の問題だと思っていましたが、今では仮想ネットワークの最適化が欠落しているのではないかと考えています...

Answer 1

仮想ブリッジを経由する必要があるものはすべて、かなり大きな影響を受けます。これは、ovs と Linux ブリッジングに当てはまります。どちらも、どこに送信する必要があるかを判断するために、無差別モードでパケット検査を実行する必要があるためです (基本的には、レイヤー 2 スイッチ)。

10Gib イーサネットなどの高パフォーマンス シナリオでは、ホスト OS にレイヤー 2 で切り替えさせるよりも、srv-io デバイス パススルーを実行する方が賢明な場合があります。ただし、パスされたイーサネット カードを使用できるのは 1 つのゲストのみという欠点があります。PCI パススルーはネットワーク カードに非常に適しており、KVM / libvirt はこの点で優れています。

Macvtap は、オーバーヘッドをほとんどかけずに、srv-io PCI パススルーを使用せずに、トラフィックをゲスト VM に直接渡すこともできます (そのため、単一の VM にハードウェアを専用にする必要はありません)。Macvtap には、ホストからゲストへの通信、または同じハイパーバイザー内でのゲストからゲストへの通信さえも提供できないという制限があります (仮想スイッチ上の各ゲストに異なる MAC アドレスを使用するのではなく、ホストの同じ MAC アドレスを使用するため)。これを回避する 1 つの方法は、スイッチ レベルで「ヘアピン」を実行することです (スイッチがサポートしている場合)。これにより、デバイスは単一のポートと単一の MAC アドレスで一種のループバックを介して自分自身と通信できるようになります。

上で述べたいずれかの方法を使用する場合、ホストとゲストの相互通信では、高パフォーマンス通信に使用されない専用の追加のブリッジ ネットワークを提供するのが一般的です。これは、VM で >=10Gib イーサネットを使用する場合の非常に一般的な構成です。

Answer 2

私がうまく（そして簡単に、NICなどを交換することなく）適用できた大きな最適化の1つは、VMテンプレート内のすべてのNICに対して、または各NICごとに個別に、デフォルトでvirtioモデルを使用することです。ここ:

NIC_DEFAULT = [
  MODEL = "virtio" ]

すでにインスタンス化されている VM の場合は、シャットダウンし、すべての NIC を切断して、「virtio」モデルで再接続します。

最初のテストでは、ホストとゲスト間の iperf3 帯域幅が 5.6 Gbps に増加し、テスト中にホスト CPU 負荷が qemu スレッドごとに約 50 ～ 60 % に減少しました (Gbit 接続ホストから iperf3 クライアントを実行してほぼ 1 Gbps で 5 % 未満)。

さらなる最適化についてご存知の場合は、遠慮なく追加してください。