Leaf-spine сеть ЦОД: когда переходить с двухуровневой схемы

Зачем вообще менять топологию сети в ЦОД

Пока ЦОД небольшой, сеть часто работает без сюрпризов. Есть несколько коммутаторов доступа, пара агрегации - все понятно и привычно. Сложности начинаются не в день запуска, а когда добавляются новые стойки, сервисы и требования к скорости.

Обычно первой всплывает не «нехватка пропускной способности», а набор мелких, но регулярных проблем: не хватает портов в нужном месте, растет количество аплинков и патчкордов, сложнее держать одинаковые настройки, а любое расширение превращается в проект с риском простоя. Параллельно появляется и другая симптоматика: скачки задержек из-за перегрузки аплинков, рост east-west трафика (между серверами), сложнее прогнозировать oversubscription и его последствия.

В какой-то момент вы упираетесь не только в железо, но и в «геометрию» сети. Тогда и возникает вопрос: продолжать наращивать классическую двухуровневую сеть ЦОД или перейти на leaf-spine, где масштабирование и пути трафика устроены иначе.

Чаще всего сравнивают два варианта:

• Двухуровневая схема (доступ + агрегация), где рост идет через добавление аплинков и или усиление агрегации.
• Leaf-spine, где стойки подключаются к leaf, а leaf подключаются к spine по одинаковым правилам.

Чтобы принять решение без «на глаз», важно заранее понимать, на каких нагрузках смена топологии реально оправдана, какие метрики посмотреть до покупки оборудования и что заложить в коммутаторы и оптику (10G, 25G, 100G и выше), чтобы сеть росла без переделок.

Двухуровневая и leaf-spine простыми словами

Двухуровневая сеть ЦОД обычно выглядит так: на стойках стоят коммутаторы доступа (ToR или EoR), а выше - пара мощных коммутаторов агрегации или ядра. Серверы подключены к доступу, доступ поднимается аплинками в агрегацию, а дальше трафик уходит либо в другие стойки, либо наружу к пользователям и сервисам.

Leaf-spine сеть устроена иначе. Коммутаторы leaf стоят у серверов, как ToR, но каждый leaf подключается не к одному уровню агрегации, а ко всем spine. Spine образуют общую «фабрику»: между любыми двумя стойками есть несколько равнозначных путей, а маршрутизация распределяет потоки.

Разница сильнее всего заметна на east-west трафике (между серверами). В двухуровневой схеме обмен между стойками часто проходит через агрегацию, и при росте нагрузки именно там появляется узкое место. В leaf-spine обмен чаще всего идет leaf -> spine -> leaf, то есть почти всегда с одинаковым числом «прыжков». Для north-south (к пользователям, интернету, офисной сети) обе схемы могут работать хорошо, но leaf-spine обычно проще расширять без перестройки «центра».

Если совсем коротко:

• Задержки: в leaf-spine они более предсказуемы, потому что путь чаще одинаковый.
• Масштабирование: в двухуровневой схеме упираются в ядро, в leaf-spine добавляют leaf или spine по мере роста.
• Кабели: leaf-spine требует больше межстоечных соединений, зато меньше «особых» линков к ядру.
• Oversubscription: в leaf-spine проще держать понятные коэффициенты, но их нужно заложить в дизайн заранее.

Пример: если кластер виртуализации или база данных активно общается между узлами в разных стойках, переход на leaf-spine часто ощущается сразу - меньше очередей на верхнем уровне и стабильнее время отклика.

Когда двухуровневая схема остается хорошим выбором

Двухуровневая сеть (доступ + агрегация) выглядит скучно, и это ее плюс. Если ЦОД небольшой и рост понятен, вы получаете рабочую схему с меньшим числом устройств, кабелей и настроек. В таких условиях leaf-spine может добавить сложности больше, чем дать пользы.

Самый частый сценарий, где двухуровневая схема оправдана, - предсказуемые нагрузки и небольшой парк стоек. Когда у вас условно 3-10 стоек, а серверы в основном ходят в интернет, к пользователям и в центральные сервисы, ключевыми становятся простота и стоимость, а не максимальная масштабируемость.

