Добрый день! Меня зовут Роман Помазанов, я руковожу командой Global Network Fabric в MWS Cloud Platform. Сегодня я хочу рассказать о фундаменте, который обычно остаётся в тени, когда говорят об облачных платформах. Речь пойдёт не о виртуальных машинах, контейнерах или системах хранения, а о том, что заставляет всю эту сложную машинерию работать как единое целое, — о сети.
Если представить облако как живой организм, то сеть — это его кровеносная система. Это та самая инфраструктура, которая связывает вычислительные ресурсы, системы хранения, сервисы безопасности и подключает всё это к внешнему миру — к интернету. Без её бесперебойной и предсказуемой работы ни один сервис, ни одна виртуальная машина просто не смогут функционировать. Хотя я, конечно, лукавлю — функционировать-то сможет, но только диск будет в read-only режиме, он же сетевой :)
В этой статье я подробно расскажу об Underlay-сети — том самом физическом фундаменте нового облака MWS. Мы разберём, почему мы приняли стратегическое решение спроектировать её с чистого листа, отказавшись ��т следования традиционным, зачастую излишне сложным вендорским подходам. Поговорим о принципах, которые легли в основу архитектуры: простоте, отказоустойчивости и масштабируемости. И наконец, заглянем «под капот»: посмотрим на leaf-spine фабрику, на протоколы BGP и IPv6, которые стали её нервной системой, и на то, как мы управляем этой сложной распределённой системой с помощью автоматизации и мониторинга.
Этот материал — попытка объяснить сложные инженерные решения без излишнего упрощения, но и без «магии». Важно помнить, что надёжное облако начинается с правильно спроектированной сети. Ок, давайте начнём с самого главного вопроса: почему мы не стали копировать проверенную на практике сетевую архитектуру, а пошли своим путём?
Почему мы не стали копировать проверенную сетевую архитектуру
В целом, если у вас уже есть работающее публичное облако — кажется логичным использовать проверенные решения и для нового. Мы в MWS Cloud Platform столкнулись именно с этой дилеммой: у нас уже было облако, построенное на классической и, казалось бы, надёжной сетевой платформе одного из ведущих мировых вендоров в соответствии с его best practice. Его архитектура во многом опиралась на EVPN VXLAN для построения overlay-сетей. Но для новой платформы мы приняли стратегическое решение не копировать этот подход, а пойти другим путём. И вот почему.
Во-первых, сложность. EVPN VXLAN — мощный, но очень комплексный протокол. Чем сложнее протокол, тем больше его кодовая база, количество состояний и потенциальных корнер-кейсов. А в сетевой инженерии (да и, наверное, вообще в любой) есть простое правило: чем больше сложности, тем выше вероятность сбоя. Мы стремились построить максимально простую и предсказуемую систему, где каждая часть понятна и управляема. Монолитная, перегруженная функциями архитектура — это не наш путь.
Во-вторых, нам нужен был vendor agnostic. События последних лет показали, что экосистема может измениться мгновенно. Жёсткая привязка к одному вендору и его уникальным реализациям протоколов (как раз таким, как EVPN VXLAN) — это серьёзный стратегический риск. Нам была нужна сеть, которую можно было бы построить на оборудовании разных производителей без потери функциональности и надёжности. А для этого необходимо было отказаться от самых сложных, «тяжёлых» протоколов в пользу максимально простого и универсального стека, который гарантированно работает везде.
В-третьих, контроль и прозрачность. Используя вендорский дизайн «из коробки», вы во многом отдаёте контроль над логикой работы и диагностикой в руки вендора. Мы же хотели понимать нашу сеть до самого низа, иметь возможность модифицировать её под наши уникальные требования и масштабы. Например, один из ключевых принципов, который мы заложили, — использование commodity hardware. Там, где это возможно, сетевые функции (вроде шлюзов) работают на обычных x86-серверах под нашим софтом, а не на специализированных «коробках» с закрытой прошивкой.
Иными словами, мы сознательно отказались от пути «как у всех» или «как было раньше». Вместо наследования сложной вендорской архитектуры мы решили построить сеть с чистого листа, основанную на принципах минимализма, универсальности и полного контроля. Это был стратегический выбор в пользу долгосрочной устойчивости, а не сиюминутного удобства. И этот выбор сразу определил требования к архитектуре: она должна быть настолько простой и стандартизированной, чтобы её можно было тиражировать в любом дата-центре, с любым совместимым оборудованием.
Быть ближе к клиенту: география вместо абстракции
Наш стратегический выбор в пользу простоты и универсальности не был самоцелью. Он стал фундаментом для решения гораздо более масштабной задачи. Стратегия MWS Cloud Platform в облачном бизнесе — быть максимально близко к своему клиенту, физически сокращая задержки и повышая доступность сервисов.
Что это означает на практике? Это отказ от модели одного-двух гипермасштабных дата-центров где-то в центре стра��ы. Вместо этого мы строим распределённое облако, элементы которого размещаются максимально приближаясь к точкам концентрации бизнеса и пользователей. Эта философия «ближе к клиенту» кардинально меняет требования к сети.
Представьте себе карту. Где-то на ней — наш клиент, подключённый к интернету через своего провайдера (ISP), а где-то — его виртуальный ресурс в нашем облаке. Задача сети — обеспечить между ними надёжный, быстрый и безопасный канал связи. Для этого мы создаём точки присутствия (Points of Presence, PoP) — узлы, расположенные на границе между интернетом и нашей платформой. Именно через них заходит весь внешний трафик.
Но облако — не монолит. Внутри него критически важные рабочие нагрузки размещаются в изолированных зонах доступности (Availability Zones, AZ), которые представляют собой физически независимые дата-центры. И здесь вступает в силу наш старый добрый инженерный принцип: всё, что критично, должно быть продублировано.
Между двумя AZ мы обязательно прокладываем два независимых физических канала связи, разнесённых на расстояние в несколько километров. Почему? Чтобы ни один землеройный механизм, будь то экскаватор или буровая установка — злейший враг любого сетевого инженера — не мог повредить оба канала одновременно. Такова суровая практика построения отказоустойчивых магистралей.
Ещё мы развиваем инфраструктуру Edge-вычислений, размещая компактные узлы обработки данных ещё ближе к пользователю — например, на площадках операторов связи. Это позволяет выполнять задачи с минимально возможной задержкой, что критично для 5G-сервисов, IoT или интерактивных приложений.
Наконец, для корпоративных клиентов, которые не могут или не хотят доверять трафик публичному интернету, мы предоставляем возможность прямого, выделенного подключения (Interconnect). Клиент может протянуть свой канал до нашего PoP и получить безопасный, предсказуемый по задержкам приватный канал прямо в своё облачное окружение.
Так что же у нас в сухом остатке? Не просто «сеть где-то там», а распределённая платформа с чёткими географическими координатами. Платформа, в которой отказоустойчивость заложена на уровне физических связей, а низкие задержки достигаются за счёт архитектуры.
Однако такая распределённая модель ставит перед нами нетривиальный вопрос: как по одной физической инфраструктуре безопасно и изолированно пустить трафик тысяч разных клиентов? Для ответа на него нам пришлось чётко разделить две большие концепции — Underlay и Overlay.
Магия изоляции: один физический мир, много виртуальных
Распределённая физическая инфраструктура — это мощно, но недостаточно. Представьте: в облако одновременно заходят тысячи клиентов — от стартапа с одним веб-сервером до крупного банка с распределённой ERP-системой. Весь их трафик неизбежно проходит через одни и те же магистральные каналы и коммутаторы в наших дата-центрах. Возникает фундаментальный вопрос: как гарантировать, что данные одного клиента никогда не смешаются с данными другого? Как обеспечить приватность и безопасность в общей среде?
Ответ кроется в разделении сетевой логики на два чётких, независимых слоя: Underlay и Overlay. Давайте разберём их на аналогии.
Представьте мощную, разветвлённую железную дорогу (Underlay). Её задача — предоставлять базовый транспорт. Рельсы, стрелки, расписание — всё подчинено одной цели: максимально надёжно и быстро доставить груз из пункта А в пункт Б. Железная дорога не знает и не интересуется, что именно везут в вагонах. Её мир — это локомотивы, станции и пути.
А теперь представьте, что по этим общим путям едут закрытые частные вагоны (Overlay). Каждый клиент облака получает свой набор таких вагонов. Клиент загружает в них свой «груз» (трафик), вагоны закрываются, и железная дорога доставляет их до нужной станции (хоста). На всём пути содержимое вагонов остаётся невидимым для посторонних и полностью изолированным от грузов других клиентов.
Вот как эт�� аналогия воплощается в нашей платформе:
Underlay («железная дорога») — это фабрика из коммутаторов, о которой мы подробно расскажем дальше. Её единственная задача — обеспечить IP-связность с предсказуемой задержкой и отказоустойчивостью между всеми критическими точками: между точками присутствия (PoP) и зонами доступности (AZ), между серверами внутри фабрики. Underlay работает на протоколах BGP и IPv6 и лишь заботится об эффективной маршрутизации. Он «слеп» к тому, что лежит в полезной нагрузке пакетов.
Overlay («частные вагоны») — это виртуальный слой изоляции и сервисов. Когда клиент создаёт виртуальную машину, система оркестрации автоматически программирует для него туннели на базе Segment Routing over IPv6 (SRv6). Эти туннели начинаются и заканчиваются не на специализированном оборудовании, а прямо на гипервизорах (compute hosts) и шлюзах (gateways) — обычных x86-серверах, где работает высокопроизводительный стек VPP (Vector Packet Processing) и наш собственный SDN-агент. Overlay отвечает за то, чтобы трафик клиента был упакован в его «частный вагон» (туннель SRv6) на входе в сеть и доставлен строго в его виртуальную сеть (VPC) без возможности пересечения с другими.
Главный вывод прост: Overlay не висит в воздухе. Вся его «магия» изоляции, безопасности и гибкой маршрутизации полностью опирается на скорость, надёжность и предсказуемость Underlay. Если «железная дорога» встанет, никакие «частные вагоны» никуда не поедут.
Именно поэтому проектированию Underlay мы уделили первостепенное внимание. В следующем разделе мы наконец заглянем «под рельсы» и разберёмся, как устроена эта самая сетевая фабрика, способная выдержать нагрузку от миллионов «частных вагонов».
Сердце Underlay: сетевая фабрика по принципу Leaf-Spine
Итак, Underlay — это фундамент. Но как спроектировать этот фундамент, чтобы он был одновременно простым, отказоустойчивым и способным переваривать терабиты трафика от тысяч клиентов? Ответ — современная, ставшая индустриальным стандартом архитектура Clos, или Leaf-Spine.
В её основе — два чётких уровня:
Spine («хребет») — мощные коммутаторы ядра сети.
Leaf («листья») — коммутаторы доступа.
Ключевой принцип: каждый Leaf-коммутатор подключён ко всем Spine-коммутаторам. Это образует плотную, полносвязную сеть каналов. К Leaf подключаются конечные устройства: серверы, системы хранения. А для связи с внешним миром (с точками присутствия — PoP и магистральными каналами) используются Border Leaf — специализированные коммутаторы, которые также подключены напрямую ко всем Spine, становясь полноценной частью фабрики.
Почему такая топология стала для нас единственно верным выбором?
Во-первых, она даёт детерминированность. В архитектуре Clos путь трафика от одного сервера до другого всегда строго определён и минимален (классические три «хопа»: Leaf → Spine → Leaf). Это критически важно для распределённых приложений, баз данных и систем хранения, которые формируют львиную долю трафика в облаке — так называемый трафик «восток-запад» (между сервисами внутри дата-центра). Именно этот тип трафика, а не «север-юг» (из интернета в облако) составляет 80–90% всей нагрузки, и наша фабрика оптимизирована именно под него.
Во-вторых, она обеспечивает отказоустойчивость через избыточность. Выход из строя одного Spine-коммутатора или даже нескольких линков не парализует сеть. Благодаря тому что каждый Leaf соединён со всеми Spine, трафик мгновенно перераспределяется по оставшимся каналам. Этот механизм называется ECMP (Equal-Cost MultiPath — множественные пути равной стоимости). BGP, который работает на всех устройствах фабрики, видит несколько равнозначных путей до одной цели и балансирует нагрузку между ними. Таким образом, ECMP не только повышает отказоустойчивость, но и позволяет агрегировать пропускную способность многих линков.
В-третьих, она логично и линейно масштабируется. Мы выделяем два сценария:
Нужно больше пропускной способности внутри фабрики? Увеличиваем количество или пропускную способность линков от Leaf к Spine. Если ёмкости спайнов не хватает — добавляем в фабрику новые Spine-коммутаторы, что увеличивает суммарную полосу пропускания для всех Leaf.
Нужно подключить новые стойки с серверами? Устанавливаем новые Leaf-коммутаторы и подключаем их ко всем имеющимся Spine. Архитектура при этом не меняется, а новая вычислительная мощность просто вливается в фабрику.
Наконец, самое важное: в этой фабрике сервер — не пассивный потребитель, а полноправный участник домена динамической маршрутизации. На каждом сервере работает демон маршрутизации (FRR), который через BGP «знакомится» с соседними Leaf-коммутаторами. Таким образом, сервер сам рассказывает сети́ о своих адресах, активно участвуя в построении картины связности. Это фундаментальный отход от модели, где сервер был просто конечным устройством в сегменте коммутации (L2).
Итог — мы получаем сетевую фабрику: единую, однородную, управляемую как целое. Она не знает о виртуальных машинах и клиентах, её задача — с максимальной эффективностью доставлять IP-пакеты между своими портами. И она блестяще справляется с этой задачей, обеспечивая ту самую «железную дорогу», по которой ездят «частные вагоны» Overlay.
Однако сама по себе фабрика из железа и линков — лишь «тело». Чтобы оно ожило и стало умной, самовосстанавливающейся системой, ему нужны «мозг» и «нервная система». Ими в нашем Underlay стали несколько тщательно выбранных протоколов.
Мозг фабрики: протоколы, которые всё оживляют
Итак, фабрика из железа и линков — это мощный скелет. Но чтобы он стал живой, самовосстанавливающейся системой, ему нужны «нервы» и «рефлексы». В мире сетей эту роль выполняют протоколы. Наш подход здесь был таким же минималистичным, как и в выборе архитектуры: использовать ровно столько технологий, сколько необходимо, и ни одной лишней.
Весь мозг нашего Underlay построен на трёх китах: BGP, BFD и IPv6.
BGP (Border Gateway Protocol): протокол интернета в дата-центре
Выбор BGP для внутренней сети дата-центра может показаться неочевидным. В конце концов, для этого традиционно используют IGP (Internal Gateway Protocols), такие как OSPF или IS-IS. Мы же сознательно отказались от них. Почему?
Масштабируемость и проверенность. Если BGP справляется с маршрутизацией во всей глобальной сети Интернет, с её сотнями тысяч префиксов и постоянными изменениями, то с нашей фабрикой он справится одной левой. Это самый стрессоустойчивый и отлаженный протокол из существующих.
Гибкость и контроль. BGP даёт невероятно мощный инструментарий для управления политиками маршрутизации. Это важно для тонкого управления трафиком, например на границе с внешними сетями.
Вопрос холиварный: eBGP vs iBGP. Мы используем eBGP (External BGP), где каждый участник — Spine, Leaf, Border Leaf — и даже каждый сервер имеет свою уникальную автономную систему (AS). Почему не классический iBGP внутри одной AS? Потому что eBGP с уникальными AS даёт нам беспрецедентную visibility для траблшута. Глядя на путь AS (AS_PATH) в объявлении маршрута, мы можем мгновенно определить, с какого именно сервера он пришёл, не роясь в дополнительных базах данных. Это упрощает диагностику сложных проблем на порядок.
BFD (Bidirectional Forwarding Detection): рефлекс на сбой
BGP — протокол надёжный, но не мгновенный. Для быстрого реагирования на обрыв линка или соседа используется BFD. Это легковесный протокол, который постоянно, с интервалами в десятки миллисекунд, обменивается «hello-пакетами» между соседями. Если несколько пакетов подряд не дошли, BFD моментально (в те же доли секунды) сообщает об этом BGP, и тот перестраивает таблицу маршрутизации, убирая «умерший» путь. BFD — это тот самый «рефлекс», который превращает отказоустойчивую архитектуру в реально быстровосстанавливающуюся систему.
IPv6: бесконечное пространство вместо костылей
Мы с самого начала приняли стратегическое решение: в Underlay нет и не будет IPv4. Только IPv6. Почему? Адресное пространство IPv4 исчерпано, а работа с ним часто требует костылей вроде NAT (Network Address Translation), которые усложняют архитектуру и диагностику. IPv6 решает эту проблему раз и навсегда. У нас есть столько адресов, сколько мо��ет понадобиться для роста в обозримом и необозримом будущем, что позволяет использовать простые и логичные схемы адресации.
Это даёт чистоту и простоту: нет наложенной трансляции адресов, нет конфликтов приватных диапазонов. Каждое устройство в фабрике имеет свой уникальный, маршрутизируемый адрес. Кроме того, большая длина адреса IPv6 (128 бит) открывает интересные возможности для кодирования в них служебной информации, что мы и используем в нашем Overlay на базе SRv6.
Итог нашего стека: мы сознательно отказались от отдельного IGP (OSPF/IS-IS) и полностью исключили L2-протоколы (вроде Spanning Tree\LACP) из Underlay. Вся фабрика работает на чистом IP (L3), где связность обеспечивается динамической маршрутизацией через eBGP, а стабильность — сверхбыстрым BFD.
Таким образом, «мозг» нашей сети — это не набор разрозненных технологий, а целостная, минималистичная система. BGP строит маршруты, BFD мгновенно реагирует на изменения, а IPv6 предоставляет неограниченное пространство для манёвра. Вместе они превращают железо фабрики в интеллектуальную, саморегулирующуюся платформу.
Но даже самая совершенная сеть нуждается в управлении, наблюдении и обслуживании. Как мы справляемся с этой задачей в масштабах распределённого облака? Об этом — в заключительной части.
Жизнь с фабрикой: управление, автоматизация и мониторинг
Спроектировать и построить сеть — это только половина дела. Вторая, не менее важная половина — управлять ею, масштабировать и поддерживать в рабочем состоянии 24/7. Когда речь идёт о распределённом облаке с десятками фабрик, сотнями коммутаторов и тысячами серверов, ручное управление через CLI исключено. Наше спасение — автоматизация, основанная на принципах Infrastructure as Code (IaC), и многоуровневый мониторинг, который видит всё.
Автоматизация: свой код, единая истина и OOB-канал
Фундаментом всей нашей автоматизации служит Netbox. Это не просто база данных, а единый источник истины (Single Source of Truth — SSOT). В нём хранится полная модель инфраструктуры: какие устройства существуют, как они называются, какие у них IP-адреса и AS-номера, как они соединены друг с другом. Вся последующая автоматизация берёт данные отсюда и только отсюда, что исключает рассинхрон и человеческий фактор.
Почему мы не используем готовые инструменты вроде Ansible? Наш опыт показал, что для специфических задач, особенно при работе с инфраструктурой "на границе сети" (именно там основная сложность!) и глубокой интеграцией с внутренними системами, требуется максимальная гибкость. Поэтому мы пошли по пути собственного фреймворка автоматизации. По сути, мы создали внутренний продукт — набор Python-библиотек и утилит, которые напрямую интегрируются с Netbox как с источником данных, генерируют конфигурации по шаблонам (Jinja2) и управляют жизненным циклом устройств. Это дало нам возможность точечно решать наши уникальные задачи, не подстраиваясь под ограничения готовых решений, и идеально встроить сетевое управление в общие процессы разработки и эксплуатации платформы.
Важный нюанс: вся работа автоматики с сетевым оборудованием (заливка конфигураций, сбор информации) ведётся не через основную фабрику, а через выделенный Out-of-Band (OOB) канал управления. Это гарантирует, что даже в случае серьёзного сбоя в data plane мы сохраняем контроль над инфраструктурой и можем, например, удалённо перезагрузить «зависший» коммутатор.
Мониторинг: от старого доброго SNMP до современной телеметрии
Однажды я услышал принцип: мониторинг это та вещь, которую можно и нужно улучшать бесконечно.
SNMP по-прежнему служит нам добрую службу для сбора базовых метрик: загрузки CPU и памяти, температуры, состояния портов. Это проверенный, универсальный стандарт.
BMP (BGP Monitoring Protocol) — это наше «окно» в контрольную плоскость. Мы пассивно слушаем BGP-сессии на коммутаторах разного уровня и получаем полную картину маршрутизации в реальном времени, а также историю всех её изменений. Это бесценно для расследования инцидентов: можно отмотать время и увиде��ь, какой маршрут и когда исчез, что привело к проблеме.
NETCONF/YANG используется там, где нужны более тонкие и оперативные данные. Например, мы подписываемся на стрим изменений состояния BGP-сессий на коммутаторах и получаем эти события по push-модели, а не опрашиваем устройство раз в минуту.
Активные пробы (Synthetic Monitoring) имитируют поведение реального пользовательского трафика. Серверы внутри фабрики постоянно «пингуют» друг друга, проверяя не только доступность, но и задержки и потери пакетов. В перспективе мы смотрим в сторону стандарта TWAMP для более точных сквозных измерений, хотя поддержка этой технологии у разных вендоров пока оставляет желать лучшего.
Переход к телеметрии — это наш стратегический вектор. Наша цель — получать все метрики (от счётчиков на портах до состояния чипов) по push-модели, когда устройство само, с высокой частотой, отправляет данные на коллектор. Это даёт несоизмеримо лучшую детализацию и позволяет быстрее реагировать на аномалии. Реализация, однако, зависит от возможностей конкретного вендора, и здесь мы движемся постепенно, выбирая наиболее зрелые решения.
Итог: простота — это стратегия
Если оглянуться на всё, о чём мы рассказали — от отказа от сложных вендорских стеков до минималистичного набора протоколов и автоматизации от единой истины, — становится видна единая красная нить. Это стратегический выбор в пользу простоты, контроля и предсказуемости.
Мы построили не просто сеть для облака. Мы построили сетевую платформу — однородную, автоматизированную, масштабируемую и наблюдаемую. Платформу, где каждый компонент понятен, а каждое решение обосновано. Платформу, которая не боится экскаваторов, легко растёт вместе с бизнесом и служит абсолютно надёжным фундаментом для любых сервисов, которые будут работать поверх неё.
Теперь наша задача — использовать эту платформу по максимуму, создавая на её основе сервисы, которые оценят наши клиенты. Более подробную информацию о сервисах MWS Cloud Platform ищите на сайте.
