Open vswitch что это

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 для разделения виртуалок между VLAN

Виртуализация уже давно стала частью инфраструктуры практически каждого предприятия. Любой администратор использует или хотя бы пробовал сервер виртуализации. Мы уже рассматривали, как развернуть сервер виртуализации, поэтому в сегодняшней статье речь пойдет о другом: об Open vSwitch для объединения физических и виртуальных сетевых узлов и его преимуществах.

Представь, что у тебя есть готовая инфраструктура с гипервизорами и виртуалками внутри. Задача: предоставить определенной группе виртуальных машин IP-адрес в одном широковещательном домене, другой группе — в другом, а самому гипервизору — в третьем. То есть разместить их в различных сетях.

Такая ситуация может возникнуть по разным причинам. Приведу несколько примеров.

1. Обязанности в организации строго разделены. Есть администратор доменной сети (AD), есть администратор других серверов, предоставляющих различные сетевые сервисы организации (DNS-сервер, mail-сервер, веб-сервер, сервер баз данных и другие). Администратор сервера AD хочет, чтобы его виртуальный сервер был в одной сети с клиентами, при этом безопасник настаивает, чтобы сам гипервизор находился в отдельной сети серверов (отдельный широковещательный домен).
2. Ты предоставляешь доступ извне к виртуальной машине. Как обеспечить такой доступ и закрыть доступ к любому другому узлу?

Самый простой способ реализовать такую схему — это включить один сетевой интерфейс в одну сеть, другой в другую и настроить мосты соответствующим образом. Нельзя сказать, что такой подход на 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 и для каждой виртуальной карты поднять отдельный виртуальный сетевой мост, через который и подключать нужную виртуальную машину. Способ рабочий, правда есть несколько недостатков:

1. Очень некрасивый вывод ifconfig.
2. Нет возможности на лету добавить или удалить VLAN. Иначе говоря, для каждого нового VLAN’а нужно добавлять виртуальный интерфейс. Подключать его в VLAN, включать в мост. Останавливать виртуальную машину и подключать сеть через этот мост.
3. Занимает много времени.

Но если у нас виртуальные машины, почему бы не воспользоваться виртуальным коммутатором второго уровня, в который и воткнуть все виртуальные проводки? Это решение гораздо лучше, позволяет более гибко настроить систему. Ну и использовать такой коммутатор, как самый обычный!

Гугление привело к трем наиболее популярным решениям. Одно входит в состав Hyper-V, который платный и не умеет OpenFlow. Второе: MikroTik, с помощью которого можно не только создать виртуальный коммутатор, но и перенести его конфигурацию на железный. Отпугивает только, что он базируется на полноценной операционной системе — RouterOS. А это уже совсем не то. И наконец, встречай — Open vSwitch.

Open vSwitch

Open vSwitch — программный многоуровневый коммутатор с открытым исходным текстом, предназначенный для работы с гипервизорами. Работает в Linux начиная с версии 2.6.15. Основные возможности коммутатора:

• учет трафика, в том числе проходящего между виртуальными машинами с использованием SPAN/RSPAN, sFlow и Netflow;
• поддержка VLAN (IEEE 802.1q);
• привязка к конкретным физическим интерфейсам и балансировка нагрузки по исходящим MAC-адресам;
• работа на уровне ядра, совместимость с программным мостом Linux Bridge;
• поддерживает OpenFlow для управления логикой коммутации;
• с меньшей производительностью, чем в режиме на уровне ядра, Open vSwitch может работать как обычное приложение.

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. Логика подлога

• Содержание выпуска
• Подписка на «Хакер» -60%

Напоминаю: исходим из того, что сервер виртуализации уже установлен и настроен. Также установлен пакет bridge-utils и настроен сетевой мост br0. В системе присутствуют некоторые виртуальные машины, подключенные через этот сетевой мост.

Установка и первоначальная настройка

На самом деле установка Open vSwitch сводится к установке одного пакета:

$ sudo apt-get install openvswitch-switch

После установки никаких изменений не происходит, кроме запуска сервиса OVS. Создадим коммутатор:

$ sudo ovs-vsctl add-br br1

