OpenNebula (KVM) + OpenvSwitch,高頻寬使用下的高 CPU 負載

OpenNebula (KVM) + OpenvSwitch,高頻寬使用下的高 CPU 負載

我們在 Ubuntu 16.04 上運行 OpenNebula 5.0.2 環境,使用 OpenvSwitch 2.5 橋接虛擬介面並使用 LACP 中繼兩個 Gbit 端口,運行完美。

但是,當我在虛擬機器及其主機之間執行iperf3 頻寬測試時,htop 顯示運行該虛擬機的qemu 的CPU 負載為100%,而iperf3 僅獲得100-200 Mbps,即使沒有其他高頻寬需求的虛擬機在運轉。兩個 VM 主機之間的 iperf3 幾乎可以達到 1 Gbps,且沒有 CPU 負載。

當我們還在使用 2.0.2 時,我曾經認為這是一個 OpenvSwitch 問題,但現在我認為這是缺少一些虛擬網路優化......

答案1

任何必須通過虛擬橋的事情都會受到相當大的打擊。 ovs 和 linux 橋接也是如此,因為它們都必須在混雜模式下執行封包檢查,以確定事物需要去往何處(本質上是第 2 層交換器)。

在高效能場景中,例如10Gib 以太網,有時明智的做法是執行srv-io 設備直通,而不是讓主機作業系統在第2 層上切換。的乙太網路卡。 PCI 直通對於網路卡來說效果非常好,KVM / libvirt 在這方面表現出色。

Macvtap 還可以將流量直接傳遞到來賓虛擬機,幾乎沒有任何開銷,並且無需使用 srv-io PCI 直通(因此您不必將硬體專用於單一虛擬機)。 Macvtap 的限制在於它永遠無法提供主機到來賓通信,甚至無法在同一虛擬機管理程式中提供來賓到來賓通信(因為它使用主機的相同MAC 位址,而不是透過虛擬交換器為每個來賓使用不同的MAC 位址) )。解決這個問題的一種方法是在交換器層級執行「髮夾」(如果您的交換器支援),允許設備透過單一連接埠和單一 MAC 位址上的某種環回與自身進行通訊。

對於使用上面提到的這些方法中的任何一種的主機和來賓相互通信,通常只為不用於高效能通信的網路提供額外的橋接網路。在虛擬機器上使用 >=10Gib 乙太網路時,這實際上是一種非常常見的配置。

答案2

我可以成功(並且輕鬆地,無需交換網卡等)應用的一項巨大優化是默認對虛擬機模板中的所有網卡或單獨對每個網卡使用 virtio 模型,如下所述這裡

NIC_DEFAULT = [
  MODEL = "virtio" ]

對於已經實例化的 VM,將其關閉,分離所有 NIC,然後使用“virtio”模型重新附加它們。

在我的第一次測試中,它將主機和來賓之間的iperf3 頻寬增加到5.6 Gbps,並將測試期間每個qemu 線程的主機CPU 負載降低到約50-60%(< 5% @ 幾乎1 Gbps 從Gbit 連線的主機執行iperf3 用戶端)。

如果您知道進一步的優化,請隨時添加!

相關內容