Mpls Есть Везде. Как Работает Сетевая Инфраструктура Яндекс.облака

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

MPLS есть везде.
</p><p>
 Как работает сетевая инфраструктура Яндекс.
</p><p>
Облака

Продолжаем знакомить вас с внутренним устройством Яндекс.

Облако .

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

Сеть в Облаке состоит из трех слоев.

Нижний уровень — это уже упомянутая инфраструктура.

Это физическая «аппаратная» сеть внутри дата-центров, между дата-центрами и в точках подключения к внешним сетям.

Виртуальная сеть создается поверх сетевой инфраструктуры, а сетевые службы создаются поверх виртуальной сети.

Эта структура не монолитна: уровни пересекаются, виртуальная сеть и сетевые сервисы напрямую взаимодействуют с сетевой инфраструктурой.

Поскольку виртуальную сеть часто называют оверлеем, мы обычно называем сетевую инфраструктуру подложкой.



MPLS есть везде.
</p><p>
 Как работает сетевая инфраструктура Яндекс.
</p><p>
Облака

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

Независимые – независящие друг от друга в разрезе сетей, инженерных и электротехнических систем и т.п.

О характеристиках.

География расположения дата-центров такова, что время прохождения между ними (туда и обратно, RTT) всегда составляет 6–7 мс.

Суммарная емкость канала уже превысила 10 терабит и постоянно увеличивается, ведь у Яндекса есть собственная оптоволоконная сеть между зонами.

Поскольку мы не арендуем каналы связи, мы можем быстро увеличить пропускную способность между ДЦ: каждый из них использует оборудование мультиплексирования с разделением по длине волны.

Вот наиболее схематичное изображение зон:

MPLS есть везде.
</p><p>
 Как работает сетевая инфраструктура Яндекс.
</p><p>
Облака

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

MPLS есть везде.
</p><p>
 Как работает сетевая инфраструктура Яндекс.
</p><p>
Облака

Здесь показана текущая магистраль Яндекса в регионе.

На нем работают все сервисы Яндекса, часть сети использует Облако.

(Это картинка для внутреннего использования, поэтому служебная информация намеренно скрыта.

Однако вы можете оценить количество узлов и соединений.

) Решение использовать опорную сеть было логичным: мы могли ничего не изобретать, а повторно использовать текущую инфраструктуру.

- «пострадал» за годы разработки.

Чем отличается первая картинка от второй? Прежде всего, зоны доступности не связаны друг с другом напрямую: между ними располагаются технические площадки.

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

Точки присутствия связаны с техническими площадками, через которые Яндекс и Облако соединяются с внешним миром.

Все точки присутствия охватывают весь регион.

Кстати, важно отметить, что с точки зрения внешнего доступа из Интернета все зоны доступности Облака равнозначны.

Другими словами, они обеспечивают одинаковую возможность подключения, то есть одинаковую скорость и пропускную способность, а также одинаковую низкую задержку.

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

Это можно сделать с помощью партнеров или самостоятельно.

Базовая сеть используется облаком в качестве транспорта MPLS.



МПЛС



MPLS есть везде.
</p><p>
 Как работает сетевая инфраструктура Яндекс.
</p><p>
Облака

Многопротокольная коммутация меток — чрезвычайно широко используемая технология в нашей отрасли.

Например, при передаче пакета между зонами доступности или между зоной доступности и Интернетом транзитное оборудование обращает внимание только на верхнюю метку, не «думая» о том, что находится под ней.

Таким образом, MPLS позволяет скрыть сложность Облака от транспортного уровня.

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

MPLS есть везде.
</p><p>
 Как работает сетевая инфраструктура Яндекс.
</p><p>
Облака

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

)

Почему МПЛС?

MPLS действительно не часто встречается в сетях центров обработки данных.

Часто используются совершенно разные технологии.

Мы используем MPLS по нескольким причинам.

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

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

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

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

Единственной проблемой при построении такой архитектуры была сигнализация.



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

Классический стек протоколов MPLS довольно сложен.

Это, кстати, одна из причин, почему MPLS не получил широкого распространения в сетях дата-центров.

Мы, в свою очередь, не использовали ни IGP (Interior Gateway Protocol), ни LDP (Label Distribution Protocol), ни другие протоколы распространения меток.

Используется только одноадресная рассылка BGP (протокол пограничного шлюза).

Каждое устройство, которое работает, например, как виртуальная машина, создает сеанс BGP со стоечным конечным коммутатором.



MPLS есть везде.
</p><p>
 Как работает сетевая инфраструктура Яндекс.
</p><p>
Облака

Сеанс BGP создается с использованием ранее известного адреса.

Нет необходимости автоматически настраивать коммутатор для работы каждого устройства.

Все коммутаторы настраиваются заранее и единообразно.

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

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

В результате на устройствах появляется информация о том, как они могут связаться друг с другом.

Путь коммутации меток строится от облачного шлюза через листовой коммутатор, коммутатор Spine и сеть до пограничного маршрутизатора.

Коммутаторы — это коммутаторы уровня 3, которые ведут себя как маршрутизаторы с меточными коммутаторами и «не осознают» окружающих их сложностей.

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

Ешьте свою собственную собачью еду

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

Вот схематическое изображение стоек в зонах доступности:

MPLS есть везде.
</p><p>
 Как работает сетевая инфраструктура Яндекс.
</p><p>
Облака

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

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

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

Поэтому мы отказались от отдельного сегмента.

