Проектирование оптических сетей в ЦОД

Раздел описывает принципы построения волоконно-оптических сетей в центрах обработки данных, включая проектирование интерфейсов, кабельных трасс, магистральных и распределительных уровней (ER, MDA, HDA, ZDA, EDA), а также примеры реализации в архитектуре Spine–Leaf. Особое внимание уделено зависимостям между скоростью интерфейсов, количеством волокон и требованиями к размещению шкафов и каналов.

Основные принципы

Успешное проектирование сетей ЦОД требует участия обеих проектных групп — инженерной (архитектурной, электротехнической, конструктивной) и IT-команды (сетевые и серверные архитекторы, проектировщики кабельной инфраструктуры). Интегрированный подход обеспечивает:

оптимальную компоновку телекоммуникационных залов;
совместимость инженерных и IT-систем;
масштабируемость и энергоэффективность на протяжении всего жизненного цикла ЦОД.

Интерфейсы волоконно-оптических сетей

Исторически 10 Gbps интерфейсы использовали последовательные оптические пары (2 волокна). С появлением 40/100/200/400 Gbps перешли к параллельным интерфейсам — требующим от 8 до 32 волокон. Эта зависимость влияет на проектирование каналов, габариты полок и ёмкость стоек.

Интерфейс	Кол-во волокон	Комментарий
10GBASE-S	2	Двухволоконный канал
40GBASE-SR4	8	Параллельная оптика (4×10 Gbps)
100GBASE-SR10	20	Требует многоволоконных линий
200GBASE-SR4	8	Параллельная оптика
400GBASE-SR16	32	Высокая полоса, высокая плотность
400GBASE-SR8	16	Компромисс скорость/плотность
100/200/400GBASE-DR4	8	Одномодовые для больших дистанций

Для ЦОД в условиях РФ обычно применяют OM4/OM5 (в пределах зала) и OS2 (между уровнями/зданиями) при длинах >100 м.

Влияние скорости и технологии интерфейсов

Количество волокон на порт определяется не только скоростью (40G, 100G, 400G), но и типом интерфейса. При переходе на параллельную оптику требуется больше RU под оптические панели и большее сечение кабельных каналов.

Проектом закладывается запас по сечению каналов и U-месту под панели, чтобы поддержать несколько поколений технологий (40G→400G+) без перестройки трасс.

$$N_{strand} = f(V_{port}, T_{interface})$$

где: - $N_{strand}$ — количество волокон на порт; - $V_{port}$ — скорость интерфейса (бит/с); - $T_{interface}$ — технология (последовательная / параллельная оптика).

Иерархия уровней оптической инфраструктуры

ER → MDA → HDA → ZDA → EDA (Entrance Room, Main Distribution Area, Horizontal Distribution Area, Zone Distribution Area, Equipment Distribution Area)

flowchart TB classDef node font-size:18px,stroke-width:1.5px,fill:#f1f8e9,stroke:#558b2f,color:#1b5e20; classDef layer font-size:18px,stroke-width:1.5px,fill:#e3f2fd,stroke:#1565c0,color:#0d47a1; ER["ER — Ввод кабеля (провайдеры, маршрутизаторы)"]:::layer --> MDA["MDA — Главная кроссовая (ядро, Spine)"]:::layer --> HDA["HDA — Горизонтальная кроссовая (Leaf, агрегаторы)"]:::layer --> ZDA["ZDA — Зона распределения (ряд, PoD)"]:::layer --> EDA["EDA — Зона оборудования (стойки, серверы, SAN)"]:::node

Каждый уровень — самостоятельная зона коммутации. ZDA обеспечивает локальную гибкость при подключении стоек, сокращает длины патчей и ускоряет переобвязку.

Пример сетевой архитектуры (Spine–Leaf + SAN)

Логическая схема связи Spine–Leaf с подключением уровня хранения.

flowchart TB classDef layer font-size:17px,stroke-width:1.5px,fill:#e3f2fd,stroke:#1976d2,color:#0d47a1; classDef device font-size:17px,stroke-width:1px,fill:#fff8e1,stroke:#fbc02d,color:#795548; subgraph MDA["MDA — Spine слой"] Spine1(("Spine-1")):::layer Spine2(("Spine-2")):::layer end subgraph HDA["HDA — Leaf слой"] Leaf1(("Leaf-1")):::layer Leaf2(("Leaf-2")):::layer end subgraph ZDA["ZDA — Распределение по рядам"] MoR(("Middle-of-Row коммутаторы")):::device end subgraph EDA["EDA — Серверные стойки"] Server1(("Сервер A")):::device Server2(("Сервер B")):::device end subgraph SAN["SAN — Уровень хранения"] SAN1(("SAN Director")):::layer Storage(("Дисковые массивы")):::device end Spine1 --> Leaf1 Spine2 --> Leaf2 Leaf1 --> MoR Leaf2 --> MoR MoR --> Server1 MoR --> Server2 MoR --> SAN1 --> Storage

Каждый Leaf связан минимум с двумя Spine (N+1/2N резерв). SAN подключается к MoR выделенными каналами Fibre Channel.

Конфигурации больших залов

Пример 1 — PoD-архитектура (компьютинг, хранение и сеть внутри блока)

flowchart TB classDef node font-size:17px,stroke-width:1.2px,fill:#f1f8e9,stroke:#2e7d32,color:#1b5e20; classDef infra font-size:17px,stroke-width:1.2px,fill:#e3f2fd,stroke:#1976d2,color:#0d47a1; subgraph PoD["PoD"] Compute["Вычислительные стойки"]:::node Storage["Локальное хранилище"]:::node Network["MoR-коммутаторы"]:::infra end PoD --> Spine["Spine (MDA)"]:::infra Spine --> Carrier["Входной шлюз / Carrier"]:::infra

PoD упрощает масштабирование: добавляются новые блоки без вмешательства в существующие залы. Типично для гипермасштабных ЦОД.

Пример 2 — Централизованное хранилище на верхнем уровне

flowchart TB classDef layer font-size:17px,stroke-width:1.2px,fill:#fff8e1,stroke:#f9a825,color:#6d4c41; classDef infra font-size:17px,stroke-width:1.2px,fill:#e3f2fd,stroke:#1565c0,color:#0d47a1; subgraph Halls["Залы 1–3 (Compute + Network)"] MoR1["MoR — коммутаторы залов"]:::infra Servers["Серверные стойки"]:::layer end subgraph CentralStore["Уровень 3 — Центральное хранилище"] SAN1["SAN Directors"]:::infra Drives["Дисковые массивы"]:::layer end MoR1 --> SAN1 --> Drives

Схема разделяет масштабирование вычислений и хранения. Требуется строгий расчёт бюджета потерь и числа соединений (на практике до 8 коннекторов на канал).

Основные зависимости при проектировании

До начала трассировки определяются:

архитектура сети (Spine–Leaf, PoD и др.);
топология маршрутизации и резервирования;
архитектура вычислений и хранения (локально/централизованно);
тип и ёмкость кроссовых зон (MDA/HDA/ZDA);
планировка залов и размещение шкафов;
классы волокон (OM4/OM5, OS2), допустимые длины и бюджет потерь.

Ключевые идеи

Поддержка эволюции скоростей 40G→400G+ без замены трасс — ключевое требование.
Заранее закладывать запас по сечению каналов и RU под оптические панели.
Для крупных ЦОД (>9 000 м²) — модульность через PoD или централизованное хранилище.
Spine–Leaf обеспечивает масштабируемость и отказоустойчивость; связи Leaf↔Spine — по схеме полносвязности.
При 400G+ критичны длины, число соединений и точный бюджет потерь.
Проект выполняется совместно инженерной и IT-командой, с фиксацией требований к трассам и кроссовым уровням.