VirtIO или SR-IOV. Взгляд Mellanox

Сравнение двух техник виртуализации сетевого интерфейса: VirtIO или SR-IOV
Перевод. Оригинал статьи: https://www.facebook.com/MellanoxTech/photos/download-the-free-wp-sr-iov-vs-virtio-comparison-of-two-ovsvrouter-acceleration-/10157144535384117/

В статье, подготовленной специалистами компании Mellanox, рассматриваются достоинства и недостатки двух технологий виртуализации сетевого интерфейса в применении с аппаратными ускорителями — VirtIO и SR-IOV.

Обзор

Виртуализация вычислительных, сетевых ресурсов и ресурсов хранения имеет решающее значение для обеспечения гибкости и масштабируемости центров обработки данных. Часто для достижения этой гибкости в жертву приносятся производительность и эффективность. Виртуализация традиционно выполняется программным обеспечением, которое потребляет ресурсы центрального процессора. В частности, виртуализация ввода / вывода может вызвать большую паразитную нагрузку на процессоры, поскольку они должны обрабатывать каждый пакет передаваемых и принимаемых данных.

Возможны три различных реализации виртуализации:

  • Только программное обеспечение
  • Полное аппаратное ускорение
  • Гибридный подход

Лучшие примеры реализации сегодня:

  • VirtIO
  • SR-IOV Ускоренная коммутация и пакетная обработка (ASAP2)
  • Гибрид, сочетающий в себе VirtIO и SR-IOV

VirtIO

VirtIO в настоящее время является самым распространенным программным интерфейсом виртуализации ввода-вывода, позволяющий драйверам гостевых устройств представлять общий программный интерфейс для блочных и сетевых устройств. Приложения, работающие на виртуальных машинах, не должны знать о базовом физическом оборудовании. К сожалению, как программный подход к паравиртуализации, он имеет несколько недостатков:

  • низкая производительность;
  • низкая эффективность;
  • аппаратное ускорение VirtIO предлагает только низкоуровневые интерфейсы, которые ограничивают функциональность;
  • аппаратное ускорение VirtIO виртуализирует не все функциональные возможности оборудования. Это приводит к зависимости от его конкретного производителя.

SR-IOV

SR-IOV преодолевает большинство из этих ограничений, но имеет два недостатка:

  • Некоторые важные функции, такие как миграция виртуальных машин, еще не поддерживаются всеми операционными системами.
  • Виртуальные машины и приложения должны быть адаптированы для использования преимуществ ускорителей виртуализации.

Ни один из этих недостатков не свойственен аппаратному ускорению на основе SR-IOV. Например, Microsoft уже решила проблему оперативной миграции для операционной системы Windows Server и разрешает миграцию виртуальных машин, которые используют полностью ускоренный ввод-вывод SR-IOV. Программное обеспечение, обеспечивающее миграцию виртуальных машин, находится в разработке в сообществе открытого исходного кода и скоро станет доступным в последующих коммерческих дистрибутивах. Точно так же функциональность более высокого уровня стандартизируется для таких функций, как качество обслуживания (Linux tc_flower API), работа в сети (ESXi, Nuage, Contrail и т. д.), Хранение (NFV через Fabrics, RDMA) и безопасность. Разрабатывается все больше приложений и виртуализированных сетевых функций, которые используют преимущества этих интерфейсов с возможностью прозрачного использования аппаратного ускорения.

Аппаратное ускорение на основе SR-IOV обеспечивает наилучшую производительность и эффективность, а также более высокий уровень функциональности. В то же время, широкое внедрение VirtIO означает, что многие уже написанные приложения должны быть адаптированы для использования интерфейса SR-IOV. Таким образом, сегодня нет единственного «лучшего» решения для виртуализации ввода / вывода. Скорее, лучший вариант заключается в принятии гибридного подхода, который позволяет отдельным приложениям использовать любой тип интерфейса. Приложения, ориентированные на производительность, используют преимущества ускорения SR-IOV. В то же время приложения с меньшим объемом данных могут использовать существующее программное обеспечение с интерфейсом VirtIO. Как вариант — гибридный подход с API-интерфейсами, поддерживающими высокоуровневую функциональность и ускорение в сочетании с низкоуровневыми интерфейсами VirtIO или SR-IOV. Сетевые решения должны иметь возможность поддерживать все это независимо и одновременно, поскольку гибридная модель развивается.

