Сеть на вырост: Как проектировать надежную и масштабируемую IT-инфраструктуру

Топологии и архитектурные модели: кампус, филиалы, дата-центр и распределённая сеть

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

Когда-то такая схема была разумной. У компании было три офиса, собственный сервер и одна главная площадка. Теперь — головной офис, дата-центр, двадцать восемь филиалов, облачная CRM и план открыть ещё десять точек за год. Сеть выросла не просто в размере: у неё изменился характер движения. И проблема оказалась не в том, что «не хватает скорости», а в том, что прежняя форма сети больше не соответствовала жизни компании.

На архитектурной сессии директор по инфраструктуре развернул карту площадок и спросил: «Какую топологию нам выбрать?» Инженер ответил вопросом: «Для какого трафика, какого масштаба и какого отказа?» Это был более полезный вопрос. Топология — не модный рисунок из презентации и не обещание, что «всё будет резервировано». Это устройство дорог, по которым данные попадут к своим целям, и правила, по которым сеть переживёт поломку одной из этих дорог.

Сначала понять, кто куда едет

На карте «Северного контура» было три основных типа трафика.

•Пользователи в филиалах обращались к облачной CRM и видеосервису.

•Торговые приложения филиалов связывались с системами в дата-центре.

•Сотрудники головного офиса обменивались данными с внутренними сервисами и друг с другом.

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

Полезно различать физическую и логическую топологии. Физическая показывает, где проходят кабели и линии связи, к каким коммутаторам подключены устройства и какие площадки соединены напрямую. Логическая — какие сети видят друг друга, где проходят маршруты, какие туннели связывают площадки и через какие политики проходит трафик.

Эти карты могут не совпадать. Физически филиалы могут подключаться к двум региональным узлам, а логически — к десяткам других площадок через защищённую оверлейную сеть. И наоборот: несколько отдельных физических линий могут предоставлять один логический путь. Такое расхождение полезно, но его нельзя считать волшебством: логический резерв не поможет, если оба «разных» маршрута идут по одному кабельному каналу или зависят от одного оператора.

Поэтому хорошая архитектура начинается с нескольких простых вопросов:

1. Какие приложения и площадки должны взаимодействовать?

2. Какой путь для каждого взаимодействия приемлем по задержке и пропускной способности?

3. Что должно продолжать работать при отказе устройства, линии, площадки или оператора?

4. Сколько сложных связей команда сможет надёжно настроить, проверить и поддерживать?

Ответы постепенно проявляют подходящую форму сети.

Кампус: порядок вместо бесконечных перемычек

Головной офис «Северного контура» занимал два здания. В каждом были этажные коммутаторы доступа: к ним подключались компьютеры, телефоны, точки Wi-Fi и принтеры. Эти коммутаторы сходились к уровню распределения, где объединялись сети этажей, применялись политики и маршрутизировался трафик. Выше находилось ядро — быстрый транзит к дата-центру, интернету и другим частям кампуса.

Так устроена иерархическая модель: доступ — распределение — ядро. Её сила не в том, что три уровня обязательны, а в разделении ролей. Доступ подключает пользователей и устройства; распределение объединяет локальные сегменты и задаёт правила; ядро быстро переносит трафик между крупными блоками.

Для большой площадки такая структура похожа на городской транспорт: местные улицы не должны по отдельности вести к каждому зданию города, а магистрали не должны разбираться с каждым дворовым выездом. Разделение упрощает диагностику и позволяет добавлять новые корпуса, не переплетая соединения между всеми коммутаторами.

Но иерархия не означает, что нужно строить три этажа ради красоты. Небольшому офису или компактному кампусу может хватить модели collapsed core, где функции распределения и ядра объединены. Это дешевле и проще в управлении. Цена — меньший запас для роста и более крупная область воздействия при отказе центрального оборудования. Пара резервных устройств не снимает это ограничение автоматически: надо ещё продумать питание, соединения, маршрутизацию и переключение.

Для «Северного контура» выбрали кампусную иерархию с парой узлов распределения, независимыми линиями от крупных блоков и чёткими границами маршрутизации. Там, где отказ одного этажного коммутатора допустим до приезда техника, сделали менее дорогой резерв. Там, где отключение корпуса останавливало важную операцию, предусмотрели более независимые пути и оборудование.

Именно так следует относиться к резервированию: не как к флажку «есть/нет», а как к ответу на вопрос, какие последствия отказа организация согласна принять. Две линии в одном кабельном лотке дают резерв от поломки порта, но не обязательно от строительных работ. Два коммутатора в одной стойке могут пережить отказ устройства, но не потерю питания в серверной.

Филиалы: лучи, кольца и управляемые обходы

С филиалами картина другая. В небольшой точке обычно не нужен сложный кампус: несколько пользовательских устройств, кассовое или производственное оборудование, беспроводная сеть и канал к центральным сервисам. Классическая модель — hub-and-spoke, или «звезда»: филиалы подключаются к одному или нескольким центральным узлам.

У такой схемы есть достоинства. Её легко объяснить, контролировать и защищать: политика доступа задаётся в центральных точках, а число связей не превращается в клубок. Она хорошо работает, если приложения действительно размещены в центре и филиалам не нужно интенсивно общаться друг с другом.

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

Первый шаг к устойчивости — два центральных узла с независимыми подключениями. Но «независимость» надо проверять, а не рисовать: разные ли у каналов операторы, трассы и точки входа? Работают ли оба узла при потере одного? Не зависит ли переключение от единственного устройства или специалиста, который помнит пароль?

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

