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

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 и правда совсем не часто можно встретить в сетях дата-центров. Зачастую используются совсем другие технологии.

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

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

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

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

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

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

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

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

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

Eat your own dogfood

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

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

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

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

IP/MPLS-фабрика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мониторинги

Нам нужны разные мониторинги. Один из самых востребованных — мониторинг 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-сеть стала проще. Иными словами, есть определенное «количество» сложности, которое никуда не деть. Его можно «перекидывать» с одного уровня на другой — например, между уровнями сети или с уровня сети на уровень приложений. А можно эту сложность грамотно распределить, что мы и стараемся делать.
  • И конечно, ведётся доработка нашего набора инструментов по управлению всей инфраструктурой.

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Network tools, или с чего начать пентестеру?

Toolkit начинающего пентестера: представляем краткий дайджест главных инструментов, которые пригодятся при пентесте внутренней сети. Эти инструменты уже активно используются широким кругом специалистов, поэтому знать об их возможностях и владеть в совершенстве будет полезно каждому. Содержание: Nmap Nmap – opensource утилита ...

Домашняя лаборатория для самоконтроля, или что купить в гик-аптечку

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