GetNet

Задача сформулирована исходя из критериев, характерных для компании-интегратора, которая обслуживает и строит крупные сети, но при этом имеет и собственную инфраструктуру. Штат такой компании — порядка одной-двух тысяч человек, и у неё есть свой небольшой ЦОД. Он и взят за референс; плюс-минус такие же ЦОДы встречаются и в других компаниях.
Это небольшой ЦОД на 10 стоек, каждая стойка по 7 кВт. В каждой стойке максимум 12 серверов — ограничение возникает из-за мощности, хотя по факту можно уйти и в плюс. Из каждого сервера берётся минимум по два порта 10 Гбит/с.

В цифрах картина выглядит так. 10 стоек по 12 серверов дают 120 серверов, а в сумме — 240 портов. Сети управления на данный момент нет: возможно, некоторая её часть и присутствует, но будем считать, что её нет. Условно она есть на уровне СКС, но именно сети управления с точки зрения инфраструктуры нет — её тоже предстоит сделать.

Подключается сервер, подключается коммутатор — имеется в виду менеджмент-подключение с out-of-band-управлением. Получается 120 серверов плюс N сетевых устройств. Почему N — потому что их количество пока не посчитано; оно будет определено далее.

Ещё один момент, который нужно учесть, — переподписка. Это параметр, который считают всегда на коммутаторах в сторону хостовых включений. По сути, она возникает везде в том или ином виде, но основная идея именно здесь.

Переподписка — это соотношение ёмкости хостовых портов к ёмкости сетевых портов (тех, что смотрят наверх). Идея такая: если в какой-то момент все подключённые серверы дадут burst по трафику и каждый нагрузит свой линк на максимум, то в единицу времени на коммутаторе окажется занято, например, 200 Гбит/с, и их нужно отдать наверх. Если наверх ведёт один линк на 100 Гбит/с, возникает соотношение 2:1 — то есть 50 % трафика будет отброшено.
На практике это не страшно: таких burst-ов в среднем почти не возникает.

Эта рекомендация растёт корнями из дизайнов Cisco, но так делают многие, и это приемлемо. Некоторые более важные элементы стоит делать 1:1 — когда burst реально возникает и его нужно полностью передать наверх. Такие требования тоже встречаются. Главное — этот параметр нужно учитывать. Для сети управления он значения не имеет: если там появляются burst-ы по 100 Гбит/с, значит, что-то идёт не так.

Внутри ЦОД есть два типа направления трафика

Существует несколько стандартных вариантов. Классическая трёхуровневая топология имеет очевидный минус — наличие уровня ядра (core). Взаимодействие между разными элементами на уровне access всегда идёт через уровень core, а это лишние хопы. При этом топология хорошо адаптирована именно под трафик север-юг, поскольку пришла из кампусных сетей. В кампусе она показывает себя отлично, потому что пользователи практически никогда не общаются напрямую.

То же самое справедливо для сети OOB. OOB-сеть направлена исключительно на взаимодействие север-юг: не бывает такого, чтобы один коммутатор подключался по менеджменту к другому. Исключение — когда кто-то потерял доступ, зашёл консолью и переходит вручную. Обычно же подключение всегда идёт откуда-то извне и персонифицировано на каждый узел.

Для основного трафика есть де-факто стандарт в мире ЦОД — так называемый Clos, он же spine-leaf, он же fat tree. Это плюс-минус синонимы; за этими аббревиатурами стоит достаточно сложная историческая справка, которую при желании можно изучить отдельно.

Это ровно то, что нужно для основного трафика, потому что основной трафик ЦОД — как показывают статистические выкладки последних лет — это как раз East-West. Это связано с тем, что внутри ЦОД ходит много репликаций и внутренней информации, а наверх отдаются только короткие пакеты, и трафика там немного.

Минус топологии в том, что она в целом дорогая: её нужно строить сразу целиком, заранее закладываясь на все линки, покупая трансиверы и так далее. Но на скоростях 100 Гбит/с это приемлемо.

Существуют и более современные методы. Самый популярный на данный момент — Dragonfly+, топология, которую у себя реализовали в Яндексе. Она имеет плюсы по стоимости портовой ёмкости, так как подразумевает меньшее количество подключений. Но это играет роль уже на скоростях 400G и 800G, где трансивер по стоимости сопоставим с самолётом. У неё есть и существенные минусы: сложный, точнее очень специфичный роутинг — множество простых нюансов, которые вместе образуют запутанный клубок. Для рассматриваемой задачи это неприменимо.

По большому счёту существует два типа коммутаторов.

Для сети управления подходит коммутатор с 48 гигабитными портами и 4 портами 10G — в примере это модель MikroTik. По требованиям нужно обслужить 120 серверов плюс некоторое количество сетевого оборудования, поэтому имеет смысл брать с запасом — 4 таких коммутатора, что даёт портовую ёмкость 192 порта.

