Масштабируемые сети в Openstack. Часть 2: VlanManager

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

-Отсутствие масштабируемости (менеджеры, работающие в плоском режиме, полагаются на единый широковещательный домен L2 для всех установок OpenStack)
-Отсутствие изоляции пользователей (единый пул IP-адресов, который используется всеми пользователями)

В этой статье я концентрируюсь на VlanManager, который использует сетевой режим с несколькими узлами в OpenStack. За пределами “песочницы” это безопаснее, чем режим с одним узлом, так как многоузловой режим не страдает от единичного отказа, возникшего в результате работы отдельного экземпляра сервиса nova-network на всем кластере openstack. Тем не менее, возможно использовать VlanManager в режиме одного узла. (Больше о соотношении “многоузлового” и «одноузлового» режима можно почитать здесь ).

Отличия менеджеров, работающих в “плоском” режиме, и VlanManager

При работе с менеджерами в плоском режиме в процессе настройки сети администратор обычно выполняет следующие действия:
-Создает одну крупную сеть с фиксированными ip-адресами (обычно с сетевой маской из 16 или менее разрядов), которая совместно используется всеми пользователями:
nova-manage network create --fixed_range_v4=10.0.0.0/16 --label=public

-Создает пользователей
-После того, как пользователи создали свои экземпляры, назначает каждому свободный IP-адрес из общего пула IP-адресов.

Обычно в этом режиме IP-адресам выделяются экземпляры следующим образом:

tenant_1:

tenant_2:

Мы видим, что экземпляры tenant_1 и tenant_2 находятся в одной IP-сети, 10.0.0.0.

Если используется VlanManager, администратор действует следующим образом:
-Создает нового пользователя, записывает tenantID
-Создает выделенную фиксированную ip-сеть для нового пользователя:
nova-manage network create --fixed_range_v4=10.0.1.0/24 --vlan=102 \ --project_id="tenantID"
-После создания экземпляра пользователя автоматически будет назначен IP-адрес из частного пула IP-адресов.

Таким образом, по сравнению с FlatDHCPManager, мы дополнительно определяем две вещи для сети:
-Связь сети с конкретным пользователем (—project_id=). Таким образом, IP-адреса из сети не может брать никто, кроме пользователя.
-Выделение отдельной виртуальной сети для этой сети (—vlan=102).

С этого момента, как только пользователь создает новую виртуальную машину, она автоматически получает IP-адрес из выделенного пула. Также она помещается на выделенную виртуальную сеть vlan, которая автоматически создается и поддерживается платформой OpenStack. Таким образом, если мы создали две различные сети для двух пользователей, ситуация выглядит следующим образом:

tenant_1:

tenant2:

Явно видно, что экземпляры пользователей находятся в различных пулах IP-адресов. Но как поддерживаются виртуальные сети?

Как VlanManager настраивает сетевые параметры

VlanManager здесь делает три вещи:
-Создает выделенный мост для сети пользователя на вычислительном узле.
-Создает интерфейс vlan поверх интерфейса физической сети eth0 вычислительного узла.
-Запускает и настраивает процесс dnsmasq, соответствующий мосту, таким образом, чтобы экземпляр пользователя мог загружаться из него.
Давайте предположим, что пользователь под названием “t1” создает свой экземпляр t1_vm_1. Он попадает на один из вычислительных узлов. Вот так выглядит схема сети:

Мы видим, что был создан выделенный мост “br102” с интерфейсом vlan под названием “vlan102”. Кроме того, был создан процесс dnsmasq, который слушает на адресе 10.0.2.1. При загрузке экземпляра instance t1_vm_1 он получает свой адрес от процесса dnsmasq на основе статической аренды (подробно о том, как dnsmasq управляется платформой OpenStack, см. в предыдущей статье ).

Теперь, давайте предположим, что пользователь “t1” создает другой экземпляр под названием t1_vm_2, и он случайно оказывается на том же вычислительном узле, что и предыдущий созданный экземпляр:

Оба экземпляра подключены к одному мосту, так как они принадлежат одному пользователю, и таким образом они находятся в одной выделенной сети пользователи. Кроме того, они получают свою конфигурацию DHCP с одного сервера dnsmasq.

Теперь, представим, что пользователь “t2” создает своей первый экземпляр. Он также попадает на один вычислительный узел с пользователем “t1”. Кроме того, для его сети настроены выделенный мост, интерфейс vlan и процесс dnsmasq:

Таким образом, выходит, что в зависимости от числа пользователей, вполне нормальна ситуация, когда у вас достаточно большое количество сетевых мостов и процессов dnsmasq, и все работают на одном вычислительном узле.

Нет ничего странного в такой ситуации — OpenStack будет автоматически управлять всеми ними. В отличие от использования менеджеров в плоском режиме здесь оба экземпляра пользователей располагаются на разных мостах, которые не подключены друг к другу. Это обеспечит разделение трафика на уровне L2. В случае с пользователем “t1” трансляции ARP, передаваемые по br102, а затем по vlan102, не видны на портах br103 и vlan103, и наоборот.

Поддержка сетей пользователей на нескольких вычислительных узлах

