Применение аппаратных ускорителей в SDN: как мы добились скорости передачи пакетов на уровне Bare Metal

Каждый, кто имеет дело с более-менее крупной IT-инфраструктурой, знает, что в мире сетей есть две прямо противоположных реальности. В одной — виртуализация с эффективным дроблением ресурсов, но потерей скоростей, в другой — Bare Metal с высокой скоростью и мощностью, но слабой гибкостью в вопросах выделения ресурсов. И если вы уже задались вопросом: «А можно без крайностей?», я инженер R&D-команды Cloud.ru Вадим Михеев, расскажу, как нам удалось достичь скоростей передачи пакетов в SDN на уровне Bare Metal на примере облака OpenStack. А еще посмотрим, какой прирост к скорости передачи пакетов дает технология ASAP².

Статья будет полезна всем обладателям железок NVIDIA Mellanox ConnectX-5/6/7, использующим виртуализацию, ну а остальные смогут посмотреть, какие способы ускорить сеть для своих клиентов мы тестируем и, возможно, вдохновиться.

Краткая история виртуализации: SDN и зачем их ускорять

Давайте совершим короткий утрированный экскурс в вопросы виртуализации, чтобы смысл дальнейшей части был прозрачен для вас как слеза комсомолки.
В начале были серверы (compute) и системы хранения данных (storage), да сети между ними и бездной интернета (network). Вскоре стало понятно, что если под каждое используемое приложение или сервис отводить по отдельному серверу, то это:

• никаких серверов не напасешься;

• те, что есть, могут работать не на полную катушку;

• если для работы приложения нужна другая среда, нужно либо таскать приложение с машины на машину, либо имитировать другую среду прямо на этой.

И увидели архитекторы, что это не очень, и отделили они программное от аппаратного. Над физическим оборудованием возникла абстрактная сущность, позволяющая нескольким виртуальным машинам (ВМ) работать на одном физическом устройстве. Примерно так и появилась виртуализация и ее вечные спутники — гипервизоры и SDN (программно-определяемые сети).

В принципе, с тех пор все жили долго и счастливо: виртуальные машины имитировали отдельные компьютеры каждый со своей средой и характеристиками. Гипервизоры распределяли ресурсы (процессорное время, память и сетевые подключения) между виртуальными машинами, устройства хранения делились на виртуальные сегменты. Виртуальные коммутаторы и маршрутизаторы управляли трафиком между ВМ, а пользователи радовались, что ресурсы одного физического сервера можно напилить на удобные кусочки и каждый использовать для своих задач.

Была только маленькая проблема: скорость передачи пакетов как между виртуальными машинами, так и между машинами и интернетом была значительно меньше, чем при отсутствии программной прослойки. В итоге все, для кого скорость передачи данных означала время, деньги и лояльность пользователей (облачные провайдеры, телеком, IТ-гиганты), задались вопросом: «А можно, чтобы было так же удобно как с виртуализацией, но без замедления?». Так начались поиски путей аппаратного ускорения.

При чем тут облако?

О поиске способов ускорения SDN, как правило в рамках более широких работ по ускорению ввода-вывода и выгрузке служебных сервисов облака с хоста на платы расширения (smartnic/dpu/ipu), заявляют многие облачные провайдеры. Так в мае прошлого года Google объявил о релизе серии виртуальных машин S3, где упомянул об использовании IPU, который позволяет в том числе предоставить высокопроизводительную сеть.

В конце сентября 2020 года VMware анонсировала проект Monterey, в рамках которого они объявили о намерении внедрить использование DPU в свои продукты. Если обратить внимание на один из их обзоров по тестированию производительности, можно сделать вывод, что в рамках этого проекта также ведутся работы по аппаратному ускорению сети облака.

Alibaba Cloud объявил о релизе чипа CIPU, Amazon имеет в своем арсенале AWS Nitro. Также NVIDIA разработала свой DPU – bluefield-2/bluefield-3, который имеет в своем составе технологию ASAP² для акселерации SDN.