Особенность решения в том, что ставятся, по сути, 4 access-коммутатора, один из которых выступает агрегатором: три access подключаются к нему портами 10G, ещё одна десятка остаётся свободной на случай необходимости. К этому же агрегатору можно подключать и другие линки.

Для обеих сетей — управления и data — нужен маршрутизатор, который умеет в IPsec. Минимально нужны гигабитные порты для подключения провайдера, при необходимости — подключение десятками снизу.

Ещё один полезный и часто выручающий девайс — терминальный сервер. Через него организуется консольный доступ. По сути, он имеет порты RJ45: в меди из консольного порта устройства через патч-панели линия дотягивается до терминального сервера, который подключается в OOB-сеть. Подключаясь по Telnet или SSH к его специфичному порту, попадаешь на консоль нужного устройства.

Data-сеть — это сеть, куда включаются хосты. Здесь порты должны быть 100 Гбит/с и 10 Гбит/с. Функционал уровня leaf должен быть относительно богаче, чем у spine.

Border leaf — это точно такой же стандартный коммутатор уровня leaf, встроенный в топологию так же, как обычный, но с другой задачей: в него подключаются не хосты, а внешние сети — другой ЦОД, firewall или что-либо ещё. На схеме слева как раз изображены border leaf, к ним подключены роутеры.

Оборудование собрано и стоит, лампочки моргают, но пока ничего не работает — нужно всё настроить. Стандартный вариант, который использовался более 10 лет назад, — Spanning Tree (STP) плюс MLAG. Есть вариант не тянуть L2 и делать чистый L3, но он в данном случае не подходит.
Причины следующие. При STP заблокирована половина линков. При чистом L3 не получится разделять трафик на потоки по зонам безопасности: трафик всё равно будет смешиваться и не пойдёт только через firewall. Пришлось бы делать истории с VRF и VRF-lite, что неудобно и сложно в эксплуатации, а также возникает ограничение по количеству подсетей.
Поэтому была разработана конструкция EVPN VXLAN. Она пришла из сетей провайдеров:

Идея в том, чтобы разделить трафик на плоскости. Есть транспортная (underlay) сеть, которая всегда стандартна: её не трогают и не меняют. И есть overlay-сеть. В рассматриваемой схеме spine относятся практически всегда только к underlay и в overlay не участвуют. Это спорный момент: на них можно навешивать функции route reflector или route server для обмена маршрутной информацией. Но организация туннелей всегда происходит на уровне leaf — коммутаторов, которые смотрят в сторону хостов.
При этом открываются все линки для трафика, в том числе для L2, так как используются L3-линки и STP уже ничего не блокирует. Доступно огромное количество так называемых VNI — метка принимает значения в несколько миллионов, что позволяет создать множество разделённых между собой сетей и разбить их на зоны безопасности.

Всё работает средствами MP-BGP, где EVPN — это address family для BGP. Знание L2/L3 VPN становится обязательным — хотя бы в общих чертах: как формируется L2/L3 VPN на примере стандартного сценария MPLS. В рамках разбора проблем приходится погружаться достаточно глубоко, а EVPN VXLAN — комплексная технология, включающая классические сети, маршрутизацию и коммутацию.

Причина выбора EVPN VXLAN — это сейчас фактический стандарт. Большинство сетей его эксплуатируют, показывая хорошую устойчивость. Нет задачи экспериментировать над продуктивной сетью — для экспериментов есть прекрасные лабораторные инструменты.

Внешние сети в рамках EVPN VXLAN подключаются следующим образом. Border leaf уходят в spine. В примере рассмотрены два варианта: в сторону второго ЦОД (появляется ещё одна пара border leaf 3–4) и в сторону firewall — какого-то внешнего сегмента (кампус и т. п.).Существует два сценария :

Без ряда служб инфраструктура будет в шатком состоянии. В качестве мониторинга — SNMP. Обязательно NTP: логи должны быть с актуальным временем. AAA — must have, потому что нужно понимать, кто зашёл на коробку и что сделал. Соответствующие open-source-инструменты приведены в материалах.
Первичная автоматизация — полезное дело.Минимум по автоматизации, который используется регулярно: проверка коммутации, создание конфигураций, плагины в NetBox, а также сбор специфичных данных с узлов и их разбор — например, сбор серийных номеров в моменте. Отказываться от этого точно не стоит.
Ещё два немаловажных инструмента. NetBox — нужно понимать, что происходит с инфраструктурой и IP-адресацией. Резервное копирование конфигураций — обязательно. Инженеры делятся на три типа: те, кто не делает бэкапы; те, кто делает бэкапы; и те, кто делает бэкапы и проверяет их. Разумно сразу перейти на третий уровень.