Эволюция облачных дата-центров

Облачные центры обработки данных поддерживают множество различных приложений, многие из которых не требуют высокой производительности. Серверы можно разделить на следующие три категории приложений:

  • Вычислительные узлы: создание виртуальных машин для запуска приложений, являющихся частью эластичного облачного сервиса.
  • Сетевые узлы: запуск сетевых функций, таких как балансировка нагрузки (на основе L4 или L7), IPS / Firewall, Anti-DDoS и т. д.
  • Узлы хранения: распределенное хранилище, определяемое программным обеспечением.

Во всех случаях важна эффективность. Высокопроизводительные сети часто могут давать косвенные преимущества даже для приложений, которые сами по себе не требуют высокой производительности. Например, высокопроизводительная сеть может позволить вычислительным узлам поддерживать более чувствительные к задержке виртуальные машины и, таким образом, обеспечить значительную экономию средств. В целом, сетевые узлы и узлы хранения предъявляют самые высокие требования к производительности, и они получили самое раннее и самое широкое развертывание 100G сетей в облачных дата-центрах. Для узлов, нуждающихся в максимальной пропускной способности, лучшим выбором являются собственные драйверы SR-IOV.

Развертывание виртуальных вычислительных узлов стало обычным явлением в облачных и корпоративных дата-центрах. К сожалению, виртуальные коммутаторы на основе ядра (например, Open vSwitch или OVS) могут обеспечить пропускную способность только 200 Кбит / с. Основанный на DPDK vSwitch (OVS-DPDK) с интерфейсом VirtIO может обеспечить более высокую производительность до 7,5 Мбит / с, но при этом полностью загружаются 2 физических ядра центрального процессора. Обеспечивается улучшение в 25 раз. Этого достаточно для удовлетворения требований к пропускной способности многих пользователей. Однако, OVS-DPDK улучшает производительность за счет снижения эффективности использования вычислительной мощности и увеличения капитальных затрат. Масштабирование производительности приложения DPDK пропорционально количеству выделенных ядер ЦП. Выделение большего количества ядер для обработки пакетов означает меньшее количество доступных ядер для запуска приложений. Облачные провайдеры стремятся к максимальной эффективности своих центров обработки данных, их доход прямо пропорционален количеству сдаваемых в аренду виртуальных машин. Таким образом, программно-управляемое ускорение, связанное с загрузкой ЦП, снижает общую эффективность инфраструктуры центра обработки данных.

Тенденции развития технологий сетевых адаптеров Ethernet

Скорость Ethernet растет быстрее, чем растут возможности процессора. Существующие программные и аппаратные интерфейсы были недостаточно хороши для масштабирования пропорционально с улучшениями центрального процессора. Поставщики оборудования внедрили множество нововведений в свои драйверы для решения проблем оптимизации скорости передачи пакетов, пропускной способности, снижения задержки и разгрузки ЦП. Драйверы постоянно переписываются и оптимизируются, в аппаратное обеспечение добавляются новые функции. Программно-аппаратный интерфейс NIC также постоянно обновлялся из поколения в поколение. Двигаясь вперед, мы убеждены, что для адекватного решения проблем, связанных с высокими требованиями к приложениям, необходимо использовать аппаратные возможности интерфейсных карт. Интерфейс Ethernet NIC должен позволить производителям оборудования продолжать инновации для обеспечения наилучшей производительности. Правильный способ абстрагирования оборудования находится на уровне драйвера ОС. Использование аппаратного API «отраслевого стандарта», связанного с программным интерфейсом, таким как VirtIO, означает огромный компромисс в производительности, масштабируемости и гибкости.

Потребность в производительности огромна. От драйверов Ethernet ожидется производительность на уровне сотен миллионов пакетов в секунду. Ограничения интерфейса для хранения данных NVMe оправданы, однако они на порядок снижают производительность, что приводит к гораздо более низкой скорости ввода-вывода. Стандартизация аппаратных / программных интерфейсов для массовых потребителей, безусловно, необходима, но когда вам нужно иметь дело с гораздо более высокими скоростями — стандарты не успевают за растущими потребностями.

Сегодня собственные драйверы или драйверы SR-IOV являются единственным способом достижения максимальной производительности, не затрагивающим ядер ЦП.

Что такое ускорение VirtIO?

Рисунок 1: Архитектура ускорения VirtIO
Рисунок 1: Архитектура ускорения VirtIO

VirtIO — это стандартный программный интерфейс для виртуального представления одного физического устройства на нескольких виртуальных машинах. Текущие реализации VirtIO требуют, чтобы гипервизор (также известный как VirtIO backend vhost) обрабатывал запрос VirtIO, отправляемый виртуальной машиной (внешний интерфейс VirtIO), для связи с физическим драйвером NIC, который потребляет ресурсы процессора. Архитектура VirtIO с аппаратным ускорением подразумевает, что серверная часть (по крайней мере, путь к данным) реализована аппаратно, что освобождает ресурсы гипервизора для возможного достижения более высокой скорости передачи пакетов. Методы аппаратного ускорения VirtIO, такие как vDPA (ускорение виртуальной плоскости данных), заблокированы и являются специфическим механизмом ускорения стандартного API программного обеспечения virtio. Эта техника, хотя и интересная, имеет свои достоинства и недостатки.

Преимущества VirtIO

Ниже приведены преимущества VirtIO API:

  • Универсальный драйвер VirtIO в ВМ
  • Независимость от производителя оборудования, так как это программный API
  • Достаточно хорошая производительность
    • Выше, чем не ускоренный VirtIO
    • Гораздо ниже, чем IHV VF для SR-IOV
  • Уменьшенная загрузка ЦП для эмуляции NIC
  • Поддержка живой миграции

Интерфейс VirtIO был разработан и реализован в программном обеспечении, но можно добиться некоторого ускорения этого API в аппаратном обеспечении. Однако из-за низкоуровневой программной природы VirtIO он не сможет достичь той же производительности и эффективности, что и собственные аппаратные интерфейсы виртуализации, такие как SR-IOV. VirtIO может развиваться для улучшения производительности и более высоких уровней функциональности, но это развитие должно идти по тому же пути, что прошел существующий SR-IOV, и потребует разработки API-интерфейсов, которые поддерживают ускорение с более высоким уровнем функциональности.

Ряд проблем, которые необходимо преодолеть для развития VirtIO описан ниже.

Стандарт ускорения VirtIO развивается

Virtio Acceleration ни в коем случае не является отраслевым стандартом. В настоящее время это инициатива одного поставщика, и поскольку интерфейс был разработан как чисто программный API, он не идеален для аппаратного ускорения. Спецификация ускорения VirtIO вряд ли будет соответствовать скорости Ethernet следующего поколения и может стать узким местом. Спецификация VirtIO меняется и ясно указывает на то, что существующее программное обеспечение VirtIO не подходит ни в качестве стандартного драйвера, ни в качестве интерфейса для аппаратного ускорения.

Ниже приведены различные версии спецификаций ускорения VirtIO и проблемы с каждой из них:

1. VirtIO 0.95 устарело. Аппаратное ускорение не может быть полностью ускорено, поскольку оно обменивается данными через PIO (требуется некоторое вмешательство в гипервизор).