Конечно же, этот вопрос не обошел и нас, потому что если существует шанс предоставить своим клиентам более высокие скорости, то его стоит как минимум изучить и протестировать.

Что и зачем мы планировали сделать

У нас в эксплуатации уже было некоторое количество сетевых карт Mellanox ConnectX-5/6. Производитель любезно предусмотрел для них возможность аппаратного ускорения и даже написал подробную инструкцию по применению решения Accelerated Switching and Packet Processing (ASAP²). Мы решили хорошенько закопаться в матчасть и проверить, все ли так хорошо с ускорением, как заявляет производитель.

Зачем? Ну, во-первых, R&D-команда для того и существует, чтобы отвечать на вопрос «а что будет если…?». А во-вторых, если фокус действительно сработает, есть шанс когда-нибудь раскатать его в большем масштабе и предоставить клиентам лучшие скорости и качество передачи данных без необходимости закупать новые устройства.

Работу ASAP² будем проверять на примере облака OpenStack, так как NVIDIA заявляет о их полной совместимости. Для этого попробуем кратко разобраться, как работает сеть облака OpenStack и каким образом туда встраивается ASAP².

Как устроена сеть ОpenStack и почему ASAP²

Сеть облака OpenStack построена по классической парадигме SDN с разделением на control plane — управляющий уровень и data plane — уровень передачи данных. Есть различные варианты приложений, реализующих эти функции, мы будем использовать OVN в качестве control plane и Open vSwitch в качестве data plane.

Работа с облаком OpenStack для пользователя ведется на уровне создания таких объектов, как виртуальная машина, виртуальная сеть, правила фаервола и т. д. Например, в облаке OpenStack есть веб-интерфейс Horizon, в котором пользователь может создать следующую виртуальную инфраструктуру:

Здесь есть три виртуальных объекта — две виртуальные машины и виртуальная сеть. Облако OpenStack подыщет для виртуальных машин пользователя физические серверы, где есть достаточное количество ресурсов, и запустит их при помощи гипервизора KVM.

Для виртуализации сети используются OVN и Open vSwitch. На каждом гипервизоре запущен Open vSwitch, к которому подключаются ВМ, и приложение ovn-controller. Приложение ovn-controller по протоколу OpenFlow передает правила, по которым будет обрабатываться трафик от виртуальных машин, в Open vSwitch:

Допустим, пользователь выполняет команду ping на первой ВМ и пингует вторую ВМ. В этом случае из первой ВМ в Open vSwitch придет пакет такого вида:

с IP-адресом источника и назначения в виртуальной сети. В таком виде пакет не может быть маршрутизирован через физическую сеть, поэтому для его передачи используются протоколы туннелирования. В нашем примере мы будем использовать geneve-протокол:

В этом случае пакет от виртуальной машины попадает в Open vSwitch, далее Open vSwitch инкапсулирует его в geneve-пакет c IP-адресами на физической сети и отправляет в сеть. На втором сервере Open vSwitch декапсулирует geneve-пакет и передает вложенный пакет на вторую ВМ. Необходимо обратить внимание, что все действия по отправке пакета с одной ВМ на вторую: передача пакета из ВМ в Open vSwitch, инкапсуляция пакета, отправка пакета в физическую сеть — выполняются на центральном процессоре гипервизора.
Технология ASAP² позволяет выгрузить эти действия на сетевую карту, выполняя их более эффективно и разгружая центральный процессор.

Технология ASAP²

