OpenNebula (KVM) + OpenvSwitch, alta carga de CPU em alto uso de largura de banda

Question

Estamos executando um ambiente OpenNebula 5.0.2 no Ubuntu 16.04, usando OpenvSwitch 2.5 para fazer a ponte entre as interfaces virtuais e entroncamento LACP nas duas portas Gbit, que está funcionando perfeitamente.

Mas quando executo um teste de largura de banda iperf3 entre uma VM e seu host, htop mostra 100% de carga de CPU para qemu executando essa VM e iperf3 obtém apenas 100-200 Mbps, mesmo que não haja outras VMs com alta demanda de largura de banda em execução. iperf3 entre dois hosts VM me dá quase 1 Gbps completo e nenhuma carga de CPU.

Eu costumava acreditar que era um problema do OpenvSwitch quando ainda estávamos no 2.0.2, mas agora acho que faltam algumas otimizações de rede virtual...

Answer 1

Qualquer coisa que precise passar por uma ponte virtual sofrerá um grande golpe. Isso é verdade para ovs e linux bridging, já que ambos precisam realizar inspeção de pacotes em modo promíscuo para determinar para onde as coisas precisam ir (essencialmente, um switch de camada 2).

Em cenários de alto desempenho, como com Ethernet de 10Gib, às vezes é prudente executar a passagem do dispositivo srv-io em vez de deixar o sistema operacional host alternar para a camada 2. Isso tem a desvantagem de que apenas este convidado pode usar a Ethernet passada cartão. A passagem PCI funciona extremamente bem para placas de rede, e KVM/libvirt se destaca nisso.

O Macvtap também pode passar o tráfego diretamente para uma VM convidada quase sem sobrecarga e sem usar passagem PCI srv-io (para que você não precise dedicar hardware a uma única VM). O Macvtap é limitado porque nunca pode fornecer comunicação de host para convidado, ou mesmo de convidado para convidado dentro do mesmo hipervisor (uma vez que usa o mesmo endereço MAC do seu host em vez de usar um diferente para cada convidado em um switch virtual ). Uma maneira de contornar isso é realizar "hairpinning" no nível do switch (se o seu switch suportar), permitindo que um dispositivo se comunique consigo mesmo por meio de uma espécie de loopback em uma única porta e um único endereço MAC.

Para intercomunicação entre host e convidado ao usar qualquer um dos métodos mencionados acima, é comum fornecer uma rede em ponte adicional apenas para aquela que não é usada para comunicações de alto desempenho. Na verdade, essa é uma configuração muito comum ao usar Ethernet >=10Gib em VMs.

Answer 2

Uma grande otimização que pude aplicar com sucesso (e facilmente, sem trocar a NIC etc.) foi usar o modelo virtio por padrão para todas as NICs no modelo VM ou para cada NIC separadamente, conforme descritoaqui:

NIC_DEFAULT = [
  MODEL = "virtio" ]

Para uma VM já instanciada, desligue-a, desconecte todas as NICs e reconecte-as com o modelo "virtio".

Em meus primeiros testes, aumentou a largura de banda do iperf3 para 5,6 Gbps entre host e convidado e diminuiu a carga da CPU do host para ~ 50-60% por thread qemu durante o teste (<5% @ quase 1 Gbps executando o cliente iperf3 de um host conectado de Gbit).

Se você souber de outras otimizações, fique à vontade para adicioná-las!