Посмотрим, что к нему подключено:

$ sudo ovs-vsctl show. 0b58d70f-e503-4ed2-833c-e24503f2e45f Bridge "br1" Port "br1" Interface "br1" type: internal ovs_version: "2.5.2"

Мы видим, что создан коммутатор br1 с подключенным интерфейсом br1 . Если требуется, можно этот порт настроить, например задать ему определенный VLAN или порт как trunk с ограничениями по конкретным VLAN’ам. Далее подключим к нашему коммутатору свободный сетевой интерфейс ОС.

$ sudo ovs-vsctl add-port br1 eth0

По умолчанию этот порт начинает работать как обычный и транковый порт, пропуская все VLAN’ы. Далее можно сделать этот порт транковым для указанных VLAN ID. Или можно оставить как есть, тогда порт будет пропускать все VLAN ID. У нас структура большая, сеть может каждый день меняться, поэтому оставим как есть.

Следующим шагом обнуляем конфигурацию интерфейса eth0 и отключаем его от TCP/IP-стека операционной системы:

$ sudo ifconfig eth0 0

Далее вместо eth0 подключаем к TCP/IP-стеку ОС новый внутренний интерфейс br1 коммутатора br1. Приятная новость: OVS автоматически применяет и сохраняет свою конфигурацию, поэтому ничего особо делать не придется. Интерфейс OVS управляется, как обычный интерфейс операционной системы, а значит, идем в /etc/network/interfaces и делаем необходимые изменения — меняем eth0 на br1 , eth0 пишем как manual:

auto eth0 iface eth0 inet manual auto br1 iface br1 inet static address 192.168.*.160 netmask 255.255.255.0 gateway 192.168.*.1 dns-nameservers 192.168.*.2

И все! Никаких дополнительных настроек bridge, как в случае с мостом.

Подключаем наш интерфейс к порту коммутатора, на котором настройки такие: trunk-порт для всех VLAN, для VLAN ID 1 трафик не тегирован. То есть порт пропускает транком все VLAN ID и трафик без VLAN вообще. Запускаем сеть командой ifup br1 , после этого мы в сети. В некоторых случаях это может не сработать из-за правки файла настроек сети. Тогда можно попробовать запустить интерфейс вот так:

$ sudo ifconfig br1 up

Проверяем пингами доступность.

Посмотрим, что изменилось у нас на виртуальном коммутаторе:

$ sudo ovs-vsctl show 0b58d70f-e503-4ed2-833c-e24503f2e45f Bridge "br1" Port "eth0" Interface "eth0" Port "br1" Interface "br1" type: internal ovs_version: "2.5.2"

Как видим, в коммутатор подключено уже два интерфейса: физический интерфейс коммутатора eth0 и интерфейс операционной системы br1.

Теперь займемся виртуальными машинами.

Настройка групп адресов KVM

Как же теперь подключить к этому коммутатору еще и виртуальные машины? Есть два стандартных пути. Первый нам уже знаком — добавляем порт в коммутатор командой ovs-vsctl add-port , затем добавляем этот порт в виртуальную машину.

Второй путь более гибкий. Он заключается в создании групп портов KVM для OVS. Каждая группа будет принадлежать к соответствующему VLAN ID. К сожалению, настройка таких групп из Archipel или virt-manager пока недоступна. Поэтому потребуется вручную подготовить XML-файл, описывающий необходимые группы, и после этого с помощью virsh применить его.

 ovs-lan                                  

$ sudo virsh net-define /path_to/file.xml

Далее запускаем саму сеть:

$ sudo virsh net-start ovs-lan

И делаем запуск автоматическим:

$ sudo virsh net-autostart ovs-lan

Для удаления ненужных сетей можно воспользоваться Archipel (раздел NETWORK), virt-manager или выполнить команды

$ virsh net-destroy ovs-network $ virsh net-autostart --disable ovs-network $ virsh net-undefine ovs-network

Далее переходим к созданию виртуалок через virt-manager или открываем существующую остановленную виртуальную машину.

Подключение виртуальных машин

Открываем двойным кликом требуемую виртуальную машину. Переходим по кнопке «Показать виртуальное оборудование». Выбираем NIC.

Далее выбираем «Создать на базе» и указываем нашу созданную сеть ovs-lan . Появляется группа портов. Здесь можно ничего не выбирать. Тогда у нас будет обычный trunk-порт с трафиком для всех VLAN ID и обычный трафик не VLAN. Можно привязать его к одному VLAN и получать только одну сеть. В общем, в зависимости от задачи.

Мы же хотим настроить Kerio, но на определенных VLAN ID. Здесь существует несколько вариантов. Можно создавать несколько сетевых интерфейсов с разными VLAN ID. Или создать trunk-порт и внутри Kerio «нарезать» VLAN. Этот вариант предпочтительнее благодаря возможности более гибко маневрировать, не выключая и не перезагружая саму виртуальную машину для применения настроек.

После того как все успешно настроено, запускаем виртуальную машину и смотрим, что у нас изменилось на нашем коммутаторе:

d3ff1e72-0828-4e38-b5bf-3f5f02d04c70 Bridge "br1" Port "eth0" Interface "eth0" Port "br1" Interface "br1" type: internal Port "vnet5" trunks: [10, 20, 30, 40, 50, 60, 70, 80, 90] Interface "vnet5"

Видим, что виртуальная машина автоматически подключилась к порту vnet50 .

Переходим к интерфейсу управления Kerio. Идем в раздел «Интерфейсы», далее выбираем наш интерфейс, который подключили к VLAN. Открываем его двойным кликом, выбираем вкладку «Виртуальная ЛВС → Добавить или удалить виртуальные ЛВС» и перечисляем нужные VLAN’ы. После этого жмем ОK, и у нас появляются требуемые виртуальные интерфейсы. Далее настраиваем их, как обычные физические интерфейсы, подключенные напрямую в нужные коммутаторы.

Заключение

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

Александр «Plus» Рак

Участник сообщества OmskLUG. Заместитель начальника отдела сопровождения информационных систем ГКУ «Ресурсы Ямала».

Виртуальный коммутатор Open vSwitch: обзор возможностей

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

INFO

Введение

Без качественных управляемых коммутаторов просто невозможно наладить правильную работу крупной сети и добиться оптимальной пропускной способности и взаимодействия между ее элементами. Хороший коммутатор предоставляет такие необходимые возможности, как организация виртуальных сетей (VLAN), QoS, агрегация каналов, зеркалирование трафика и даже функции брандмауэра. Настолько же важную роль коммутаторы играют и в виртуальных сетях, однако до недавнего времени решения, реализующие программные коммутаторы, предлагали только коммерческие организации, которые просили за них немалые деньги. За тот же Cisco Nexus 1000V для систем VMware vSphere приходилось отдавать около тысячи долларов, что пустяк в сравнении с остальными расходами на сетевую инфраструктуру, но, тем не менее, дополнительная трата средств. Вдобавок это привязка к другому коммерческому решению, за которое придется отдать еще больше. Сегодня, когда полностью открытые решения на базе KVM и Xen уже достигли того уровня развития, при котором они могут составить конкуренцию коммерческим продуктам виртуализации, нам нужен такой же открытый коммутатор, не привязанный к коммерческим решениям.

К счастью, такой продукт есть, и носит он имя Open vSwitch. Это многоуровневый коммутатор с открытым исходным кодом, разрабатываемый совместными усилиями Citrix, Red Hat, Canonical, Oracle и других компаний (в команде разработчиков есть даже человек из FreeBSD Foundation). Open vSwitch может работать как на уровне ядра, так и в пространстве пользователя, предлагая следующие возможности:

• поддержка протоколов NetFlow, sFlow, SPAN и RSPAN;
• поддержка VLAN (IEEE 802.1Q);
• механизм QoS;
• возможность агрегации портов с распределением нагрузки;
• GRE-туннелирование;
• совместимость с программным мостом Linux Bridge (brctl);
• индивидуальные политики для виртуальных машин.

Коммутатор имеет распределенный дизайн, позволяющий установить компоненты системы на множество физических машин и управлять общей виртуальной сетью, используя протокол OpenFlow, другими словами — используя любой совместимый с этим протоколом интерфейс удаленного управления коммутаторами.