Выше мы говорили о том, как это работает на одном вычислительном узле. Вероятнее всего вы будете использовать несколько вычислительных узлов. Обычно мы стремимся к наибольшему числу вычислительных узлов. Затем, вероятнее всего, пользователь “t1″ будет распределен между несколькими вычислительными узлами. Это означает, что выделенная сеть также должна быть распределена между несколькими вычислительными узлами. Тем не менее, она должна удовлетворять двум требованиям:
-Должно быть обеспечено общение экземпляров t1, которые располагаются на различных физических компьютерных узлах
-Сеть t1, распределенная по нескольким вычислительным узлам, должна быть изолирована от других сетей пользователей

Обычно вычислительные узлы подключены к сети одним кабелем. Нам хотелось бы, чтобы несколько пользователей совместно использовали этот канал, не видя трафик друг друга.

Существует технология, которая удовлетворяет этому требованию — тэгирование Vlan (802.1q). Технически каждый фрейм Ethernet дополняется 12-разрядным полем под названием VID (Vlan ID), которое имеет номер vlan. Фреймы, имеющие одинаковый тэг Vlan, принадлежат одному домену трансляции L2; таким образом, устройства с трафиком, помеченным одинаковым Vlan ID, могут сообщаться.

Поэтому ясно, что можно изолировать сети пользователей, помечая их различными идентификаторами Vlan ID.
Как это работает на практике? Взглянем на диаграммы выше.

Трафик для пользователя “t1” покидает вычислительный узел по интерфейсу “vlan102″. Vlan102 представляет собой виртуальный интерфейс, подключенный к eth0. Его единственным назначением является тегирование фреймов номером “102″ с помощью протокола 802.1q.

Трафик для пользователя “t2”покидает вычислительный узел по интерфейсу “vlan103″, который помечен тэгом 103. Так как у потоком разные теги vlan, трафик “t1′s” никак не пересекается с трафиком “t2’.

Они не имеют представления друг о друге, хотя они оба используют один и тот же физический интерфейс eth0, а затем порты и магистраль коммутатора.

Затем нам надо сказать коммутатору, что тегированный трафик нужно передавать по его портам. Это достигается путем перевода данного порта коммутатора в режим транка (в противоположность режиму “доступа” по умолчанию). Если кратко, транк позволяет коммутатору передавать фреймы, тегированные VLAN; дополнительную информацию о транках vlan можно получить в этой статье(802.1q). В это время настройку коммутатора выполняет системный администратор. Openstack не выполняет эту настройку самостоятельно. Не все коммутаторы поддерживают транкирование vlan. Это необходимо проверить заранее перед приобретением коммутатора.

Кроме того, если вы используете devstack+ virtualboxдля экспериментов с VlanManager в виртуальной среде, убедитесь, что вы выбрали “PCNET – Fast III” в качестве адаптера для подключения к своей сети VLAN.

Сделав это, мы приходим к следующей модели коммуникации:

Толстая черная линия от вычислительных узлов к коммутатору представляет собой физический канал (кабель). Поверх одного и того же кабеля переносится трафик vlan с тегами 102 и 103 (красная и зеленая пунктирные линии). Трафик не смешивается (две линии никогда не пересекаются).

Как же выглядит трафик, когда пользователь “t1” хочет отправить пакет с 10.0.2.2 на 10.0.2.5?
-Пакет проходит с 10.0.2.2 на мост br102 и наверх до vlan102, где ему назначается тег 102.
-Трафик проходит за коммутатор, который обрабатывает теги vlan. Как только он достигает второго вычислительного узла, изучается его тег vlan.
-Основываясь на результатах изучения, вычислительный узел принимает решение отправить его на интерфейс vlan102.
-Vlan102 убирает поле Vlan ID с пакета таким образом, чтобы пакет мог достигнуть экземпляров (экземпляры не имеют тегированного интерфейса).
-Затем он проходит через br102 и достигает адреса 10.0.2.5.

Настройка VlanManager

Чтобы настроить сетевые параметры VlanManager в OpenStack, поместите следующие строки в файл nova.conf:
#We point OpenStack to use VlanManager here:
network_manager=nova.network.manager.VlanManager

#Interface on which virtual vlan interfaces will be created:
vlan_interface=eth0

#The first tag number for private vlans
#(in this case, vlan numbers lower than 100 can serve our
#internal purposes and will not be consumed by tenants):
vlan_start=100

Вывод

В любом случае VlanManager представляет собой наиболее утонченную модель сетевого взаимодействия, которая предлагается в OpenStack на данный момент. Предоставляется масштабируемость L2 и изоляция трафика разных пользователей.
Тем не менее, у этого менеджера есть свои ограничения. Например, для каждой сети пользователя она присваивает ip пулы (уровень L3) сетям vlan (уровень L2) (помните? Сеть каждого пользователя определяется парой пул ip + vlan). Таким образом, невозможно сделать так, чтобы два разных пользователя использовали одинаковую схему адресации по IP независимо в разных доменах L2.
Кроме того, длина поля тега vlan составляет только 12 бит, что позволяет создать максимум 4096 vlan. Это значит, что у вас может быть не более 4096 потенциальных пользователей, не так уж много в масштабе облака.
Эти ограничения ещё будут обойдены возникающими решениями, как например Quantum, новый сетевой менеджер для платформы OpenStack и программно-определяемой организации сети.

В следующей статье этой серии я приведу объяснение, как работают плавающие ip-адреса.

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