Overlay и underlay сети на службе платформы виртуализации VMmanager10.08.2021 14:31

Всем привет, меня зовут Александр Гришин, и я работаю продакт-менеджером в ISPsystem. И сегодня хочу рассказать об интересной разработке нашей компании — схеме сети IP-Fabric на основе BGP в платформе виртуализации VMmanager.

Осенью прошлого года мы добавили новую сетевую настройку для кластера виртуализации KVM, а чуть позже — и в кластер с LXD.

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

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

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

Принципиальная схема IP-fabric кластера

Словарик

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. Адреса ВМ и контейнеров анонсируются в сторону сети. Таким образом пользователь получает доступ к своей виртуальной машине или контейнеру по публичному адресу.

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

Часто для решения этих задач используют VLAN. VMmanager позволяет настроить и такие варианты конфигурации — плоской сети. Однако IP-fabric даёт преимущества при масштабировании и возможность просто обслуживать десятки тысяч изолированных клиентских объектов.

VMmanager поддерживает настройку практически любой конфигурации плоской сети используя bridge, bond и VLAN

Вариант настройки 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

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

Алгоритм настройки 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.

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.
Открываем консоль командой birdc
Проверяем, что получили список маршрутов до ВМ с узла:

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 в продукте VMmanager

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

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

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

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

Кластер виртуальной инфраструктуры с включенной 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 Олега Сироткина.