Технология ASAP² призвана улучшить производительность виртуальной сети облака и снизить нагрузку на центральный процессор по обработке сетевого трафика. Помимо bluefield-2/bluefield-3 DPU эта технология поддерживается также и линейкой сетевых карт СonnectX-5/6/7. Эти сетевые карты имеют в своем составе embedded switch (eSwitch), и могут рассматриваться системой не как сетевая карта, а как карта расширения, на которой имеется аппаратный свич, который позволяет продвигать пакеты между своими портами, попутно выполняя различные действия. Порты строятся либо на технологии Single Root IO Virtualization (SR-IOV) Virtual Functions, либо vDPA, и используются в качестве сетевых карт виртуальных машин. В данной статье мы будем рассматривать SR-IOV, vDPA рассмотрим в будущих статьях.

Основная идея SR-IOV заключается в том, что одно физическое устройство регистрирует на PCI-шине дополнительно некоторое количество устройств подобного же типа, называемых virtual functions(VF). Физическое устройство при этом называют physical function(PF). Когда Linux загружается, то при сканировании PCI-шины он видит не только физическое устройство, вставленное в физический слот сервера, но и дополнительно зарегистрированные виртуальные устройства, которые с точки зрения Linux ничем не отличаются от физического. В случае сетевых карт регистрируются дополнительные сетевые карты, которые при помощи passthrough могут быть использованы в ВМ. В документации NVIDIA они называются виртуальными портами, между которыми eSwitch позволяет продвигать пакеты. То есть, если ВМ отправляет пакет со своей VF, то он может быть продвинут на другую VF или PF внутри eSwitch, и тем самым передан в другую ВМ внутри сетевой карты без участия центрального процессора.

Технология SR-IOV появилась задолго до появления ASAP² и в исходном виде не подходит для использования в SDN. Изначально SR-IOV поддерживает простейшие сценарии по продвижению пакетов между VF и PF по MAC и VLAN. В случае SDN требуется гораздо более интеллектуальное поведение, например, инкапсуляция, как в описанном выше сценарии. SR-IOV был доработан при участии Mellanox для использования в облаках: появилась возможность продвигать пакеты между портами по более широкому набору критериев и производить действия над ними при передаче внутри eSwitch. В том числе была разработана модель драйверов, названная switchdev, для работы с улучшенной версией SR-IOV, интегрированная в ядро Linux.

Настройка ASAP²

Параметры стенда

Тестировать работу ASAP² будем на стенде со следующей конфигурацией:

Для развертывания OpenStack еще используются control- и network-ноды, они на схеме не указаны.

А вот параметры оборудования Compute1 и Compute2:

Конфигурирование ASAP²

Все описываемые далее инструкции необходимо проделать на обеих compute-нодах.
В примерах и выводах команд далее будут использоваться следующие BDF и имя интерфейса: 0000:98:00.0 ens6f0np0, например:

~$ lspci | grep -i 98:00 98:00.0 Ethernet controller: Mellanox Technologies MT2894 Family [ConnectX-6 Lx] 98:00.1 Ethernet controller: Mellanox Technologies MT2894 Family [ConnectX-6 Lx] 

~$ ip -br l show dev ens6f0np0  ens6f0np0    UP         b8:3f:d2:8d:30:36  <BROADCAST,MULTICAST,UP,LOWER_UP> 

В выводе команды lspci приведены два порта одной сетевой карты. Мы будем работать с первым портом.

Для настройки ASAP² на нашем стенде необходимо сделать следующие шаги: настроить SR-IOV, перевести карту в режим switchdev, настроить OpenStack для работы с passthrough.

Установка NVIDIA firmware tools

Для настройки ASAP² могут потребоваться утилиты из пакета nvidia firmware tools(MFT). Можно установить MFT отдельным пакетом или при установке пакета драйверов MLNX_OFED. Из MFT нам потребуются две утилиты: mst и mlxconfig, mst — запускает драйвер, который позволяет работать с регистрами сетевой карты, и mlxconfig — позволяет в удобном виде сделать настройку.

Настройка SR-IOV

Для работы SR-IOV необходимо включить его поддержку в BIOS. Далее необходимо убедиться, что в сетевой карте включена поддержка virtual functions. Для этого можно воспользоваться командой:

~$ cat /sys/class/net/ens6f0np0/device/sriov_totalvfs

Если выведенное значение 0, то необходимо воспользоваться утилитой mlxconfig для включения поддержки VF в сетевой карте. Для этого сначала нужно выполнить команду:

~$ sudo mst start

для запуска драйвера mst. После загрузки драйвера в папке /dev/mst/ появятся файлы для работы с сетевыми картами. Далее можно выполнить команду:

~$ sudo mst status  MST modules:  ------------  MST PCI module is not loaded  MST PCI configuration module loaded   MST devices:  ------------  /dev/mst/mt4127_pciconf2     - PCI configuration cycles access.                                     domain:bus:dev.fn=0000:98:00.0 addr.reg=88 data.reg=92 cr_bar.gw_offset=-1                                 Chip revision is: 00 

чтобы вывести список сетевых карт, которые были найдены драйвером. Далее можно запросить список параметров конкретного адаптера командой:

~$ mlxconfig -d /dev/mst/mt4127_pciconf2 query

Для настройки SRIOV необходимо выстваить параметр SRIOV_EN в единицу и в параметре NUM_OF_VFS указать количество поддерживаемых VF. Также в параметрах ядра Linux необходимо включить поддержку iommu при помощи флага intel_iommu=on.

~$ mlxconfig -d /dev/mst/mt4127_pciconf2 set SRIOV_EN=1 NUM_OF_VFS=8

~$ reboot

После того, как поддержка VF включена на сетевой карте, можно включить ее в Linux командой:

~$ sudo bach -c ’echo 1 > /sys/class/net/ens6f0np0/device/sriov_numvfs’

либо в конфигурационном файле netplan:

network:    version: 2    renderer: networkd    ethernets:  ens6f0np0:    virtual-function-count: 1 

После включения виртуальной функции, она должна появиться в выводе команды lspci:

~$ lspci | grep -i 98:00  98:00.0 Ethernet controller: Mellanox Technologies MT2894 Family [ConnectX-6 Lx]  98:00.1 Ethernet controller: Mellanox Technologies MT2894 Family [ConnectX-6 Lx]  98:00.2 Ethernet controller: Mellanox Technologies ConnectX Family mlx5Gen Virtual Function 

Переключение сетевой карты в режим switchdev

Как уже упоминалось, стандартный SR-IOV не подходит для работы в облаках. Необходимо использовать подсистему драйверов switchdev. Чтобы переключить ConnectX-6 в режим switchdev, необходимо выполнить следующие действия:

1. Выгрузить драйверы всех VF. В нашем примере она одна:

~$ echo 98:00.2> /sys/bus/pci/drivers/mlx5_core/unbind

2. Переключить ConnectX-6 в режим switchdev при помощи утилиты devlink:

~$ devlink dev eswitch set pci/0000: 98:00.0 mode switchdev

либо через sysfs:

~$ echo switchdev > /sys/class/net/ens6f0np0/compat/devlink/mode

3. Загрузить обратно драйвер VF:

~$ echo 98:00.2> /sys/bus/pci/drivers/mlx5_core/bind

После переключения ConnectX-6 в режим switchdev в системе должны появиться дополнительные сетевые интерфейсы, так называемые representor ports. Representor port создается для каждой VF. Основная идея подсистемы switchdev заключается в том, что пакет отправленный с VF будет передан не в сетевую карту, а на representor port, и наоборот. И чтобы объединить виртуальные машины, например, в L2 домен, можно при помощи passthrough «прокинуть» VF в виртуальные машины, а representor порты объединить в linux bridge или при помощи openvswitch.

Именно такой сценарий мы и будем использовать в нашем примере в OpenStack. Если пакеты будут передаваться с VF сначала на representor port, а потом обрабатываться в Open vSwitch, то работать это будет медленно, но switchdev позволяет выгружать правила продвижения пакетов в свич, в этом случае передача пакетов происходит аппаратно без передачи пакетов на representor port, что, как ожидается, позволяет достигнуть высокой производительности.

