Виртуальные сети VXLAN и VMware NSX: руководство для инженера

У вас 500 арендаторов в ЦОДе, и вы только что поняли, что 802.1Q начинает трещать по швам. Стандарт IEEE даёт 4094 рабочих VLAN ID (два зарезервированы), и всё — потолок. Дальше либо городить агрегацию через QinQ, либо признать, что архитектура сети проектировалась в другую эпоху. VXLAN появился именно как ответ на этот тупик — и сегодня это фундамент, на котором стоит большинство серьёзных SDN-решений, включая VMware NSX.

Что такое VXLAN и зачем он нужен

В 2011 году консорциум из Cisco, VMware, Arista и ещё нескольких вендоров разработал VXLAN (Virtual Extensible LAN) — протокол, который расширяет L2-сегментацию поверх существующего IP-underlay. Идея проста: берём Ethernet-фрейм, упаковываем его в UDP-пакет и отправляем между хостами через обычную IP-сеть. Получатель распаковывает, виртуальная машина видит свой привычный L2-домен.

Главный посыл этой архитектуры — оверлейные сети полностью отделяются от физической топологии. Физическая сеть (underlay) занимается только IP-маршрутизацией и не знает ничего о VM, VLAN и сегментации. Виртуальная сеть (overlay) живёт своей жизнью поверх underlay и управляется программно. Это и есть суть Software-Defined Networking в ЦОДе.

Размер адресного пространства вырастает радикально: вместо 12-битного VLAN ID используется 24-битный VNI (VXLAN Network Identifier). Это 16 777 216 уникальных сегментов против 4096 у традиционных VLAN.

Туннелирование между хостами обеспечивают VTEP — VXLAN Tunnel Endpoints. Каждый ESXi-хост или физический коммутатор с поддержкой VXLAN выступает как VTEP: инкапсулирует исходящий трафик и декапсулирует входящий. В vSphere роль VTEP берёт на себя vDS (vSphere Distributed Switch) — аппаратно или через NSX-агент.

Структура пакета и накладные расходы

Инкапсуляция — это не бесплатно. К каждому фрейму добавляется overhead:

При стандартном MTU 1500 байт полезная нагрузка сжимается до ~1450 байт. Это создаёт фрагментацию — и именно здесь большинство инженеров получают свои первые грабли в продакшне.

Для underlay рекомендуется MTU не менее 1600 байт, а комфортное значение — 9000 (Jumbo Frames). Если в вашей физической сети где-то стоит коммутатор с дефолтным MTU 1500, ловите асимметричные потери и головную боль при диагностике.

По части discovery VTEP есть два режима: multicast и unicast (headend replication). Multicast элегантнее масштабируется — BUM-трафик (Broadcast, Unknown unicast, Multicast) рассылается через мультикастовую группу. Unicast проще в тех средах, где мультикаст в underlay не поддерживается или заблокирован. NSX по умолчанию использует unicast с репликацией через контроллеры.

Отдельный момент — выбор UDP-порта. IANA зарегистрировала для VXLAN порт 4789, но Cisco и часть вендоров исторически использовали 8472. В смешанной среде это источник тихих проблем: трафик уходит, но до получателя не доходит, потому что файрвол или ACL на пути не пропускает "чужой" порт. Проверяйте это при интеграции NSX с физическими VXLAN-коммутаторами.

VMware NSX: SDN на базе VXLAN

В 2012 году VMware купила Nicira за $1,26 млрд — тогда это казалось дорого. Сегодня NSX — это фундаментальная часть VMware-стека и де-факто стандарт SDN для enterprise vSphere-сред.

Архитектура NSX строится вокруг нескольких плоскостей:

• Management Plane — NSX Manager, единая точка управления. В NSX-T это три узла в кластере для отказоустойчивости.
• Control Plane — отвечает за распределение таблиц маршрутизации и ARP-записей между VTEP. Это то, что делает VXLAN-сеть "умной" — хосты не флудят, а получают точную информацию о местонахождении MAC-адресов.
• Data Plane — NSX-агент на каждом ESXi-хосте. Именно здесь происходит реальная инкапсуляция и применяются политики безопасности.

Разделение плоскостей — не архитектурная красота ради красоты. Это практическая необходимость: если NSX Manager недоступен, уже настроенная сеть продолжает работать. Data Plane на хостах не зависит от связности с Management Plane в режиме реального времени. Для продакшна это означает, что плановое обслуживание NSX Manager не вызывает сетевого даунтайма — хосты продолжают коммутировать трафик по закэшированным таблицам.

NSX-V и NSX-T: в чём разница

NSX-V был заточен исключительно под vSphere. NSX-T (с 2018 года, сейчас просто NSX) — это переписанная архитектура с поддержкой multi-hypervisor: KVM, bare-metal, контейнеры через Kubernetes/Tanzu. При выборе платформы виртуализации для NSX-T полезно понимать, какой гипервизор лучше выбрать с учётом совместимости и лицензирования. Вместо чистого VXLAN NSX-T использует Geneve (Generic Network Virtualization Encapsulation) — расширяемый формат, который добавляет в заголовок метаданные вплоть до L7. Это открывает возможности для более тонкой инспекции трафика без дополнительного оборудования.

Если вы ещё эксплуатируете NSX-V — время думать о миграции. VMware прекратила поддержку NSX-V в 2022 году.

Микросегментация: почему это меняет подход к безопасности

Традиционный периметральный файрвол — это "стена" на входе в ЦОД. Внутри сети — практически открытое пространство. Если атакующий прорвался внутрь, lateral movement между серверами ничто не останавливает.

