Почему CLOS? Проблема трёхуровневых сетей
Традиционная трёхуровневая архитектура сети (Core → Aggregation → Access) служила нам десятилетиями. Но с взрывным ростом east-west трафика — вызванным виртуализацией, контейнеризацией и распределёнными приложениями — её ограничения стали критическими:
- Переподписка на уровне агрегации — трафик между access-коммутаторами должен проходить через агрегацию
- STP блокирует резервные пути, впустую расходуя полосу
- Масштабирование требует замены оборудования — более крупные core-коммутаторы, более дорогие модули
- Непредсказуемая задержка — разные пути имеют разное количество хопов
CLOS (Leaf-Spine) архитектура устраняет эти проблемы по дизайну.
Основы архитектуры CLOS
В Leaf-Spine топологии:
- Каждый leaf подключён к каждому spine — нет заблокированных путей
- Максимум два хопа между любыми двумя серверами — предсказуемая задержка
- Добавление ёмкости = добавление spine-коммутаторов — горизонтальное масштабирование
- ECMP (Equal-Cost Multi-Path) распределяет трафик по всем доступным путям
Расчёт размера CLOS-фабрики
Математика проста:
- Leaf-коммутаторы: количество аплинк-портов к spine = количество spine-коммутаторов
- Spine-коммутаторы: количество даунлинк-портов = максимальное количество leaf
- Серверные порты на leaf: оставшиеся порты после аплинков
Пример: leaf с 48 x 10G даунлинками и 6 x 40G аплинками подключается к 6 spine, поддерживая до 48 серверов на leaf. С 6 spine по 48 портов можно иметь до 48 leaf — это 2,304 серверных подключения.
Принципы проектирования из реальных внедрений
Спроектировав CLOS-сети для банковской среды, вот принципы, которым я следую:
1. Симулируйте перед развёртыванием
Используйте EVE-NG или GNS3 для построения полной симуляции фабрики. Тестируйте:
- Время конвергенции BGP/OSPF
- Поведение при отказе spine
- Распределение трафика под нагрузкой
- Шаблоны конфигурации на всех коммутаторах
2. Выберите протокол маршрутизации
eBGP — современный стандарт для CLOS-фабрик:
- Каждый коммутатор получает собственный ASN
- Простая модель пиринга — leaf пирится со всеми spine
- Понятные домены отказов
- Используется гиперскейлерами (Facebook, Microsoft, LinkedIn)
OSPF подходит для меньших фабрик:
- Проще начальная конфигурация
- Быстрее конвергенция в малых сетях
- Рассмотрите OSPF unnumbered для уменьшения адресного пространства
3. Стандартизируйте всё
Каждый leaf должен иметь идентичный шаблон конфигурации. Каждый spine должен быть идентичен. Сила CLOS — в его единообразии. Используйте управление конфигурациями с первого дня.
4. Планируйте Day 2
- Мониторинг: утилизация портов, состояние BGP-сессий, распределение ECMP-хешей
- Автоматизация: zero-touch provisioning для новых коммутаторов
- Документация: диаграммы топологии, обновляемые автоматически
Стратегия миграции
Миграция с three-tier на CLOS без простоев требует тщательного планирования:
- Разверните spine параллельно существующим core-коммутаторам
- Мигрируйте access в роль leaf по одному стоку за раз
- Перенаправляйте трафик постепенно через метрики маршрутизации
- Выведите старый core только после полной валидации
Такой подход позволяет запускать обе архитектуры параллельно в переходный период.
Ключевые выводы
CLOS — не только для гиперскейлеров. Любая организация с 50+ серверами, значительным east-west трафиком или планами роста выиграет от Leaf-Spine. Начальная сложность в настройке маршрутизации окупается операционной простотой и предсказуемой производительностью.
Самый важный шаг? Начните с симуляции. EVE-NG даст вам безрисковую среду для валидации дизайна до того, как будет проложен первый кабель.