2. VirtIO 1.0 определяет, как более старые драйверы, использующие 0.95, могут опционально поддерживаться новыми устройствами. Самое главное, VirtIO 1.0 добавляет поддержку пространства памяти PCI. Это потенциально позволяет гостевому драйверу обмениваться данными с аппаратным устройством, однако это не так просто, как кажется. Основная структура / протокол, используемый для разделения, довольно сложна и включает много операций чтения / записи PCI. VirtIO1.0 входит в стандартный дистрибутив Linux, такой как Red Hat Enterprise Linux 7.2, с апреля 2014 года и до сих пор не получил широкого распространения из-за узких мест PCI.

3. Спецификация VirtIO 1.1 расширяет 1.0, но полностью обратно совместима (с использованием битов возможностей). Она все еще находится в стадии разработки и не выпущена официально. VirtIO 1.1 представляет упакованную оптимизацию virtqueue, которая более проста и требует меньше операций чтения / записи PCI. Это позволяет повысить производительность, особенно для аппаратного обеспечения. Она также вводит биты возможностей, необходимые для согласования с оборудованием:

  • IOMMU (контролирует, выполняет ли гость карту DMA)
  • Барьер DMA — определяет, будут ли гостевые системы создавать сильные барьеры для синхронизации записи на аппаратное устройство ввода-вывода.

Подводя итог, можно сказать, что VirtIO 1.1 явно поддерживает связь с оборудованием в отличие от VirtIO 1.0. Следовательно, все сводится к тому, могут ли НОВЫЕ бэкэнд-драйверы гипервизора вводить механизмы, обеспечивающие корректную работу для гостей, использующих драйверы СУЩЕСТВУЮЩИЕ — различные поколения реализаций VirtIO в ядре Linux, DPDK, Windows и т. д.

Ускорение VirtIO требует определенных манипуляций

Драйвер VirtIO включен в исходные ядра и во многие дистрибутивы Linux, включая Red Hat Enterprise Linux, CentOS, Canonical, Ubuntu, Suse и т. д. Нет необходимости в его дополнительной установке. Архитектура Mellanox обеспечивает обратную и прямую совместимость драйвера ОС с оборудованием, развернутым на сервере. Драйвер доступен из коробки вместе с лучшими в отрасли показателями для SR-IOV. Для любых новых функций, которые недоступны в восходящем потоке, Mellanox поддерживает механизм OFED для обработки таких исключений.

В отличие от SR-IOV, VirtIO Acceleration не поддерживается по умолчанию всеми операционными системами. Якобы стандартный драйвер VirtIO должен быть изменен, чтобы соответствовать конкретному оборудованию. Следовательно, для развертывания решения VirtIO вам необходимо изменить ОС и установить такой драйвер.

VirtIO Acceleration не зависит от оборудования

Проблемы взаимодействия с оборудованием обычно решаются путем написания собственных драйверов. Эти драйверы не только оптимизируют производительность, но также могут работать с микропрограммным обеспечением, которое является частью каждого аппаратного устройства. Ограничение программного интерфейса VirtIO в доступе к оборудованию не позволяет поставщикам устройств обновлять встроенное программное обеспечение. Тем самым, повышается риск выхода из строя определенные устройства в полевых условиях и ставится под угрозу работоспособность системы, ее производительность и безопасность.

Для ускорения VirtIO требуется поддержка живой миграции

Поддержка динамической миграции для любого аппаратного ускорителя (оборудование Intel VirtIO, оборудование Mellanox VirtIO, Mellanox SR-IOV, Intel SR-IOV и т. Д.) требует проверки:
1. Last_used_idx — состояние серверной части.
2. Dirty_used_ring_bitmap — это запрос временной страницы. Поскольку согласование зависит от устройства, оно потребует реализации для конкретного устройства (следовательно, нестандартной).

Мы можем логически разделить поддержку VirtIO для живой миграции на три части:

1. Внешняя память virtq и сохранение / восстановление состояния. Поддержка миграции действительно сохраняется без проблем при работе с VirtIO с аппаратным ускорением.