Как работает OpenFlow

Сегодня мы рассмотрим, как установить и начать использовать Open vSwitch на одной физической машине с несколькими виртуальными гостевыми окружениями. Рассказ об установке и настройке крупной сетевой инфраструктуры потребовал бы гораздо более объемной статьи, поэтому нижеследующий текст можно считать неким введением в технологию и точкой, от которой можно оттолкнуться для дальнейшего ее изучения.

Установка и запуск

Open vSwitch уже можно найти в репозиториях многих дистрибутивов и портах FreeBSD, так что в большинстве случаев для его установки не понадобится особых усилий. В некоторых дистрибутивах, однако, может потребоваться ручная установка системы из исходных текстов, в особенности если дистр включает в себя устаревшую версию Open vSwitch.

Чтобы установить систему из исходников, необходимо сделать следующее:

Получить тарболл с официальной страницы Open vSwitch и распаковать его:

$ cd /tmp $ wget http://openvswitch.org/releases/openvswitch-1.4.0.tar.gz $ tar -xzf openvswitch-1.4.0.tar.gz

$ ./configure $ make $ sudo make install $

Если же предполагается установка модуля ядра, configure следует вызвать с опцией «—with-linux»:

$ ./configure --with-linux=/lib/modules/`uname -r`/build

После этого можно загрузить модуль ядра с помощью insmod:

$ insmod datapath/linux/openvswitch.ko

$ sudo mkdir -p /usr/local/etc/openvswitch $ sudo ovsdb-tool create /usr/local/etc/openvswitch/conf.db vswitchd/vswitch.ovsschema

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

$ sudo ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock --remote=db:Open_vSwitch,manager_options --private-key=db:SSL,private_key --certificate=db:SSL,certificate --bootstrap-ca-cert=db:SSL,cacert --pidfile --detach

После этого базу настроек необходимо инициализировать:

$ sudo ovs-vsctl --no-wait init

Наконец, можно запустить сам коммутатор, а точнее демон, ответственный за его работу:

$ sudo ovs-vswitchd --pidfile --detach

Open vSwitch и KVM

А что такое OpenFlow?

OpenFlow — это протокол, разработанный для управления политикой прохождения сетевых пакетов в больших сетях, построенных на основе множества коммутаторов. Суть протокола не просто в том, чтобы управлять свитчами на расстоянии, — можно переложить всю работу по управлению правилами прохождения пакетов на плечи выделенного сервера, выполняющего роль контроллера. Контроллер постоянно обменивается информацией с коммутаторами и строит на основе полученных данных карту сети, после чего берет на себя управление всеми правилами обработки пакетов. Это не только повышает производительность сети за счет того, что со свитчей снимается дополнительная нагрузка, но и позволяет администратору создавать эффективные схемы прохождения пакетов из одной точки и с помощью единого интерфейса. Протокол пока еще очень молодой, но интерес к нему растет рекордными темпами. О поддержке протокола уже заявили такие производители, как Cisco, Juniper, HP, IBM и NEC, разработавшие для своих маршрутизаторов прошивки с поддержкой протокола. Многие программные маршрутизаторы также поддерживают OpenFlow.

Open vSwitch может быть использован для управления сетями виртуальных машин, построенных на основе гипервизора Xen и KVM. Однако в этом разделе мы остановимся на KVM, как на более распространенном, популярном и простом в развертывании средстве виртуализации. KVM, а точнее QEMU, для которого он выступает в качестве базы, умеет связывать виртуальные машины в сеть и обеспечивать доступ к внешним физическим сетевым интерфейсам с помощью нескольких различных методов. Среди этих методов есть как очень простой виртуальный интерфейс tun, позволяющий прокидывать туннель между виртуальным и физическим интерфейсом, так и более сложный внутриядерный механизм Linux Bridge, позволяющий объединить виртуальные машины между собой и внешним миром с помощью программного неуправляемого коммутатора. Open vSwitch, в свою очередь, использует Linux Bridge в качестве базы, превращая его в сложный управляемый свитч. Это значит, что если ты уже имел дело с настройкой виртуальной сети на основе Linux Bridge, то легко разберешься с тем, как работает vSwitch. Фактически все, что понадобится сделать, — это изучить несколько новых команд, предназначенных для управления возможностями коммутатора, тогда как вся остальная виртуальная сетевая инфраструктура останется неизменной.