Полная mesh-связность соединяет каждую площадку с каждой. Для небольшого числа критичных узлов это может быть оправдано. Но количество возможных пар быстро растёт: при \(n\) площадках их \(n(n-1)/2\). Для тридцати филиалов это уже 435 пар. На практике не каждую из них обязательно строить отдельной линией, однако логические связи, маршруты, политики и сценарии проверки всё равно требуют внимания. Полная mesh — не «резерв на всякий случай», а выбранная цена за прямые пути и дополнительные возможности обхода.

Программно-определяемая WAN, или SD-WAN, может упростить управление такими связями: централизованно задавать политики, выбирать канал по условиям и создавать защищённые туннели поверх разных транспортов. Но SD-WAN — не топология сама по себе. Это способ управлять связностью. Он не создаст второй физический путь, если у филиала есть только один канал, и не избавит от необходимости разбираться, куда в итоге пойдёт трафик.

Для «Северного контура» малые филиалы подключили к двум региональным узлам, а критичные площадки получили дополнительные прямые или резервные связи. Для облачной CRM предусмотрели локальный выход в интернет там, где это разрешали требования безопасности. Так запрос перестал делать крюк через штаб-квартиру. Трафик к внутренним системам по-прежнему шёл по контролируемому пути в дата-центр.

Это разделение особенно важно при выборе локального выхода в интернет. Он уменьшает задержку и нагрузку на центральные каналы, но переносит на филиал часть требований к защите, фильтрации, мониторингу и резервированию. Экономия на маршруте не должна обернуться десятью разными и непроверенными правилами безопасности.

Дата-центр: когда большинство разговоров происходит внутри

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

Для таких задач подходит модель leaf-spine. Каждый коммутатор leaf подключён ко всем коммутаторам spine, а серверы и другие конечные устройства подключаются к leaf. Путь между двумя leaf проходит через spine. Это даёт предсказуемую структуру и позволяет распределять потоки по нескольким путям с помощью равностоимостной маршрутизации — ECMP.

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

Эта модель также требует дисциплины в маршрутизации, адресации и эксплуатации. Больше путей дают больше возможностей распределять трафик, но неверная настройка может ухудшить предсказуемость или затруднить поиск неисправности. Если в небольшом дата-центре почти весь трафик идёт от серверов к внешним пользователям, сложность leaf-spine может быть избыточна. Архитектуру выбирают под обмен данными, а не под привлекательность схемы.

Дальность — тоже элемент топологии

Карта площадок — это не только точки, но и расстояния между ними. По оптоволокну свет распространяется примерно со скоростью 200 тысяч километров в секунду. Это значит, что только физическое прохождение 1000 километров добавляет около 5 миллисекунд в одну сторону. Реальный маршрут может быть длиннее прямого, а оборудование и обработка пакетов добавляют свою задержку.

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

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

Архитектурная сессия: сравнить не моды, а последствия

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

Модель

Цена

Устойчивость

Задержка

Сложность эксплуатации

Иерархический кампус

Средняя; растёт с резервированием

Хорошая при независимых путях и продуманной архитектуре

Предсказуемая внутри площадки

Средняя; роли уровней облегчают поиск проблем

Филиалы «звездой» к одному узлу

Низкая или средняя

Центральная точка — общий риск

Может быть высокой для удалённых сервисов

Низкая; просто контролировать, но легко перегрузить центр

Два региональных узла и выборочная mesh-связь

Средняя или высокая

Хорошая при независимых каналах и корректном переключении

Ниже для выбранных прямых путей

Средняя или высокая; растёт число сценариев

Полная mesh между площадками

Высокая

Много возможных путей, но результат зависит от общей инфраструктуры

Потенциально низкая между узлами

Высокая; много связей и политик

Leaf-spine в дата-центре

Средняя или высокая

Хорошая при нескольких независимых путях

Предсказуемая между стойками

Средняя или высокая; нужна дисциплина маршрутизации и измерений

Таблица помогла не найти единственного победителя, а увидеть, где именно компании нужна каждая модель. Кампусу — иерархия. Небольшим филиалам — управляемая связь с региональными узлами. Критичным площадкам — выборочные прямые маршруты. Дата-центру — leaf-spine там, где интенсивность внутреннего обмена оправдывает эту архитектуру. Облаку — близкий и контролируемый выход, не зависящий от единственной центральной дороги.

В результате схема выглядела примерно так:

```text

┌──────────── Облачные сервисы

│ ↑

Интернет / частный канал

│ ┌────────────────┴────────────────┐ │ │ Региональный узел A ─── Резерв ─── Региональный узел B ↑ ↑ ↑ ↑ │ └── прямая связь критичных площадок ─┘ Филиалы малого размера Критичные филиалы │ └──── локальный защищённый выход к разрешённым сервисам

Головной кампус

доступ → распределение → ядро

│ Дата-центр leaf ↔ spine │ внутренние приложения

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

Как выбрать модель для своей сети

Попробуйте провести собственную короткую архитектурную сессию.

1. Нарисуйте площадки и расстояния. Отметьте число филиалов, дата-центр, регионы облачных сервисов и каналы связи. Не ограничивайтесь логическими соединениями: запишите операторов, физические трассы и точки входа, если эти данные доступны.

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

3. Опишите отказ, а не только резерв. Что произойдёт при потере линии, центрального узла, электропитания или всего региона? Какую работу нужно сохранить немедленно, а какую можно восстановить позже?

4. Сравните цену владения. Учитывайте не только каналы и оборудование, но и мониторинг, тестирование переключения, сопровождение политик, обучение сотрудников и время диагностики.

5. Проверьте, что резерв действительно независим. Два маршрута, проходящие через одну шахту, одного оператора или одну точку питания, могут оказаться одним маршрутом под разными именами.