Когда ты провайдер с большим набором услуг — от colocation и выделенных серверов до облачных серверов и частного облака на VMware, в какой-то момент сталкиваешься с вопросом, как связать их между собой одной сетью. Учитывая разную природу облачных и bare-metal-сервисов, это задача под звездочкой.

В Selectel мы прошли от ручного и немного костыльного метода до услуги L3 VPN, связыющей все продукты компании. Под катом директор по развитию ядра облачной платформы Иван Романько рассказывает, как мы перешли c VLAN на VxLAN, писали собственную систему SDN (Software-defined networking) и допиливали OpenStack Neutron.

Как появилась потребность в связности разных услуг

Сейчас услуга L3 VPN решает три задачи, к которым раньше в Selectel подходили по-разному.

Задача 1. Связать выделенные серверы в разных локациях

Сначала это были серверы в одном регионе, но в разных локациях — например, в Дубровке и в ДЦ «Цветочная» или в разных дата-центрах Дубровки (Ленинградская область). С появлением дата-центра в Москве добавился сценарий распределенной инфраструктуры в двух столицах.

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

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

Закрытием таких задач занимались сетевые инженеры Selectel вручную — вносили нужные изменения на сетевом оборудовании. Связывали два разных VLAN между собой либо старались выдать тот же номер VLAN в другом дата-центре. Последнее было удобно и нам, и клиенту, но получалось так далеко не всегда. Если клиент решал разместиться в другом пуле через год после его запуска, шансы найти там парный номер сводились к нулю.

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

Задача 2. Связать выделенные серверы с несколькими виртуальными машинами

Клиенты, которые запускали приложения на выделенных серверах, а потом что-то еще приобретали в облаке, приходили с вопросом: «Нельзя ли сделать так, чтобы мои серверы видели несколько виртуальных машин в облаке?»

Технически это валидный запрос, но далеко не каждый провайдер такое предлагал.

Почему? Чтобы это реализовать, в облаке должна быть та «виртуальная приватность», о которой мы упоминали в первом тексте цикла. То есть клиенты в облаке должны иметь изолированные друг от друга L2-сегменты. Поскольку большинство облачных конкурентов предлагали просто VDS c общей шареной сетью с публичными адресами, они не могли выделить приватные для клиента L2-сегменты.

Чтобы решить задачу связности выделенных и облачных серверов, в Selectel мы реализовали технологию Q-in-Q. Она инкапсулирует тег VLAN с двумя уровнями — внутренним тегом частной сети и внешним тегом общедоступной сети. Когда пакет прибывает на сетевое оборудование от гипервизора, на котором включен Q-in-Q, он уже имеет двойной тег VLAN.

В выделенных серверах туннелирование Q-in-Q позволяло связывать несколько разных VLAN-ID, а в облаке, где мы использовали Q-in-Q VLAN, — направлять трафик в определенную виртуальную метку в облаке, где рядом таких еще миллион.

На каждую compute-ноду подавался Q-in-Q VLAN с заранее «нарезанными» в нем тегами — от 2 до 4094. Все, что нам требовалось, — это создать сеть для клиента с типом VLAN и указать, какой тег использовать. Далее передавали информацию в сетевой отдел, который прописывал указанный тег до нужных выделенных серверов.

Эта схема не автоматизировалась. Если клиент отказывался от всех выделенных серверов, часть сети могла остаться на стороне облака. Просто человеческий фактор — могли забыть передать, чтобы там разобрали сеть.

Задача 3. Связать несколько облачных регионов или пулов

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

Тогда мы реализовали cross-region сети, связывая виртуальные VLAN между собой. Тут схема была еще сложнее: трафик нужно было передавать через промежуточное сетевое оборудование между дата-центрами.

Критичные минусы этих решений

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

На тот момент, а это был 2016 год, технологически мы не могли решать все три задачи связности иначе. Только «растягиванием» L2-сегмента на инфраструктуру, обозначенную клиентом. В случае с выделенными серверами все было еще не так плохо: связывая 20 дедиков в одной локации с 20 машинами в другой, мы объединяем 40 серверов. Если связывать те же 20 выделенных серверов с облаком, все гораздо сложнее. Получается, нам надо было связать 20 машин клиента с сотней серверов в облаке этим первым тегом Q-in-Q.

На базовом уровне мы постоянно рисковали растущим отказ-доменом двух разных услуг — с разными политиками по трафику и его увеличения.

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

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

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

Очень много ручной работы и невозможность ее автоматизировать

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

Если в аппаратной части этой задачи мы на тот момент не могли ничего изменить, то облегчить процессы пытались. Как минимум по части работы с облаком. Так, мы научились выдавать системным администраторам облака API и обвязку, которые снимали человеческий фактор на этапе заведения Q-in-Q VLAN в облако.

Также договорились, что в каждом новом регионе облака у нас будет зарезервирован диапазон VLAN — одинаковый во всех регионах. Если клиент хотел связать облачные серверы в нескольких регионах, мы просто выдавали один из этих VLAN. Тем самым мы спасались от ошибок на стороне клиента, если он будет работать с двумя разными VLAN и сделает что-то не то. На тот момент у нас было три региона (ныне — пулы) — ru-1, ru-2, ru-3.

VxLAN

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

В общем, нужно было выходить на новый уровень — инструментом здесь стал VxLAN.

VxLAN позволяет надстраивать над нашей сетью дополнительную overlay-сеть уровня L3. Эта технология позволяет обычные ethernet-кадры упаковывать в UDP-сегменты и транспортировать их в таком виде по IP-сети. Главным для нас стало то, что мы устраняли невозможность маршрутизации VLAN и ограничение диапазона 4096 VLAN на коммутационный домен.

Реализовывалось это добавлением новой сетевой «железки» — VxLAN Switch. Они всегда ставятся парами — для резервирования N+1 — на определенные локации.

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


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

Мы написали дополнительный плагин для OpenStack Neutron, ядра сети нашего облака. Назвали его bmnet-плагин (bare-metal networking). Он позволил строить сети не только между compute-хостами, но и в направлении bare-metal устройств. Написанный плагин отвечает за настройку VxLAN сетей для L3 VPN со стороны облака и по сей день. Например, его можно использовать для настройки удаленного endpoint для VxLAN, настраиваемых из облака во внешнюю сеть, или для настройки внешнего bare-metal файрвола.


В первой реализации архитектуры такой сети сеть строилась от compute-хоста, на котором располагались ВМ клиента, до уже упомянутого выделенного VTEP-коммутатора. А уже с него уходил Q-in-Q VLAN в сторону выделенных серверов и другого оборудования.

На данный момент эта схема все еще поддерживается, потому что мы успели перевести на нее значительную часть оборудования. При этом уже существует и новая, когда промежуточный VTEP-коммутатор не нужен, а VxLAN-тоннель строится от compute-ноды, на которой развернута ВМ клиента, сразу в современный роутер, включенный в регионально-распределенную фабрику.

Этот текст — часть цикла про развитие облака Selectel. Не пропустите другие тексты:

→ Как мы научились запускать новые облачные пулы за несколько дней
→ Как мы работаем с локальными и сетевыми дисками

Почему решили реализовать VxLAN

1. Основная ценность инфраструктурных продуктов для любого клиента — это надежность. Схема с общими VLAN была принципиально ненадежна для дата-центров большого размера. С ней можно было жить, как можно жить в небольшом городе без тротуаров. Но когда город растет и число машин увеличивается, без тротуаров не обойтись — машины начнут давить людей. VxLAN позволял нам исключить этот фактор ненадежности.
2. В какой-то момент скорость роста клиентов начала превышать скорость роста некоторотых наших дата-центров. Мы не успевали добавлять новые стойки! Раньше проблемы «у нас заканчивается место» не было. А тут клиент приходил и просил, например, еще тысячу ядер, а мы в ряде случаев могли предложить их только в другом регионе. Потому что в этом уже нет столько ресурсов.
   
   Быстрый и легкий скейлинг «from zero to hero» — еще одна ценность облаков. Нам нужно было обеспечивать его, чтобы клиенты не начали искать другого провайдера. VxLAN позволил достойно пережить период, когда мы уперлись в потолок мощности в некоторых регионах, и связывать инфраструктуру клиента в разных локациях практически бесшовно.

