SmartNIC в хостинге: как правильно оценить ускорение сетевого трафика

Правильное использование SmartNIC в хостинге

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

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

A ДПУ как правило, имеет более сложную архитектуру: помимо сетевого ASIC, она обладает собственными вычислительными ресурсами и может поддерживать отдельный путь передачи данных инфраструктуры. NVIDIA описывает для BlueField режим DPU, в котором встроенная система на базе ARM управляет ресурсами сетевой карты и каналом передачи данных, а также режим сетевой карты, в котором карта ведет себя по отношению к внешнему хосту как адаптер. Таким образом, в зависимости от режима работы создается собственная область управления и доверия.

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

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

Как аппаратная разгрузка изменяет тракт передачи данных

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

Этот путь становится особенно актуальным при большом количестве мелких пакетов, многочисленных кратковременных соединений или обширных политик клиентов. Нагрузку на хост создает не только объем передаваемых данных, но и неоднократная обработка отдельных пакетов и потоков. Поэтому ускорение работы сети не является общим свойством сервера, а представляет собой целенаправленное снижение нагрузки на конкретно определённый путь передачи данных.

На сайте Аппаратная разгрузка компоненты управления могут передавать допустимые правила перенаправления и фильтрации в аппаратный канал передачи данных. Модель Linux switchdev описывает для этого перенос траектории пересылки данных из ядра в сетевой коммутатор. То, какие правила фактически принимаются, зависит от конкретной платы, её драйвера и вышестоящей сетевой интеграции.

В документации по OVS в ветке разработки 4.0.90 отдельный раздел, посвящённый аппаратной разгрузке потоков (Flow Hardware Offload), явно обозначен как экспериментальный. Именно для этой конфигурации OVS с DPDK в документации проводится различие между полной разгрузкой сопоставлений и действий, а также частичной разгрузкой, при которой переносятся только сопоставления. Данное описание не является стабильным и универсальным подтверждением совместимости с другими версиями OVS, сетевыми картами или платформами.

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

В каких случаях использование SmartNIC в хостинге целесообразно

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

Многопользовательские оверлейные сети и Микросегментация являются ещё одним отправным пунктом. Если во многих сетях клиентов повторно применяются VLAN- или оверлейные сопоставления, правила контроля доступа и аналогичные решения по потокам, то подходящий аппаратный путь прохождения данных может снизить нагрузку на процессоры хостов. При этом необходимо, чтобы количество правил, поля сопоставления и действия были доступны в выбранной карте вместе с драйвером, а семантика политик сохранялась в полном объеме.

В документации по OpenShift Container Platform 4.22 компания Red Hat описывает аппаратное разгружение для узлов «bare-metal» с совместимым SmartNIC и активным сетевым оператором SR-IOV. Поддерживаются только связь между под-подами, а также связь между под-подами и службой ClusterIP с обычными под-подами; приложения DPDK несовместимы с этой функцией. Кроме того, преимущество ограничивается участками связи, в которых участвующие узлы используют совместимые SmartNIC.

В случае зашифрованных сетей хостов или локальных сетей IPsec-оффлоуд может брать на себя отдельные задачи или весь процесс инкапсуляции, деинкапсуляции, шифрования и защиты от повторного воспроизведения. Компания NVIDIA описывает различные типы разгрузки, включая Crypto- и Full-Offload. Однако это не означает их универсальной применимости: поддержка и ограничения производительности зависят от модели, прошивки и криптографического алгоритма.

Простой сервер веб-хостинга специально приведён в качестве противоположного примера. Если он в основном отправляет небольшое количество крупных HTTP-ответов и не демонстрирует нагрузки на ЦП в тракте пакетов, то можно использовать более специализированный серверное оборудование только создадут дополнительные эксплуатационные расходы. Сначала следует выяснить, что именно является причиной узкого места: приложение, база данных, хранилище или сеть. Использование SmartNIC не является целесообразной альтернативой такой диагностике.

Техническое сравнение вариантов применения

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

В случае платформ виртуализации SR-IOV Типичный подход: виртуальные функции назначаются виртуальной машине, в то время как интерфейсы Representor в операционной системе отображают порты таких функций. Это позволяет реализовать на аппаратном уровне правила перенаправления между виртуальными и физическими портами в архитектуре, ориентированной на switchdev. Однако это не заменяет проверку того, сохраняются ли требуемое разделение клиентов и модель эксплуатации.

