Привет, Хабр!
Меня зовут Евгений, и с недавних пор я являюсь членом команды развития инфраструктуры в Домклике. Больше всего опыта у меня в области сетевых технологий, в простонародье я «сетевик». На сегодняшний день наша команда, да и не только наша, активно прорабатывает возможность использования облачной инфраструктуры для создания резервного центра обработки данных (РЦОД). А раз я много лет занимаюсь сетями, то вполне логично, что мне стало интересно решить одну задачку, о которой я хочу вам поведать.
Лирическое отступление
Многие вопросы, такие как создание ресурсов типа VPC (Virtual Private Cloud), Network Subnet, ECS (Elastic Cloud Server), настройка сети в ОЦОД и так далее, выходят за рамки статьи. Также, по понятным причинам, все подсети изменены.
Задача
Есть у нас основная площадка в центре обработки данных (ОЦОД), и мы хотим наладить сетевое взаимодействие между ОЦОД и РЦОД. Одной из ключевых задач является проверка на отказоустойчивость и время недоступности при нештатных ситуациях. Мерилом тестирования будет длительность потери связи до вычислительных ресурсов в РЦОД. Мы выбрали облачного провайдера, на базе которого подняли dev-инфраструктуру, и пришла пора реализовывать сетевую связность.
Решение
Так как мы большой Enterprise, для нас очень важно добиться минимально допустимого простоя при нештатных ситуациях. Для решения этой задачи, в первую очередь, используя разные телекоммуникационные трассы, мы подключили две волоконно-оптические линии связи (ВОЛС) между ОЦОД и РЦОД. Такая коммутация даёт нам отказоустойчивость на уровне физических линий.
По ряду причин не было возможности объединить эти ВОЛС в агрегированный канал, потому линии независимы.
Потратив немного времени, я нарисовал схему взаимодействия, в которой для маршрутизации между площадками использован встроенный в облако протокол BGP:
Согласно схеме, между ОЦОД и РЦОД будет настроено две P2P (peer-to-peer) подсети 192.168.255.0/30 и 192.168.255.4/30, где адреса 192.168.255.2 и 192.168.255.6 будут на стороне облачной инфраструктуры, а 192.168.255.1 и 192.168.255.5 на стороне маршрутизаторов ОЦОД. Между членами P2P-подсетей будет настроена BGP-сессия, в которой каждая сторона будет анонсировать свои префиксы. Из инфраструктуры ОЦОД будем анонсировать префикс 192.168.0.0/17, а из инфраструктуры РЦОД — 10.50.0.0/16.
Приступаем к реализации
К сожалению, большую часть работы нельзя выполнить с помощью подхода IaC и решения Terraform, а потому я буду опираться только на web-интерфейс управления своей инфраструктурой в облаке.
Кстати, кусок выделенных вам вычислительных ресурсов в облачной платформе называется Tenant.
Первым этапом было создание в облаке Connections, иными словами наши ВОЛС. Это сделали специалисты облачного провайдера. Теперь необходимо создать Virtual Gateway, он выступает в роли инструмента разделения нашей инфраструктуры в облаке и налаживания взаимодействиями с внешними интеграциями. Ниже представлен пример настройки:
Краткое пояснение полей:
Name — понятное название.
VPC — привязка к существующему VPC.
Subnet CIDR Block — подсеть, описанная в п.2.
Description — указываем, что хотим.
VPC или Virtual Private Cloud — это «облако в облаке», изолированный сегмент всего облака, в котором вычислительные ресурсы выделены только вам.
Здесь есть два очень важных момента, о которых стоит упомянуть:
Subnet CIDR Block — это поле описывает подсети, о которых должны узнать и с которыми могут работать за пределами VPC. В нашем случае тут описывается анонсируемый нами в BGP-префикс. Без правильной настройки Virtual Gateway маршрутизации не будет.
VPC — можно выбрать только при создании и оно никак потом не редактируется. Также стоит учитывать, что у одного VPC может быть только один Virtual Gateway.
Теперь надо создать и настроить Virtual Interface. Пример:
Пройдемся по полям:
Region — выбирается регион, "ru-moscow".
Name — понятное название.
Connection — выбирается в Direct Connect.
Virtual Gateway — выбирается ранее созданный.
Local Gateway — указываем адрес облака в P2P-подсети.
Remote Gateway — адрес маршрутизатора в ОЦОД.
Remote Subnet — указываем подсеть, которую нам будет анонсировать маршрутизатор в ОЦОД.
Routing Mode — способ получения маршрута.
BGP ASN — указываем номер автономной системы маршрутизатора ОЦОД, иными словами "peer AS".
BGP MD5 Authentication Key — симметричный ключ шифрования BGP-сессии.
Description — указываем, что хотим.
Почти все параметры, кроме Name, Remote Subnet и Description в Virtual Interface можно задать только в момент создания, после их изменить будет нельзя.
Подробнее расскажу про особенности полей "Remote Subnet" и "BGP ASN". Начну с последнего:
В текущей реализации мы не можем выбирать номер локальной автономной системы или как-то его менять, система сама выбирает первый свободный из пула приватных номеров, с 64512 по 65534. Иными словами, если это первая BGP сессия в вашей инфраструктуре, то номер локальной AS будет 64512, следующая получит номер 64513 и т.д. Подробнее про приватный пул AS можно прочесть в RFC6996.
Remote Subnet — указанная подсеть автоматически прописывается в дефолтной (default) таблице маршрутизации, которая привязана к используемому нами VPC. Со стороны пользователя это выглядит как статичный маршрут, у которого next-hop созданный нами Virtual Gateway. Даже если BGP-сессия упала и мы не получаем анонс, маршрут остаётся на месте.
Последним этапом будет создание правила, которое разрешит прохождение трафика в РЦОД из ОЦОД. Для регулирования сетевого взаимодействия между вычислительными ресурсами есть гибкий механизм — Security Group.
Security Group — это группа с набором правил входящего/исходящего трафика для ресурсов, которые в неё входят.
В примере выше мы разрешаем весь входящий трафик по всем портам из подсети 192.168.0.0/17. Это правило добавляем в Inbound Rules. Исходящее правило у нас будет базовым, то есть 0.0.0.0/0. Тогда вычислительный ресурс в такой Security Group может обращаться на любой IP-адрес, а пакеты примет от источника в подсети 192.168.0.0/17 и от членов той же группы.
Настало время всё это проверить, приступим...
Тестирование решения
С точки зрения сети у нас всё готово, BGP-сессии подняты, пинги между нами и виртуальными машинами исправно бегают, так что пора перейти к тестам на отказоустойчивость. Для этого напишем маленький скрипт, который будет в цикле «курлить» наши Nginx в РЦОД:
#!/bin/bash
x=1
while [ true ]
do
echo "Запрос в SCA № $x ↓"
curl -I -s http://nginx.testdomain.ru | egrep HTTP\|date
sleep 1
x=$(( $x + 1 ))
Возможно, кому-то будет полезно маленькое разъяснение, как это работает:
while
— это тип цикла, который будет повторяться, пока условие в скобках истинно.true
в нашем случае означает вечный цикл.echo
— выводимая надпись, где$x
увеличивается на 1 при каждом проходе цикла благодаря условиюx=$(( $x + 1 ))
.curl
— сам запрос, мы получим код ответа и время сервера (egrep
выводит строчки с точным совпадением).sleep
— устанавливает таймер ожидания перед продолжением, 1 сек.
Методика испытаний была предельно простой:
Что делаем |
Результат |
Запускаем скрипт в подсети ОЦОД. |
Получаем код 200. |
Разрываем одно соединение между площадками. |
Одна BGP-сессия упала. |
Включаем разорванное соединение. |
Все BGP-сессии работают. |
Разрываем второе соединение между площадками. |
Вторая BGP-сессия упала. |
Давайте кратко разберём каждый шаг:
-
Запустив скрипт, мы начинаем получать примерно такой вывод:
-
В ОЦОД мы разорвали одно соединение и пакеты стали теряться, а скрипт перестал получать какой-либо ответ, потому что с точки зрения облака их стало некуда отправлять. Но спустя примерно 27-28 секунд всё восстановилось, потому что стал активен маршрут, полученный через вторую BGP-сессию. Это время сходимости:
Восстановили работу первой BGP-сессии и не заметили какого-то влияния.
В ОЦОД мы разорвали второе соединение и получили примерно такую же картину, что и на шаге 2, с теми же 27-28 секундами потерь.
По итогам тестирования могу сказать, что 30 секунд простоя вполне приемлемый для нас результат. К сожалению, у облачного провайдера не реализован механизм балансировки ECMP, но и такой результат вполне удовлетворителен для наших задач.
Вывод
Схема рабочая и вполне жизнеспособная, но есть и существенные недостатки реализации BGP на базе облачной платформы, которые мне хотелось бы отметить:
Невозможно влиять на некоторые параметры настроек после их создания, а на некоторые — даже во время создания.
Невозможно посмотреть, какой локальный AS был выбран системой, эту информацию пришлось получать из дампа трафика на стороне ОЦОД.
Нехватает инструментов диагностики состояния BGP-сессии на стороне РЦОД.
Как и в любой большой системе, есть свои плюсы и минусы. Я верю, что со временем минусов станет меньше, появятся новые фишки и инструменты, ну а пока могу сказать, что этим решением вполне можно пользоваться и работает оно достаточно стабильно. Какие-то более чёткие выводы можно будет сделать лишь после увеличения нагрузки.
Спасибо за внимание!
Комментарии (9)
iddqda
02.12.2021 12:09+130сек для p2p линков как то совсем печально
т.е. переход на запасной линк происходит по hello таймерам (можно подкрутить), а не по состоянию интерфейсов
интересно что именно разрывали?
поддеживается ли BFD со стороны VirtualGateway?
EvgenNet Автор
02.12.2021 13:3430сек для p2p линков как то совсем печально
т.е. переход на запасной линк происходит по hello таймерам (можно подкрутить), а не по состоянию интерфейсов
30 секунд уходит на протухание маршрутов в разорванной BGP сессии и активации маршрута из второй сессии. Да, тут можно играться с таймерами на стороне ОЦОД.
интересно что именно разрывали?
Разрывали физический линк со стороны ОЦОД, т.е. гасили интерфейс на коммутаторе.
поддеживается ли BFD со стороны VirtualGateway?
BFD тут скорее применителен именно к virtual interface, так как там описаны сети и режим BGP, если я правильно понял вопрос. И ответ на него - пока нет.
antonvn
02.12.2021 23:40+2Ожидал увидеть, что человек с одной стороны настроит BGP на Cisco, с другой стороны на Juniper, все это в cli конечно. Поднимет ip sla или еще какой триггер для переключения площадок. Подаст это все на виртуализацию. Покажет, как у него стартуют или деплоятся dev виртуалки на резерве, особенно когда там меняется IP адресация.
Не увидел. Расстроился. Наверное, старею.
EvgenNet Автор
03.12.2021 10:25Я наверное не очень точно попал в название статьи. Целью было рассказать, как устроена работа BGP в облачной платформе со стороны пользователя UI. К сожалению, на стороне облака я очень ограничен в технологиях и настройках.
antonvn
03.12.2021 10:33Так вы даже не написали, что у вас за облако. Их же миллион, и у каждого свои менюшки и окошки. Завтра они поменяются, и что? Мы же не знаем, как эти конкретные заполненные поля превращаются в конкретные команды ios xr или апи вызовы неизвестного sdn контроллера. А главное, сколько там ждет глюков, багов и органичений.
EvgenNet Автор
03.12.2021 10:49К сожалению я не могу сказать, на базе какого облачного провайдера выполнено решение, но глубоко под капотом облака лежит OpenStack.
bukoka
07.12.2021 00:02+1Мне все время казалось, что 30 секунд для большого энтерпрайза это долго... прямо очень-очень. Ну разве что там не "боевые" сервисы, а тестовые или просто реплики-бекапы\прочий глубокий бэкграунд трафик, деградация которого на 30 секунд будет "не заметна" для фронт-энд пользователя.
Почему Вы не развернули какое-то "свое" решение в виде виртуального(ых) роутер(ов) на (например, CSRv) в Вашей вычислительной инфраструктуре? До него можно было бы и BFD настроить и все, что Вам угодно сделать "поверх" клауда (overlay-сеть), который предоставлял бы Вам просто L3 связность между Вашими WAN-роутерами.
Опять же, если подается оптика (L1) - почему нельзя её терминировать на обычном роутере(ах) в Вашей ЗО, а все остальное (VPC) подключить "стыком" с этого(их) роутеров с клаудом - Вы обсуждали данный подход с оператором облачного сервиса?
В общем кейс интересный, но подходы к снаряду могут быть разные. В виду того, что многие ограничения не описаны или не названы - я бы выбрал другой, на мой взгляд, более "правильный и быстрый" вариант :)
allexx
Подумал изначально что очередной перевод: «встроенный в облако протокол BGP», как это понимать «встроенный в облако”?
На картинке иконки AWS серпиков, а судя по UI облако похоже на яклакд.
(зануда) то ли я стал старый и помудрел, то ли Хабр в конец наводнялся совсем базовым и пресным контентом.
EvgenNet Автор
"Встроенный в облако" - это наличие возможности настраивать BGP из UI.
Вы помудрели, в том числе, благодаря таким "базовым" статьям. Кому-то может быть полезно :)