Open vSwitch и его возможности

В качестве демонстрации приведу пример настройки простейшей сети на основе голого QEMU (то есть без libvirt и прочих надстроек типа virsh). Допустим, нам необходимо сделать так, чтобы каждая виртуальная машина автоматически подключалась к нашему коммутатору во время старта. Нет ничего проще. Для начала создадим два стартовых скрипта для управления виртуальной сетью:

$ sudo vi /etc/ovs-ifup #!/bin/sh switch='br0' /sbin/ifconfig $1 0.0.0.0 up ovs-vsctl add-port $ $1 $ sudo vi /etc/ovs-ifdown #!/bin/sh switch='br0' /sbin/ifconfig $1 0.0.0.0 down ovs-vsctl del-port $ $1

Первый будет автоматически поднимать виртуальный сетевой интерфейс, созданный эмулятором, и подключать его к коммутатору. Второй, соответственно, отключать. Для управления коммутатором здесь используется стандартная утилита ovs-vsctl, подробнее о которой я расскажу ниже, хотя мы могли бы использовать для тех же целей старый добрый brctl (команда «brctl addif $ $1»), и сути это бы не поменяло.

Теперь создадим виртуальный коммутатор. Сделать это можно опять же с помощью brctl:

$ sudo brctl addbr br0

Или вызовом утилиты ovs-vsctl:

$ sudo ovs-vsctl add-br br0

Далее подключаем к свитчу физический сетевой интерфейс:

$ sudo ovs-vsctl add-port br0 eth0

И запускаем виртуальную машину:

$ sudo qemu-kvm -m 512 -net nic,maddr=00:11:22:EE:EE:EE -net tap,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown-drive file=/образ-диска.img,boot=on

После запуска виртуальная машина автоматически получит собственный виртуальный интерфейс (tap0, tap1, tap2 и так далее), который будет подключен к коммутатору с помощью стартового скрипта. Просмотреть информацию о свитче и подключенных машинах можно с помощью одной из двух следующих команд:

$ sudo brctl show $ sudo ovs-vsctl list ports br0

Теперь коммутатор готов к работе и настройке. В случае использования более высокоуровневых средств управления виртуальными машинами, вроде графического virt-manager, процесс будет еще проще. Достаточно выбрать в настройках сети подключение с помощью Linux Bridge и перейти к чтению следующего раздела статьи.

Чтобы использовать Open vSwitch в сочетании с virt-manager, достаточно прописать в настройках сети имя нужного коммутатора

Продвинутые возможности

Теперь, когда сеть настроена, поговорим о том, что может дать Open vSwitch в сравнении со стандартным мостом, встроенным в ядро Linux. Выше я уже писал о возможностях свитча, а также о том, что он поддерживает протокол удаленного управления OpenFlow, а значит, фактически совместим со всеми контроллерами удаленного управления коммутаторами на основе этого протокола. В частности, управление можно осуществлять с помощью открытого OpenFlow-контроллера FloodLight (floodlight.openflowhub.org) и консолей управления на его основе, таких как, например, FlowScale (openflowhub.org/display/FlowScale). Однако в этой статье мы говорим об Open vSwitch, поэтому сконцентрируемся на управлении с помощью стандартных команд, включенных в пакет коммутатора. В предыдущем разделе статьи мы уже вскользь коснулись главного инструмента управления Open vSwitch — утилиты ovs-vsctl. С ее помощью можно изменять любые настройки коммутатора, начиная от самых простых, например добавление и удаление портов и свитчей:

$ sudo ovs-vsctl add-br br0 $ sudo ovs-vsctl add-port br0 eth0 $ sudo ovs-vsctl del-port br0 eth0 $ sudo ovs-vsctl del-br br0

Как работает контроллер Floodlight

