Хоронили VLANы — порвали два баяна и счастливы вместе с Leaf-Spine архитектурой

Дисклеймер

Основное, чем хочется поделиться, — это подход. Мы не изобретали велосипед: сетевая архитектура эволюционирует естественным образом, и переход от классической топологии к Leaf-Spine — это предсказуемый «этап жизни» в развитии облачного провайдера. Важен сам подход к эволюции — не от большой нужды из-за накопившихся проблем, а благодаря стратегическому взгляду и живому интересу к авангардным решениям.

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

Смена топологии

Изначально мы использовали классическую топологию, она же — топология Typical 3-Tier, унаследованная от древовидной архитектуры и реализуемая на канальном уровне L2.

В нашем случае, на верхнем уровне располагались взаимосвязанные Border-switch, к ним были подключены взаимосвязанные Aggregation-switch и/или Core-switch, к ним — коммутаторы доступа (Access) с линками к рабочим машинам (последние на иллюстрации не указаны).

Число машин стабильно увеличивается, растет нагрузка на сеть. Как следствие, увеличивается число коммутаторов доступа, часть из них резервируется посредством MLAG. Оперировать таким количеством взаимосвязей — иногда избыточных — и, тем более, объяснять их новым инженерам в растущей команде — сомнительное удовольствие. С точки зрения архитектуры, такая схема со временем вырождается в сложности горизонтального масштабирования и расширения пропускной способности сети.

Было решено пересмотреть архитектуру. Нынешняя топология — Leaf-Spine — унаследована от топологии Клоза и реализуется на канальном и сетевом уровнях L2-L3 (все порты коммутаторов работают в L3-режиме). Каждый Leaf-узел подключен к каждому Spine-узлу, при этом Spine-узлы не связаны между собой.

IP-фабрику мы построили на свежекупленных 100-гигабитных коммутаторах Extreme X870-32c и Juniper qfx5120-32c. Приступаем к настройке сети.

Протоколы и методы маршрутизации сети

• BGP — протокол динамической маршрутизации трафика, предназначенный для обмена информацией о достижимости подсетей между автономными системами (АС).
  • internal BGP (iBGP) — используется для описания связи внутри АС;
  • external BGP (eBGP) — используется для описания связи между АС;
  • EVPN — расширение BGP, сигнализирующее о доступности узла и передающее его MAC- и IP-адреса;
• BFD — протокол обнаружения переадресации трафика;
• ECMP — механизм балансировки трафика.

Сеть настраивается в два слоя: underlay и overlay.

Underlay строится на eBGP, каждому из Leaf-узлов присваивается номер АС. Узлы обмениваются loopback. Каждая рабочая машина подключена двумя линками к разным Leaf-узлам, от них идут по два линка к каждым Spine-узлам. Трафик между линками балансируется ECMP.

Overlay строится на iBGP и определен одной АС. Связь в overlay осуществляется через EVPN/VXLAN-туннель. EVPN используется в качестве плоскости соединения L2- и L3-уровней посредством инкапсуляции L2-кадров в L3-пакеты. VXLAN применяется для расширения адресного пространства — с 4 тысяч адресов, доступных на уровне L2, до 16 миллионов на уровне L3.

Конечными точками EVPN/VXLAN-туннеля являются VTEP — Virtual Tunnel End Point. VTEP — это не обязательно сетевое устройство, в его роли может выступать и рабочая машина с поддержкой технологии VXLAN. EVPN/VXLAN туннели мы строим между Spine-узлами и рабочими машинами.

В качестве VTEP на стороне рабочих машин настраиваем инкапсулирующий сетевой мост. После того, как на одном из узлов настроен VTEP, все остальные узлы узнают об этом автоматически по BGP — в отличие от handjob, применимый к VLAN. Настройку рабочих машин реализуем через FRRouting — ПО, развивающее возможности Quagga для маршрутизации в UNIX-подобных системах. FRR имеет Cisco-like интерфейс и активно поддерживается сообществом, шлем привет и лучи любви.

При конфигурации FRR мы:

1. Определяем peer-группы для overlay и underlay, настраиваем на них BFD. BFD существует параллельно BGP, поскольку быстрее, чем BGP, справляется с переадресацией трафика, если активный линк перестанет работать.
2. Настраиваем underlay: для каждого Leaf-узла, к которому подключена рабочая машина, указываем loopback и номер АС.
3. Для overlay указываем общий номер АС, loopback, и АС для каждого из Spine-узлов.

Вот и вся магия, если не углубляться совсем уж в мелкие костыли. В заключение, пара рекомендаций by design, которых мы придерживались:

Соотношение Leaf- и Spine-узлов: максимальное количество Leaf-коммутаторов в топологии определяется плотностью портов Spine-коммутаторов. А количество Spine-коммутаторов определяется комбинацией требуемой пропускной способности между конечными коммутаторами, количеством избыточных/ECMP (эквивалентных многопутевых) путей и плотностью портов.

Коэффициент переподписки  — соотношение между пропускной способностью восходящего потока (к магистральным коммутаторам) и пропускной способностью нисходящего потока (к серверам/хранилищам). Его можно измерить в направлении север/юг (трафик, входящий/выходящий из ЦОД) и в направлении восток/запад (трафик между устройствами в ЦОД). Наиболее распространенный коэффициент переподписки в современных сетевых архитектурах составляет 3:1.

Многое о BGP-протоколе хотелось бы рассказать отдельно — этим мы займемся в следующем материале, как только разберемся с коробкой ваших валентинок Мише Охрименко и стопкой гневных писем в редакцию.