Масштабируемые сети в OpenStack. Часть 1: плоская топология

За последнее время сети в OpenStack прошли эволюцию от простой, едва ли пригодной к использованию модели к более совершенной с возможностью полной изоляции владельцев. Поддержка различных требований пользователей в OpenStack реализована с помощью т.н. “сетевых менеджеров”. Сетевой менеджер определяет сетевую топологию конкретного деплоймента OpenStack. Начиная с версии Essex, пользователь может выбрать один из трех вариантов сетевых менеджеров: FlatManager, FlatDHCPManager, VlanManager. В этой части статьи мы рассмотрим первые два, для последнего будет отведена вторая часть.

У менеджеров FlatManager и FlatDHCPManager есть много общего. Оба они основываются на концепции сетевых мостов (bridged networking) с использованием одного моста. В качестве примера рассмотрим сеть, состоящую из нескольких узлов.

Для каждого вычислительного узла создается 1 виртуальный мост, имя которого задается в конфигурации Nova с помощью опции:

flat_network_bridge=br100

Все виртуальные машины, запускаемые OpenStack, присоединяются к этому выделенному мосту.

Сетевой мост на вычислительном узле OpenStack

Главным недостатком подхода с использованием одного моста на вычислительный узел является известное ограничение сетевых мостов в Linux — мост может быть присоединен только к одному физическому интерфейсу (ограничение можно обойти с помощью VLAN, но они не поддерживаются FlatDHCPManager и FlatManager). По этой причине невозможна изоляция на втором уровне, и все узлы работают в одном домене ARP.

В основе FlatManager и FlatDHCPManager лежит идея наличия 1 “плоского” пула IP адресов, заданного для всего кластера. Это адресное пространство делится между всеми пользовательскими машинами, вне зависимости от того, какому владельцу они принадлежат. Каждый владелец может забрать любой адрес из доступных в пуле.

FlatManager

Сетевой менеджер FlatManager предоставляет наиболее примитивный набор операций. Его роль состоит только в присоединении пользовательской машины к мосту на вычислительном узле. По умолчанию менеджер не настраивает IP на пользовательской машине. Эта задача ложится на плечи системного администратора и может быть выполнена с помощью внешнего DHCP сервера.

Сетевая топология с использованием FlatManager

FlatDHCPManager

Сетевой менеджер FlatDHCPManager подключает заданную пользовательскую машину к мосту и предоставляет DHCP сервер.

Таким образом, на каждом вычислительном узле:
•сетевой мост получает адрес из “плоского” пула IP адресов
•запускается процесс dnsmasq, который слушает IP адрес мостового интерфейса
•мост выступает в роли шлюза по умолчанию для всех пользовательских машин, запущенных на вычислительном узле

Сетевая топология с использованием FlatDHCPManager
Для сервиса dnsmaq сетевой менеджер FlatDHCPManager на каждом вычислительном узле создает статические записи, чтобы гарантировать получение одного и того же IP адреса для заданной пользовательской машины. Файл записей создается на основе базы данных Nova и состоит из MAC-адреса, IP и имени машины. Предусмотрено, что сервер dnsmasq раздает адреса только машинам, запущенным локально на вычислительном узле. Это достигается фильтрацией записей из таблицы ‘instances’ по полю ‘host’. Также, шлюз по умолчанию выставляется в IP адрес мостового интерфейса. На следующем рисунке вы можете увидеть, что шлюз по умолчанию зависит от того, на каком вычислительном узле расположена виртуальная машина.

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

root@vm_1:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0

root@vm_3:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.0.4 0.0.0.0 UG 0 0 0 eth0

По умолчанию все виртуальные машины в “плоской” сети могут видеть друг друга вне зависимости от того, какому владельцу они принадлежат. Изоляция может быть достигнута при помощи следующего флага из nova.conf:

allow_same_net_traffic=False

Это настраивает политики iptables, которые блокируют любой трафик между машинами (даже в пределах одного владельца) до тех пор, пока он не будет разрешен с помощью групп безопасности (security group).

С практической точки зрения “плоские” сетевые менеджеры выглядят пригодными для однородных довольно небольших внутренне-корпоративных облаков, в которых нет владельцев как таковых, либо их количество сильно ограничено. Обычно сценарий использования — это динамически маштабируемый веб-сервер или HPC кластер. Для подобных задач обычно достаточно иметь единое пространство IP адресов, управляемых либо внешним DCHP сервером, либо процессом dnsmasq, предоставляемым OpenStack. С другой стороны это решение ограничено в плане масштабируемости, поскольку все виртуальные машины должны находиться в одном L2 домене.

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

Оригинал статьи на английском языке