NSX реализует микросегментацию на уровне каждой виртуальной машины. Политики применяются прямо в vNIC — ещё до того, как пакет попадает в физическую сеть. Distributed Firewall (DFW) работает на каждом ESXi-хосте и применяет правила независимо от сетевой топологии. Никакого дополнительного железа, никаких разворотов трафика на физический файрвол.

Принципиальное отличие от периметральной модели — политика привязана к VM, а не к IP-адресу или VLAN. При vMotion виртуальная машина переезжает на другой хост, и DFW-правила следуют за ней автоматически. Если в вашей среде VM меняют хосты часто (например, при DRS-балансировке), политики безопасности не нужно пересматривать вручную.

Маршрутизация и интеграция с underlay

NSX предоставляет два типа маршрутизации: Distributed Logical Router (DLR) и Edge Gateway. DLR работает непосредственно на хостах — это distributed routing без hop через отдельный узел. Каждая VM маршрутизирует трафик локально, что даёт минимальную задержку. На хосте с DPDK задержка туннелирования составляет 5–10 мкс — это сопоставимо с задержкой физического коммутатора среднего уровня.

Edge Gateway обеспечивает выход во внешние сети и поддерживает EVPN-VXLAN для L3-маршрутизации между площадками. Это позволяет строить multi-site федерации без MPLS — BGP в underlay заменяется EVPN-сигнализацией, которой управляет NSX.

Практически это выглядит так: два ЦОДа, NSX Manager в каждом, между ними — IP-connectivity. Живая миграция VM между площадками без изменения IP-адреса работает через L2-расширение поверх VXLAN. Трафик маршрутизируется оптимально через локальный Edge, а не шпилькой через основной ЦОД.

Бридж-режим DLR отдельного внимания: он позволяет соединить VXLAN-оверлей с физической VLAN без отдельного физического маршрутизатора. Актуально при поэтапной миграции — когда часть серверов ещё в физической сети, а часть уже в NSX-оверлее, и им нужна связность между собой.

Мониторинг и диагностика

Несколько точек, которые стоит держать под контролем в VXLAN/NSX-среде:

• MTU по всему пути — проверяется через ping с установленным DF-битом и размером пакета 1572 байта (1500 + 72 байт для VXLAN overhead при MTU 1600). Если где-то теряется — ищите звено с недостаточным MTU.
• ARP-супрессия — NSX Controller кэширует ARP-записи и отвечает от имени VM, не пропуская ARP-запросы во весь сегмент. Это критично в больших кластерах, где broadcast-шторм от ARP может положить underlay.
• IPFIX — NSX экспортирует flow-данные в совместимые коллекторы. Если вы используете Zabbix или аналогичный инструмент, IPFIX даёт видимость на уровне VM-to-VM потоков, что при диагностике ценнее, чем агрегированная статистика с физических портов.

Отдельно про VXLAN-флуд в высоконагруженных кластерах. Если ARP-супрессия не включена (или выключена по ошибке после обновления), в сегменте с тысячами VM broadcast-трафик начинает ощутимо нагружать underlay. Симптом — периодические микро-потери на VTEP в часы пиковой нагрузки, которые на первый взгляд выглядят как проблема физической сети. Проверяйте через net-vdl2 -M stats — там видны счётчики BUM-трафика на логическом свитче.

Команды для быстрой диагностики на ESXi:

Требования к железу: что нужно VTEP-хосту

VXLAN и NSX — это не только программная часть. Производительность зависит от того, на каком железе крутится ESXi.

VTEP на хосте с 64 vCPU при DPDK обрабатывает 100 000+ флоу в секунду. Но DPDK требует выделенных ядер — они полностью уходят под сетевой стек и недоступны для VM. На хостах с Xeon Scalable или EPYC это обычно 2–4 ядра на VTEP-функции. Считайте это заранее при планировании ресурсов.

DDR5 даёт заметный прирост на VTEP-хостах при высоком трафике: шина памяти перестаёт быть узким местом при обработке большого количества мелких пакетов. Если собираете новый кластер под NSX — DDR5 с поддержкой ECC и двухканальным режимом на каждый сокет стоит заложить в спецификацию. Подробнее о том, чем отличается серверная оперативная память по типам и характеристикам, мы разбирали отдельно.

Сетевые карты — отдельная история. NSX поддерживает SR-IOV и DPDK, но не все NIC одинаково полезны. Карты с аппаратной поддержкой VXLAN offload (Intel X710, Mellanox ConnectX-5 и выше) разгружают CPU от инкапсуляции. Без offload на хостах с высоким трафиком процессор начинает греться именно на сетевых задачах — это видно в esxtop по cpu% на vmnic-процессах.

Куда движется технология

Geneve постепенно вытесняет VXLAN как туннельный протокол — гибкие метаданные открывают возможности для L4-L7 сервисов прямо в заголовке. NSX интегрируется с Tanzu для управления сетями Kubernetes-кластеров, и граница между виртуальными сетями ЦОДа и контейнерными оверлеями стирается.

EVPN как control plane для VXLAN — уже не экзотика, а стандарт для новых инсталляций. Это даёт нормальную BGP-сигнализацию для MAC/IP-таблиц без проприетарных контроллеров, что особенно актуально в гетерогенных средах с несколькими вендорами.

Broadcom, который приобрёл VMware, активно продвигает NSX как часть VCF (VMware Cloud Foundation). Это означает, что архитектура будет развиваться в сторону ещё большей интеграции с vSAN и vCenter, а standalone-инсталляции NSX могут постепенно уйти в прошлое. Если планируете долгосрочную стратегию — смотрите на VCF как на целевую платформу.

Если вы только строите SDN-инфраструктуру — смотрите в сторону NSX-T с EVPN-поддержкой и Geneve. Если уже эксплуатируете NSX-V — план миграции лучше составить сейчас, пока это не стало срочным.