Kubernetes — это противоположность общим обещаниям об ускорении. Для задокументированной интеграции с OpenShift 4.22 действуют определенные поддерживаемые трафиковые пути, совместимые узлы SmartNIC и требования к рабочим нагрузкам. Если узел с поддержкой разгрузки взаимодействует с обычным узлом, этот обычный узел обрабатывает свою часть в ядре, тем самым ограничивая общий путь. Поэтому при развертывании следует сначала учитывать ограниченный пул узлов и реальные пути связи.

В случае зашифрованных сетей хостов или локальных сетей эти термины следует использовать особенно точно. Задокументированные варианты IPsec варьируются в зависимости от платформы от «Crypto-Offload» до «Full Offload» для инкапсуляции, деинкапсуляции, шифрования и защиты от повторного воспроизведения. Из этого не следует никакой общей гарантии пропускной способности: модель, прошивка, используемые алгоритмы и ограничения, связанные с конкретным продуктом, определяют, какая часть обработки фактически переносится на внешнее устройство.

Проверить совместимость перед развертыванием

Процесс закупки начинается с объективного анализа текущей ситуации, а не с активации опций разгрузки. Зафиксируйте точную конфигурацию карты, включая PCI-ID, версию прошивки, драйверы и ядро. Кроме того, необходимо знать режим eSwitch, а также версию и конфигурацию Open vSwitch, OVN, гипервизора или платформы Kubernetes, поскольку сама по себе совместимость карты не гарантирует полной интеграции с программным обеспечением.

Необходимая семантика правил должна быть заранее представлена в виде описания пути данных: например, сопоставление VLAN, IPv4 или IPv6, TCP или UDP, тип туннеля, изменение заголовка, перенаправление или отбрасывание. Экспериментальная документация по OVS 4.0.90 показывает, что в случае конфигурации DPDK отсутствие определённых аппаратных действий может привести к частичной разгрузке. Из этого следует, что для любой другой версии или платформы это является лишь рекомендацией для проверки, но не гарантией функциональности.

Матрицы платформы — это подтверждения совместимости с конкретными версиями, а не общие утверждения о семействе сетевых карт. В OpenShift 4.22 для интеграции аппаратной разгрузки указаны конкретные сетевые карты, в том числе BlueField-2 в режиме ConnectX-6. Из этого нельзя сделать вывод ни о поддержке другой прошивки, ни о другом режиме DPU, ни об иной дистрибуции. Поэтому документируйте каждую комбинацию оборудования, прошивки, драйвера и версии платформы отдельно.

Кроме того, для Linux-switchdev крайне важно, чтобы аппаратное обеспечение соблюдало семантику программной сети. Например, при фильтрации VLAN коммутатор, осуществляющий разгрузку, должен учитывать правила VLAN моста и отбрасывать недопустимые идентификаторы VLAN. Это требование показывает, почему списки функций и политика безопасности должны проверяться совместно: ускорение не должно приводить к отклонениям в сегментации сети.

Сравнить преимущества SmartNIC с CPU и программным обеспечением

SmartNIC — это лишь один из нескольких вариантов, когда сетевая обработка достигает своих пределов. Сначала стоит проверить, не удастся ли устранить узкое место за счёт увеличения мощности ЦП, подходящего количества очередей, настроек RSS, распределения IRQ или оптимизации ядра. Для классификации SoftIRQ, очередей и распределения прерываний см. статью по адресу Производительность процессора и пропускная способность сети в хостинге дополнительные основы. Без подтверждения наличия сетевого узкого места дополнительное специализированное оборудование остаётся лишь предположением.

DPDK и AF_XDP позволяют сократить длину программных путей на процессорах хоста, однако каждый из них требует отдельного проектирования архитектуры и процессоров. Утверждение о постоянном опросе нельзя безоговорочно применять к обоим подходам: в документации OVS-DPDK для описанной конфигурации один поток непрерывно опрашивает устройства DPDK, полностью занимая при этом одно ядро процессора. Поэтому NUMA-распределение, изоляция ядер и конкретные версии OVS и DPDK остаются частью проектирования.

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

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

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

Визуализация разгрузки в процессе работы

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

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

