Open vSwitch
Open vSwitch — программный многоуровневый коммутатор с открытым исходным текстом, предназначенный для работы в гипервизорах и на компьютерах с виртуальными машинами. Работает в Linux, начиная с версии 2.6.15 и выше. Основные возможности коммутатора:
- Учёт трафика, в том числе проходящего между виртуальными машинами с использованием SPAN, RSPAN, sFlow и Netflow.
- Поддержка VLAN (IEEE 802.1q)
- Привязка к конкретным физическим интерфейсам и балансировка нагрузки по исходящим mac-адресам.
- Работа на уровне ядра, поддержка существующих возможностей Linux по работе в качестве моста.
- Поддерживает Openflow для управления логикой коммутации.
Помимо режима на уровне ядра, с меньшей производительностью, open vSwitch может так же работать и с правами пользователя (вне ядра).
Основные области применения:
- Замена обычных bridgetools
- Использование в составе Xen Server, Xen Cloud Platform, KVM, VirtualBox, QEMU[1]
Источники
- Официальный сайт проекта
- Обзор в Linux Magazine
- Анатомия облачных систем
- ↑http://openvswitch.org/papers/hotnets2009.pdf
Пожалуйста, воспользуйтесь подсказкой и установите ссылки в соответствии с принятыми рекомендациями.
- Сетевое программное обеспечение
- Управление компьютерной сетью
Wikimedia Foundation . 2010 .
Etcnet/openvswitch
OVS сложная система. Имеет собственную базу данных, где хранит настройки. И не все эти порты и бриджи могут отражаться в системе как сетевые интерфейсы. В связи с чем создавать интерфейс (папку в /etc/net/ifaces) для такого типа порта нет смысла, т.к. etcnet оперирует реальными интерфейсами. Поэтому управлять будем только теми ресурсами которые реально отражаются в системе как сетевые интерфейсы. Это 3 типа интерфейсов: бридж реальный и фейковый (ovsbr), порт типа internal (ovsport) и специальный тип порта — бондинг (ovsbond). Реальный и фейковый бридж по сути имеют один тип ovsbr и отличаются только наличием родительского бриджа и влана. Порт типа не internal это или существующий реальный интерфейс (eth0) или не отраженные в операционной системе интерфейсы (нпример gre, veth). Поэтому я не выделяю их для etcnet. Все это должно настраиваться через OVS_EXTRA.
Бридж
Для создания этого типа в options должно быть:
TYPE=ovsbr
Также как опция может быть указан список сетевых интерфейсов, которые должны быть добавлены в данный бридж. Они будут запущены и добавлены в бридж.
HOST='eth2'
NB! Нельзя сюда писать порты OVS (тип ovsport или ovsbond). Они должны быть описаны отдельно, т.к. для их добавления требуется уже существующий бридж.
В результате будет создан бридж. Проверить можно командой
#ovs-vsctl show
Фейковый бридж
Данный вид бриджа можно использовать в ситуации, когда нет возможности задать влан на порту или когда вы его не знаете. Например подобная ситуация описана в http://blog.scottlowe.org/2012/10/19/vlans-with-open-vswitch-fake-bridges/ . Для создания такого бриджа нужно указывать родительский бридж и влан. Для этого дополнительно к тем переменным что используются для реального бриджа, указываем:
BRIDGE=br0 VID=105
И тогда будет создаваться фейковый бридж
Порт типа internal
Для его создания в options должно быть:
TYPE=ovsport
Бридж в который должен этот порт добавиться:
BRIDGE=br0
В результате получится сетевой интерфейс который может управляться через утилиту ip и др.
Порт бондинг
Специальный тип порта для объединения 2х физических сетевых интерфейса в один. Для его создания в options должно быть
TYPE=ovsbond
Бридж в который должен этот порт добавиться:
BRIDGE=br0
Также должны быть указаны не меньше 2х сетевых интерфейсов, которые должны быть добавлены в данный порт.
HOST='eth1 eth2'
Общие настройки для всех типов
Для задания всех остальных всевозможных настроек, должны использоваться переменные: OVS_REMOVE Если установлено в yes, то при отключении интерфейса, данный порт будет удален из базы данных OVS. Осторожно, т.к. некоторые параметры, например MAC будет сгенерирован заново. OVS_OPTIONS параметры которые должны быть переданы для настройки данного бриджа или порта. Возможные поля для бриджа можно посмотреть командой:
# ovs-vsctl list bridge _uuid : 6aac9201-4272-41cc-a7be-1a36e00f6748 controller : [] datapath_id : "000078e7d17fcf13" datapath_type : "" external_ids : <> fail_mode : [] flood_vlans : [] flow_tables : <> ipfix : [] mirrors : [] name : "ovsbr0" netflow : [] other_config : <> ports : [1de75723-f51e-441b-8d69-e6536d9dcfad, 47988e8e-23bd-494b-bbd0-49b7fa79e23c, 58a10ab2-f344-46f9-a313-104c23ba2a8b] protocols : [] sflow : [] status : <> stp_enable : false
Тогда если мы хотим включить STP, нужно написать:
OVS_OPTIONS='stp_enable=yes'
Для порта можно посмотреть командой:
# ovs-vsctl list port _uuid : 58a10ab2-f344-46f9-a313-104c23ba2a8b bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 external_ids : <> fake_bridge : false interfaces : [987b7dfe-34b4-4d55-b9ae-dedfa05d9779] lacp : [] mac : [] name : "ovsport0" other_config : <> qos : [] statistics : <> status : <> tag : [] trunks : [] vlan_mode : []
Если нужно настраивать дополнительно другие интерфейсы или параметры, то это делать нужно через Database Commands (см. соответствующую секцию в ovs-vsctl(8)) Это все указывается в OVS_EXTRA Например влан, тип и т.д.
OVS_EXTRA='set port eth0 tag=10 -- set port eth1 trunk="1,2,15" '
Данные переменные действуют для всех типов сетевых интерфейсов ovs*.
Примеры
$ cat ens18/options TYPE=eth CONFIG_WIRELESS=no BOOTPROTO=static CONFIG_IPV4=yes $ cat vmbr0/options TYPE=ovsbr CONFIG_WIRELESS=no BOOTPROTO=static CONFIG_IPV4=yes ON_BOOT=yes HOST="ens18" # ovs-vsctl show 6669027e-d2a5-4f23-8d36-bf279d39355c Bridge "vmbr0" Port "vmbr0" Interface "vmbr0" type: internal Port "ens18" Interface "ens18" ovs_version: "2.11.1"
Настройка VLAN (добавляется к предыдущим):
# cat vlan495/options TYPE=ovsport CONFIG_WIRELESS=no BOOTPROTO=static CONFIG_IPV4=yes BRIDGE=vmbr0 VID=495 # cat vlan666/options TYPE=ovsport CONFIG_WIRELESS=no BOOTPROTO=static CONFIG_IPV4=yes BRIDGE=vmbr0 VID=666 # ovs-vsctl show 6669027e-d2a5-4f23-8d36-bf279d39355c Bridge "vmbr0" Port "vmbr0" Interface "vmbr0" type: internal Port "ens18" Interface "ens18" Port "vlan495" tag : 495 Interface "vlan495" type: internal Port "vlan666" tag : 666 Interface "vlan666" type: internal ovs_version: "2.11.1"
Open vSwitch часть №1. Зачем и для чего
Сегодня виртуализация серверов и рабочих станций помогает оптимизировать множество процессов, но она также привносит некоторые специфические проблемы, требующие нового подхода. Одной из таких непростых задач является контроль трафика ВМ, его приоритезация и мониторинг. Так как на одном узле может работать множество ВМ и трафик между виртуальными интерфейсами может не выходить за его рамки, применение классических, аппаратных коммутаторов и фаерволов в данной среде становится неэффективным.По этой причине возникла необходимость в реализации виртуального коммутатора, работающего на каждом из физических узлов и умеющего отслеживать и контролировать трафик ВМ. open vswitch
Какое-то время в средах виртуализации на базе KVM и Xen для решения данной задачи использовался встроенный в ядро Linux коммутатор второго уровня — Linux Bridge (мост, он же разновидность коммутатора)[1]. В принципе, он и сейчас используется по умолчанию в некоторых дистрибутивах как наиболее простое решение. Linux-мост позволяет создавать виртуальные интерфейсы для ВМ, а также коммутировать их между собой и внешним миров через физические интерфейсы узла. Также возможны некоторые методы фильтрации трафика на канальном уровне. Но даже этот скромный функционал едва ли применим в крупных инфраструктурах из-за еще одной особенности виртуализации — высокой мобильности объектов(ВМ). К сожалению Linux-мост не подходит для динамичных сред с большим количеством узлов и миграцией ВМ по причине отсутствия централизованности и взаимодействия между узлами. Связанность состояний и правил, таких как правила маршрутизации, ACL, QoS, мониторинга, закрепленные за сетевым объектом (ВМ) при перемещении на другой физический узел — это основной список требований к коммутатору в виртуальной среде. Здесь нам на помощь и приходит распеределенный, управляемый, многоуровневый виртуальный коммутатор, каковым и является Open vSwitch(далее OVS).
OVS — это свободный аналог коммерческих VMware Distributed vSwitch и Cisco Nexus 1000v, изначально развиваемый компанией Citrix, а теперь уже и многочисленным сообществом, включающим специалистов из Red Hat, Canonical, Oracle и других компаний. Он базируется на некоторых уже имеющихся в ядре компонентах, например, том же Linux Bridge и штатном стеке QoS, плюс собственных разработках, реализующих дополнительный функционал.
С помощью OVS можно создавать VLAN’ы, фильтровать трафик на сетевом уровне, агрегировать каналы, зеркалировать трафик, ограничивать ширину канала для конкретных ВМ.
OVS значительно упрощает администрирование виртуализированных сред, так как вся сетевая конфигурация ВМ и статистика остаются связанными, даже если ВМ мигрирует с одного физического узла на другой. Управление коммутаторами, создание правил и их перемещение на каждом из узлов осуществляется централизованно с помощью протокола OpenFlow.
Поддержка NetFlow[2] и sFlow[3] позволяет мониторить и анализировать состояние сети по множеству аспектов, учитывать трафик ВМ.
Также реализована сетевая база данных состояний (OVSDB), которая поддерживает удаленные триггеры. Поэтому часть программного обеспечения оркестровки может наблюдать различные аспекты сети и сообщать об их изменениях, например, отслеживать миграцию ВМ.
Кроме всего, OVS может работать с логическими тегами так же как и его коммерческие конкуренты. Поддержка логического контекста в сети достигается посредством добавления тегов или управления ими в сетевых пакетах. Это может использоваться, например чтобы однозначно определить ВМ (способ, стойкий к аппаратному спуфингу).
Так же имеется реализация GRE-туннелирования, способная обрабатывать тысячи одновременных GRE-туннелей. Это, например, может использоваться, для объединения частных сетей ВМ в различных центрах обработки данных.
Помогла ли вам статья?
Open vSwitch как ядро виртуальной сети
В данной статье для виртуализации используется KVM/libvirt, но сразу отмечу, статья не столько о KVM, сколько именно об особенностях преимуществах использования для объединения виртуальных и физических сетевых устройств посредством технологии VLAN (802.1q). В былинные времена для проброса тегированного трафика в гипервизор использовались всевозможные костыли и подпорки различной степени неожиданности (tuntap, brctl, vconfig, ebtables и прочее), что приводило к захламлению операционной системы, хостящей гипервизор, большим количеством ненужных виртуальных сетевых интерфейсов, мозолящих глаза в выводе ifconfig и вообще огорчало администраторов необходимостью строить стандартное сетевое устройство (коммутатор) из отдельных частей как какой-то велосипед. Помимо поддержки 802.1q от коммутатора на самом деле сегодня требуется еще много функций. Так необходимость в виртуальном устройстве максимально соответствующем по функционалу стандартному современному управляемому коммутатору привела к появлению проекта (далее — OVS).
Рисунок 1: Проект песочницы
На КДПВ (Рисунок 1) изображен юзкейс OVS для построения песочницы для подготовки к замене наших устаревших VPN-маршрутизаторов на новые. Нужно сконфигурировать новые VPN-маршрутизаторы аналогично уже инсталлированным в нашей компании с теми же IP адресами, правилами фильтрации и настройками динамической маршрутизаци. И протестировать всё в песочнице, эмулирующей ISP (через которые соединяются VPN-маршрутизаторы) и сайты нашей локалки. Но повторюсь, эта статья не о сложностях настройки наших VPN-маршрутизаторов, а о том, как подключить их к нашей уютной виртуальной песочнице посредством VLAN вообще и OVS в частности.
Начнём с самого начала, установив чистую копию ubuntu-14.04.1-server-amd64 с опцией «Virtual Machine host». После установки система имеет следующий вид:
Вывод утилит просмотра сетевых параметров
root@sandbox:~# ifconfig |grep -vE ‘RX|TX|coll|inet6|MTU’
eth0 Link encap:Ethernet HWaddr 00:1b:78:9c:2b:fc inet addr:10.0.7.1 Bcast:10.0.7.255 Mask:255.255.255.0 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 virbr0 Link encap:Ethernet HWaddr 1a:70:19:e9:3c:c7 inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
root@sandbox:~# route -n
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.0.7.254 0.0.0.0 UG 0 0 0 eth0 10.0.7.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
root@sandbox:~# cat /etc/network/interfaces |grep -v ^#
auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.0.7.1 netmask 255.255.255.0 network 10.0.7.0 broadcast 10.0.7.255 gateway 10.0.7.254 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 10.0.1.1
root@sandbox:~# virsh net-list —all
Name State Autostart Persistent ---------------------------------------------------------- default active yes yes
root@sandbox:~# virsh net-dumpxml default
default 865fd53b-5bd5-430c-b7c7-664125dee9f6
root@sandbox:~# brctl show
bridge name bridge id STP enabled interfaces virbr0 8000.000000000000 yes
Всё очень стандартно, ни чего необычного.
На картинке всё еще проще:
Рисунок 2: Начальное состояние системы
Устанавливаем openvswitch:
apt-get install openvswitch-switch
После его установки ни каких изменений в сетевых параметрах не происходит, лишь запускается сервис OVS, ждущий наших распоряжений. Не будем заставлять его ждать. Вводим нижеприведенные команды с консоли или помещаем их во временный .sh скрипт и запускаем:
ovs-vsctl add-br ovs-br0 ovs-vsctl set port ovs-br0 tag=7 ovs-vsctl add-port ovs-br0 eth0 ovs-vsctl set port eth0 trunks=7,10,20,1010,1020,30,1030 ifconfig eth0 0 ifconfig ovs-br0 10.0.7.1/24 up ip r add default via 10.0.7.254
переключаем хост в тегированный порт коммутатора
Пояснения
ovs-vsctl add-br ovs-br0
Создает почти пустой инстанс виртуального коммутатора, есть только один порт к которому и подключен одноименный внутренний интерфейс ovs-br0.
ovs-vsctl set port ovs-br0 tag=7
Конфигурируем этот порт как access-port для VLAN 7.
ovs-vsctl add-port ovs-br0 eth0
Добавляем к нашему коммутатору еще один порт, в который переключаем интерфейс eth0.
ovs-vsctl set port eth0 trunks=7,10,20,1010,1020,30,1030
делаем этот порт транковым для указанных VLAN ID. В принципе, параметр trunks можно вообще не указывать, тогда порт будет пропускать все VLAN ID.
ifconfig eth0 0
Обнуляем конфигурацию IP для eth0. Он больше не будет связан с IP стеком OS.
ifconfig ovs-br0 10.0.7.1/24 up
Вместо eth0 к IP стеку OS прикручиваем внутренний интерфейс ovs-br0.
ip r add default via 10.0.7.254
Ну и не забываем восстановить таблицу маршрутизации
Переключаем хост в тегированный порт коммутатора
Мы в сети! (с)
Смотрим, что же изменилось в сетевых настройках
root@sandbox:~# ovs-vsctl show
40952e4d-81ad-433b-b08b-f88ccd55f26a Bridge "ovs-br0" Port "ovs-br0" tag: 7 Interface "ovs-br0" type: internal Port "eth0" trunks: [7,10,20,1010,1020,30,1030] Interface "eth0" ovs_version: "2.0.2"
root@sandbox:~# ifconfig |grep -vE ‘RX|TX|coll|inet6|MTU’
eth0 Link encap:Ethernet HWaddr 00:1b:78:9c:2b:fc lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 ovs-br0 Link encap:Ethernet HWaddr 00:1b:78:9c:2b:fc inet addr:10.0.7.1 Bcast:10.0.7.255 Mask:255.255.255.0 virbr0 Link encap:Ethernet HWaddr 32:b9:dd:38:09:f5 inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
root@sandbox:~# route -n
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.0.7.254 0.0.0.0 UG 0 0 0 ovs-br0 10.0.7.0 0.0.0.0 255.255.255.0 U 0 0 0 ovs-br0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
Ну и в виде картинки:
Рисунок 3: Установили openvswitch и подключили его к IP стеку OS вместо eth0. Интерфейс коммутатора virbr0 в дальнейшем изображать не будем, он нам не интересен и ни на что не влияет.
Ничего неожиданного, всё логично и интуитивно понятно.
Еще один приятный момент для тех, кто уже начал беспокоиться о том, где же размещать стартовые скрипты применения этой конфигурации. Ничего особо делать и не придется, конфигурация OVS вышеуказанными командами ovs-vsctl не только применяется, но и автоматически сохраняется, так что вам не нужно переживать о несовпадение текущей и сохраненной конфигурации OVS.
А файл /etc/network/interfaces нам надо лишь малость обновить в связи с заменой интерфейса eth0 на ovs-br0:
root@sandbox:~# cat /etc/network/interfaces |grep -v ^#
auto lo iface lo inet loopback auto eth0 iface eth0 inet manual auto ovs-br0 iface ovs-br0 inet static address 10.0.7.1 netmask 255.255.255.0 network 10.0.7.0 broadcast 10.0.7.255 gateway 10.0.7.254 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 10.0.1.1
Но коммутатор в данный момент всего с двумя портами, как же подключить к нему наши 5 виртуальных машин? Тут есть как минимум 2 пути. Первый, наиболее очевидный, состоит в том, чтобы с помощью команды ovs-vsctl add-port добавить порт (access или транковый — на выбор).
ovs-vsctl add-port ovs-br0 vlan10 tag=10 -- set interface vlan10 type=internal
-- (две черточки) используется для выполнения нескольких команд ovs-vsctl в одну строку
Затем можно будет прямо в GUI virt-manager’а выбрать его для подключения сетевого интерфейса виртуальной машины. Но мы пойдем более масштабируемым способом. При этом порты создавать вообще не нужно (как собственно и в стандартном linux core bridge). Вместо этого можно создать порт-группы для OVS. Каждая порт-группа предназначена для подключения VM к соответствующему VLAN. К сожалению, их настройка из GUI virt-manager’а недоступна, необходимо вручную подготовить простенький XML файл, описывающий необходимые порт-группы и затем применить его через API libvirt с помощью команды virsh, как указано ниже:
XML-конфиг для конфигурации, показанной на Рисунке 1
ovs-network
Выполняем эти команды:
vi /tmp/ovs-network.xml virsh net-define /tmp/ovs-network.xml virsh net-start ovs-network virsh net-autostart ovs-network
Пояснения
vi /tmp/ovs-network.xml
копируем в этот файл вышеуказанное содержимое XML
virsh net-define /tmp/ovs-network.xml
конфигурируем новую сеть для KVM
virsh net-start ovs-network
запускаем её
virsh net-autostart ovs-network
делаем её запуск автоматическим
что бы удалить ненужную сеть
virsh net-destroy ovs-network virsh net-autostart --disable ovs-network virsh net-undefine ovs-network
изобразим полученное:
Рисунок4: Создали порт-группы для наших VM
Создадим пару виртуальных машин VM1 и VM2 в virt-manager’е и при создании укажим Advanced options Virtual network ‘ovs-network’: Bridge network
Пока оставим их выключенными
подправим конфиги виртуалок
virsh edit VM1
Найдем секцию interface и добавим параметр portgroup
Сделаеем так же для второй VM
Если посмотреть сейчас состояние сетевых интерфейсов коммутатора и операционной системы, то увидим, что ни каких изменений не произошло. Порты на коммутаторе не добавились, лишних сетевых интерфейсов в системе не появилось.
Теперь запустим обе VM:
и еще раз проверим состояние сетевых параметров хоста
root@sandbox:~# ovs-vsctl show
40952e4d-81ad-433b-b08b-f88ccd55f26a Bridge "ovs-br0" Port "vnet0" tag: 10 Interface "vnet0" Port "ovs-br0" tag: 7 Interface "ovs-br0" type: internal Port "eth0" trunks: [7, 10, 20, 1010, 1020, 30, 1030] Interface "eth0" Port "vnet1" tag: 20 Interface "vnet1" ovs_version: "2.0.2"
root@sandbox:~# ifconfig |grep -vE ‘RX|TX|coll|inet6|MTU’
eth0 Link encap:Ethernet HWaddr 00:1b:78:9c:2b:fc lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 ovs-br0 Link encap:Ethernet HWaddr 00:1b:78:9c:2b:fc inet addr:10.0.7.1 Bcast:10.0.7.255 Mask:255.255.255.0 virbr0 Link encap:Ethernet HWaddr 32:b9:dd:38:09:f5 inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 vnet0 Link encap:Ethernet HWaddr fe:54:00:5e:b9:b2 vnet1 Link encap:Ethernet HWaddr fe:54:00:7f:40:d0
Как видим, в коммутаторе добавились порты соответствующих порт-групп, а в системе добавилось пара интерфейсов с MAC-адресами, соответствующими VM (при выключение VM соответствующие порты и интерфейсы опять исчезнут).
Рисунок 5: запустили пару VM
Еще упомяну, что 802.1q не единственная фича , с его помощью можно организовать, например, бондинг двух интерфейсов и кое-что еще.
Вот, собственно, и всё. Надеюсь, кому-то эта статья поможет решиться использовать в своих проектах и просто песочницах вместо стандартного linux bridge.