Когда трафик в основном north-south

Если сервисы классические (почта, файловые ресурсы, 1С/ERP, доменные службы, VDI для части сотрудников), заметная часть обмена идет «наружу» от серверов, а не «внутри» между ними. При таком профиле трафика двухуровневая схема обычно справляется, если аплинки с доступа на агрегацию подобраны без явного узкого места.

Признаки, что можно оставить схему как есть:

• стоек мало, добавление идет редко и небольшими шагами
• нет плотных кластеров с большим east-west трафиком
• важны простые аварийные сценарии и понятная диагностика
• бюджет ограничен, а обновлять нужно не только сеть, но и серверы или СХД
• команда небольшая и нет ресурса на сложные изменения

Пример: региональная организация держит 6 стоек с виртуализацией, телефонией, ERP и резервным копированием. Пики бывают утром и в конце месяца, но межсерверный обмен умеренный. В таком ЦОД часто разумнее вложиться в надежные коммутаторы доступа, нормальные аплинки и запас портов, чем перестраивать топологию.

Если планируете закупки и внедрение комплексно (серверы, стойки, сеть, поддержка), системный интегратор вроде GSE.kz обычно начинает с профиля трафика и плана роста, а не с выбора «модной» схемы.

На каких размерах и нагрузках leaf-spine дает смысл

Переход на leaf-spine обычно оправдан не «с определенного числа стоек», а с момента, когда предсказуемость и равномерность становятся важнее минимальной цены порта. Если большинство потоков идет не наружу (north-south), а между серверами внутри ЦОД (east-west), двухуровневая схема чаще упирается в узкие места и неравномерные задержки.

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

Еще один признак - регулярные расширения. Когда вы добавляете стойки каждые несколько месяцев, хочется подключать новые ToR как конструктор: добавил leaf, поднял аплинки, получил те же характеристики, что и у соседей, без перестройки ядра.

Leaf-spine чаще выбирают, если нужны:

• более ровная задержка и пропускная способность между любыми стойками
• горизонтальное масштабирование без крупных переделок
• понятный переход на 25/100/200/400G по мере роста
• контроль oversubscription на каждом leaf, а не «как получилось»

Простой пример: было 6 стоек с классическими сервисами и редкими бэкапами по ночам. Затем добавили кластер виртуализации, репликацию данных и ежедневные бэкапы в соседний пул хранения. Трафик между стойками стал постоянным, и в этот момент leaf-spine обычно дает заметный эффект: меньше неожиданных узких мест и проще планировать рост скоростей и портов.

Как принять решение: пошаговая оценка под ваш ЦОД

Решение о переходе на leaf-spine упирается в цифры: сколько у вас стоек, какие скорости на серверах, какой трафик внутри ЦОД и какой запас нужен на рост.

Проверка, которая помогает не ошибиться:

• Зафиксируйте текущие и целевые масштабы: число стоек и серверов, сколько портов нужно в каждой стойке, какие скорости на доступе (10G, 25G) и вверх (40G, 100G). Считайте по факту: что занято сейчас и что планируется через год.
• Измерьте профиль трафика: что преобладает - east-west или north-south. Посмотрите пики по времени и по сервисам (например, резервное копирование ночью, отчеты в конце месяца).
• Выберите целевой oversubscription отдельно для стойки и для всей фабрики. Чем больше внутренних обменов и распределенных систем, тем ближе хочется к 1:1 в стойке и к предсказуемому поведению в межстоечном сегменте.
• Прикиньте архитектуру на 2-3 года вперед: сколько uplink нужно с каждого leaf, сколько spine потребуется и какой останется запас по портам. Если расчет показывает, что при росте вы упретесь в порты или скорости уже через год, это прямой сигнал.
• Проверьте физические ограничения: место в стойках под коммутаторы и патч-панели, питание и охлаждение, реальный маршрут для кабелей. Часто именно кабельная плотность и место в лотках становятся стоп-фактором.

