Ты закладываешь DPU в новые VMware-хосты ради двух эффектов: снять сетевую обработку с x86 и перенести NSX Distributed Firewall на карту. Второго эффекта в новой закупке больше нет — VMware прекратила продажи распределённого firewall для SmartNIC.

Это не означает отказ от DPU целиком. Distributed Services Engine остаётся в VMware Cloud Foundation, а VCF 9.1 поддерживает отдельный механизм оффлоада через производительные сетевые адаптеры. Поэтому вычёркивать SmartNIC из спецификации автоматически нельзя. Сначала проверь, какую именно работу должна выполнять карта.

VMware закрыла один продукт, а не весь DPU-стек

В этой новости смешались три разные технологии:

NSX Distributed Firewall на DPU — снят с продажи;
vSphere Distributed Services Engine, или vDSE, — остаётся частью VCF;
Advanced NIC Passthrough — отдельный механизм VCF 9.1 для производительных сетевых адаптеров.

NSX Distributed Firewall на DPU успел выйти из предварительного режима. В материалах VMware по NSX 4.1.x он указан как функция для рабочей среды. Теперь VMware прекратила его продажи: об этом сообщил Umesh Mahajan, вице-президент подразделения Application Networking and Security в Broadcom. Его объяснение сводилось к спросу: заказчики обсуждали продукт, но не покупали его. Представитель VMware также признал, что экосистема SmartNIC развивалась медленнее ожиданий. Об этом сообщили The Register и SDxCentral.

При этом документация Broadcom по vSphere 9.1 по-прежнему описывает два способа вынести сетевую обработку с CPU хоста: vDSE на DPU и Advanced NIC Passthrough на производительной сетевой карте. Значит, закупочный вопрос теперь звучит не «отказалась ли VMware от SmartNIC», а «какая поддерживаемая функция окупает DPU в нашем кластере».

Будущий NSX Firewall больше не окупает DPU

Если расчёт держался на фразе «сейчас поставим SmartNIC, потом перенесём туда firewall», убери этот эффект из модели. Функцию сняли с продажи, поэтому обещанное будущее преимущество нельзя включать в экономию процессорных ядер или в запас платформы.

В презентации VMware 2023 года DPU должна была принимать на себя NSX, хранение и ввод-вывод. Там же приводились ориентиры нагрузки на CPU: 15% для ESXi, по 10% для vSAN и NSX. Это иллюстрация архитектуры, а не результат измерения твоего кластера. Нельзя сложить проценты из презентации, получить 35% и на этом основании купить меньше процессоров.

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

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

У vDSE остались жёсткие архитектурные условия

vDSE появился в vSphere 8.0 и продолжает получать поддержку. Он переносит инфраструктурную сетевую обработку с x86 на DPU. Но карту нельзя добавить в проект одной строкой «SmartNIC с запасом на будущее».

При создании vSphere Distributed Switch нужно выбрать совместимость с конкретным производителем DPU — например, NVIDIA BlueField или AMD Pensando. После подключения хостов этот режим нельзя изменить. Ошибка на этапе проекта означает пересборку распределённого коммутатора, а не замену настройки в работающем кластере.

Есть и функциональные ограничения. VDS с DPU не поддерживает Network I/O Control и политики traffic shaping. Если проект управляет полосой через эти механизмы, перенос сетевой обработки на DPU меняет не только состав оборудования, но и сетевую архитектуру.

Для отказоустойчивости Broadcom описывает Dual DPU HA: одна DPU обрабатывает трафик, вторая ждёт отказа первой. Это две карты на хост ради одного активного тракта. Такой вариант стоит оставлять в спецификации только вместе с функцией, которая нужна уже на запуске кластера.

Performance NIC снимает нагрузку иначе

VCF 9.1 добавляет Advanced NIC Passthrough для высокопроизводительных адаптеров. Это не урезанная версия vDSE, а другой путь оффлоада. Broadcom отдельно указывает режимы UPTv2 и DVX, а VMware развивает прямой оффлоад для NVIDIA ConnectX-7.

UPTv2 сохраняет vMotion, High Availability, DRS и Hot Add CPU для виртуальных машин с VMXNET3. Это позволяет ускорить сетевой тракт без полного DPU-стека.

Цена такого упрощения — схема подключения. В VCF 9.1 один offload-enabled VDS поддерживает только один физический адаптер в режиме Performance NIC. Пара адаптеров для одного оффлоадного тракта не поддерживается. Если проект требует аппаратного дублирования этого тракта, ConnectX-7 с Advanced NIC Passthrough нельзя считать прямой заменой двум DPU в режиме HA.

Три решения для закупки

Если главным основанием был NSX Distributed Firewall на DPU, убери SmartNIC из нового заказа. Оставь обычные сетевые адаптеры с той пропускной способностью, которая уже рассчитана под трафик кластера. CPU пересчитай по своим замерам, не вычитая проценты из презентации VMware.

Если DPU нужен для vDSE сейчас, сохрани его. До заказа зафиксируй производителя, совместимость с версией VCF, режим VDS и потребность в Dual DPU HA. Отдельно проверь, можно ли отказаться от Network I/O Control и traffic shaping на этом коммутаторе.

Если задача сводится к снижению сетевой нагрузки на CPU, сравни vDSE с Advanced NIC Passthrough. Для последнего рассматривай ConnectX-7 или другой адаптер из матрицы совместимости, но заложи ограничение: один физический NIC на один оффлоадный VDS.

Спецификация под задачу

Считаем типовой проект: новый кластер VCF 9.1, по одному распределённому коммутатору для ускоряемого трафика на хосте. CPU, память и диски здесь не пересчитываем — в исследовании нет профиля виртуальных машин и замеров нагрузки. Спецификация меняет только сетевой узел, которого касается решение VMware.

Сценарий	Что записать в спецификацию	Почему столько
Проект рассчитывал только на NSX Firewall на DPU	0 DPU; штатные NIC из исходного сетевого расчёта	Firewall снят с продажи, другой задачи для DPU нет
vDSE нужен в рабочей среде	2 совместимые DPU на хост: NVIDIA BlueField либо AMD Pensando; одна активная, одна резервная	Dual DPU HA переключает оффлоад на вторую карту при отказе первой
Нужен сетевой оффлоад без vDSE	1 NVIDIA ConnectX-7 или другая совместимая Performance NIC на offload-enabled VDS	VCF 9.1 поддерживает только один физический адаптер на такой VDS

Если отказоустойчивость DPU не нужна, вторая карта не требуется — но тогда отказ активной DPU прервёт аппаратный оффлоад. Если одному хосту нужны два независимых оффлоадных VDS, расчёт повторяется для каждого коммутатора: по одному Performance NIC на VDS. Объединить два адаптера в один отказоустойчивый оффлоадный тракт документация VCF 9.1 не разрешает.

Перед согласованием закупки вычеркни из неё все будущие функции без статуса поддержки в текущей VCF. Firewall был главным основанием — убирай DPU. vDSE нужен на запуске — оставляй совместимые DPU и сразу проектируй VDS. Нужен только сетевой оффлоад — сравни стоимость DPU с Performance NIC, приняв ограничение одного адаптера.

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