2. Сохранение / восстановление состояния серверной части virtq. Хотя сами очереди находятся в памяти и, таким образом, мигрируют вместе с другим состоянием виртуальной машины, серверная часть VirtIO также поддерживает внутренние состояния (такие как смещения LRO, смещения объединяемых буферов RX, счетчик переноса очереди пакетов). В решении с аппаратным ускорением qemu не знает об этих внутренних состояниях, и ему нужно будет запросить ускоренное устройство. В этом отношении решение VirtIO с аппаратным ускорением потребует такого же дополнительного протокола для аппаратного устройства VirtIO, что и решение SR-IOV.

3. Отслеживание временных страниц. Гипервизор не осведомлен о страницах, записываемых аппаратным ускорителем. Восстановление информации о временных страницах для решения VirtIO с аппаратным ускорением требует такого же (зависящего от устройства) дополнительного протокола, который потребуется для решения SR-IOV.

Таким образом, поддержку динамической миграции в OVS необходимо связать с аппаратным ускорением (на основе SR-IOV или vDPA). vDPA не решит проблему динамической миграции только потому, что ускоряет традиционный интерфейс virtio. Живая миграция одинаково зависима от оборудования как для vDPA, так и для SR-IOV. Обратите внимание, что поддержка живой миграции для VirtIO Acceleration не является стандартной, в отличие от заявлений конкурентов в отрасли. Лучшее, что мы можем сделать, — это подготовить общую среду динамической миграции с использованием методов ускорения VirtIO и SR-IOV.

VirtIO Acceleration не встроена в гипервизор

Почти все преимущества VirtIO выглядят убедительно по сравнению с SR-IOV, однако это не так.

VirtIO — стандартный интерфейс.
• Он был разработан как программный интерфейс и, следовательно, еще не стандартизирован для оборудования. Он все еще развивается.

VirtIO сейчас есть во всех дистрибутивах Linux.
• Да, однако весьма вероятно, что он не будет работать из коробки для оборудования ускорения VirtIO.
• Драйверы Mellanox также имеют статический интерфейс virtio и уже несколько лет входят в стандартные дистрибутивы Linux. Они также не будут работать с любым оборудованием для ускорения VirtIO из коробки.

VirtIO не требует установки SR-IOV в BIOS и не ограничивается несколькими VF.
• Даже если VirtIO не нужно настраивать VF для создания интерфейсов vNIC, все равно потребуется создавать кольца дескрипторов для каждого из интерфейсов VirtIO. Аппаратному обеспечению по-прежнему потребуются возможности для поддержки каждого программного интерфейса VirtIO, привязанного к аппаратным ресурсам. Не имеет значения, где выполняется эта конфигурация. Кроме того, у любого оборудования есть ограничения по масштабированию, что справедливо и для оборудования ускорения VirtIO.

VirtIO поддерживает живую миграцию
• Это верно при запуске VirtIO на гипервизоре, поскольку гипервизор может отслеживать временные страницы. Однако после аппаратной разгрузки необходимо добавить дополнительные механизмы для отслеживания записи устройством DMA. Следовательно, поддержка живой миграции непрозрачна. Эти проблемы уже решены в других аппаратных интерфейсах, таких как SR-IOV.

В конечном итоге, аппаратное ускорение VirtIO обязательно проследует по тому же пути, который уже пройден существующими интерфейсами и которые были разработаны с учетом аппаратного ускорения. При этом Mellanox рассматривает возможность повышения производительности программного интерфейса VirtIo за счет аппаратного ускорения.

Ускорение на базе SR-IOV

Новые технологии, такие как виртуализация сетевых функций (NFV) и другие варианты использования облачных вычислений, чувствительных к производительности, требуют высокой пропускной способности, скорости обработки пакетов, низкой и детерминированной задержки для устройств плоскости данных. Поскольку практически весь трафик виртуальных машин сначала обрабатывается объектом коммутации хоста, это подразумевает очень высокую нагрузку на ЦП локального хоста, реализующего программный виртуальный коммутатор. Следовательно, традиционный способ предоставления сетевого доступа виртуальным машинам не соответствует требованиям к высокой производительности.

