OpenNebula (KVM) + OpenvSwitch, hohe CPU-Auslastung bei hoher Bandbreitennutzung

Question

Wir betreiben eine OpenNebula 5.0.2-Umgebung auf Ubuntu 16.04 und verwenden OpenvSwitch 2.5 zum Überbrücken der virtuellen Schnittstellen und LACP-Trunking der beiden Gbit-Ports, was perfekt funktioniert.

Aber wenn ich einen iperf3-Bandbreitentest zwischen einer VM und ihrem Host ausführe, zeigt htop 100 % CPU-Auslastung für QEMU, auf dem diese VM läuft, und iperf3 erreicht nur 100–200 Mbit/s, obwohl keine anderen VMs mit hohem Bandbreitenbedarf laufen. iperf3 zwischen zwei VM-Hosts erreicht bei mir fast die vollen 1 Gbit/s und keine CPU-Auslastung.

Als wir noch bei 2.0.2 waren, habe ich immer geglaubt, dass es ein OpenvSwitch-Problem war, aber jetzt glaube ich, dass einige virtuelle Netzwerkoptimierungen fehlen ...

Answer 1

Alles, was über eine virtuelle Brücke laufen muss, wird ziemlich hart getroffen. Das gilt für OVS und Linux-Bridging, da beide eine Paketprüfung im Promiscuous-Modus durchführen müssen, um zu bestimmen, wohin die Dinge gehen müssen (im Wesentlichen ein Layer-2-Switch).

In Hochleistungsszenarien, wie z. B. mit 10-Gigabit-Ethernet, ist es manchmal ratsam, SRV-IO-Geräte-Passthrough durchzuführen, anstatt das Host-Betriebssystem auf Layer 2 umschalten zu lassen. Dies hat den Nachteil, dass nur dieser eine Gast die übergebene Ethernet-Karte verwenden kann. PCI-Passthrough funktioniert bei Netzwerkkarten sehr gut, und KVM/libvirt ist hier hervorragend.

Macvtap kann den Datenverkehr auch fast ohne Overhead und ohne Verwendung von srv-io PCI-Passthrough direkt an eine Gast-VM weiterleiten (Sie müssen also keine Hardware für eine einzelne VM reservieren). Macvtap ist insofern eingeschränkt, als es niemals Host-Gast-Kommunikation oder sogar Gast-Gast-Kommunikation innerhalb desselben Hypervisors bereitstellen kann (da es dieselbe MAC-Adresse Ihres Hosts verwendet, anstatt für jeden Gast über einen virtuellen Switch eine andere zu verwenden). Eine Möglichkeit, dies zu umgehen, besteht darin, „Hairpinning“ auf Switch-Ebene durchzuführen (sofern Ihr Switch dies unterstützt), wodurch ein Gerät über eine Art Loopback auf einem einzelnen Port und einer einzelnen MAC-Adresse mit sich selbst kommunizieren kann.

Für die Kommunikation zwischen Host und Gast wird bei Verwendung einer der oben genannten Methoden häufig ein zusätzliches überbrücktes Netzwerk bereitgestellt, das nicht für Hochleistungskommunikation verwendet wird. Dies ist tatsächlich eine sehr gängige Konfiguration bei Verwendung von >=10Gib Ethernet auf VMs.

Answer 2

Eine große Optimierung, die ich erfolgreich (und einfach, ohne Austausch der Netzwerkkarte etc.) anwenden konnte, war die Verwendung des Virtio-Modells standardmäßig für alle Netzwerkkarten in der VM-Vorlage oder für jede Netzwerkkarte separat, wie beschriebenHier:

NIC_DEFAULT = [
  MODEL = "virtio" ]

Fahren Sie eine bereits instanziierte VM herunter, trennen Sie alle Netzwerkkarten und verbinden Sie sie mit dem Modell „virtio“ erneut.

Bei meinen ersten Tests erhöhte es die iperf3-Bandbreite zwischen Host und Gast auf 5,6 Gbit/s und verringerte die CPU-Last des Hosts während des Tests auf ~ 50–60 % pro QEMU-Thread (< 5 % bei fast 1 Gbit/s beim Ausführen des iperf3-Clients von einem über Gbit/s verbundenen Host).

Wenn Sie weitere Optimierungen kennen, fügen Sie diese gerne hinzu!