Почему мы просто не купили готовый SDN

Software-defined networking — это класс программ для управления сетями и сетевым оборудованием, который используют энтерпрайз или компании с сильно распределенной, при этом высоко интегрированной инфраструктурой — например, телеком-операторы.

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

Чем не подошло готовое решение:

• по тем временам это было неподъемно дорого,
• это настоящая технологическая «игла»: счет за систему увеличивается с ростом инфраструктуры, а на интеграцию нужно потратить очень много времени.

Одна из причин, по которой интеграция могла обернуться адом, была мультивендорность на стороне Selectel. Мы принципиально не планировали работать на сетевом оборудовании одного поставщика — оберегали себя от вендор-лока. Кроме того, у нас были кастомизации типа собственной системы настройки портов сетевого оборудования в выделенных серверах. Интегрироваться с ней и с целым набором разного сетевого оборудования было сложно.

Поскольку в итоге по функционалу нам нужно было что-то похожее на SDN, мы начали писать систему самостоятельно. К тому времени мы уже понимали, что нам нужна система, которая покрывала бы весь IaaS в Selectel, могли управлять настройками и в выделенных серверах, и в облаке.

Что начали делать

Запустили проект NaaS (networks as a service, «сети как сервис»). По названию можно понять, что изначально целились прямо в космос. Подразумевалось, что проект будет включать себя и глобальные L3-сети для объединения всех продуктов, и универсальные балансировщики в облаке и выделенных серверах, и межсетевые экраны.

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

Самым сложным было понять, во всех ли продуктах Selectel получится дописать необходимые автоматизации. Было проведено много встреч для того, чтобы решить все проблемы взаимодействия на уровне API, физического оборудования и его возможностях, поиска неисправностей и их решения.

Для разработки взяли стек, с которым мы умеем хорошо работать. В частности, несколько Python-библиотек. Одна из них — Taskflow — уже использовалась в OpenStack Octavia, на которой работают наши балансировщики нагрузки. Для организации сетей облака используем компонент OpenStack — Neutron.


Главным выхлопом проекта NaaS стала услуга L3 VPN. Универсальный балансировщик нагрузки и межсетевые экраны в Selectel мы тоже развиваем, но сейчас это отдельные проекты.



Сервис, который мы писали, по сути, представляет собой L3 VPN менеджер, который приходит на правах администратора в разные пулы облака и регулирует«движение»: «Вот эту сеть сюда заводим, а вот эту — сюда». С такими же привилегированными правами приходит в выделенные серверы и подключает выбранный VLAN к роутеру. И конечно, не забывает делать правильные настройки на сетевом оборудовании.

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

Сколько времени заняла разработка

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

L3 VPN сейчас

Сети L3 VPN запустились в декабре 2021 года. Все это время мы повышали надежность услуги, потому что в сетях она играет огромную роль. С первого релиза в панели управления мы отловили и исправили много мелких багов — к счастью, не было ни одного, который мог бы повлиять на работу сети. Сейчас L3 VPN — более чем надежная услуга, построенная отказоустойчиво.

Все больше продуктов Selectel стали использовать L3 VPN. Сейчас команда ведет работу в сторону автоматизации создания сетевой связности облака на базе VMware с другими услугами компании. Также реализуем расшаривание существующих ресурсов одного аккаунта — другому. В рамках частого запроса, когда клиент хочет иметь возможность подключить другой аккаунт с инфраструктурой к существующему роутеру и его ресурсам.

Сейчас у клиентов Selectel есть все для того, чтобы управлять L3-сетями через панель управления. В перспективе будет открыт API. Если у него были кастомные настройки сети, которые никак не покрылись этой системой, клиент про это знает — сеть помечена специальным лейблом. Управлять ею из панели нельзя, а все модификации проводятся через тикет-систему.

Настройки L3 VPN в панели управления Selectel

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

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

В начале следующего года сервис выйдет из беты и получит другое, более понятное для клиентов название.