Элементы нашей инфраструктуры работают в одной топологии сети и с одинаковым сетевым подключением.

Естественно, они запускаются в трех экземплярах — так же, как наши клиенты запускают свои сервисы в Облаке.



IP/MPLS-фабрика

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

MPLS есть везде.
</p><p>
 Как работает сетевая инфраструктура Яндекс.
</p><p>
Облака

В каждой зоне доступности около пяти модулей и около сотни стоек в каждом модуле.

Leaf — это стоечные коммутаторы, они соединяются внутри своего модуля по уровню Spine, а межмодульная связь обеспечивается через сетевой Interconnect. Это следующий уровень, который включает в себя так называемые Super-Spines и Edge коммутаторы, которые уже соединяют зоны доступности.

Мы сознательно отказались от L2, речь идет только о L3 IP/MPLS-подключении.

Протокол BGP используется для распространения информации о маршрутизации.

На самом деле параллельных соединений гораздо больше, чем на картинке.

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

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

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



MPLS есть везде.
</p><p>
 Как работает сетевая инфраструктура Яндекс.
</p><p>
Облака

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

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

Облако — особый случай.

Мы не можем диктовать клиенту, как строить собственные сервисы, и решили устранить эту возможную единую точку отказа.

Таким образом, все серверы в Облаке подключены к двум стоечным коммутаторам.

Точно так же мы не используем никаких протоколов резервирования на уровне L2, а сразу начали использовать только L3 с BGP — опять же из соображений унификации протоколов.

Это соединение обеспечивает каждую службу возможностью подключения по протоколам IPv4 и IPv6: некоторые службы работают через IPv4, а некоторые — через IPv6. Физически каждый сервер соединен двумя 25-гигабитными интерфейсами.

Вот фото из дата-центра:

MPLS есть везде.
</p><p>
 Как работает сетевая инфраструктура Яндекс.
</p><p>
Облака

Здесь вы видите два стоечных коммутатора со 100-гигабитными портами.

Видны расходящиеся кабели, разделяющие 100-гигабитный порт коммутатора на 4 25-гигабитных порта на каждый сервер.

Мы называем эти кабели «гидра».



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

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



MPLS есть везде.
</p><p>
 Как работает сетевая инфраструктура Яндекс.
</p><p>
Облака

Как управляется эта инфраструктура? В Облаке не то чтобы запрещено, но крайне не рекомендуется заходить на сетевое устройство и вносить какие-либо настройки.

Есть текущее состояние системы, и нам нужно применить изменения: прийти к какому-то новому, целевому состоянию.

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

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

С точки зрения сети — это небольшое облако, которое полностью копирует все существующее производство.

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

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

Кроме того, мы продолжаем внимательно следить за мониторингом.

Это довольно сложный процесс, о котором мы поговорим ниже.

Убедившись, что все в порядке, мы применяем изменение ко всей продукции.

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



Мониторинг

Нам нужен другой мониторинг.

Одним из самых популярных является сквозной мониторинг соединения.

В любой момент времени каждый сервер должен иметь возможность взаимодействовать с любым другим сервером.

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

Обеспечение сквозной связи — наша основная задача.

Каждый сервер перечисляет набор всех серверов, с которыми он должен иметь возможность взаимодействовать в любой момент времени.

Сервер берет случайное подмножество этого набора и отправляет пакеты ICMP, TCP и UDP всем выбранным машинам.

При этом проверяется, есть ли потери в сети, не увеличилась ли задержка и т. д. «Прозванивается» вся сеть в пределах одной из зон доступности и между ними.

Результаты отправляются в централизованную систему, которая визуализирует их для нас.

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

MPLS есть везде.
</p><p>
 Как работает сетевая инфраструктура Яндекс.
</p><p>
Облака

Здесь вы можете увидеть, между какими сегментами сети существует проблема (в данном случае A и B), а где все нормально (A и D).

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

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

Кроме того, есть мониторинг событий.

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

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

Но если вторая из трех сессий выходит из строя, происходит автоматический вызов инженера.

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

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

Тема мониторинга достаточно большая, есть огромные возможности для совершенствования.

Хотелось бы довести систему до большей автоматизации и реального самовосстановления.



Что дальше?

У нас много планов.

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

Мы также активно ищем переключатели «белого ящика».

Это готовое «аппаратное» устройство, коммутатор, на который можно загрузить свое программное обеспечение.

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

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

  • Мы значительно снизили сложность структуры IP/MPLS. С одной стороны, уровень виртуальной сети и средства автоматизации, наоборот, несколько усложнились.

    С другой стороны, сама подстилающая сеть стала проще.

    Другими словами, существует определенная «количество» сложностей, которых невозможно избежать.

    Его можно «перебрасывать» с одного уровня на другой — например, между сетевыми уровнями или с сетевого уровня на уровень приложений.

    Но мы можем разумно распределить эту сложность, что мы и пытаемся сделать.

  • И конечно, мы совершенствуем наш набор инструментов для управления всей инфраструктурой.

Это все, что мы хотели рассказать вам о нашей сетевой инфраструктуре.

Вот ссылка на Telegram-канал Облака с новостями и советами.

Теги: #Сетевые технологии #сетевое оборудование #ит-инфраструктура #облачные сервисы #дата-центры #команда Яндекс.

облака #Яндекс.

Облако #сетевая инфраструктура #mpls #bgp #виртуальная сеть

Вместе с данным постом часто просматривают: