VXLAN: растягиваем L2-сеть между стойками без переделки коммутации

Когда в сентябре мы ставили vSphere 5.1 клиенту, в разделе «Networking» vCenter появилась опция с аббревиатурой VXLAN. Мы её тогда проигнорировали - задача была в репликации ВМ, а не в сетевых экспериментах. Но вопрос зацепил, и последние несколько недель мы разбирались, что это вообще такое и когда это реально нужно.

Коротко: VXLAN - это способ прокинуть L2-сегмент поверх обычной IP-сети, не трогая физические коммутаторы. Черновик стандарта от IETF (draft-mahalingam-dutt-dcops-vxlan, авторы из VMware и Cisco) описывает инкапсуляцию Ethernet-кадров в UDP. vSphere 5.1 - первая коммерческая платформа с нативной реализацией.

Откуда берётся проблема

Классический ЦОД устроен примерно так: у каждого VLAN есть физический или логический сегмент, граница которого определяется конфигурацией коммутаторов. Виртуальные машины одного клиента сидят в своём VLAN, трафик между ними идёт на L2, маршрутизации нет. Всё понятно, всё работает.

Проблема возникает, когда нужно переехать. Live migration - vMotion в терминах VMware - требует, чтобы ВМ до и после переезда находилась в одном L2-домене. Иначе у машины меняется сетевой шлюз, обрываются TCP-сессии, пользователи замечают проблему. Пока вы мигрируете ВМ между хостами в одной стойке или одном здании с единой коммутацией - это не вопрос. Но как только площадок становится две, или просто хосты разнесены по разным физическим сегментам - начинаются танцы с бубном: растянутые VLAN через trunk, STP с непредсказуемым поведением, и вопросы от сетевых инженеров в духе «зачем вы это сделали».

Что предлагает VXLAN

VXLAN решает задачу иначе. Каждый Ethernet-кадр целиком упаковывается в UDP-датаграмму. Заголовок добавляет 24-битный идентификатор сегмента - VNI (VXLAN Network Identifier). Это даёт теоретически 16 миллионов изолированных L2-сегментов против 4094 у VLAN. Транспорт - обычный IP, порт UDP 8472.

Схема инкапсуляции выглядит так:

[Outer Ethernet][Outer IP][UDP][VXLAN Header (VNI)][Inner Ethernet Frame]

Устройства, которые занимаются упаковкой и распаковкой, называются VTEP - VXLAN Tunnel Endpoint. В случае vSphere 5.1 роль VTEP берёт на себя vSwitch на гипервизоре. Физическим коммутаторам всё равно - они видят обычные UDP-пакеты и маршрутизируют их как IP.

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

Как это работает в vSphere 5.1

В vSphere 5.1 VXLAN появляется в составе vSphere Distributed Switch. Для работы нужен vCenter - и компонент vShield Manager, который управляет VTEP-конфигурацией на хостах.

Мы развернули тестовый стенд: два хоста ESXi 5.1 в разных IP-подсетях, vCenter, vShield Manager 5.1. Создали Distributed Switch, добавили VXLAN-сегмент. Подняли две тестовые ВМ - одну на каждом хосте - в одном VNI. Пинг прошёл без изменений в конфиге физического коммутатора. Wireshark на физическом интерфейсе подтвердил: трафик идёт как UDP на порт 8472, внутри - Ethernet-кадры ВМ.

После этого попробовали vMotion между хостами. ВМ переехала без потери пинга - именно то, ради чего это затевалось.

Что не так просто

Multicast на физической сети. VXLAN в текущем черновике для BUM-трафика (broadcast, unknown unicast, multicast) использует IP multicast. Физические коммутаторы должны поддерживать и настраивать IGMP snooping и PIM. Если сеть к этому не готова - VXLAN в исходном виде не взлетит. В vSphere 5.1 это требование явное: нужен multicast-диапазон, назначенный каждому VNI.

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

Диагностика сложнее. Когда что-то не работает на L2 - берёшь Wireshark и смотришь. Когда трафик инкапсулирован в UDP - нужно смотреть на двух уровнях сразу: и на физической сети, и внутри туннелей. Сетевые инженеры, привыкшие к обычным VLAN, поначалу смотрят на это настороженно.

MTU. VXLAN-заголовок добавляет 50 байт к каждому пакету. Если физическая сеть настроена на стандартный MTU 1500 - всё равно получится фрагментация или проблемы с производительностью. Нужно либо поднимать MTU на физических интерфейсах до 1600+, либо настраивать jumbo frames. На нашем стенде пришлось поменять MTU на uplink-интерфейсах хостов.

Зачем это нам

Несколько клиентов из тех, кого мы ведём в рамках поддержки инфраструктуры, уже столкнулись с ситуацией: нужна живая миграция ВМ между двумя физическими локациями, а переделывать физическую коммутацию - дорого, долго и требует согласования с провайдером или службой безопасности. VXLAN выглядит как реалистичный ответ на этот запрос, если физическая сеть готова к multicast.

Пока мы это только щупаем в тестовой среде. Prodaction-задача с VXLAN у нас появится - скорее всего, вопрос нескольких месяцев. Как появится - напишем по итогам.

Черновик в IETF продолжает обсуждаться, у VMware реализация уже есть, Cisco поддерживает в Nexus 1000V. Это не экзотика - это направление, которое стоит понять заранее, а не когда клиент приходит с конкретной задачей.