Следующие команды не изменяют настройки. Первый запрос учитывает как PCI-устройства, отображаемые как «Ethernet controller», так и те, которые отображаются как «Network controller». ethtool -k отображает предлагаемые или активированные в Netdev функции разгрузки, однако не подтверждает в полной мере ни разгрузку eSwitch, ни SmartNIC, ни разгрузку потоков. Остальные выводы также представляют собой данные об инвентаризации и конфигурации, а не подтверждение наличия конкретного правила, полностью переданного на разгрузку.

lspci -nn | grep -Ei 'Ethernet controller|Network controller'
ethtool -k <interface>
ethtool -i <interface>
devlink dev show
ovs-vsctl get Open_vSwitch . other_config

В случае Open vSwitch следует особо различать настроенное аппаратное ускорение и наблюдаемый результат. В документации по разработке OVS 4.0.90 аппаратное разгружение потоков обозначено как экспериментальное, а полная или частичная разгрузка описана только для данной конфигурации OVS с DPDK. Поэтому для эксплуатации в производственной среде данные о потоках и показания аппаратных счетчиков необходимо анализировать совместно с показаниями программных счетчиков хоста.

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

В интеграции с OpenShift 4.22 обзор должен дополнительно охватывать весь путь передачи данных. Документированная поддержка аппаратной разгрузки распространяется только на определенные рабочие нагрузки и типы связи. Если совместимый узел взаимодействует с узлом, не имеющим соответствующего SmartNIC, последний обрабатывает свой участок в ядре; в таком случае точки измерения, расположенные только на одном хосте, могут отображать сквозной путь неполно.

Типичные сценарии сбоев и пути устранения неполадок

Наиболее распространённая картина ошибки — это неполная разгрузка. Поток можно распознать на аппаратном уровне по простым признакам, однако для выполнения неподдерживаемого действия он должен частично или полностью вернуться в программный контур. В экспериментальной документации по OVS 4.0.90 описывается такая частичная разгрузка для конфигурации DPDK. Это не является общим утверждением, применимым ко всем установкам OVS, но подчеркивает необходимость проверки при каждой конкретной интеграции.

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

Гетерогенные кластеры затрудняют сравнение. В OpenShift 4.22 аппаратная разгрузка происходит только в том случае, если соответствующие поды и сервисы назначены узлам с совместимым SmartNIC. Если такой путь попадает на обычный узел, его обработка осуществляется в ядре, что ограничивает общий объем трафика. Поэтому один ускоренный узел не занимает полностью ускоренный путь кластера.

Неправильная конфигурация под или сети также может помешать достижению ожидаемого эффекта. Компания Red Hat специально обращает внимание на то, что в случае функции OpenShift 4.22 включенная аппаратная разгрузка без соответствующей настройки под может привести к снижению пропускной способности под. Поэтому операторам не следует устранять отклонения путём дальнейшей активации опций, а сначала необходимо проверить подключение рабочих нагрузок, сетевой режим и фактически достигнутые потоки.

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

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

Принимать реалистичные решения по закупкам и эксплуатации

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

Далее необходимо Свидетельство о совместимости для конкретной комбинации: модель карты и режим работы, прошивка, драйверы, ядро, виртуальный коммутатор или CNI, а также необходимые функции сопоставления и действий. Программируемые ускорители инфраструктуры могут, например, обеспечивать разгрузку потоков для функций, связанных с состоянием или сессией; однако из этого не следует, что каждая SmartNIC или каждая платформа предоставляет одну и ту же функцию.

Ожидаемое снижение нагрузки на ЦП станет доступным в качестве резервных мощностей только в том случае, если обработка пакетов была основным узким местом, а освободившиеся ядра можно будет эффективно использовать. Если их, например, задействовать для баз данных, веб-рабочих процессов или в качестве резерва, это будет архитектурным решением, а не автоматическим повышением производительности. Поэтому остальное серверное оборудование по-прежнему играет решающую роль; процессор, оперативная память и хранилище должны подходить для данного приложения так же, как и сеть. Более подробную информацию для комплексного анализа можно найти в статье по теме серверное оборудование, влияющее на производительность, в сфере веб-хостинга.

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

DPU расширяет сферу принятия решений за счет собственной области управления и доверия. В режиме BlueField-DPU встроенная система Arm контролирует ресурсы сетевой карты и путь передачи данных, а не просто работает в качестве адаптера хоста. Это позволяет отделить инфраструктурные задачи от хоста, но требует надежной концепции управления правами доступа, образами, обновлениями, мониторингом и восстановлением.

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