Небольшой пример: сейчас 8 стоек, в каждой по 20 серверов с 10G, трафик в основном north-south. Двухуровневая схема обычно живет спокойно. Но если план на год - 24 стойки, переход на 25G и появление кластеров (виртуализация, аналитика, репликация), доля east-west быстро растет. Тогда стоит заранее посчитать oversubscription и портовую емкость: может оказаться, что проще спроектировать фабрику сейчас, чем «латать» аплинки и менять ядро по частям позже.

Требования к коммутаторам: leaf и spine

Коммутаторы для leaf-spine лучше выбирать от задач, а не от «модной скорости». Сначала определите, какие порты нужны на стойку, какой трафик преобладает (east-west или north-south) и как быстро вы планируете расти.

По портам часто работает простое правило: к серверам 10/25G, вверх 40/100G и выше. Если много виртуализации и распределенных хранилищ, 25G к серверу дает лучший запас, чем 10G, а 100G аплинки снижают риск упереться в uplink уже через год. Смотрите не только на «скорость порта», но и на суммарную пропускную способность коммутатора, а также на запас по таблицам маршрутов.

Функции, которые стоит заложить заранее:

• ECMP, чтобы равномерно распределять потоки по нескольким линкам.
• QoS с понятными очередями и приоритизацией (например, для хранилища и голоса).
• Телеметрия и экспорт статистики (sFlow/NetFlow), чтобы видеть узкие места.
• LACP; MLAG нужен, только если вы сознательно оставляете L2-агрегацию и хотите L2-отказоустойчивость.

Отдельно проверьте буферы и поведение при микроберстах. Для смешанных потоков (резервные копии, репликация, VM-migration) маленькие буферы могут давать кратковременные потери пакетов и странные просадки, даже если средняя загрузка низкая.

По границе L2/L3 чаще выигрывает L3 до стойки: меньше широковещаний, проще масштабирование, меньше «сложных» инцидентов. Если планируете оверлеи, заложите VXLAN/EVPN на leaf (роль VTEP), а spine часто достаточно как IP-фабрики.

Пример: вы переводите стойки с 10G на 25G, и в пике резервное копирование бьет по нескольким серверным группам. Если leaf поддерживает ECMP, нормальный QoS и телеметрию, перегрузки становятся видны, и трафик проще разделять без догадок. В проектах системной интеграции (в том числе у GSE.kz) такие требования лучше фиксировать на этапе дизайна, чтобы потом не менять железо из-за одной «неучтенной» функции.

Оптика и кабельная инфраструктура: что закладывать сразу

В leaf-spine кабели и модули становятся частью архитектуры. Ошибка здесь выглядит так: сеть готова к 25G/100G, а реальная скорость упирается в тип оптики, длины линий или нехватку волокон в трассе.

DAC, AOC и оптика: что выбирать на практике

Если коротко: DAC и AOC удобны для близких соединений, а классическая оптика нужна, когда важны дистанции и гибкость.

• DAC (медь) берут для коротких патчей внутри стойки или между соседними стойками, когда важны цена и простота.
• AOC (активный оптический кабель) удобен как «поставил и забыл» на несколько десятков метров, но хуже подходит, если вы хотите легко менять длины и трассы.
• Оптика SR по многомоду подходит для типовых расстояний внутри зала.
• Оптика LR по одномоду нужна, когда стойки далеко, есть несколько залов или нужен запас по дистанции.

Выбор привязывайте к плану размещения: где будут spine, сколько рядов, будут ли отдельные залы, как пройдут лотки и вводы в стойки. Если схема размещения «плавает», чаще безопаснее закладывать вариант, который переживет перестановку без замены трасс.

План по скоростям и запас на расширение

Сразу задайте «лестницу скоростей» на 2-3 года: 10G сегодня, 25G на серверных портах завтра, 100G на аплинках, затем 200G/400G. Оптика и кроссы должны поддержать эти шаги без массовой перекладки.