SR-IOV — это спецификация PCI-SIG, которая позволяет одному физическому устройству представляться несколькими виртуальными устройствами для программного обеспечения более высокого уровня. Эти виртуальные устройства можно безопасно назначать гостевой виртуальной машине, предоставляя им прямой доступ к оборудованию. Использование аппаратного ускорения виртуализации напрямую снижает нагрузку на ЦП и приводит к повышению производительности системы.

Ускорение SR-IOV высвобождает ресурсы гипервизора, однако в реализации на основе SR-IOV виртуальная машина взаимодействует напрямую с физическим устройством. При этом используется собственный интерфейс физического устройства, предоставляемый поставщиком оборудования. SR-IOV — это отраслевой стандарт для ускорения решений хранения данных, включая RDMA, NVMe-over-Fabrics и сетевые решения, включая DPDK и ASAP2 OVS Offloads.

Технология ускоренной коммутации и обработки пакетов (ASAP2) Mellanox использует преимущества SR-IOV для значительного ускорения канала передачи данных виртуального коммутатора, освобождая ядра ЦП для выполнения приложений и других рабочих нагрузок. Пути управления API остаются неизменными, что обеспечивает прозрачную поддержку существующих программно-определяемых сетевых контроллеров (SDN).

Рисунок 2: Блок-схема разгрузки OVS с использованием режима ASAP2 SR-IOV
Рисунок 2: Блок-схема разгрузки OVS с использованием режима ASAP2 SR-IOV

Как показано на рисунке 2, виртуальные машины устанавливают прямой доступ к оборудованию Mellanox ConnectX-5 NIC через виртуальную функцию (VF) Single Root IO Virtualization (SR-IOV) для достижения максимальной производительности сетевого ввода-вывода в виртуализированной среде. Одна из проблем, связанных с устаревшей реализацией SR-IOV, заключается в том, что она полностью обходит гипервизор и виртуальный коммутатор. При этом, виртуальный коммутатор не знает о существовании виртуальных машин в режиме SR-IOV. В результате, плоскость управления SDN не может влиять на решения о пересылке для этих виртуальных машин. Основанная на стандартах технология разгрузки OVS, такая как ASAP2, решает эту проблему за счет переноса операций обработки пакетов с виртуального коммутатора и медленного пути данных virtio к электронному коммутатору ConnectX и более быстрой плоскости пересылки SR-IOV. При перемещении пути данных от virtio к SR-IOV, ASAP2 позволяет OVS по-прежнему программировать конвейер плоскости данных электронного коммутатора. Происходит это через стандартный открытый поток, такой как управление SDN. ASAP2 использует драйверы SR-IOV, которые присутствуют во всех основных дистрибутивах Linux. Посему, клиенты могут воспользоваться преимуществами более быстрой обработки пакетов при одновременном высвобождении ресурсов ЦП. Таким образом, достигается максимальная эффективность облачного центра обработки данных.

Поддержка живой миграции для SR-IOV

Для SR-IOV выполняется живая миграция. Живая миграция не уникальна для VirtIO, она также может поддерживаться для устройств SR-IOV. Фактически, в операционной системе Windows он поддерживается в течение многих лет и был развернут крупными поставщиками облачных услуг. Процесс миграции включал переход от собственного драйвера к эмуляции на очень ограниченное время и переключение обратно на драйвер. Это все, что необходимо для перехода на драйвер SR-IOV и получения максимальной производительности.

Преимущества аппаратного ускорения SR-IOV

Ниже приведены основные преимущества ускорения SR-IOV:

1. Производительность «чистого металла» (BW, PPS, Latency)
• Уникальные инновационные функции IHV

2. Родной драйвер IHV в ВМ
• Аппаратный интерфейс полностью прямо- и обратно- совместим, начиная с ConnectX-4

3. Нулевое использование ЦП для эмуляции сетевой карты.
• Родной сетевой адаптер открыт для виртуальной машины

4. Поддержка живой миграции

Сравнение производительности

