Построение отказоустойчивого решения на базе BGP с использованием облачной платформы

Привет, Хабр!

Меня зовут Евгений, и с недавних пор я являюсь членом команды развития инфраструктуры в Домклике. Больше всего опыта у меня в области сетевых технологий, в простонародье я «сетевик». На сегодняшний день наша команда, да и не только наша, активно прорабатывает возможность использования облачной инфраструктуры для создания резервного центра обработки данных (РЦОД). А раз я много лет занимаюсь сетями, то вполне логично, что мне стало интересно решить одну задачку, о которой я хочу вам поведать.

Задача

Есть у нас основная площадка в центре обработки данных (ОЦОД), и мы хотим наладить сетевое взаимодействие между ОЦОД и РЦОД. Одной из ключевых задач является проверка на отказоустойчивость и время недоступности при нештатных ситуациях. Мерилом тестирования будет длительность потери связи до вычислительных ресурсов в РЦОД. Мы выбрали облачного провайдера, на базе которого подняли 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, он выступает в роли инструмента разделения нашей инфраструктуры в облаке и налаживания взаимодействиями с внешними интеграциями. Ниже представлен пример настройки:

Краткое пояснение полей:

1. Name — понятное название.

2. VPC — привязка к существующему VPC.

3. Subnet CIDR Block — подсеть, описанная в п.2.

4. Description — указываем, что хотим.

VPC или Virtual Private Cloud — это «облако в облаке», изолированный сегмент всего облака, в котором вычислительные ресурсы выделены только вам.

Здесь есть два очень важных момента, о которых стоит упомянуть:

• Subnet CIDR Block — это поле описывает подсети, о которых должны узнать и с которыми могут работать за пределами VPC. В нашем случае тут описывается анонсируемый нами в BGP-префикс. Без правильной настройки Virtual Gateway маршрутизации не будет.

• VPC — можно выбрать только при создании и оно никак потом не редактируется. Также стоит учитывать, что у одного VPC может быть только один Virtual Gateway.

Теперь надо создать и настроить Virtual Interface. Пример:

Пройдемся по полям:

1. Region — выбирается регион, "ru-moscow".

2. Name — понятное название.

3. Connection — выбирается в Direct Connect.

4. Virtual Gateway — выбирается ранее созданный.

5. Local Gateway — указываем адрес облака в P2P-подсети.

6. Remote Gateway — адрес маршрутизатора в ОЦОД.

7. Remote Subnet — указываем подсеть, которую нам будет анонсировать маршрутизатор в ОЦОД.

8. Routing Mode — способ получения маршрута.

9. BGP ASN — указываем номер автономной системы маршрутизатора ОЦОД, иными словами "peer AS".

10. BGP MD5 Authentication Key — симметричный ключ шифрования BGP-сессии.

11. 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 сек.

Методика испытаний была предельно простой:

Давайте кратко разберём каждый шаг:

1. Запустив скрипт, мы начинаем получать примерно такой вывод:

   

2. В ОЦОД мы разорвали одно соединение и пакеты стали теряться, а скрипт перестал получать какой-либо ответ, потому что с точки зрения облака их стало некуда отправлять. Но спустя примерно 27-28 секунд всё восстановилось, потому что стал активен маршрут, полученный через вторую BGP-сессию. Это время сходимости:

   

3. Восстановили работу первой BGP-сессии и не заметили какого-то влияния.

4. В ОЦОД мы разорвали второе соединение и получили примерно такую же картину, что и на шаге 2, с теми же 27-28 секундами потерь.

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

Вывод

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

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

• Невозможно посмотреть, какой локальный AS был выбран системой, эту информацию пришлось получать из дампа трафика на стороне ОЦОД.

• Нехватает инструментов диагностики состояния BGP-сессии на стороне РЦОД.

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

Спасибо за внимание!