Или вывод на экран списка портов и коммутаторов:

$ sudo ovs-vsctl list-ports br0 $ sudo ovs-vsctl list-br

Приложение FlowScale на базе OpenFlow

И заканчивая такими, как управление QoS и пересылка статистики по протоколу NetFlow. Рассмотрим некоторые из них.

Туннелирование по протоколу GRE. Допустим, мы должны создать туннель между двумя удаленными машинами так, чтобы одна из конечных точек туннеля была портом коммутатора. Для этого добавляем дополнительный порт и назначаем ему тип «gre»:

$ sudo ovs-vsctl add-port br0 gre0 -- set Interface gre0 type=gre options:remote_ip=1.2.3.4

$ sudo ovs-vsctl -- set Bridge br0 netflow=@nf -- --id=@nf create NetFlow targets="192.168.0.34:5566" active-timeout=30

Логика этой команды следующая: мы берем запись br0 таблицы Bridge и изменяем колонку netflow, записывая в нее ссылку (UUID) на пока еще не существующую запись в таблице NetFlow. В следующей строке мы создаем новую запись в таблице NetFlow, адресуемую с помощью ссылки @nf, и прописываем в колонке targets адреса принимающих хостов, а в колонке active-timeout — время тайм-аута передачи в секундах. В любой момент конфигурацию можно изменить, например выставив другой тайм-аут:

$ sudo ovs-vsctl set NetFlow br0 active_timeout=60

Или отменить передачу, очистив колонку netflow:

$ sudo ovs-vsctl clear Bridge br0 netflow

Экспорт статистики по sFlow настраивается почти таким же образом:

$ sudo ovs-vsctl -- --id=@s create sFlow agent=eth1 target="10.0.0.1:6343" header=128 sampling=64 polling=10 -- set Bridge br0 sflow=@s



Поток трафика и sFlow

Зеркалирование портов. Так, а что если мы хотим, чтобы все пакеты, пришедшие на порт eth0 или eth1, автоматически транслировались на порт eth2? В этом случае команда будет выглядеть еще более запутанно:

$ sudo ovs-vsctl -- set Bridge br0 mirrors=@m -- --id=@eth0 get Port eth0 -- --id=@eth1 get Port eth1 -- --id=@eth2 get Port eth2 -- --id=@m create Mirror name=mymirror -- select-dst-port=@eth0,@eth1 select-src-port=@eth0,@eth1 output-port=@eth2

Здесь мы сначала присваиваем колонке mirrors записи br0 ссылку на запись в таблице Mirror, описанной в конце. Далее, чтобы мы смогли сослаться из еще не созданной записи на нужные нам порты, мы получаем ссылку на записи этих портов в таблице Port с помощью команды get. В конце создаем запись в таблице Mirror с названием mymirror и заполняем колонки нужными нам данными: select-dst-port — зеркалирование входящего трафика на порты @eth0 и @eth1, select-src-port — зеркалирование исходящего трафика, output-port — куда направлять этот трафик. В любой момент зеркалирование можно отменить:

$ sudo ovs-vsctl remove Bridge br0 mirrors mymirror

$ sudo ovs-vsctl -- set Port eth0 qos=@newqos -- set Port eth1 qos=@newqos -- --id=@newqos create QoS type=linux-htb other-config:max-rate=1000000000 queues=0=@q0,1=@q1 -- --id=@q0 create Queue other-config:min-rate=100000000 other-config:max-rate=100000000 -- --id=@q1 create Queue other-config:min-rate=500000000 $



Онлайновая документация по настройке VLAN

Выводы

В этой статье я описал лишь малую толику того, что может Open vSwitch. В реальной ситуации, когда виртуальные окружения работают на целом кластере виртуальных машин, управлять всем этим оркестром с помощью одной лишь команды ovs-vsctl уже не получится, зато можно будет использовать контроллер OpenFlow, но это тема для отдельной статьи. z

INFO

Open vSwitch активно используется в коммерческой платформе Xen Cloud.

Похожие публикации:
1. Keep case что это
2. Загрузка gpu что это
3. Как запустить jupiter notebook
4. Что такое локальные данные