OpenNebula (KVM) + OpenvSwitch, alta carga de CPU en uso elevado de ancho de banda

Question

Estamos ejecutando un entorno OpenNebula 5.0.2 en Ubuntu 16.04, usando OpenvSwitch 2.5 para unir las interfaces virtuales y LACP para conectar los dos puertos Gbit, que funciona perfectamente.

Pero cuando ejecuto una prueba de ancho de banda de iperf3 entre una máquina virtual y su host, htop muestra una carga de CPU del 100 % para qemu ejecutando esa máquina virtual e iperf3 obtiene solo 100-200 Mbps, aunque no hay otras máquinas virtuales que requieran mucho ancho de banda en ejecución. iperf3 entre dos hosts de VM me proporciona casi 1 Gbps completo y sin carga de CPU.

Solía ​​creer que era un problema de OpenvSwitch cuando todavía estábamos en 2.0.2, pero ahora creo que faltan algunas optimizaciones de redes virtuales...

Answer 1

Todo lo que tenga que pasar por un puente virtual se verá afectado considerablemente. Esto es cierto para ovs y linux bridging, ya que ambos tienen que realizar una inspección de paquetes en modo promiscuo para determinar dónde deben ir las cosas (un conmutador de capa 2, esencialmente).

En escenarios de alto rendimiento, como con Ethernet de 10 Gib, a veces es prudente realizar la transferencia del dispositivo srv-io en lugar de permitir que el sistema operativo del host cambie a la capa 2. Esto tiene el inconveniente de que solo este invitado puede usar la Ethernet pasada. tarjeta. El paso PCI funciona muy bien para tarjetas de red y KVM/libvirt sobresale en esto.

Macvtap también puede pasar tráfico directamente a una máquina virtual invitada casi sin gastos generales y sin utilizar el paso PCI srv-io (por lo que no es necesario dedicar hardware a una sola máquina virtual). Macvtap está limitado porque nunca puede proporcionar comunicación de host a invitado, o incluso de invitado a invitado dentro del mismo hipervisor (ya que usa la misma dirección MAC de su host en lugar de usar una diferente para cada invitado a través de un conmutador virtual). ). Una forma de solucionar esto es realizar una "horquilla" a nivel del conmutador (si su conmutador lo admite), permitiendo que un dispositivo se comunique consigo mismo a través de una especie de bucle invertido en un único puerto y una única dirección MAC.

Para la intercomunicación entre host e invitados cuando se utiliza cualquiera de estos métodos que mencioné anteriormente, es común proporcionar una red puente adicional solo para aquella que no se utiliza para comunicaciones de alto rendimiento. En realidad, esta es una configuración muy común cuando se usa >=10Gib Ethernet en máquinas virtuales.

Answer 2

Una gran optimización que pude aplicar con éxito (y fácilmente, sin cambiar la NIC, etc.) fue usar el modelo virtio de forma predeterminada para todas las NIC en la plantilla de VM o para cada NIC por separado, como se describeaquí:

NIC_DEFAULT = [
  MODEL = "virtio" ]

Para una máquina virtual ya instanciada, apáguela, desconecte todas las NIC y vuelva a conectarlas con el modelo "virtio".

En mis primeras pruebas, aumentó el ancho de banda de iperf3 a 5,6 Gbps entre el host y el invitado y disminuyó la carga de la CPU del host a ~ 50-60 % por subproceso qemu durante la prueba (< 5 % a casi 1 Gbps ejecutando el cliente iperf3 desde un host conectado a Gbit).

Si conoce otras optimizaciones, ¡no dude en agregarlas!