Этот раздел отличается от оригиналбного, содержащего красивые, но несколько «маркетинговые» графики c неточностями и ошибками.

Тесты производительности по данным dpdk.org

Регулярно обновляющиеся результаты тестов публикуются здесь: https://core.dpdk.org/perf-reports/
Здесь использованы данные из отчета Release 20.05 (май 2020 года).

Для составления DPDK Vhost/Virtio Performance Report проводятся тесты по двум схемам, характеризующим производительность и масштабируемость «по вертикали» — схема устройство — виртуальная машина — устройство Phy-VM-Phy или PVP (Рис. 1)
и «по горизонтали» — схема виртуальная машина — виртуальная машина в пределах одного хоста Vhost VM to VM или VM2VM (Рис. 2)

Рис. 1. Схема тестирования PVP
Рис. 2. Схема тестирования VM2VM

В Таблице 1 и на графике (Рис. 3) приведенна пропускная способность по схеме PVP в мегапакетах/с (Mpps) для двух версий Virtio — 1.0 (Split Ring) и 1.1 (Packet Ring). Для сравнения добавлена теоретически возможная скорость 40-гигабитной линии.

Размер пакета (байт)Скорость передачи по линии 40G (Mpps)Пропускная способность (Mpps)
Split Ring (v 1.0)
Пропускная способность (Mpps)
Packet Ring (v 1.1)
6459,527,618,77
12833,7836,648,27
25618,1165,416,57
5129,3983,734,93
10244,7892,783,31
12803,8462,482,99
15183,2512,232,77
Таблица 1
Рис. 3 Производительность

Производительность по схеме VM2VM составляет 43.4Гигабит/с

Преимущество ускорения SR-IOV

Этот пункт заимствован из оригинальной статьи.
Приведены проверенные заказчиком показатели производительности, а не смоделированные числа (источник данных не выявлен).

Скорость передачи пакетов: для размера пакета 64 Б

SR-IOV показало преимущество в пропускной способности в 8,5 раз по сравнению с DPDK Vhost/Virtio при полной (!) разгрузке ЦП в отличие от DPDK Vhost/Virtio, полностью занимающей 2 ядра ЦП.

Сравнительные данные по загрузке центрального процессора для двух технологий виртуализации приведены на следующей диаграмме. График несколько противоречит приведенному выше.

Производительность: Линейная пропускная способность для пакета размером 1500 Байт

Пропускная способность OVS VirtIO не превышает 30 Гбит / с из-за ограничений программного интерфейса Virtio.

Разгрузка ASAP2 OVS, которая использует ускорение пути данных SR-IOV, почти линейно масштабируется до скорости 91 Гбит / с (на сетевом адаптере ConnectX-5 100 Гбит / с). Скорость передачи пакетов достигает 66 миллионов пакетов в секунду для пакетов размером 64 байта без использования ЦП для обработки пакетов.

Сравнительная таблица SR-IOV и VirtIO

SR-IOV AccelerationVirtIO Acceleration
СтандартизацияSR-IOV PCIe StandardНет отраслевой привязки к версии
(Началось как стандарт сообщества с 0.95, текущая 1.0. Новая версия 1.1 находится в разработке)
Совместимость с интерфейсом оборудованияПрямая и обратная совместимость PF и VF начиная с ConnectX-4не известно
Поддержка распространенияMellanox «из коробки», ConnectX-5 и вышеОтсуствует
Применимый сетевой адаптерMellanox NICУниверсальный сетевой адаптер
Производительность сети (пропускная способность,
задержка, кол-во пакетов/с)
Лучшая
IHV требует постоянных инноваций для достижения наилучших результатов.
Ограниченная
— эмуляция VirtIO для нативного перевода HW I / F
— Ограниченный набор функций
Загрузка ЦПОтсутствуетОграниченная
Живая миграцияПоддержка включена в планы развитияПоддержка включена в планы развития

Вернитесь в раздел «Системное программное обеспечение» или «Оборудование«