Маленькая EVPN/VXLAN-фабрика без тупика: как мы запускали площадку в Амстердаме
Меня зовут Рене, я сетевой инженер в FirstVDS. Я работаю из Иркутска и люблю строить сетевые фабрики на базе VXLAN/EVPN — не в теории, не в лабе, а на практике в жёстком продакшене, где важнее не красивый референс-дизайн, а то, насколько решение готово к авариям, миграциям нагрузки, физическому переезду и неожиданным вводным от бизнеса.
Это первая часть истории про нашу европейскую точку присутствия в Амстердаме. Здесь речь не про сам переезд между дата-центрами, а про стартовый сетевой дизайн: как запустить небольшую площадку с минимальным количеством железа, но не построить тупиковую схему, которую потом придётся переделывать.
Помимо самой фабрики, я сознательно затрону несколько смежных тем: подключение гипервизоров, DDoS-защиту, Flow-коллектор, RTBH, OOBM и консольный доступ. Эти детали не являются центральной темой статьи, но без них картина сетевого дизайна получается неполной.
Названия вендора сетевого оборудования и части подрядчиков я сознательно опускаю. Это не рекламный материал, а архитектурный разбор. Тем, кто работал с такими платформами, класса железа и набора функций будет достаточно, чтобы понять, о каком типе решений идёт речь.
Стартовая задача: минимум железа, но не тупик
Когда компании понадобилась европейская точка присутствия, бизнес пришёл с понятным вопросом: какой минимум оборудования нужен, чтобы запуститься, и можно ли потом масштабироваться без полной переделки сети?
Проект на старте мог и не взлететь, поэтому капитальные затраты хотелось держать под контролем. От сети требовалось следующее:
- стартовать с минимального количества коммутаторов;
- не упереться в тупик, когда потребности масштабирования выйдут за пределы стартового оборудования;
- сохранить возможность горизонтального масштабирования;
- использовать тот же инженерный подход, что и в других локациях;
- на первом этапе не строить полноценную отказоустойчивость, но оставить возможность добавить её позже.
Мой ответ был простым: строим фабрику в архитектуре Clos/Fat-Tree, а, значит, нам нужны Leaf и Spine. На старте — по одному устройству в каждой роли, остальные держим в уме как следующий этап масштабирования.
Leaf должен был выполнять роль коммутатора доступа для серверов виртуализации, поддерживать VXLAN/EVPN и уметь L3-gateway. Для стартовой схемы мы выбрали модель с 48×10G портами под downlink и 6×100G на uplink-портах. Spine — коммутатор с возможностью маршрутизации и deep buffer. Под эту задачу хорошо лёг коммутатор с портовым радиксом 36×40G одного известного производителя.
Самый дешёвый стартовый вариант выглядел бы так: поставить один большой коммутатор, подключить к нему серверы и аплинк, а затем считать задачу закрытой. Проблема в том, что такая схема решает только боль первого дня. Она не даёт нормального scale-out. Когда закончатся порты, появится новая стойка или потребуется разнести подключения по разным устройствам, сеть придётся не расширять, а перестраивать.
Для Clos-модели рост выглядит иначе: если закончились порты на первом Leaf, мы добавляем второй Leaf, подключаем его к Spine и продолжаем предоставлять сервис по прежней логике. Не нужно заново придумывать адресацию, переписывать модель подключения серверов или переносить клиентов в новую сеть.
У нашей схемы есть два естественных драйвера роста. Первый — закончились порты на Leaf. Второй — изменилась физика размещения. Например, новые серверы оказались в другой стойке или на другой площадке внутри дата-центра, и тянуть к ним длинную витую пару становится плохой инженерной идеей. В этом случае новый Leaf нужен не потому, что старый заполнен, а потому что сеть должна соответствовать физическому размещению оборудования.
Хосты виртуализации: routed host networking вместо классического L2
Важная деталь: наши серверы виртуализации не подключаются как обычные хосты в одном большом или нескольких L2-доменах. Мы используем оркестратор виртуализации ISPsystem VMmanager 6 в режиме IP-Fabric, где сеть до гипервизора строится через динамическую маршрутизацию — через BGP.
Каждый гипервизор подключается к фабрике двумя физическими 10G-линками. Каждый линк — это отдельный point-to-point линк с адресацией /31 из приватного диапазона.
На гипервизоре нет LACP bond поверх этих двух портов. Вместо этого на хосте настроены статические маршруты по умолчанию через оба сетевых интерфейса. Оба next-hop равнозначны, поэтому исходящий трафик может распределяться через ECMP средствами Linux, по L4 hash: IP-адрес источника, IP-адрес назначения, протокол, порт источника и порт назначения. Такое поведение требует изменения ряда параметров ядра Linux: по умолчанию используется другой алгоритм выбора пути.
То есть отказоустойчивость и балансировка здесь строятся не через LAG/LACP, а через обычную маршрутизацию. Для сети это два независимых L3-линка, а не один логический L2-агрегат.
Мы сознательно не стали делать классический LAG/Port-channel через LACP bond в режиме 802.3ad. Команда «погонщиков» виртуализации протестировала оба подхода: bond-модель и routed-модель. В продакшен выбрали именно маршрутизацию. По их наблюдениям, routed-вариант давал меньше CPU utilization, позволял сохранить NUMA-локальность и лучше ложился на задачи, где важны pps и bps.
С эксплуатационной точки зрения такая L3-схема даже проще. Если физический линк до Leaf падает, гипервизор видит carrier loss, связанный с этим интерфейсом маршрут по умолчанию перестаёт использоваться, и трафик продолжает идти через оставшийся линк.
LACP/multihoming даёт отказоустойчивость, но добавляет много состояний, которые сложно отлаживать. Уже на этом этапе мы держали в голове будущую топологию, где серверы должны были подключаться не двумя линками в один Leaf, а двумя независимыми L3-линками в разные Leaf. Поэтому сравнение с LACP/multihoming важно не только теоретически — оно напрямую связано с тем, как площадка должна была развиваться дальше.
Отдельная часть схемы — доставка трафика до самих виртуальных машин. Сети виртуальных сетевых интерфейсов на гипервизоре не бриджуются с основной сетью хоста. Между виртуальными интерфейсами и внешней сетью выполняется L3-forwarding на хосте виртуализации. Иными словами, гипервизор не протягивает клиентский L2-сегмент наружу, а маршрутизирует трафик для виртуальных машин.
Маршруты до виртуальных машин анонсируются с гипервизоров по BGP. Каждый гипервизор сообщает, какие VM-префиксы находятся именно на нём. Обычно это host-routes /32 для IPv4-адресов виртуальных машин и /64 для IPv6.
Чтобы не строить full mesh из BGP-сессий между всеми гипервизорами и Leaf-коммутаторами, гипервизоры пирятся с двумя RR-серверами. В этой части схемы гипервизоры и RR находятся в одной ASN: RR принимают маршруты от гипервизоров как iBGP route reflector, а дальше передают их в сторону Leaf уже через eBGP, с политикой не переписывать next-hop. Уникальные приватные ASN на каждое устройство относятся к сетевым устройствам фабрики — Leaf и Spine, — а хостовая часть с гипервизорами и RR живёт в своей BGP-модели.
RR позволяют удержать количество BGP-сессий под контролем и упростить ввод новых гипервизоров через плейбуки Ansible. RR — это такая же Linux-машина с BGP-демоном. Минимум два RR на разных инфраструктурных хостах нужны для того, чтобы отказ одного из них не ломал распространение маршрутов до виртуальных машин.
Тут важна не внутренняя реализация VMmanager, а сама сетевая модель: клиентские адреса не выносятся в общий L2-домен, а становятся маршрутизируемыми префиксами, достижимость которых распространяется через eBGP family unicast.
Почему VXLAN/EVPN, если нагрузка в основном маршрутизируемая
На первый взгляд может возникнуть вопрос: если хосты виртуализации подключаются через маршрутизацию, зачем вообще нужен VXLAN/EVPN? Почему не построить чистую IP-фабрику без overlay?
Причин несколько.
Во-первых, у нас уже был накоплен серьёзный эксплуатационный опыт с VXLAN/EVPN. Мы понимали, какие версии программного обеспечения стабильны, какие функции на каких чипах работают предсказуемо, какое оборудование подходит нам по цене и по производительности, а какие варианты лучше не брать в продакшен. Когда уже есть отлаженная автоматизация и понятный набор проверенных шаблонов, развернуть такую фабрику можно быстро и без большого объёма ручных операций.
Во-вторых, текущая нагрузка не обязана навсегда оставаться единственным сценарием.
Сегодня в локации продаются VDS, и основная модель — маршрутизация до гипервизоров. Завтра бизнес может решить продавать в Амстердаме bare metal для массового рынка. И как бы мы ни вдохновлялись RFC 7938, реальные сервисы могут оказаться разными. Например, это могут быть сервисы для корпоративного заказчика, где по сей день любят L2 и часто требуют его просто потому, что так исторически сложилось.
Многолетний опыт работы в корпоративных средах, где либо не умеют, либо не хотят нормально планировать сеть, наводит меня на мысль, что «один большой VLAN на всё» для многих до сих пор остаётся базовым требованием. Так быть, конечно, не должно, но реальность от этого не меняется. Такой клиент вполне может потребовать не routed-модель, а обычное мостовое подключение своих серверов или гипервизоров.
При этом строить современную дата-центровую сеть на L2 — плохая инженерная практика и моветон. И проблема не только в размере конкретного L2-домена. Сама модель хуже управляется: широковещательный трафик, зависимость от ARP/ND, обучение MAC-адресов, риски петель, неявное поведение при отказах и сложная диагностика. Чем больше такая сеть, тем сильнее проявляются эти проблемы, но принципиально они никуда не исчезают даже в небольших сегментах.
Реальность такова, что спрос на L2-сервисы со стороны заказчиков никуда не делся. Если это не заложено в дизайн заранее, потом останется два варианта: отказывать или срочно что-то придумывать. L2 в дата-центре должен быть вынужденным сервисом, а не основой архитектуры.
EVPN/VXLAN позволяет эмулировать L2 поверх маршрутизируемой фабрики, не превращая весь дата-центр в набор мостовых соединений. А наша текущая маршрутизируемая нагрузка аккуратно ложится в отдельный routing-instance поверх overlay-сети и не смешивается с underlay. При необходимости рядом можно добавить новые L2-сервисы, отдельные VLAN/VNI, MAC-VRF и другие сценарии — не ломая базовую архитектуру.
То есть VXLAN/EVPN здесь не потому, что нам обязательно нужно растягивать L2 прямо сейчас. Он нужен как универсальная сервисная плоскость, которая не заставит нас в будущем переезжать на новую архитектуру.
Стартовая фабрика: ERB, eBGP и lean Spine
Как и было запрошено на старте, мы запускались с одним Leaf и одним Spine.
Формально это уже Spine–Leaf, хотя с точки зрения отказоустойчивости такая схема, конечно, не является полноценной сетью Clos. Но на этом этапе было важнее другое: мы сразу заложили правильные роли устройств и правильную плоскость управления, а не построили временную сеть, которую потом пришлось бы болезненно апгрейдить.
Мы используем модель ERB — Edge-Routed Bridging. В такой архитектуре маршрутизация выполняется на краю фабрики, ближе к серверам, то есть на Leaf-коммутаторах. Spine остаётся транспортным уровнем underlay и не превращается в центральную точку маршрутизации всех L3-сетей в overlay.
Leaf в нашей схеме выполняет сразу несколько ролей:
- коммутатор доступа для серверов виртуализации;
- VTEP, то есть точка терминации VXLAN-туннелей;
- L3 шлюз для маршрутизации между VLAN/VNI через IRB-интерфейсы;
- выполняет роль stateless firewall, но объём правил ограничен ресурсами TCAM чипа;
- border leaf для выхода в интернет и подключения внешнего IP-транзита через единственного ISP.
Underlay собран на eBGP: отдельные point-to-point-связи между Leaf и Spine, отдельная адресация, отдельные BGP-соседства. Overlay control plane работает через MP-EBGP EVPN, а data plane — через VXLAN. Для выделения ASN использовалась модель с уникальным приватным номером автономной системы под каждое сетевое устройство фабрики: у каждого Leaf и Spine была своя ASN.
eBGP с уникальными ASN хорошо формализуется: у каждого устройства чётко определены роль, соседи, address families, политики и маршруты. Для автоматической валидации это удобнее, чем более свободная iBGP/RR-топология. Но на Spine'ах обязательно должен быть настроен next-hop unchanged для EVPN-маршрутов транзитных Leaf, потому что eBGP по умолчанию переписывает next-hop своим адресом, что ломает VTEP-to-VTEP reachability.
Есть и практический плюс для эксплуатации: по AS-PATH очень наглядно видно, через какие устройства проходит маршрут внутри фабрики. Это удобно при диагностике и при разборе несимметричных или неожиданных путей. А если нужно временно увести трафик с проблемного участка, можно повлиять на выбор пути стандартными BGP-инструментами, например добавив AS-path prepend на нужном направлении.
Spine на первом этапе был почти без нагрузки. Он стоял, гудел и ждал момента, когда в фабрике появится второй Leaf. Это может выглядеть избыточно, но в такой архитектуре Spine — не лишняя коробка, а задел под нормальный горизонтальный рост.
В этой роли Spine можно считать lean spine: он обеспечивает IP-связность underlay между Leaf-коммутаторами и может участвовать в BGP overlay, распространяя EVPN-маршруты. При этом ему не обязательно быть VTEP, не обязательно терминировать VXLAN и не обязательно держать IRB-шлюзы клиентских сетей.
Аплинк к IP-транзиту был заведён на Leaf. Физически это был 2×10G LACP bundle. С внешним оператором мы подняли две BGP-сессии и начали анонсировать наши префиксы. Полную таблицу маршрутизации на Leaf мы не принимали: для стартовой схемы было достаточно default-route от оператора. RIB для внешней связности оставался минимальным.
Так мы получили минимальную, но не тупиковую площадку: первые серверы виртуализации, VLAN/IRB под серверные подключения, overlay через EVPN и готовность добавить следующий Leaf без смены архитектуры.
Сервисные контуры: DDoS, OOBM и телеметрия
После запуска площадки клиенты быстро начали запрашивать DDoS-защиту. Для этого мы подключили внешнего поставщика фильтрации трафика.
Аплинк к DDoS-транзиту был аналогично заведён на Leaf, через наших постоянных партнёров, специализирующихся на подобном сервисе. Физически это также 2×10G LACP bundle. Мы подняли две BGP-сессии: фактически это были две отдельные point-to-point-стыковки в разных юнитах, с собственной адресацией для каждой сессии.
Важное требование было таким: защищённый трафик не должен смешиваться с обычным IP-транзитом на уровне маршрутной политики. Поэтому мы вынесли DDoS-направление в отдельный VRF.
Внутри этого VRF был выделен отдельный свободный на тот момент префикс. Он анонсировался только в сторону провайдера DDoS-фильтрации. В результате в сети появились две логические зоны: основной VRF с обычным IP-транзитом и отдельный VRF для DDoS-protected transit.
Исходящий трафик с защищённого ресурса направлялся через FBF — filter-based forwarding. На интерфейсах, смотрящих в сторону родительских серверов, применялся фильтр: если source IP попадал в защищённый префикс, для такого трафика выбирался routing-instance с DDoS-защитой.
Обратное направление было сделано через статический маршрут с действием next-table. Такая конструкция означает не перенос пакета между VRF, а повторный lookup в другой таблице маршрутизации. В нашем случае маршрут из защищённого VRF продолжал поиск в таблице базового VRF, где уже находились маршруты до нужных виртуальных машин и гипервизоров.
С точки зрения клиента схема выглядела просто: он заказывает услугу и получает адрес из необходимого пула — обычного или защищённого. На стороне серверов при этом не требовалось менять модель подключения. Вся разница оставалась внутри сетевой маршрутизации и фильтров внутри VRF.
Такой подход удобен ещё и тем, что хорошо переживает будущие изменения. DDoS-сервис можно переносить, расширять, менять внешние стыки или политику фильтрации, не смешивая его с обычным транзитом и не переписывая базовую схему подключения гипервизоров.
Сеть в Амстердаме мы эксплуатируем удалённо. Делать это через саму продакшен-сеть было бы плохой идеей: если ошибка в конфигурации, отказ control plane или проблема с аплинком ломает основную связность, доступ к оборудованию всё равно должен сохраняться.
Поэтому управление сетевым оборудованием вынесено в отдельный OOBM-контур — out-of-band management. Это независимая сеть управления, которая не зависит от клиентского трафика, EVPN/VXLAN-фабрики и внешнего IP-транзита.
Но одного OOBM недостаточно. Бывают ситуации, когда устройство загружается некорректно, ломается конфигурация management-интерфейса или требуется смотреть процесс загрузки до поднятия сети управления. Для таких случаев у нас есть доступ к последовательным консолям коммутаторов через консольный сервер. Терминал всех коммутаторов доступен через web-интерфейс с HTML5-просмотрщиком, поэтому к консоли можно подключиться без физического присутствия в дата-центре.
Для сетевой телеметрии мы используем sFlow. С коммутаторов собираются выборки трафика, а коллектор работает на одной из инфраструктурных виртуальных машин. sFlow не заменяет полноценный мониторинг состояния устройств, BGP-сессий, интерфейсов и ошибок на портах, но хорошо помогает видеть профиль трафика: кто с кем обменивается данными, какие направления растут, какие префиксы дают нагрузку и где может начинаться аномалия.
В контексте DDoS-защиты и внешнего транзита это особенно полезно. Сетевая телеметрия используется не только для ручного анализа, но и для обнаружения DDoS-атак. Если система видит аномальный трафик на конкретный адрес, она может автоматически инициировать RTBH — Remotely Triggered Black Hole. Для этого в BGP анонсируется host-route атакуемого адреса, обычно /32 для IPv4 или /128 для IPv6, с blackhole-community оператора. После этого операторская сеть начинает отбрасывать трафик до того, как он доедет до нашей площадки.
Итоги первой части
Эта первая часть не про героический переезд, а про скучную, но важную подготовку почвы. Мы не пытались сделать маленькую площадку «как-нибудь, лишь бы запустилось». Мы сразу разложили роли: Leaf для доступа и сервисов, Spine для underlay и EVPN control plane, гипервизоры — через маршрутизацию, DDoS — в отдельный VRF, управление — через OOBM.
Главный практический результат здесь простой: минимальная архитектура не обязана быть времянкой. Один Leaf и один Spine — это ещё не полноценная отказоустойчивость, но уже нормальная декомпозиция ролей. Если маленькую площадку с первого дня строить как фабрику, следующие элементы добавляются как штатное расширение, а не как болезненная переделка сети.
Вторая важная мысль: L2 не должен становиться фундаментом дата-центра. Если он нужен заказчику или отдельному сервису, его можно дать как эмулированный L2-сервис поверх EVPN/VXLAN. Но сама фабрика при этом остаётся маршрутизируемой и предсказуемой.
И третья мысль, которая потом сильно пригодилась: хороший дизайн виден не в первый день запуска, а в момент, когда бизнес приносит неприятную вводную. Во второй части как раз будет про это: дата-центр закрывается, оборудование нужно перевозить, а клиентский сервис должен продолжать работать.
Автор статьи: Рене, сетевой инженер FirstVDS
firstvds.ru
