Мы запускаем среду OpenNebula 5.0.2 на Ubuntu 16.04, используя OpenvSwitch 2.5 для соединения виртуальных интерфейсов и LACP-транкинг двух портов Gbit, который работает отлично.
Но когда я запускаю тест пропускной способности iperf3 между виртуальной машиной и ее хостом, htop показывает 100% загрузку процессора для qemu, на котором запущена эта виртуальная машина, а iperf3 получает только 100-200 Мбит / с, хотя других виртуальных машин, требующих высокой пропускной способности, нет. iperf3 между двумя виртуальными машинами дает мне почти полный 1 Гбит / с и не загружает процессор.
Раньше я полагал, что это проблема OpenvSwitch, когда мы все еще были на 2.0.2, но теперь я думаю, что отсутствуют некоторые оптимизации виртуальной сети ...
Одна огромная оптимизация, которую я мог успешно (и легко, без замены сетевой карты и т. Д.) Применить, заключалась в использовании модели virtio по умолчанию для всех сетевых адаптеров в шаблоне виртуальной машины или для каждой сетевой карты отдельно, как описано Вот:
NIC_DEFAULT = [
MODEL = "virtio" ]
Для уже созданной виртуальной машины выключите ее, отсоедините все сетевые адаптеры и повторно подключите их с помощью модели "virtio".
В моих первых тестах он увеличил пропускную способность iperf3 до 5,6 Гбит / с между хостом и гостем и снизил нагрузку на процессор хоста до ~ 50-60% на поток qemu во время теста (<5% при почти 1 Гбит / с при запуске клиента iperf3 с хоста, подключенного к Gbit).
Если вы знаете о дальнейших улучшениях, не стесняйтесь их добавлять!
Все, что проходит через виртуальный мост, получит довольно большой удар. Это верно для ovs и linux bridging, поскольку они оба должны выполнять проверку пакетов в беспорядочном режиме, чтобы определить, что нужно делать (по сути, коммутатор уровня 2).
В высокопроизводительных сценариях, таких как Ethernet 10Gib, иногда целесообразно выполнять сквозную передачу устройства srv-io вместо того, чтобы позволить ОС хоста переключаться на уровень 2. Это имеет недостаток, заключающийся в том, что только этот гость может использовать переданную сеть Ethernet. открытка. PCI passthrough отлично работает для сетевых карт, и KVM / libvirt в этом преуспевают.
Macvtap также может передавать трафик непосредственно на гостевую виртуальную машину почти без накладных расходов и без использования сквозной передачи srv-io PCI (так что вам не нужно выделять оборудование для одной виртуальной машины). Macvtap ограничен тем, что он никогда не может обеспечить связь между хостом и гостем или даже между гостем и гостем в пределах одного гипервизора (поскольку он использует тот же MAC-адрес вашего хоста, а не использует другой для каждого гостя через виртуальный коммутатор. ). Один из способов обойти это - выполнить «закрепление» на уровне коммутатора (если ваш коммутатор его поддерживает), позволяя устройству взаимодействовать с самим собой через своего рода петлю на одном порту и одном MAC-адресе.
Для взаимодействия хоста и гостя при использовании любого из этих методов, упомянутых выше, обычно предоставляют дополнительную мостовую сеть только для той, которая не используется для высокопроизводительной связи. На самом деле это очень распространенная конфигурация при использовании> = 10Gib Ethernet на виртуальных машинах.