Создание виртуальной инфраструктуры в облаке ОpenStack

Чтобы использовать ASAP² в OpenStack, для начала необходимо добавить настройки passthrough в конфигурационные файлы OpenStack. Далее уже можно создавать виртуальную инфраструктуру с «прокинутыми» в виртуальные машины VF.

Настройка OpenStack для работы с passthrough и ASAP²

Для использования passthrough в OpenStack необходимо в конфигурационный файл nova.conf на всех compute-нодах добавить следующие параметры:

[filter_scheduler]  enabled_filters = PciPassthroughFilter  [pci]  device_spec = {"address":{"domain": "0000","bus": "98", "slot": "00","function": "2"},"physical_network":null} 

PciPassthroughFilter — параметр указывает, что нода поддерживает работу с passthrough, device_spec указывает, какие устройства можно использовать для этих целей. Мы указали BDF нашей VF.

На control нодах в nova-scheduler nova.conf также необходимо включить фильтр PciPassthroughFilter:

[filter_scheduler]  enabled_filters = PciPassthroughFilter 

На всех compute-нодах также необходимо включить поддержку hw offload в Open vSwitch:

~$ ovs-vsctl set Open_vSwitch . other_config:hw-offload=true

Создание сети

~$ openstack network create demo-net

~$ openstack subnet create --subnet-range 192.168.0.0/24 --network demo-net --gateway 192.168.0.1 demo-subnet

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

~$ openstack port create --network demo-net --vnic-type direct --binding-profile '{"capabilities": ["switchdev"]}' ASAP2_port1

~$ openstack port create --network demo-net --vnic-type direct --binding-profile '{"capabilities": ["switchdev"]}' ASAP2_port2

Создание флаворов

Для тестирования будем использовать ВМ с 32-мя процессорами и 64 ГБ памяти. Также будем использовать hugepages, которые нужно предварительно выделить на гипервизоре.

~$ openstack flavor create --vcpus 32 --ram 65536--property hw:mem_page_size=2MB ASAP2_test_flavor

Создание образов

В качестве образов использовали Ubuntu 22.04. Его можно взять, например, с сайта https://cloud-images.ubuntu.com/. Если использовать облачный образ, то необходимо будет при создании ВМ передать user-data в формате cloud-init. Также при создании образа выставим флаг hw_vif_multiqueue_enabled=’True’, чтобы виртуальные сетевые интерфейсы поддерживали несколько очередей. Будем считать, что у нас есть файл ubuntu22_04.qcow2 с образом Ubuntu 22.04.

~$ openstack image create --disk-format qcow2 –-public --file ubuntu22_04.qcow2 ubuntu22_04

Создание виртуальных машин

~$ openstack server create –-image ubuntu22_04 --flavor ASAP2 --port ASAP2_port1 --disk 40 --availability-zone compute1 vm1

~$ openstack server create –-image ubuntu22_04 --flavor ASAP2 --port ASAP2_port2 --disk 40 --availability-zone compute2 vm2

При удачном создании конфигурации можно увидеть, что в Open vSwitch были добавлены representor ports, а внутри виртуальных машин видны сетевые карты ConnectX-6.

Методика тестирования

Для тестирования производительности сетевого оборудования обычно используются генераторы трафика, такие как: ixia, spirent, trex. Например, отчеты производительности, опубликованные на сайте dpdk.org, получены при помощи ixia. Генераторы позволяют гибко настраивать сценарии тестирования и собирать точную статистику, но в то же время они требуют, чтобы генератор мог отправлять трафик с одного порта и собирать его с другого порта после прохождения сетевого устройства.

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

