Введение

Без качественных управляемых коммутаторов просто невозможно наладить правильную работу крупной сети и добиться оптимальной пропускной способности и взаимодействия между ее элементами. Хороший коммутатор предоставляет такие необходимые возможности, как организация виртуальных сетей (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 уже можно найти в репозиториях многих дистрибутивов и портах FreeBSD, так что в большинстве случаев для его установки не понадобится особых усилий. В некоторых дистрибутивах, однако, может потребоваться ручная установка системы из исходных текстов, в особенности если дистр включает в себя устаревшую версию Open vSwitch.

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

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

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

2. Запустить процесс сборки с помощью вызова стандартных configure и make. В том случае, если ты хочешь установить версию, работающую только в пространстве пользователя (удобно для тестирования возможностей), команды сборки будут иметь следующий вид:

   $ ./configure
   $ make
   $ sudo make install
   $

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

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

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

   $ insmod datapath/linux/openvswitch.ko

3. Создать базу настроек, которая будет использована для хранения текущей конфигурации коммутатора:

   $ 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

   Демон самостоятельно определит наличие в системе модуля openvswitch и задействует его возможности в работе.

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 ${switch} $1

$ sudo vi /etc/ovs-ifdown
#!/bin/sh

switch='br0'
/sbin/ifconfig $1 0.0.0.0 down
ovs-vsctl del-port ${switch} $1

Первый будет автоматически поднимать виртуальный сетевой интерфейс, созданный эмулятором, и подключать его к коммутатору. Второй, соответственно, отключать. Для управления коммутатором здесь используется стандартная утилита ovs-vsctl, подробнее о которой я расскажу ниже, хотя мы могли бы использовать для тех же целей старый добрый brctl (команда «brctl addif ${switch} $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. Рассмотрим некоторые из них.

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

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

   Здесь следует пояснить небольшой синтаксический изврат утилиты ovs-vsctl. Как видишь, первая часть команды выглядит очень похожей на остальные, тогда как дальше начинается нечто напоминающее указание опций. На самом деле это не изменение опций, а модификация той самой базы данных конфигурации. С помощью команды set здесь происходит выбор таблицы Interface, которая хранит конфигурацию сетевых интерфейсов, закрепленных за портами. Далее происходит выборка записи «gre0», которая хранит конфигурацию нужного нам интерфейса и изменение двух ее колонок: type и options. При этом если в первом случае мы изменяем значение колонки type, указав, что теперь этот сетевой интерфейс будет конечной точкой тунkнеля, то во втором также используем ключ remote_ip, чтобы сообщить, какую именно опцию мы хотим изменить, а именно — адрес удаленной машины. По умолчанию база данных Open vSwitch содержит 13 таблиц, каждая из которых предназначена для изменения того или иного параметра свитча, к примеру QoS или Mirror. Каждая таблица содержит собственный набор колонок, и порой, как ты увидишь из следующего примера, управлять конфигурацией таким способом становится весьма проблематично, хотя при настройке таких простых вещей, как GRE-туннель, все кажется тривиальным.

2. Экспорт статистики по протоколам NetFlow и sFlow. Чтобы заставить коммутатор слать статистику по NetFlow на удаленный хост, потребуется создать дополнительную запись в таблице:

   $ 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 и лишь затем адресовали эту запись. Сама команда ovs-vsctl позволяет использовать и тот и другой варианты, поэтому ты можешь писать команды в той последовательности, какая тебе удобна.


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

3. Зеркалирование портов. Так, а что если мы хотим, чтобы все пакеты, пришедшие на порт 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

4. QoS. Управлением качеством обслуживания в Linux-версии Open vSwitch занимается подсистема Traffic Control, о которой я подробно писал в статье «Каждому по потребностям» (][ #7 2009). Управление в этом случае осуществляется с помощью одной из дисциплин TC. Например, чтобы настроить ширину канала на портах eth0 и eth1, можно использовать дисциплину HTB:

   $ 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
   $

   Здесь нам потребовалось создать одну новую запись в таблице QoS для управления суммарной шириной обоих каналов, а также две новых записи в таблице Queue для управления шириной канала для каждого порта. Если ты знаешь, как работает управление трафиком с помощью Traffic Control, то легко разберешься в этой конфигурации.

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

Выводы

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