company_banner

MPLS повсюду. Как устроена сетевая инфраструктура Яндекс.Облака

    Пост подготовили: Александр Вирилин xscrew — автор, руководитель службы сетевой инфраструктуры, Леонид Клюев — редактор

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

    Сеть в Облаке состоит из трёх слоёв. Нижний слой — уже упомянутая инфраструктура. Это физическая «железная» сеть внутри дата-центров, между дата-центрами и в местах присоединения к внешним сетям. Поверх сетевой инфраструктуры строится виртуальная сеть, а поверх виртуальной сети — сетевые сервисы. Эта структура не является монолитной: слои пересекаются, виртуальная сеть и сетевые сервисы напрямую взаимодействуют с сетевой инфраструктурой. Поскольку виртуальную сеть часто называют overlay, то сетевую инфраструктуру мы обычно называем underlay.



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

    О характеристиках. География расположения дата-центров такова, что время приема-передачи в оба конца между ними (round-trip time, RTT) всегда составляет 6–7 мс. Суммарная емкость каналов уже перевалила за 10 терабит и постоянно наращивается, потому что Яндекс обладает собственной волоконно-оптической сетью между зонами. Поскольку мы не арендуем каналы связи, то можем оперативно наращивать ёмкость полосы между ДЦ: в каждом из них используется оборудование спектрального уплотнения.

    Вот максимально схематичное представление зон:



    Реальность, в свою очередь, немного другая:


    Здесь изображена текущая опорная сеть Яндекса в регионе. Поверх неё работают все сервисы Яндекса, часть сети используется Облаком. (Это картинка для внутреннего пользования, поэтому сервисная информация сознательно скрыта. Тем не менее, можно оценить количество узлов и соединений.) Решение задействовать опорную сеть было логичным: мы могли ничего не изобретать, а переиспользовать текущую инфраструктуру — «выстраданную» за годы развития.

    В чем отличие между первой картинкой и второй? В первую очередь, зоны доступности не связаны между собой напрямую: между ними расположены технические площадки. Площадки не содержат серверного оборудования — на них размещаются только сетевые устройства по обеспечению связности. К техническим площадкам подключаются точки присутствия, где происходит стыковка Яндекса и Облака с внешним миром. Все точки присутствия работают на весь регион. Кстати, важно отметить, что с точки зрения внешнего доступа из интернета все зоны доступности Облака равнозначны. Другими словами, они обеспечивают одинаковую связность — то есть одну и ту же скорость и пропускную способность, а также одинаково низкие задержки.

    Кроме того, на точках присутствия находится оборудование, к которому — при наличии on-premise-ресурсов и желании расширить локальную инфраструктуру облачными мощностями — могут подключиться клиенты по гарантированному каналу. Это можно сделать с помощью партнёров или самостоятельно.

    Опорная сеть используется Облаком как MPLS-транспорт.

    MPLS




    Multi protocol label switching (мультипротокольная коммутация по меткам) — крайне широко используемая в нашей отрасли технология. Например, когда какой-либо пакет передаётся между зонами доступности или между зоной доступности и интернетом, то транзитное оборудование обращает внимание только на верхнюю метку, «не думая» о том, что под ней. Таким образом MPLS позволяет скрыть сложность Облака от транспортного уровня. Вообще, мы в Облаке очень любим MPLS. Мы даже сделали её частью нижнего уровня и используем непосредственно на коммутационной фабрике в дата-центре:



    (На самом деле между Leaf-свитчами и Spines огромное количество параллельных линков.)

    Почему MPLS?


    MPLS и правда совсем не часто можно встретить в сетях дата-центров. Зачастую используются совсем другие технологии.

    Мы используем MPLS по нескольким причинам. Во-первых, мы посчитали удобным унифицировать технологии control plane и data plane. То есть вместо одних протоколов в сети дата-центра, других протоколов в опорной сети и мест стыка этих протоколов — единый MPLS. Тем самым мы унифицировали технологический стек и снизили сложность сети.

    Во-вторых, в Облаке мы используем различные сетевые appliances, например Cloud Gateway и Network Load Balancer. Им нужно коммуницировать между собой, отправлять трафик в интернет и наоборот. Эти сетевые appliances могут горизонтально масштабироваться при росте нагрузки, а поскольку Облако строится по модели гиперконвергентности, они могут быть запущены в абсолютно любом месте с точки зрения сети в дата-центре, то есть в общем пуле ресурсов.

    Таким образом, эти appliances могут запуститься за любым портом стоечного свитча, где находится сервер, и начать общаться по MPLS со всей остальной инфраструктурой. Единственной проблемой в построении такой архитектуры была сигнализация.

    Сигнализация


    Классический стек протоколов MPLS достаточно сложный. Это, кстати, является одной из причин нераспространённости MPLS в сетях дата-центров.

    Мы, в свою очередь, не стали использовать ни IGP (Interior Gateway Protocol), ни LDP (Label Distribution Protocol), ни другие протоколы распространения меток. Используется только BGP (Border Gateway Protocol) Label-Unicast. Каждый appliance, который запускается, например, в виде виртуальной машины, строит сессию BGP до стоечного Leaf-свитча.



    BGP-сессия строится по заранее известному адресу. Нет необходимости автоматически настраивать свитч под запуск каждого appliance. Все свитчи настроены заранее и единообразно.

    В рамках сессии BGP каждый appliance отправляет свой loopback и получает loopbacks остальных устройств, с которыми ему нужно будет обмениваться трафиком. Примеры таких устройств — route reflectors нескольких видов, пограничные маршрутизаторы и другие appliances. В итоге на устройствах появляется информация о том, как им достичь друг друга. Из Cloud Gateway через Leaf-свитч, Spine-свитч и сеть до пограничного маршрутизатора строится Label Switch Path. Свитчи — это L3-коммутаторы, которые ведут себя как Label Switch Router и «не знают» об окружающей их сложности.

    MPLS на всех уровнях нашей сети, помимо прочего, позволила нам использовать концепцию Eat your own dogfood.

    Eat your own dogfood


    C точки зрения сети эта концепция подразумевает, что мы живем в той же инфраструктуре, которую предоставляем пользователю. Здесь схематично изображены стойки в зонах доступности:



    Cloud host принимает на себя нагрузку от пользователя, содержит его виртуальные машины. А буквально соседний хост в стойке может нести на себе инфраструктурную с точки зрения сети нагрузку, включающую в себя route reflectors, сервера менеджмента, мониторинга и т. д.

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

    Поэтому мы отказались от отдельного сегмента. Наши инфраструктурные элементы запускаются в той же сетевой топологии и с той же сетевой связностью. Естественно, они запускаются в тройном экземпляре — подобно тому, как наши клиенты запускают в Облаке свои сервисы.

    IP/MPLS-фабрика


    Вот примерная схема одной из зон доступности:



    В каждой зоне доступности около пяти модулей, а в каждом модуле около сотни стоек. Leaf — стоечные свитчи, они внутри своего модуля связаны уровнем Spine, а межмодульная связность обеспечивается через сетевой Interconnect. Это следующий уровень, включающий в себя так называемые Super-Spines и Edge-свитчи, которые уже связывают между собой зоны доступности. Мы сознательно отказались от L2, речь идёт только про L3 IP/MPLS-связность. Для распространения маршрутной информации используется протокол BGP.

    На самом деле параллельных соединений гораздо больше, чем на картинке. Такое большое количество соединений ECMP (Equal-сost multi-path) накладывает особые требования к мониторингу. Кроме того, возникают неожиданные, на первый взгляд, лимиты в оборудовании — например, количество ECMP-групп.

    Подключение серверов



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

    Яндекс.Облако — особый случай. Мы не можем диктовать клиенту, как ему строить собственные сервисы, и решили нивелировать эту возможную единую точку отказа. Поэтому все сервера в Облаке подключаются к двум стоечным свитчам.

    Мы точно так же не используем какие-либо протоколы резервирования на уровне L2, а сразу начали использовать только L3 с BGP — опять же, из соображения унификации протоколов. Такое подключение обеспечивает каждому сервису IPv4- и IPv6-связность: какие-то сервисы работают по IPv4, а какие-то — по IPv6.

    Физически каждый сервер подключается двумя 25-гигабитными интерфейсами. Вот фото из дата-центра:



    Здесь вы видите два стоечных свитча со 100-гигабитными портами. Видны расходящиеся breakout-кабели, делящие 100-гигабитный порт свитча на 4 порта по 25 гигабит на сервер. Мы называем такие кабели «гидра».

    Управление инфраструктурой


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



    Как происходит управление этой инфраструктурой? В Облаке не то чтобы запрещено, но крайне не приветствуется заходить на сетевое устройство и вносить какие-то корректировки. Существует текущее состояние системы, и нам нужно применить изменения: прийти к какому-то новому, целевому состоянию. «Пробежаться скриптом» по всем железкам, что-то изменить в конфигурации — так делать не стоит. Вместо этого мы вносим изменения в шаблоны, в единую систему source of truth и коммитим наше изменение в систему контроля версий. Это очень удобно, потому что всегда можно сделать rollback, посмотреть историю, узнать ответственного за коммит и т. д.

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

    Если мониторинги говорят, что всё спокойно, то мы продолжаем выкатку — но применяем изменение только к части топологии (две и более доступности «не имеют права» сломаться по одной и той же причине). Кроме того, мы продолжаем пристально следить за мониторингами. Это достаточно сложный процесс, о котором мы расскажем чуть ниже.

    Убедившись, что всё хорошо, мы применяем изменение ко всему продакшену. В любой момент времени можно откатиться и вернуться к предыдущему состоянию сети, оперативно отследить и исправить проблему.

    Мониторинги


    Нам нужны разные мониторинги. Один из самых востребованных — мониторинг End-to-End-связности. В любой момент времени каждый сервер должен иметь возможность покоммуницировать с любым другим сервером. Дело в том, что если где-то есть проблема, то мы хотим как можно раньше узнать, где именно (то есть какие сервера имеют проблемы с доступом друг к другу). Обеспечение End-to-End-cвязности — наша основная задача.

    На каждом сервере перечислен набор всех серверов, с которыми он должен иметь возможность коммуницировать в любой момент времени. Сервер берёт случайное подмножество этого набора и отправляет на все выбранные машины ICMP-, TCP- и UDP-пакеты. Тем самым проверяется, есть ли потери на сети, не увеличилась ли задержка и т. д. «Прозванивается» вся сеть в пределах одной из зон доступности и между ними. Результаты отправляются в централизованную систему, которая их для нас визуализирует.

    Вот как выглядят результаты, когда всё не очень хорошо:


    Здесь видно, между какими сегментами сети есть проблема (в данном случае это A и B) и где всё хорошо (A и D). Здесь могут отображаться конкретные сервера, стоечные свитчи, модули и целые зоны доступности. Если что-либо из перечисленного станет источником проблемы, мы это увидим в реальном времени.

    Кроме того, есть событийный мониторинг. Мы пристально следим за всеми соединениями, уровнями сигналов на трансиверах, BGP-сессиями и т. д. Предположим, из какого-то сегмента сети строится три BGP-сессии, одна из которых прервалась ночью. Если мы настроили мониторинги так, что падение одной BGP-сессии для нас не критично и может подождать до утра, то мониторинг не будит сетевых инженеров. Но если падает вторая из трёх сессий, происходит автоматический звонок инженеру.

    Помимо End-to-End- и событийного мониторинга, мы используем централизованный сбор логов, их реалтайм-анализ и последующий анализ. Можно посмотреть корреляции, выявить проблемы и узнать, что творилось на сетевом оборудовании.

    Тема мониторинга достаточно большая, тут огромный простор для улучшений. Хочется привести систему к большей автоматизации и настоящему self-healing.

    Что дальше?


    У нас множество планов. Необходимо совершенствовать системы управления, мониторинга, коммутационной IP/MPLS-фабрики и многое другое.

    Ещё мы активно смотрим в сторону white box-свитчей. Это готовое «железное» устройство, коммутатор, на который можно накатить свой софт. Во-первых, если всё сделать правильно, можно будет к коммутаторам «относиться» так же, как к серверам, выстроить по-настоящему удобный CI/CD-процесс, инкрементально раскатывать конфиги и т. д.

    Во-вторых, если есть какие-то проблемы, лучше держать у себя группу инженеров и разработчиков, которые эти проблемы исправят, чем подолгу ждать исправления от вендора.

    Чтобы всё получилось, ведётся работа в двух направлениях:

    • Мы существенно снизили сложность IP/MPLS-фабрики. С одной стороны, уровень виртуальной сети и средства автоматизации от этого, наоборот, немного усложнились. С другой — сама underlay-сеть стала проще. Иными словами, есть определенное «количество» сложности, которое никуда не деть. Его можно «перекидывать» с одного уровня на другой — например, между уровнями сети или с уровня сети на уровень приложений. А можно эту сложность грамотно распределить, что мы и стараемся делать.
    • И конечно, ведётся доработка нашего набора инструментов по управлению всей инфраструктурой.

    Это всё, что мы хотели рассказать о нашей сетевой инфраструктуре. Вот ссылка на Телеграм-канал Облака с новостями и советами.
    Яндекс
    562,00
    Как мы делаем Яндекс
    Поделиться публикацией

    Комментарии 24

      +2
      Приятно, когда интересно и легко написано)

      Мы продолжаем знакомить вас с внутренним устройством Яндекс.Облака


      А можно статьи помечать каким-то тегом, чтобы было легко найти?

        +1
        Сделали, спасибо.
        +1
        Замечательный дизайн. Кто вендор коммутаторов?
          +1
          Вендор используется не один. Однако общее между ними то, что большинство сетевых устройств базируется на Broadcom Trident/Tomahawk series чипсетах.
            0
            Какие вендоры используются? У самого сеть на Trident первого поколения.
              0

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

          +2
          Хотелось бы еще почитать о логической составляющей — как и на чем работает виртуализация…
            0
            Трансляция была значительно подробнее:
            www.youtube.com/watch?v=Kr6WIYPts8I
              +1
              расскажите побольше про управление инфраструктурой. как или чем накатываются конфиги? если тестирование конфигов?
                +1
                Я надеюсь, мы когда-нибудь про это напишем подробнее, а пока перечислю используемые у нас инструменты: netbox (ipam), git, ansible, естественно самописные python скрипты, jinja, netconf (как один из способов управления устройствами и получения информации с них), и еще различные сопутствующие внутренние вещи.
                  +1
                  Вот это было бы очень интересно всем кто хочет автоматизировать сеть. Ждем. Спасибо.
                0
                Если у вас в качестве underlay используется mpls, то что в качестве overlay? vpls? evpn/mpls?
                  0

                  В качестве overlay используется Tungsten Fabric, переработанный и по частям.

                    0
                    Т.е. если я правильно понял, фабрика у вас используется только в качестве mpls транспорта, никаких сервисов на ней нет, а все сервисы сидят на виртуальных роутерах?
                      0
                      Действительно, часть сервисов сидит на виртуальных роутерах и, соответственно, в виртуальной сети. Однако, немалая часть сервисов сидит в underlay-сети, это например само управление серверами, сетевой сторадж и др.
                        0
                        Сопутствующий вопрос про storage трафик. По картинке label switch path начинается с Cloud GateWay. А он под Leaf. Не увеличиваются ли задержки в IP Storage трафике? Distributed Storage ноды вряд ли под одним Leaf, так как тогда бы стойка была точкой отказа…

                        Красите storage трафик? data и replication под одним QoS?
                  +1
                  переиспользовать текущую инфраструктуру

                  Кабы я была царица, — говорит одна девица, — стала б я «использовать существующую инфраструктуру».
                  Теперь не только авторы, но и Хабр говорит по английски! Англоязычной аудитории будет интересно почитать про Яндекс.
                    +1

                    Я считаю, что вы молодцы — использовать «нестандартное» решение это амбициозно. У меня несколько вопросов возникло:


                    1) по какой причине вы решили подключать сервера к двум коммутаторам вместо одного? Ведь это существенно дороже и сервер все равно остаётся единой точкой отказа.
                    2) Используете ли вы cut-through или store-n-forward режим коммутации? Если второе, то не беспокоит ли вас увеличивающаяся задержка в пути?
                    3) Ничего не сказано про максимальный размер пакета (MTU) доступный конечным пользователям
                    4) Насколько использование MPLS ограничивает вас в выборе оборудования? На горизонте есть несколько разных поставщиков сетевых ASIC, но сможете ли вы их использовать со своими специфичными требованиями?
                    5) Возникали ли у вас какие либо трудности с взаимодействием между MPLS и балансировкой нагрузки между интерфейсами? Например поляризация трафика.
                    6) Используете ли вы какую либо систему маркировки и приоритезации трафика?


                    Спасибо.

                      +1
                      Отвечу по пунктам:

                      1) по какой причине вы решили подключать сервера к двум коммутаторам вместо одного? Ведь это существенно дороже и сервер все равно остаётся единой точкой отказа.

                      На самом деле, стоимость второго коммутатора в серверной стойке не является сильно принципиальной на фоне стоимости самой стойки серверов в полной их набивке.
                      Зато такая конструкция снижает домен отказа в *количество серверов в стойке* раз, а также позволяет сравнительно безболезненно проводить различные работы.

                      2) Используете ли вы cut-through или store-n-forward режим коммутации? Если второе, то не беспокоит ли вас увеличивающаяся задержка в пути?

                      Нет, текущие значения нас совсем не беспокоят.

                      3) Ничего не сказано про максимальный размер пакета (MTU) доступный конечным пользователям

                      Внутри виртуальных пользователских сетей доступны jumbo frames.

                      4) Насколько использование MPLS ограничивает вас в выборе оборудования? На горизонте есть несколько разных поставщиков сетевых ASIC, но сможете ли вы их использовать со своими специфичными требованиями?

                      Конечно есть некоторые ограничения, но в основном они сводятся к софту. Однако наши требования не сильно специфичные, по большей части нужно просто уметь делать label swap, а с этим как правило все хорошо.
                      Есть места где нужно уметь делать label imposing на сетевом оборудовании, но их не так много, а там где много — мы делаем на наших сетевых appliances.

                      5) Возникали ли у вас какие либо трудности с взаимодействием между MPLS и балансировкой нагрузки между интерфейсами? Например поляризация трафика.

                      Как таковых трудностей в этом месте, которые заставили бы нас думать серьезно об этом, у нас не возникало.

                      6) Используете ли вы какую либо систему маркировки и приоритезации трафика?

                      QoS, несколько красок по типу трафика, но еще смотрим что тут можно сделать в нашей ситуации лучше.
                      0
                      Есть возможность рассказать, что используется в качестве vRouter'ов?
                      А также рассматривали ли более «традиционную» схему с EVPN/VXLAN и EVPN/MPLS на DCs interconnect'е? и если, да, то почему не выбрали в двух словах?
                        0

                        Как писал выше, у нас используется по частям Tungsten Fabric с нашими изменениями.


                        Конечно, мы держали в голове разные схемы, но нам в том числе нужна была end-to-end mpls связность, поэтому иметь несколько схем (усложнение) и делать между ними какой-либо stitching (тоже усложнение) не хотелось, и в итоге остановились на том, на чем остановились.

                        0
                        Здравствуйте, Александр!
                        Вы выделили сервис Облака в отдельную AS200350 относительно основной AS Яндекса AS13238 и для этого развиваете отдельную связность Облака. Это сделано для удобства размещения на одной структуре и возможности разделения сигнализаций этих структур? Не накладно ли держать дублирующие линки с магистральными операторами, или это делается в одних и тех же каналах для обеих AS параллельно?
                          0

                          Это было сделано с целью разделить внешний трафик Яндекс.Облака и трафик самого Яндекса.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое