Всем привет, меня зовут Александр Гришин, и я работаю продакт-менеджером в ISPsystem. И сегодня хочу рассказать об интересной разработке нашей компании — схеме сети IP-Fabric на основе BGP в платформе виртуализации VMmanager.
Осенью прошлого года мы добавили новую сетевую настройку для кластера виртуализации KVM, а чуть позже — и в кластер с LXD.
IP-Fabric позволяет использовать публичную сеть виртуальной машины или контейнера поверх локальной сети компании. Эта настройка обеспечивает абстрагирование сервиса от внутренней инфраструктуры.
Расскажу об особенностях ее реализации и покажу вариант настройки IP-Fabric.
IP-Fabric: настройка в VMmanager
Словарик
BGP — протокол динамической маршрутизации. Отвечает за обмен маршрутами между узлами и сетевым оборудованием компании.
Узел — физический сервер, где разворачиваются виртуальные машины и контейнеры (гипервизор).
Core или Border Gateway — устройство, через которое осуществляется маршрутизация.
Сервис Bird — ПО, реализующее работу BGP-протокола в Linux.
Route Reflector (RR) — устройство, которое принимает маршруты от узлов и передаёт их на Core/Border Gateway посредством протокола BGP (Эту роль может выполнять как специализированное оборудование, так и просто linux сервер с ПО bird на борту).
IP-Fabric мы называем одну из конфигураций сети на узлах в VMmanager. Конфигурация применяется на весь кластер. Это оцифрованные знания наших сетевых инженеров, упакованные в продукт. Фактически в IP-Fabric мы имеем несколько уровней:
Underlay уровень — обычная локальная плоская сеть для узлов. К ней могут иметь доступ определенные специалисты. Это может быть безопасный закрытый контур компании.
Overlay уровень имеет размер /32, публичный IP-адрес и создается для каждой виртуальной машины или контейнера. Это point-to-point соединение от маршрутизатора до конкретного виртуального интерфейса на узле. Маршрутизация до этого интерфейса осуществляется по BGP. Адреса ВМ и контейнеров анонсируются в сторону сети. Таким образом пользователь получает доступ к своей виртуальной машине или контейнеру по публичному адресу.
Функциональность IP-fabric настраивается и используется на уровне кластера и применяется ко всем узлам в кластере. Рассмотрим некоторые технические особенности такой конфигурации кластера:
На узлах не используются linux-bridge;
Шлюзом по умолчанию для каждой виртуальной машины является отдельный виртуальный интерфейс на узле (vnet);
Все эти виртуальные интерфейсы имеют одинаковый IP-адрес и mac-адрес;
Узлы выступают в роли маршрутизаторов, и несмотря на одинаковый IP и mac-адрес интерфейса, точно знают, какому интерфейсу предназначен тот или иной пакет;
VMmanager автоматически устанавливает, настраивает и обслуживает сервис Bird на каждом узле;
Можно использовать роль RR для обмена маршрутов между узлом и маршрутизатором. Это позволяет не перенастраивать маршрутизатор «на горячую» при добавлении узлов в кластер;
Необходимо настраивать соседство между RR и каждым узлом кластера;
Соседство между RR и маршрутизатором настраивается один раз. Перенастраивать маршрутизатор при добавлении новых узлов нет необходимости;
Для обеспечения отказоустойчивости можно использовать несколько RR на кластер;
Технически можно не использовать роль RR и сразу «соседиться» с маршрутизатором. Это оправдано для тестового или лабораторного стенда в песочнице. Однако такая схема не рекомендуется в продакшен — при добавлении новых узлов в кластер придется каждый раз конфигурировать Border Gateway/Core… А значит, в случае ошибки, можно «положить» всю сеть компании.
Более безопасный вариант — один раз настроить промежуточную роль — RR, а затем настраивать соседство между ним и вновь добавленными узлами.
Когда в кластере создаётся новая виртуальная машина или контейнер, происходит следующее:
ВМ или контейнер разворачиваются на узле;
Настраивается маршрутизация на узле;
Конфигурируется сервис bird на узле;
Bird анонсирует через BGP новый маршрут до виртуальной машины для Route Reflector;
Route Reflector передаёт этот маршрут по BGP дальше, в сторону Core (Border Gateway);
Core (Border Gateway) получает информацию о маршруте до новой виртуальной машины и может обрабатывать её трафик в обоих направлениях.
Сам RR не принимает участие в маршрутизации трафика. Он служит лишь BGP-посредником между узлами и Border Gateway/Core, поэтому не слишком требователен к ресурсам.
Теперь когда стало понятно, как всё работает, настал момент рассказать какую выгоду это принесет компании. И оказывается, IP-fabric закрывает сразу несколько потребностей компаний:
Сохраняет деньги. IP-fabric экономит публичные адреса. И чем больше инфраструктура компании, тем существеннее выгода.
Повышает безопасность. Инфраструктура компании находится по сути в закрытом контуре, изолированном от клиентов. А все клиенты сети изолированы друг от друга.
Повышает удовлетворенность клиентов. Благодаря исключению клиентского широковещательного трафика, производительность сети повышается в несколько раз. Это положительно сказывается на удовлетворенности сервисом, ведь все любят когда сеть работает быстро.
Часто для решения этих задач используют VLAN. VMmanager позволяет настроить и такие варианты конфигурации — плоской сети. Однако IP-fabric даёт преимущества при масштабировании и возможность просто обслуживать десятки тысяч изолированных клиентских объектов.
Вариант настройки IP-fabric
Рассмотрим простой вариант настройки IP-fabric в инфраструктуре, которая состоит из кластера серверов под виртуализацию. Роль Border Gateway выполняет маршрутизатор Juniper MX. В качестве Route Reflector будут несколько физических серверов на Linux.
Нам понадобятся:
Сервер для установки платформы VMmanager 6;
Один или несколько серверов под гипервизоры с установленной ОС CentOS 8 для KVM или с OC Ubuntu 20.04 для LXD;
Один или два linux-сервера под роль RR;
Возможность настраивать BGP сессии на стороне Juniper MX;
Данные о автономной системе BGP для узлов VMmanager и Core Gateway;
Пул IP-адресов для виртуальных машин.
Настройка IP-fabric проходит в три этапа:
Настройка маршрутизатора;
Настройка сервера в роли RR;
Настройка VMmanager.
Алгоритм настройки маршрутизатора
Настроим соседство между маршрутизатором и RR. Подключим RR к маршрутизатору Juniper MX:
Перед настройкой у вас уже должен быть настроен BGP с вашим провайдером.
Заменяем переменные
{{ AS }} — AS
{{ filter }} — список сетей, которые мы принимаем со стороны VMmanager, а так же которые мы отдаем на роутер
{{ rr_ip }} — IP-адрес RR, с которым осуществляется пиринг
Добавляем новый фильтр:
|
Добавляем в конфиг новую группу:
|
Проверяем и применяем конфигурацию:
|
Если в течении 5 минут не позвать commit, будет осуществлен автоматический возврат настроек маршрутизатора.
Проверяем, что RR прислал нам маршруты (нас интересует строчка Accepted prefixes)
|
Если все нормально, то подтверждаем конфигурацию
|
Алгоритм настройки RR
Теперь настроим соседство между маршрутизатором и RR, а также между RR и будущими узлами кластера виртуализации.
Берем свободный физический linux сервер (bird не требователен к ресурсам, можно использовать самую простую конфигурацию сервера под эту роль).
Устанавливаем bird на сервер.
Перед настройкой нам понадобится подготовить следующую информацию:
{{ filter }} — список сетей, которые мы принимаем со стороны VMmanager, а так же которые мы отдаем на роутер;
{{ local_ip }} — ip-адрес RR, с которым осуществляется пиринг как со стороны VMmanager так и со стороны роутера;
{{ bird.as }} — AS;
{{ bird.community }} — комьюнити;
{{ route.name }} — подпись для роутера;
{{ router.ip }} — ip-адрес роутера, с которым осуществляется пиринг;
{{ neighbor }} — описание для узла VMmanager;
{{ neighbor_ip }} — ip-адрес узла VMmanager для пиринга.
Прописываем конфиг /etc/bird/bird.conf.
|
Перезапускаем bird:
systemctl restart bird.Открываем консоль командой
birdcПроверяем, что получили список маршрутов до ВМ с узла:
show route all protocol node1
Если маршрутов нет, проверяем лог /var/log/bird.log
Важно: если в будущем появится необходимость добавить новые узлы в кластер, нужно будет редактировать параметры настройки RR.
Алгоритм настройки IP-Fabric в платформе VMmanager
Последний этап: настраиваем конфигурации сети в интерфейсе продукта.
Устанавливаем VMmanager на сервер;
В VMmanager 6 создаём кластер с типом сети IP-Fabric;
Указываем информацию для связи с Core Gateway по BGP;
Указываем информацию для соединения с первым RR;
Заходим в раздел Сети и указать информацию о сетях и пулах IP-адресов;
Подключаем серверы под гипервизоры в кластер;
Создаём ВМ или контейнер;
Проверяем сеть.
При создании кластера c IP-Fabric платформа предлагает IP и MAC-адреса для шлюза по умолчанию, который будет настроен на ВМ и контейнерах (можно оставить эти значения по умолчанию). Этим шлюзом является виртуальный интерфейс vnet($имя_машины) на узле, свой для каждой ВМ.
Остальные параметры AS, BGP-community (bird.community) и адреса Route-reflectors — те же самые, что мы использовали при настройке маршрутизатора и RR.
Вот и все: мы получили в VMmanager кластер, предоставляющий виртуальную инфраструктуру с использованием IP-Fabric.
Немного о планах
В этом году мы планируем развить IP-fabric в виртуальный IaaS. Пользователи VMmanager смогут получить не просто виртуальную машину или контейнер, а скоуп виртуальных объектов с пулом изолированных частных сетей под свои нужды. Реализовать эту функциональность помогут технологии VXLAN и EVPN, но подробнее об этом я расскажу в одной из следующих статей (если будет интерес).
Как попробовать IP-fabric
Приглашаю вас поделится своим мнением в комментариях и попробовать IP-fabric в VMmanager.
Заказать демо
А еще приглашаю вас на вебинар про IP-fabric. Он состоится осенью этого года, а предварительно записаться на него можно прямо сейчас!
Зарегистрироваться на вебинар
Благодарности
Благодарю за помощь в написании материала, а также за тестирование и обкатку бета-версии IP-Fabric в VMmanager:
DevOps инженера компании ISPsystem и по совместительству System Analyst команды VMmanager Илью Калиниченко;
Сетевого архитектора компании FirstVDS Стаса Титова;
Системного архитектора компании G-core labs Олега Сироткина.
