Proxmox ovs bridge что это
Настройка Open vSwitch в Proxmox
Если вам в Proxmox надо подать в виртуальные машины несколько vlan-ов, то удобней будет использовать Open vSwitch.
Содержание
Подготовка [ править ]
Для начала сделайте бэкап сетевых настроек:
Настройка openvswitch [ править ]
Установите Open vSwitch на каждой ноде кластера:
После чего в GUI ноды удалите старый мост, создать новый в следующем виде:
Здесь «внутреннему» порту дали имя proxmox.
Нажав Apply configuration будет произведен перезапуск сервера (не сети).
После перезапуска всё должно работать.
Смысл происходящего [ править ]
Дальше создаётся мост, в этот мост включены все остальные порты.
Но если мы так и оставим, у нашего сервера не будет IP-адреса и в Proxmox для управления не достучаться. Чтобы достучаться, создаем «внутренний» порт с IP-адресом сервера, включаем его в мост и указываем vlan (access vlan в терминах cisco) на этот порт, если трафик в сети управления Proxmox тегированный.
Пример конфигурации Open vSwitch в Proxmox [ править ]
На всякий случай привожу содержимое файла /etc/network/interfaces, в котором адрес сервера proxmox 172.16.1.2/24 и эта сеть тегирована vlan 123:
Назначаем ВМ и контейнерам их vlan [ править ]
Чтобы сеть в ВМ и контейнерах ходила в своих vlan, надо теперь просто зайти в настройки сети ВМ/контейнера и назначить нужный access vlan. Больше нигде этот vlan в Open vSwitch вводить не надо. Исходящий трафик из порта ВМ/контейнера будет Open vSwitch тегироваться соответствующим vlan, а с входящего тег сниматься (т.е. внутри ВМ ничего с тегами настраивать не надо).
Open vSwitch в кластере Proxmox [ править ]
Чтобы работала миграция, Open vSwitch должен быть развернут на всех узлах кластера.
Open vSwitch
Open vSwitch (openvswitch, OVS) is an alternative to Linux native bridges, bonds, and vlan interfaces. Open vSwitch supports most of the features you would find on a physical switch, providing some advanced features like RSTP support, VXLANs, OpenFlow, and supports multiple vlans on a single bridge. If you need these features, it makes sense to switch to Open vSwitch.
Contents
Installation
Update the package index and then install the Open vSwitch packages by executing:
Configuration
Overview
Open vSwitch and Linux bonding and bridging or vlans MUST NOT be mixed. For instance, do not attempt to add a vlan to an OVS Bond, or add a Linux Bond to an OVSBridge or vice-versa. Open vSwitch is specifically tailored to function within virtualized environments, there is no reason to use the native linux functionality.
Bridges
A bridge is another term for a Switch. It directs traffic to the appropriate interface based on mac address. Open vSwitch bridges should contain raw ethernet devices, along with virtual interfaces such as OVSBonds or OVSIntPorts. These bridges can carry multiple vlans, and be broken out into ‘internal ports’ to be used as vlan interfaces on the host.
It should be noted that it is recommended that the bridge is bound to a trunk port with no untagged vlans; this means that your bridge itself will never have an ip address. If you need to work with untagged traffic coming into the bridge, it is recommended you tag it (assign it to a vlan) on the originating interface before entering the bridge (though you can assign an IP address on the bridge directly for that untagged data, it is not recommended). You can split out your tagged VLANs using virtual interfaces (OVSIntPort) if you need access to those vlans from your local host. Proxmox will assign the guest VMs a tap interface associated with a vlan, so you do NOT need a bridge per vlan (such as classic linux networking requires). You should think of your OVSBridge much like a physical hardware switch.
Remember, if you want to split out vlans with ips for use on the local host, you should use OVSIntPorts, see sections to follow.
NOTE: All interfaces must be listed under ovs_ports that are part of the bridge even if you have a port definition (e.g. OVSIntPort) that cross-references the bridge.
Bonds
Bonds are used to join multiple network interfaces together to act as single unit. Bonds must refer to raw ethernet devices (e.g. eth0, eth1).
When configuring a bond, it is recommended to use LACP (aka 802.3ad) for link aggregation. This requires switch support on the other end. A simple bond using eth0 and eth1 that will be part of the vmbr0 bridge might look like this.
NOTE: The interfaces that are part of a bond do not need to have their own configuration section.
VLANs Host Interfaces
In order for the host (e.g. proxmox host, not VMs themselves!) to utilize a vlan within the bridge, you must create OVSIntPorts. These split out a virtual interface in the specified vlan that you can assign an ip address to (or use DHCP). You need to set ovs_options tag=$VLAN to let OVS know what vlan the interface should be a part of. In the switch world, this is commonly referred to as an RVI (Routed Virtual Interface), or IRB (Integrated Routing and Bridging) interface.
Setting up this vlan port would look like this in /etc/network/interfaces:
Rapid Spanning Tree (RSTP)
Open vSwitch supports the Rapid Spanning Tree Protocol, but is disabled by default. Rapid Spanning Tree is a network protocol used to prevent loops in a bridged Ethernet local area network.
WARNING: The stock PVE 4.4 kernel panics, must use a 4.5 or higher kernel for stability. Also, the Intel i40e driver is known to not work, older generation Intel NICs that use ixgbe are fine, as are Mellanox adapters that use the mlx5 driver.
In order to configure a bridge for RSTP support, you must use an «up» script as the «ovs_options» and «ovs_extras» options do not emit the proper commands. An example would be to add this to your «vmbr0» interface configuration:
It may be wise to also set a «post-up» script that sleeps for 10 or so seconds waiting on RSTP convergence before boot continues.
Other bridge options that may be set are:
You should also consider adding a cost value to all interfaces that are part of a bridge. You can do so in the ethX interface configuration:
Interface options that may be set via ovs_options are:
You can look at the RSTP status for an interface via:
NOTE: Open vSwitch does not currently allow a bond to participate in RSTP.
Note on MTU
If you plan on using a MTU larger than the default of 1500, you need to mark any physical interfaces, bonds, and bridges with a larger MTU by adding an mtu setting to the definition such as mtu 9000 otherwise it will be disallowed.
Odd Note: Some newer Intel Gigabit NICs have a hardware limitation which means the maximum MTU they can support is 8996 (instead of 9000). If your interfaces aren’t coming up and you are trying to use 9000, this is likely the reason and can be difficult to debug. Try setting all your MTUs to 8996 and see if it resolves your issues.
Examples
Example 1: Bridge + Internal Ports + Untagged traffic
The below example shows you how to create a bridge with one physical interface, with 2 vlan interfaces split out, and tagging untagged traffic coming in on eth0 to vlan 1.
This is a complete and working /etc/network/interfaces listing:
Example 2: Bond + Bridge + Internal Ports
The below example shows you a combination of all the above features. 2 NICs are bonded together and added to an OVS Bridge. 2 vlan interfaces are split out in order to provide the host access to vlans with different MTUs.
This is a complete and working /etc/network/interfaces listing:
Example 3: Bond + Bridge + Internal Ports + Untagged traffic + No LACP
The below example shows you a combination of all the above features. 2 NICs are bonded together and added to an OVS Bridge. This example imitates the default proxmox network configuration but using a bond instead of a single NIC and the bond will work without a managed switch which supports LACP.
This is a complete and working /etc/network/interfaces listing:
WARNING: The stock PVE 4.4 kernel panics, must use a 4.5 or higher kernel for stability. Also, the Intel i40e driver is known to not work, older generation Intel NICs that use ixgbe are fine, as are Mellanox adapters that use the mlx5 driver.
This example shows how you can use Rapid Spanning Tree (RSTP) to interconnect your ProxMox nodes inexpensively, and uplinking to your core switches for external traffic, all while maintaining a fully fault-tolerant interconnection scheme. This means VM VM access (or possibly Ceph Ceph) can operate at the speed of the network interfaces directly attached in a star or ring topology. In this example, we are using 10Gbps to interconnect our 3 nodes (direct-attach), and uplink to our core switches at 1Gbps. Spanning Tree configured with the right cost metrics will prevent loops and activate the optimal paths for traffic. Obviously we are using this topology because 10Gbps switch ports are very expensive so this is strictly a cost-savings manoeuvre. You could obviously use 40Gbps ports instead of 10Gbps ports, but the key thing is the interfaces used to interconnect the nodes are higher-speed than the interfaces used to connect to the core switches.
This assumes you are using Open vSwitch 2.5+, older versions did not support Rapid Spanning Tree, but only Spanning Tree which had some issues.
To better explain what we are accomplishing, look at this ascii-art representation below:
This is a complete and working /etc/network/interfaces listing:
On our Juniper core switches, we put in place this configuration:
Multicast
Right now Open vSwitch doesn’t do anything in regards to multicast. Typically where you might tell linux to enable the multicast querier on the bridge, you should instead set up your querier at your router or switch. Please refer to the Multicast_notes wiki for more information.
Using Open vSwitch in Proxmox
Using Open vSwitch isn’t that much different than using normal linux bridges. The main difference is instead of having a bridge per vlan, you have a single bridge containing all your vlans. Then when configuring the network interface for the VM, you would select the bridge (probably the only bridge you have), and you would also enter the VLAN Tag associated with the VLAN you want your VM to be a part of. Now there is zero effort when adding or removing VLANs!
Разделяй и властвуй. Используем Open vSwitch для разделения виртуалок между VLAN
Содержание статьи
Представь, что у тебя есть готовая инфраструктура с гипервизорами и виртуалками внутри. Задача: предоставить определенной группе виртуальных машин IP-адрес в одном широковещательном домене, другой группе — в другом, а самому гипервизору — в третьем. То есть разместить их в различных сетях.
Такая ситуация может возникнуть по разным причинам. Приведу несколько примеров.
Самый простой способ реализовать такую схему — это включить один сетевой интерфейс в одну сеть, другой в другую и настроить мосты соответствующим образом. Нельзя сказать, что такой подход на 100% правильный или неправильный, но он вполне рабочий. И значит, имеет право на жизнь. А как быть тем, у кого всего один сетевой интерфейс? В любом случае наиболее правильный метод, если есть коммутатор второго уровня (L2), — это разделить сеть на логические сегменты. Проще говоря, построить сеть на VLAN’ах.
Что нужно знать о VLAN
VLAN — это виртуальные сети, которые существуют на втором уровне модели OSI и реализуются с помощью коммутаторов второго уровня. Не вдаваясь в подробности, можно сказать, что это группа портов коммутатора, разделенная на логические сегменты сети. Каждый такой сегмент имеет свой маркер (тег PVID). Каждая группа портов VLAN’а знает о своей принадлежности к определенной группе благодаря этим тегам.
Существует два типа портов: access и trunk. В access подключаются конечные сетевые устройства, в trunk подключаются только другие trunk-порты. Если с компьютера пакет попадает на access-порт, то он помечается тегом (PVID), и далее коммутатор отправляет этот пакет только на порты точно с такими же VLAN ID или на trunk-порт. При отправке кадра конечному узлу тег снимается, так что они понятия не имеют о том, что находятся в каком-либо VLAN’е.
Когда пакет попадает на trunk-порт, он передается как есть, тег не снимается. Таким образом, внутри trunk-порта передаются пакеты с несколькими тегами (PVID).
Стоит заметить, что access-порт можно настроить так, чтобы тег на выходе не снимался, тогда для принятия пакета конечный клиент должен знать, в какой VLAN он подключен. Не все сетевые карты и/или ОС поддерживают работу с VLAN по умолчанию. Как правило, это зависит от драйвера сетевой карты.
Приступаем к настройке
Напоминаю, что в одной из предыдущих статей мы рассматривали построение виртуализации на базе Ubuntu/Debian и KVM. Поэтому исходить будем из того, что система установлена и настроена, есть два физических интерфейса, один подключен к виртуальному мосту и есть виртуальные машины, которые им пользуются. Второй интерфейс не сконфигурирован.
Теперь вернемся к нашим VLAN’ам. Чтобы наша идея работала, нам нужно подключить первый физический интерфейс нашей машины к trunk-порту коммутатора, но при этом заблаговременно разделить (а точнее, протегировать) трафик виртуалок по разным VLAN’ам.
Самый простой и примитивный вариант это сделать — создавать виртуальные сетевые карты, каждую настраивать на определенный VLAN и для каждой виртуальной карты поднять отдельный виртуальный сетевой мост, через который и подключать нужную виртуальную машину. Способ рабочий, правда есть несколько недостатков:
Но если у нас виртуальные машины, почему бы не воспользоваться виртуальным коммутатором второго уровня, в который и воткнуть все виртуальные проводки? Это решение гораздо лучше, позволяет более гибко настроить систему. Ну и использовать такой коммутатор, как самый обычный!
Гугление привело к трем наиболее популярным решениям. Одно входит в состав Hyper-V, который платный и не умеет OpenFlow. Второе: MikroTik, с помощью которого можно не только создать виртуальный коммутатор, но и перенести его конфигурацию на железный. Отпугивает только, что он базируется на полноценной операционной системе — RouterOS. А это уже совсем не то. И наконец, встречай — Open vSwitch.
Open vSwitch
Open vSwitch — программный многоуровневый коммутатор с открытым исходным текстом, предназначенный для работы с гипервизорами. Работает в Linux начиная с версии 2.6.15. Основные возможности коммутатора:
Open vSwitch используется в составе Xen Server, Xen Cloud Platform, KVM, VirtualBox, QEMU, ProxMox (начиная с 2.3).
В качестве наглядного примера будем виртуализировать сервер Kerio 9.1.4. Итак, чтобы понимать, как сейчас все устроено до переделки. Железный сервер Kerio — второй сервер виртуализации, в котором работает несколько сетевых сервисов организации: клиентские сети net1, net2, net3 и net4, серверная сеть net5. Каждый сегмент сети подключен в отдельный сетевой интерфейс «железного» Kerio.
Схема, которую будем реализовывать
Xakep #222. Логика подлога
Напоминаю: исходим из того, что сервер виртуализации уже установлен и настроен. Также установлен пакет bridge-utils и настроен сетевой мост br0. В системе присутствуют некоторые виртуальные машины, подключенные через этот сетевой мост.
Установка и первоначальная настройка
На самом деле установка Open vSwitch сводится к установке одного пакета:
После установки никаких изменений не происходит, кроме запуска сервиса OVS. Создадим коммутатор:
Посмотрим, что к нему подключено:
Схема подключения OVS и физического интерфейса
По умолчанию этот порт начинает работать как обычный и транковый порт, пропуская все VLAN’ы. Далее можно сделать этот порт транковым для указанных VLAN ID. Или можно оставить как есть, тогда порт будет пропускать все VLAN ID. У нас структура большая, сеть может каждый день меняться, поэтому оставим как есть.
Следующим шагом обнуляем конфигурацию интерфейса eth0 и отключаем его от TCP/IP-стека операционной системы:
И все! Никаких дополнительных настроек bridge, как в случае с мостом.
Проверяем пингами доступность.
Посмотрим, что изменилось у нас на виртуальном коммутаторе:
Как видим, в коммутатор подключено уже два интерфейса: физический интерфейс коммутатора eth0 и интерфейс операционной системы br1.
Теперь займемся виртуальными машинами.
Настройка групп адресов KVM
Второй путь более гибкий. Он заключается в создании групп портов KVM для OVS. Каждая группа будет принадлежать к соответствующему VLAN ID. К сожалению, настройка таких групп из Archipel или virt-manager пока недоступна. Поэтому потребуется вручную подготовить XML-файл, описывающий необходимые группы, и после этого с помощью virsh применить его.
Далее запускаем саму сеть:
И делаем запуск автоматическим:
Для удаления ненужных сетей можно воспользоваться Archipel (раздел NETWORK), virt-manager или выполнить команды
Далее переходим к созданию виртуалок через virt-manager или открываем существующую остановленную виртуальную машину.
Подключение виртуальных сетевых машин к порту коммутатора OVS
Подключение виртуальных машин
Открываем двойным кликом требуемую виртуальную машину. Переходим по кнопке «Показать виртуальное оборудование». Выбираем NIC.
Настройка сетевого интерфейса ВМ в virt-manager
Мы же хотим настроить Kerio, но на определенных VLAN ID. Здесь существует несколько вариантов. Можно создавать несколько сетевых интерфейсов с разными VLAN ID. Или создать trunk-порт и внутри Kerio «нарезать» VLAN. Этот вариант предпочтительнее благодаря возможности более гибко маневрировать, не выключая и не перезагружая саму виртуальную машину для применения настроек.
После того как все успешно настроено, запускаем виртуальную машину и смотрим, что у нас изменилось на нашем коммутаторе:
Переходим к интерфейсу управления Kerio. Идем в раздел «Интерфейсы», далее выбираем наш интерфейс, который подключили к VLAN. Открываем его двойным кликом, выбираем вкладку «Виртуальная ЛВС → Добавить или удалить виртуальные ЛВС» и перечисляем нужные VLAN’ы. После этого жмем ОK, и у нас появляются требуемые виртуальные интерфейсы. Далее настраиваем их, как обычные физические интерфейсы, подключенные напрямую в нужные коммутаторы.
Обзор интерфейсов Kerio с подключенными VLAN ID
Заключение
Описанная в статье конфигурация позволяет очень гибко и быстро добавлять любое количество сетевых интерфейсов практически любой конфигурации. Таким же образом можно переносить виртуальные серверы в сети клиентов, держа сам гипервизор далеко. Как видишь, настройка не сложнее, чем стандартный сетевой мост, а функциональность намного больше!
Александр «Plus» Рак
Участник сообщества OmskLUG. Инженер отдела электронного взаимодействия МКУ «Информационно-технического управления».
Инфраструктура для экспериментов разработчиков
У себя в компании я часто сталкиваюсь, что нужно поднять какой-то сервис, чтобы «общупать» его досконально. Хотя PCшники у нас довольно мощные, но большую часть ресурсов съедают PyCharm и Chrome, а на виртуалки с экспериментами очень часто остаётся совсем мало.
Поэтому мы завели у себя небольшую стойку с парой-тройкой серверов для экспериментов и локального Gitlab’а. Но что-то пошло не так и очень захотелось поиграться с чем-то новым.
Disclaimer
Я далеко не журналист, поэтому прошу заранее простить меня за возможные ошибки в тексте. Хотя я и пробежался по тексту, но всё равно мог что-то упустить. Всегда открыт к исправлениям в личном сообщении.
Помимо всего прочего «о вкусах не спорят» и я ничего не рекламирую, а просто хочу поделиться тем, как мы решили нашу задачу. Ну и конечно же всё это можно было сделать иначе, но мне захотелось именно так.
Лирика
Ещё очень огорчало поедание ресурсов просто работающего кластера (фактически 2-3 сервера по 4CPU/16GbRAM чисто под работу пустого кластера) и необходимость держать контроллер отдельно от compute-ноды, чтобы не мешать работе (AIO отъедает в простое 35Гб ОЗУ — это как-то многовато для сервера в офисе).
Конечно можно было бы всё вынести в AWS/DO/Azure/GCE, но если есть 3-4 сервера, то почему бы их не использовать, ведь так или иначе уже имеющееся оборудование выйдет дешевле «облака».
Оборудование
Собственно об железе:
Помимо всего прочего, есть:
Последние 2 сервера были успешно оккупированы после того, как очередной внезапный ночной сбой по питанию привёл Ceph в OpenStack’е в негодность и было принято вынести их на независимые ноды. Впрочем, ничего не мешает их потом перенести в VM.
HITACHI вообще 2 шт, но мы всё вгрузили в одну машину и позже я поясню почему.
Я так подробно расписываю, просто, чтобы было понятно принятое решение.
Муки выбора
Основная проблема с OpenStack была в том, что AIO был слишком прожорливым и конкурировал с виртуалками, а размазывание по хостам… Короче говоря, ванильный OpenStack как бы нам ни нравился, но не подходил под наши нужды и возможности.
Логично было бы предположить, что может стоит перейти на VMWare ESXi (как многие товарищи и предлагали). Но не лежала душа у меня к этому продукту.
Нужно было то, что можно будет хорошо закастомизировать под наши нужды (где-то в пересечении дёшево, производительно и гибко), а так же, чтобы этим было удобно пользоваться простым разработчикам, которые не хотят ничего настраивать, а только делать «фыр-фыр-фыр» кодить и ставить эксперименты.
Выбор пал на Proxmox VE, потому что:
Настройка Proxmox
Публикация далее описывает то, как я настраивал инфраструктуру только сервера с Proxmox практически в живом режиме. Перенос серверов Gitlab’а никак не описывается, потому что к этой теме никак не относится.
Сеть и маршрутизатор
Есть некоторое legacy после OpenStack по нарезке сети, в частности публичная сеть и настройки OSPF на Mikrotik’ах. Хотелось следующего:
Буду описывать как это сделать «с нуля»:
Нельзя сказать, что это прям очень правильное правило, но если кто из знатоков подскажет как правильно его написать, то буду премного благодарен. Вообще нам изоляция нужна только на L2, но на L3 привожу больше для ознакомления.
Настройка сервера
Сервер будет настроен так, чтобы получить максимальную производительность от текущих дисков. Однако мы не забываем, что всё может случиться и ночью свет может резко на час-другой пропасть пока все спят.
Так как мы ничего не хотим покупать, то следует отключить всё, что связано с подпиской:
На этом пока закончим основную настройку.
Магия сетевых интерфейсов
Вообще настройка Proxmox Bridge для работы достаточно простая. Но я не я, если не удалю гланды ректально сделаю что-нибудь экстравагантное. Мне очень хотелось, чтобы работал OVSBridge и на OVSBond. Но проблема в том, что мне так же не хотелось бы, чтобы пользователи каждый раз назначали VLAN при создании VM/LXC. Поэтому порядок настройки следующий для всех 6ти интерфейсов:
Настройка LVM + lvmcache
Добавляем второй раздел к нашему volume group:
Создаём новый раздел как нас учит документация Proxmox + небольшой хак для оптимизации snapshot’ов:
Теперь нам нужно подключить lvmcache, но в целях оптимизации ресурса SSD, я специально выделил раздел на нём размером 241Гб. Этого объёма вполне хватит для кеша, а оставшаяся часть диска будет ресурсом для убитых блоков. Правда это в теории, потому что лично мне до конца не понятно работает ли это. В любом случае, кеш в 465Гб потом будет вдвое дольше и сложнее удалять (например, чтобы заменить диск или расширить массив).
Поначалу всё работало, но потом почему-то перестало. Видимо с обновлением удалили эти модули.
Финальные штрихи
Обычно я перед перезагрузкой делаю, чтобы быть уверенным, что всё обновлено и ядро самое свежее:
К слову, в 6ой версии ядро 5.0, а на подходе (на момент публикации) вроде как 5.3.7.
Всё, теперь отправляем систему в ребут. Если мы всё правильно сделали, то после перезагрузки наш сервер будет доступен извне по обоим адресам. Так же можно будет загрузить свежие шаблоны контейнеров и радоваться жизни.
Делаем красивые графики
Ну мы же не просто админы, а DevOps’ы (что это вообще значит?), поэтому нам нужно знать, когда какая-то из виртуалок взбесится и будет творить непотребства.
Контейнер с InfluxDB и Grafana
Вообще все эти действия проще всего сделать в GUI, но на меня внезапно напала агрессивная форма лени, чтобы делать скриншоты, поэтому опишу командами.
Смотрим доступные нам шаблоны:
Думаю для начала можно загрузить ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz :
Создадим контейнер для InfluxDB и Grafana:
Устанавливаем пакеты InfluxDB и Grafana:
Настраиваем InfluxDB для работы. Нам для этого нужно будет сперва создать базу:
Далее, нам необходимо настроить UDP-порт, на который Proxmox будет слать запросы:
… и теперь перезапустим influx: systemctl restart influxdb
Настройка Proxmox и Dashboard
Тут всё предельно просто. На сервере с proxmox’ом нужно создать файл следующего содержания:
Файла там по умолчанию нет.
По какой-то мне неведомой причине метрики пошли не сразу, поэтому пришлось вызвать systemctl restart pvestatd на сервере проксмокса.
Теперь нам нужно всё это визуализировать. Заходим в нашу grafana по адресу http://172.16.1.101:3000/ (admin:admin), меняем пароль.
Нашёл в дебрях сайта графаны, что можно прикрутить красивый дашборд для визуализации Proxmox, но его пришлось немного подпилить напильником исправить, чтобы учесть все наши реалии.
Теперь нам нужно импортировать Dashboard:
В общем-то всё. Для удобства, я дополнительно туда же подключил Dashboard’ы из Gitlab. Описывать этот процесс нет смысла, надо только иметь в виду, что Prometheus должен быть доступен с этого контейнера, его необходимо подключить как Datastore в Grafana и при экспорте дашбордов указывать, что они external, чтобы выбрать нужный datastore.
Со скриншотами из свежей Grafana косяк вышел, поэтому простите за качество. 