Масштабируемые Сети В Openstack. Часть 2: Вланменеджер

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



арендатор_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-адрес из выделенного пула.

Он также размещается в выделенной виртуальной сети виртуальной сети, которая автоматически создается и поддерживается платформой OpenStack. Итак, если мы создали две разные сети для двух пользователей, ситуация выглядит так: арендатор_1:



арендатор2:



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

-Создает интерфейс виртуальной локальной сети поверх физического сетевого интерфейса eth0 вычислительного узла.

-Запускает и настраивает процесс dnsmasq, соответствующий мосту, чтобы экземпляр пользователя мог загружаться с него.

Предположим, что пользователь по имени «t1» создает свой собственный экземпляр t1_vm_1 .

Он попадает на один из вычислительных узлов.

Вот как выглядит схема сети:



Мы видим, что создан выделенный мост «br102» с интерфейсом vlan под названием «vlan102».

Кроме того, был создан процесс dnsmasq, который прослушивает адрес 10.0.2.1. Когда экземпляр t1_vm_1 загружается, он получает свой адрес от процесса dnsmasq на основе статической аренды (подробнее о том, как dnsmasq управляется платформой OpenStack, см.

предыдущая статья ).

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



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

Кроме того, они получают конфигурацию DHCP с одного сервера DNSmasq. Теперь представим, что пользователь «t2» создает свой первый экземпляр .

Он также оказывается на том же вычислительном узле, что и пользователь «t1».

Кроме того, для его сети настроен выделенный мост, интерфейс vlan и процесс dnsmasq:



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

В этой ситуации нет ничего странного — OpenStack автоматически всеми ими управляет. В отличие от использования менеджеров в плоском режиме, здесь оба экземпляра пользователя расположены на разных мостах, не связанных друг с другом.

Скорее всего, вы будете использовать несколько вычислительных узлов.

Обычно мы стремимся к максимальному количеству вычислительных узлов.

Тогда, скорее всего, пользователь «t1» будет распределен между несколькими вычислительными узлами.

Это означает, что выделенная сеть также должна быть распределена по нескольким вычислительным узлам.

Однако он должен удовлетворять двум требованиям: - Должна быть обеспечена связь экземпляров t1, расположенных на разных физических компьютерных узлах.

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

Обычно вычислительные узлы подключаются к сети одним кабелем.

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

Есть технология, удовлетворяющая этому требованию - Маркировка Vlan (802.1q).

Технически каждый кадр Ethernet сопровождается 12-битным полем под названием VID (идентификатор Vlan), в котором указан номер виртуальной локальной сети.

Кадры с одинаковым тегом Vlan принадлежат одному и тому же домену трансляции L2; таким образом, устройства с трафиком, помеченным одним и тем же идентификатором Vlan, могут обмениваться данными.

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

Трафик пользователя «t1» покидает вычислительный узел через интерфейс «vlan102».

Vlan102 — это виртуальный интерфейс, подключенный к eth0. Его единственная цель — пометить кадры номером «102» с использованием протокола 802.1q. Трафик пользователя «t2» покидает вычислительный узел через интерфейс «vlan103», который отмечен тегом 103. Поскольку потоки имеют разные теги vlan, трафик «t1’s» никак не пересекается с трафиком «t2’».

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

Затем нам нужно указать коммутатору пересылать тегированный трафик на его порты.

Это достигается путем перевода данного порта коммутатора в магистральный режим (в отличие от режима «доступа» по умолчанию).

Короче говоря, магистраль позволяет коммутатору передавать кадры с тегами VLAN; Более подробную информацию о транках VLAN можно найти в Эта статья (802.1q).

В это время Коммутатор настраивается системным администратором .

Openstack сам не выполняет эту настройку.

Не все коммутаторы поддерживают транкинг VLAN. Это необходимо проверить заранее перед покупкой переключателя.

Кроме того, если вы используете стек разработчиков + виртуальный бокс Чтобы поэкспериментировать с 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 из пакета, чтобы пакет мог достигать экземпляров (экземпляры не имеют тегированного интерфейса).

Однако этот менеджер имеет свои ограничения.

Например, для каждой пользовательской сети он назначает пулы ip (уровень L3) сетям vlan (уровень L2) (помните? Сеть каждого пользователя определяется парой ip пул + vlan).

Таким образом, невозможно, чтобы два разных пользователя использовали одну и ту же схему IP-адресации независимо в разных доменах L2. Кроме того, длина поля тега виртуальной локальной сети составляет всего 12 бит, что позволяет создать максимум 4096 виртуальных локальных сетей.

Это означает, что у вас может быть максимум 4096 потенциальных пользователей, что не так уж и много в масштабе облака.

Эти ограничения по-прежнему будут преодолеваться новыми решениями, такими как Квантовый , новый сетевой менеджер для платформы OpenStack и программно-определяемая сеть .

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