09 августа 2021

Время чтения: 12 минут

Pure L3 play на службе платформы виртуализации VMmanager

Александр Гришин

владелец продукта VMmanager

Сетевая настройка IP-fabric в VMmanager помогает экономить публичные IP-адреса и создавать изолированные сети

Осенью прошлого года в платформе для виртуализации появилась новая схема настройки сети — IP-Fabric на основе BGP. Мы уже писали о преимуществах этой технологии для изолирования приватных сетей и экономии IP-адресов. А в этой раз руководитель платформы Александр Гришин расскажет, подробнее, как работает IP-fabric и как использовать её в кластере.

IP-Fabric позволяет использовать публичную сеть виртуальной машины или контейнера поверх локальной сети компании. Эта настройка обеспечивает абстрагирование сервиса от внутренней инфраструктуры.

Расскажу об особенностях ее реализации и покажу вариант настройки IP-Fabric.

IP-Fabric: настройка в VMmanager

Словарик

BGP — протокол динамической маршрутизации. Отвечает за обмен маршрутами между узлами и сетевым оборудованием компании.

Узел — физический сервер, на котором разворачиваются виртуальные машины и контейнеры.

Core или Border Gateway — устройство, через которое осуществляется маршрутизация.

Сервис Bird — ПО которое реализует работу BGP-протокола в Linux.

Route Reflector (RR) — устройство, которое принимает маршруты от узлов и передаёт их на Core/Border Gateway посредством протокола BGP.

Термином IP-Fabric мы называем одну из конфигураций сети на узлах в VMmanager. Конфигурация применяется на весь кластер. Это оцифрованные знания наших сетевых инженеров упакованные в продукт. Фактически мы имеем несколько уровней:

Underlay уровень — обычная локальная плоская сеть для узлов. К ней могут иметь доступ определенные специалисты компании. Это безопасный закрытый контур компании.
Overlay уровень имеет размер /32, публичный IP-адрес и создается для каждой виртуальной машины или контейнера. Это point-to-point соединение от маршрутизатора до конкретного виртуального интерфейса на гипервизоре. Маршрутизация до этого интерфейса осуществляется по BGP. Адреса ВМ и контейнеров анонсируются в сторону сети. Таким образом пользователь получает доступ к своей виртуальной машине или контейнеру по публичному адресу.

Схема анонсирования BGP маршрутов с узла в сторону маршрутизатора

Функциональность IP-fabric настраивается и используется на уровне кластера и применяется ко всем узлам в кластере. Рассмотрим некоторые технические особенности такой конфигурации кластера:

На узлах не используются linux-bridge;
Шлюзом по умолчанию для каждой виртуальной машины является отдельный виртуальный интерфейс на узле (vnet);
Все эти виртуальные интерфейсы имеют одинаковый IP-адрес и mac-адрес;
Узлы выступают в роли маршрутизаторов, и несмотря на одинаковый IP и mac-адрес интерфейса, точно знают, какому интерфейсу предназначен тот или иной пакет
VMmanager автоматически устанавливает, настраивает и обслуживает сервис Bird на каждом узле;
Можно использовать роль RR для обмена маршрутов между узлом и маршрутизатором. Это позволяет не перенастраивать маршрутизатор «на горячую» при добавлении узлов в кластер;
Необходимо настраивать соседство между RR и каждым узлом кластера;
Соседство между RR и маршрутизатором настраивается один раз. Перенастраивать маршрутизатор при добавлении новых узлов нет необходимости;
Для обеспечения отказоустойчивости можно использовать несколько RR на кластер;
Технически можно не использовать роль RR и сразу “соседиться” с маршрутизатором. Это оправдано для тестового или лабораторного стенда в песочнице. Однако такая схема не рекомендуется в продакшен — при добавлении новых узлов в кластер придется каждый раз конфигурировать Border Gateway/Core… А значит, в случае ошибки, можно «положить» всю сеть компании.

Более безопасный вариант — один раз настроить промежуточную роль — RR, а затем настраивать соседство между ним и вновь добавленными узлами.

Принципиальная схема сети в кластере с IP-fabric. IP 10.0.0.1 для виртуальных интерфейсов можно изменить на любой другой на этапе создания кластера виртуализации

Когда в кластере создаётся новая виртуальная машина или контейнер, происходит следующее:

ВМ или контейнер разворачиваются на узле;
Настраивается маршрутизация на узле;
Конфигурируется сервис bird на узле;
Bird анонсирует через BGP новый маршрут до виртуальной машины для Route Reflector;
Route Reflector передаёт этот маршрут по BGP дальше, в сторону Core (Border Gateway);
Core (Border Gateway) получает информацию о маршруте до новой виртуальной машины и может обрабатывать её трафик в обоих направлениях.

Сам RR не принимает участие в маршрутизации трафика. Он служит лишь BGP-посредником между узлами и Border Gateway/Core, поэтому не слишком требователен к ресурсам.

Схема публичной overlay-сети для ВМ поверх частной underlay-сети

Теперь когда стало понятно, как всё работает, настал момент рассказать какую выгоду это принесет компании. И оказывается, IP-fabric закрывает сразу несколько потребностей компаний:

Сохраняет деньги. IP-fabric экономит публичные адреса. И чем больше инфраструктура компании, тем существеннее выгода.
Повышает безопасность. Инфраструктура компании находится по сути в закрытом контуре, изолированном от клиентов. А все клиенты изолированы друг от друга.
Повышает удовлетворенность клиентов. Благодаря исключению клиентского широковещательного трафика, производительность сети повышается в несколько раз. Это положительно сказывается на удовлетворенности сервисом, ведь все любят когда сеть работает быстро.

Интерфейс создания кластера с IP-Fabric в продукте VMmanager

Стоит отметить, что для решения этих задач в некоторых компаниях используют VLAN. Однако 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, с которым осуществляется пиринг

Добавляем новый фильтр:


set policy-options policy-statement VM term isp-ipv4 from protocol bgp
set policy-options policy-statement VM term isp-ipv4 from route-filter {{ filter }} orlonger
set policy-options policy-statement VM term isp-ipv4 then accept
set policy-options policy-statement VM then reject
set policy-options policy-statement reject-all then reject

Добавляем в конфиг новую группу:


set protocols bgp group VM import VM
set protocols bgp group VM export reject-all
set protocols bgp group VM peer-as {{ AS }}
set protocols bgp group VM neighbor {{ rr_ip }}

Проверяем и применяем конфигурацию:


commit check
commit confirmed 5

Если в течении 5 минут не позвать commit, будет осуществлен автоматический возврат настроек маршрутизатора.

Проверяем, что RR прислал нам маршруты (нас интересует строчка Accepted prefixes)

show bgp group VM detail

Если все нормально, то подтверждаем конфигурацию

commit

Алгоритм настройки RR

Теперь настроим соседство между маршрутизатором и RR, а также между RR и будущими узлами кластера виртуализации.

Устанавливаем 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.


log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug };
log "/var/log/bird.log" all;
log stderr all;

router id {{ local_ip }};

protocol kernel {
learn;
scan time 20;
import none;
export none;
}
function avoid_martians()
prefix set martians;
{
martians = [ 169.254.0.0/16+, 172.16.0.0/12+, 192.168.0.0/16+, 10.0.0.0/8+, 224.0.0.0/4+, 240.0.0.0/4+, 0.0.0.0/0{0,7} ];
# Avoid RFC1918 and similar networks
if net ~ martians then return false;
return true;
}

filter ibgp_policy_out
prefix set pref_isp_out;
{
pref_isp_out = [ {{ filter }} ];
if ( net ~ pref_isp_out ) then
{
    bgp_origin = 0;
    bgp_community = -empty-;
    bgp_community.add(({{ bird.as }},{{ bird.community }}));
    accept "VPS prefix accepted: ",net;
}
reject;
}
filter ibgp_policy_in
prefix set pref_isp_in;
{
if ! (avoid_martians()) then reject "prefix is martians - REJECTING ", net;
pref_isp_in = [ {{ filter }} ];
if ( net ~ pref_isp_in ) then
{
    accept "VPS remote prefix accepted: ",net;
}
reject;
}

protocol device {
scan time 60;
}

protocol bgp router {
description "{{ route.name }}";
local as {{ bird.as }};
neighbor {{ router.ip }} as {{ bird.as }};
default bgp_med 0;
source address {{ local_ip }};
import filter none;
export where source=RTS_BGP;
export filter ibgp_policy_out;
rr client;
rr cluster id {{ local_ip }};
}
protocol bgp node1 {
description "{{ neighbor }}";
local as {{ bird.as }};
multihop 255;
neighbor {{ neighbor_ip }} as {{ bird.as }};
source address {{ local_ip }};
import filter ibgp_policy_in;
export none;
rr client;
rr cluster id {{ local_ip }};
}

Перезапускаем bird: systemctl restart bird.

Проверяем, что получили список маршрутов до VDS с узла:

show route all protocol node1

Если маршрутов нет, проверяем лог /var/log/bird.log

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

Алгоритм настройки IP-Fabric в платформе VMmanager

Последний этап, настраиваем конфигурации сети в интерфейсе продукта.

Установить VMmanager на сервер;

В VMmanager 6 создать кластер с типом сети IP-Fabric;

Указать информацию для связи с Core Gateway по BGP;

Указать информацию для соединения с первым RR;

Зайти в раздел Сети и указать информацию о сетях и пулах IP-адресов;

Подключить сервера под гипервизоры в кластер;

Создать ВМ или контейнер.

При создании IP-fabric кластера платформа предлагает IP и MAC адреса для шлюза по умолчанию, который будет настроен на ВМ и контейнерах. Этим шлюзом является виртуальный интерфейс vnet на узле.

Остальные параметры AS, BGP-community (bird.community) и адреса Route-reflectors — те же самые, что мы использовали при настройке маршрутизатора и RR.

Настройка IP-fabric кластера в интерфейсе платформы VMmanager

Вот и все, мы получили кластер в VMmanager, который предоставляет виртуальную инфраструктуру заказчику, используя ip-fabric.

Немного о планах

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

Как попробовать IP-fabric

Приглашаю вас поделится своим мнением в комментариях и попробовать IP-fabric в VMmanager.

Заказать демо

И присоединяйтесь к нашему вебинару про IP-fabric, который состоится осенью. Чтобы не пропустить мероприятие, предварительно записаться на него можно уже сейчас.

Зарегистрироваться на вебинар