Чтобы не упираться в расширение каждые полгода, помогает минимум:

• запас по волокнам в магистралях (часто в 1.5-2 раза от текущей потребности)
• кроссы и патч-панели с резервом по портам, а не «впритык»
• единые коннекторы и типы модулей по всему залу
• понятная маркировка: стойка, юнит, порт, тип линии, длина, тип модуля
• учет совместимости модулей и скоростей, чтобы не искать «почему не поднялось» во время работ

Когда эти вещи заранее собраны и документированы, апгрейды проходят заметно спокойнее.

Типовые ошибки при переходе на leaf-spine

Leaf-spine иногда покупают как «быстрый апгрейд», а потом сталкиваются с тем, что задержки растут, линков не хватает, а поиск причины занимает недели. Чаще всего проблема не в топологии, а в решениях, которые были нормальны в двухуровневой сети.

Самая частая ошибка - поставить ToR-коммутаторы (leaf) с 25G к серверам, но сэкономить на аплинках к spine. В итоге oversubscription получается слишком высоким: фабрика есть, а реальной полосы между стойками нет. Это особенно больно при виртуализации, распределенных хранилищах и резервном копировании, где много east-west.

Вторая ловушка - смешение скоростей без плана роста. Сегодня 10G к серверам и 40G вверх кажется разумным, но через год появляются 25G и 100G, и «временные» аплинки становятся постоянным узким местом.

Отдельная тема - MTU и джамбо-фреймы. Если часть сети на MTU 1500, а часть на 9000, оверлеи и хранилища могут работать нестабильно: где-то будет фрагментация, где-то скрытые потери и ретрансляции. Это выглядит как «случайные» тормоза, хотя причина в настройках.

Также часто забывают про отдельное управление и отказоустойчивость. Когда нет OOB-сети, ошибка в фабрике может отрезать доступ к самим коммутаторам, и восстановление превращается в поездку в зал.

Наконец, оптика и трансиверы: непроверенная совместимость модулей, разные партии, разные длины и типы волокна - и вы получаете flaps линка под нагрузкой.

Перед вводом в эксплуатацию проверьте базовые вещи:

• рассчитайте oversubscription и подтвердите его измерениями в тесте
• зафиксируйте целевые скорости (10G/25G вниз, 100G вверх - или ваш вариант) и план апгрейда
• выровняйте MTU end-to-end и проверьте ключевые потоки (хранилище, оверлей, бэкапы)
• сделайте OOB-управление и две независимые линии питания/маршрута
• прогоните оптику и трансиверы на совместимость и стабильность

Короткий чек-лист перед сменой топологии

Перед переходом от двухуровневой схемы к leaf-spine полезно за полчаса зафиксировать несколько цифр и решений. Это убирает споры «на глаз» и быстро показывает, где риск: в портах, в оптике или в ожиданиях по росту.

Важно, чтобы ответы были записаны в одном документе, а не «в голове у инженера»:

• Масштаб и горизонт роста: сколько стоек и серверов будет через 24-36 месяцев, и какая часть роста уже подтверждена проектами.
• Цель по oversubscription: отдельно для стойки (серверы -> leaf) и для межстоечного сегмента (leaf -> spine). Если много east-west (виртуализация, контейнеры, HCI, базы), цель обычно жестче.
• Скорости и стыки: какие порты на серверах (10G/25G), какие uplink у leaf, и какая скорость нужна на выход наружу (WAN/интернет/межЦОД). Важно заранее решить, где вы переходите на 100G, а где достаточно 25G.
• Обязательные функции коммутаторов: ECMP, телеметрия и мониторинг, QoS для критичных приложений, буферы под «взрывной» трафик, поддержка нужных протоколов.
• План по оптике и кабельной инфраструктуре: какие модули берете (SR/LR/DR по вашим расстояниям), реальные длины трасс, запас волокон под расширение, правила маркировки и учета.

Практичный тест: возьмите одну типовую стойку и посчитайте, что будет, если завтра в ней станет на 30% больше серверов. Если сразу упираетесь в uplink или в оптику, leaf-spine стоит планировать уже сейчас.