Iperf3 поддерживает флаг —parallel для работы iperf3 в несколько потоков данных, но при этом iperf3 все равно все делает в рамках одного потока операционной системы. Поэтому мы будем запускать несколько процессов iperf3. На одной ВМ будем запускать iperf3 в режиме сервера, на другой — в режиме клиента, постепенно наращивая количество пар.

Тест будем проводить для трех случаев, запуская 1, 2, 8 и 32 iperf пары для каждого случая. Сначала протестируем, что показывает тест вне облака между compute-нодами, на графиках обозначим как Bare Metal. Далее протестируем производительность SDN, когда в ВМ создаются виртуальные сетевые адаптеры virtio, а на стороне гипервизора используется реализация vhost-протокола в ядре. На графиках обозначим как vhost. И в третьем случае протестируем производительность конфигурации ASAP², настройку которой мы подробно описали выше. На графиках обозначим как ASAP².

В случае Bare Metal каждая iperf пара будет запущена командой:

~$ iperf3 -c compute2 -u -b 0 -l 76

В случае vhost и ASAP² будем использовать команду с минимально возможной длиной датаграммы:

~$ iperf3 -c vm2 -u -b 0 -l 18

После инкапсуляции длина пакета на физической сети будет 122 байта, поэтому для Bare Metal была выбрана длина пакета 76 байт, чтобы также получить пакет длиной 122 байт.
Распределение потоков ipref, vhost, softirqd по ядрам на гипервизоре и в виртуальных машинах выполнялось планировщиком Linux c настройками по умолчанию.

Результаты тестирования

Далее на графиках приведены результаты тестов для количества успешно отправленных пакетов и успешно доставленных в миллионах пакетов в секунду. По оси Х указано количество iperf3 пар, по оси Y — количество пакетов. Значения были получены суммированием по всем отчетам, полученным от каждой iperf3 пары.

Выводы

На приведенных тестах использование технологии ASAP² по сравнению с vhost дает прирост производительности от двух до трех раз. На всех тестах производительность ASAP² близка к производительности Bare Metal, где-то превышая ее, где-то уступая. Разница в большой степени связана с работой планировщика Linux как на гипервизоре, так и в виртуальных машинах (где-то iperf3 потоки могли исполняться на одном ядре, где-то пакеты от разных iperf3 пар попадали в одну и ту же очередь сетевой карты). Можно считать, что производительность ASAP² близка к производительности Bare Metal.

В статье не анализируется, насколько ASAP² позволяет высвободить вычислительные ресурсы. Предварительный анализ показывает, что в случае vhost конфигурации на каждую очередь запускается один поток ядра, т. е. в приведенных тестах на обоих гипервизорах было запущено по 32 потока vhost. Когда vhost-поток полностью занимает процессор, он позволяет обработать около 400 000 пакетов в секунду. То есть для обработки 4 млн пакетов в секунду потребуется около 10 процессоров, в случае ASAP² эти ресурсы не требуются.

Из минусов ASAP² можно отметить сложности при интеграции. Так SR-IOV по умолчанию не поддерживает живую миграцию. Для живой миграции необходимо создавать дополнительный виртуальный интерфейс, настраивать конфигурацию с бондом между VF и этим интерфейсом, как на гипервизоре, так и внутри ВМ. Для карт ранее ConnectX-6 DX использование ASAP² также подразумевает объединение в бонд двух портов сетевой карты для обеспечения отказоустойчивости, что сужает возможные варианты архитектуры физической сети облака.

Вам может быть интересно:

• Возможности аппаратного ускорения сети OpenStack — доклад Вадима Михеева на конференции GoCloud Tech

• Как мы работу блочного pNFS исправляли: продолжение остросюжетного детектива с Linux в главной роли

• Эволюция в режиме цейтнота: как мы изобрели SDK и CLI для Cloud.ru Evolution в ходе нагрузочного тестирования

• Темы, доклады, две конфы: история трека для инженеров и исследователей «Под капотом»