Пример: как ЦОД вырастает из двухуровневой схемы

Представьте небольшой корпоративный ЦОД на 10-20 стоек. Сеть собрана по классике: доступ (ToR или EoR) и пара агрегационных коммутаторов. На старте это удобно: меньше оптики, понятная схема, расширения редкие.

Через год-два площадка растет до 40-60 стоек. Появляются несколько кластеров виртуализации, отдельная зона резервного копирования, пара «тяжелых» приложений и тестовый контур. Трафик становится смешанным: не только north-south (к пользователям), но и east-west (между серверами) - репликации, storage, сервис-сервис, бэкапы. В этот момент часто всплывает oversubscription: вверх из стоек уводится меньше полосы, чем реально нужно в пике.

Симптомы обычно повторяются:

• агрегация упирается в порты и пропускную способность, особенно в окна бэкапов
• каждое расширение требует «перешивать» схему, двигать VLAN и пересобирать uplink
• задержки между разными зонами получаются разными, и это видно на кластерах

Решение нередко делают поэтапным, без «большого взрыва». Сначала строят новую зону как leaf-spine (например, под новые стойки или под новый кластер). Затем постепенно переносят сервисы: сначала те, кому важны предсказуемая задержка и широкая east-west полоса, потом остальное. Старую двухуровневую сеть оставляют как «остров» на время миграции.

Заранее полезно согласовать с эксплуатацией три вещи:

• единый мониторинг портов и загрузки (и для старой, и для новой зоны)
• инвентаризацию оптики 10G/25G/100G и трасс, чтобы не искать «что воткнули год назад»
• план миграции с тестами: замеры задержек, проверка отказоустойчивости, окно отката

На практике интеграторы (в том числе GSE.kz) часто начинают с пилотной зоны на нескольких стойках: так проще подтвердить расчеты и выбрать коммутаторы и типы оптики без риска для всего периметра.

Следующие шаги: пилот, план миграции и поддержка

Чтобы переход на leaf-spine не превратился в «большой взрыв», начните с подготовки: актуальная схема, скорости на аплинках и портах серверов, где уже есть узкие места, прогноз по росту стоек на 12-24 месяца. Отдельно выпишите критичные приложения и что для них важнее: задержка, пропускная способность, предсказуемость или простота обслуживания.

Дальше имеет смысл сделать пилот на небольшом сегменте, а не на всей площадке. Практичный вариант - 1-2 стойки с типовой нагрузкой (например, кластер виртуализации и хранилище), подключенные к новым leaf и spine.

План пилота обычно укладывается в несколько шагов:

• Зафиксировать «как сейчас»: задержки, загрузку линков, потери, пики по east-west.
• Поднять новый сегмент и повторить замеры в те же периоды.
• Проверить отказоустойчивость: отключение одного линка, одного leaf, перезагрузка spine.
• Оценить удобство эксплуатации: схемы, маркировка, мониторинг.

После пилота закрепите стандарты, иначе сеть быстро станет разношерстной. Согласуйте типы оптики (10G/25G/100G), длины и классы модулей, правила патчевания и маркировки, а также шаблоны конфигураций (порт-профили, LACP/ECMP, MTU, правила безопасности). Даже простое правило «один тип трансиверов на уровень leaf и один на spine» заметно снижает риск ошибок.

Если привлекаете партнера, в ТЗ стоит явно указать:

• целевые скорости и допустимый oversubscription
• требования по отказоустойчивости и окнам работ
• ограничения по стойкам, питанию и охлаждению
• список обязательных интеграций (мониторинг, логирование, доступы)

В Казахстане часто важна поддержка на месте: кто и как быстро приедет, есть ли запас оптики и оборудования. Если нужен партнер, который закрывает полный цикл (железо, интеграция, сопровождение), можно обсуждать проект с GSE.kz (gse.kz): у них есть системная интеграция, инфраструктурные решения для ЦОД и круглосуточная техническая поддержка.