Openvswitch настройка сети в kvm
Эра облачных вычислений постепенно вошла в нашу жизнь, принеся с собой множество плюсов для системных администраторов, которые теперь могут управлять целыми сетевыми фермами серверов, не вставая с удобного кресла. Однако там, где есть виртуальные машины, должна быть и виртуальная сеть, их связывающая. Небольшую виртуальную сеть создать просто, а вот когда речь заходит о десятках и сотнях виртуальных машин, без качественного виртуального коммутатора не обойтись.
Приступаем к настройке
Напоминаю, что в одной из предыдущих статей мы рассматривали построение виртуализации на базе Ubuntu/Debian и KVM. Поэтому исходить будем из того, что система установлена и настроена, есть два физических интерфейса, один подключен к виртуальному мосту и есть виртуальные машины, которые им пользуются. Второй интерфейс не сконфигурирован.
Теперь вернемся к нашим VLAN’ам. Чтобы наша идея работала, нам нужно подключить первый физический интерфейс нашей машины к trunk-порту коммутатора, но при этом заблаговременно разделить (а точнее, протегировать) трафик виртуалок по разным VLAN’ам.
Самый простой и примитивный вариант это сделать — создавать виртуальные сетевые карты, каждую настраивать на определенный VLAN и для каждой виртуальной карты поднять отдельный виртуальный сетевой мост, через который и подключать нужную виртуальную машину. Способ рабочий, правда есть несколько недостатков:
- Очень некрасивый вывод ifconfig.
- Нет возможности на лету добавить или удалить VLAN. Иначе говоря, для каждого нового VLAN’а нужно добавлять виртуальный интерфейс. Подключать его в VLAN, включать в мост. Останавливать виртуальную машину и подключать сеть через этот мост.
- Занимает много времени.
Но если у нас виртуальные машины, почему бы не воспользоваться виртуальным коммутатором второго уровня, в который и воткнуть все виртуальные проводки? Это решение гораздо лучше, позволяет более гибко настроить систему. Ну и использовать такой коммутатор, как самый обычный!
Гугление привело к трем наиболее популярным решениям. Одно входит в состав Hyper-V, который платный и не умеет OpenFlow. Второе: MikroTik, с помощью которого можно не только создать виртуальный коммутатор, но и перенести его конфигурацию на железный. Отпугивает только, что он базируется на полноценной операционной системе — RouterOS. А это уже совсем не то. И наконец, встречай — Open vSwitch.
Александр «Plus» Рак
Участник сообщества OmskLUG. Заместитель начальника отдела сопровождения информационных систем ГКУ «Ресурсы Ямала».
Интерес пользователей к виртуализации в последнее время стал пропадать. С одной стороны, есть понятные десктопные решения под любую ось. С другой — стоимость VDS не так уж и высока, а сервер доступен всем, можно демонстрировать разработки с любой точки. Но если с Linux все более-менее ясно и выбор есть, то Windows-хостинги предлагают далеко не все, их стоимость высока (примерно в два раза дороже) и брать их, когда такая система нужна редко, не имеет смысла. Вот здесь нас может выручить знание KVM.
Настройка групп адресов KVM
Как же теперь подключить к этому коммутатору еще и виртуальные машины? Есть два стандартных пути. Первый нам уже знаком — добавляем порт в коммутатор командой ovs-vsctl add-port , затем добавляем этот порт в виртуальную машину.
Второй путь более гибкий. Он заключается в создании групп портов KVM для OVS. Каждая группа будет принадлежать к соответствующему VLAN ID. К сожалению, настройка таких групп из Archipel или virt-manager пока недоступна. Поэтому потребуется вручную подготовить XML-файл, описывающий необходимые группы, и после этого с помощью virsh применить его.
Далее запускаем саму сеть:
И делаем запуск автоматическим:
Для удаления ненужных сетей можно воспользоваться Archipel (раздел NETWORK), virt-manager или выполнить команды
Далее переходим к созданию виртуалок через virt-manager или открываем существующую остановленную виртуальную машину.
Подключение виртуальных сетевых машин к порту коммутатора OVS
Что нужно знать о VLAN
VLAN — это виртуальные сети, которые существуют на втором уровне модели OSI и реализуются с помощью коммутаторов второго уровня. Не вдаваясь в подробности, можно сказать, что это группа портов коммутатора, разделенная на логические сегменты сети. Каждый такой сегмент имеет свой маркер (тег PVID). Каждая группа портов VLAN’а знает о своей принадлежности к определенной группе благодаря этим тегам.
Существует два типа портов: access и trunk. В access подключаются конечные сетевые устройства, в trunk подключаются только другие trunk-порты. Если с компьютера пакет попадает на access-порт, то он помечается тегом (PVID), и далее коммутатор отправляет этот пакет только на порты точно с такими же VLAN ID или на trunk-порт. При отправке кадра конечному узлу тег снимается, так что они понятия не имеют о том, что находятся в каком-либо VLAN’е.
Когда пакет попадает на trunk-порт, он передается как есть, тег не снимается. Таким образом, внутри trunk-порта передаются пакеты с несколькими тегами (PVID).
Стоит заметить, что access-порт можно настроить так, чтобы тег на выходе не снимался, тогда для принятия пакета конечный клиент должен знать, в какой VLAN он подключен. Не все сетевые карты и/или ОС поддерживают работу с VLAN по умолчанию. Как правило, это зависит от драйвера сетевой карты.
Заключение
При выполнении настроек OVS понравилась простота, удобство, сразу чувствуется что работаешь с коммутатором, а не просто с мостами))) В общем есть смысл его использовать хотя бы параллельно с классическими мостами в РП.
Перед выше описанной интеграцией по мимо использованных в ней ссылок изучал еще следующие статьи:
This document describes how to use Open vSwitch to allow VMs on two different hosts to communicate over port-based GRE tunnels.
This guide covers the steps required to configure GRE tunneling. The same approach can be used for any of the other tunneling protocols supported by Open vSwitch.
Продвинутые возможности
Как работает контроллер Floodlight
Или вывод на экран списка портов и коммутаторов:
Приложение FlowScale на базе OpenFlow
И заканчивая такими, как управление QoS и пересылка статистики по протоколу NetFlow. Рассмотрим некоторые из них.
- eth0 is connected to the Transport Network. eth0 has an IP address that is used to communicate with Host2 over the Transport Network.
- eth1 is connected to the Management Network. eth1 has an IP address that is used to reach the physical host for management.
- Получить тарболл с официальной страницы Open vSwitch и распаковать его:
- Запустить процесс сборки с помощью вызова стандартных configure и make. В том случае, если ты хочешь установить версию, работающую только в пространстве пользователя (удобно для тестирования возможностей), команды сборки будут иметь следующий вид:
- Обязанности в организации строго разделены. Есть администратор доменной сети (AD), есть администратор других серверов, предоставляющих различные сетевые сервисы организации (DNS-сервер, mail-сервер, веб-сервер, сервер баз данных и другие). Администратор сервера AD хочет, чтобы его виртуальный сервер был в одной сети с клиентами, при этом безопасник настаивает, чтобы сам гипервизор находился в отдельной сети серверов (отдельный широковещательный домен).
- Ты предоставляешь доступ извне к виртуальной машине. Как обеспечить такой доступ и закрыть доступ к любому другому узлу?
- поддержка протоколов NetFlow, sFlow, SPAN и RSPAN;
- поддержка VLAN (IEEE 802.1Q);
- механизм QoS;
- возможность агрегации портов с распределением нагрузки;
- GRE-туннелирование;
- совместимость с программным мостом Linux Bridge (brctl);
- индивидуальные политики для виртуальных машин.
- учет трафика, в том числе проходящего между виртуальными машинами с использованием SPAN/RSPAN, sFlow и Netflow;
- поддержка VLAN (IEEE 802.1q);
- привязка к конкретным физическим интерфейсам и балансировка нагрузки по исходящим MAC-адресам;
- работа на уровне ядра, совместимость с программным мостом Linux Bridge;
- поддерживает OpenFlow для управления логикой коммутации;
- с меньшей производительностью, чем в режиме на уровне ядра, Open vSwitch может работать как обычное приложение.
- name — имя, по которому можно обращаться к VM;
- ram и vcpus — количество памяти и vCPU, выделяемых VM;
- disk — имя диска, формат и драйвер;
- cdrom — виртуальный CD-ROM, здесь указан ISO-образ, с которого будет загружаться система;
- network — сетевое подключение, тип и модель (можно использовать virtio, но бывают проблемы, потом можно сменить);
- os-type и os-variant — тип ОС.
-
Туннелирование по протоколу GRE. Допустим, мы должны создать туннель между двумя удаленными машинами так, чтобы одна из конечных точек туннеля была портом коммутатора. Для этого добавляем дополнительный порт и назначаем ему тип «gre»:
Логика этой команды следующая: мы берем запись br0 таблицы Bridge и изменяем колонку netflow, записывая в нее ссылку (UUID) на пока еще не существующую запись в таблице NetFlow. В следующей строке мы создаем новую запись в таблице NetFlow, адресуемую с помощью ссылки @nf, и прописываем в колонке targets адреса принимающих хостов, а в колонке active-timeout — время тайм-аута передачи в секундах. В любой момент конфигурацию можно изменить, например выставив другой тайм-аут:
Или отменить передачу, очистив колонку netflow:
Экспорт статистики по sFlow настраивается почти таким же образом:
Поток трафика и sFlow
-
Зеркалирование портов. Так, а что если мы хотим, чтобы все пакеты, пришедшие на порт eth0 или eth1, автоматически транслировались на порт eth2? В этом случае команда будет выглядеть еще более запутанно:
Здесь мы сначала присваиваем колонке mirrors записи br0 ссылку на запись в таблице Mirror, описанной в конце. Далее, чтобы мы смогли сослаться из еще не созданной записи на нужные нам порты, мы получаем ссылку на записи этих портов в таблице Port с помощью команды get. В конце создаем запись в таблице Mirror с названием mymirror и заполняем колонки нужными нам данными: select-dst-port — зеркалирование входящего трафика на порты @eth0 и @eth1, select-src-port — зеркалирование исходящего трафика, output-port — куда направлять этот трафик. В любой момент зеркалирование можно отменить:
Онлайновая документация по настройке VLAN
Установка и настройка OVS
На первой и третей ноде кластера были установлены OVS следующей командой:
После установки можно проверить командой
Вывод будет примерно следующий:
Далее необходимо создать мост виртуального коммутатора на который и будем вешать порты, интерфейсы или другие мосты.
Имя моста назовем так чтобы было понятно, что это экземпляр одного виртуального коммутатора.
Далее можем создать тегированный мост для добавления к определенной ВМ.
Тег при этом может быть не привязан к какому-то реальному тегу с физического порта, это только в рамках виртуального коммутатора.
Далее назначаем его ВМ к виртуальной сети, где предварительно создаем xml файл:
К сожалению веб ui Р-управления пока не поддерживает настройки с OVS, но их можно сделать через cli. Для создания и добавления виртуальных сетевых адаптеров к ВМ я воспользовался веб ui, но далее уже через cli подменил привязку этих адаптеров к ovsvl и ovsvl2 вместо Bridged. Главное потом не забыть, что изменения в сетевые настройки оборудования ВМ уже вносить через cli иначе веб ui не зная про OVS вернет Bridged.
Для просмотра существующих сетей используем команду:
Для добавления нашей сети:
Далее необходимо ее запустить/активировать
И прописать в автостарт
Далее необходимо добавить эту сеть к ВМ
Находим необходимые строки с интерфейсами, редактируем их или добавляем свои по аналоги существующих меняя мак адрес и номер порта(слот):
Редактирование осуществляется командами редактора vi
Далее после редактирования необходимо выключить и запустить ВМ для применения текущих настроек:
Для проверки можно ввести команду:
После этого можно приступать к настройкам сети изнутри гостя ВМ или добавить сетевые порты в коммутатор для связи с другим кластером по VXLAN overlay:
где IP адрес это адрес той ноды на которой произведены такие же настройки как показано выше. Прямая связь между этими адресами может быть, как через роутеры, так и через VPN, и из разных подсетей, главное, чтобы между ними был настроен маршрут. Но еще главнее, чтобы интерфейс физического порта на котором назначен это адрес, был настроен MTU больше чем 1500 для пропускания пакетов с большим размером, так как vxlan добавляет свои данные, заголовок в несколько байт, но я не стал заморачиваться считать все байты и просто назначил 2000.
сам мост зависящий от этого интерфейса тоже должен быть с mtu2000, но он может не сразу его наследовать и возможно понадобиться его перезапустить.
На стороне второго кластера выполнить на ноде с адресом 10.43.11.12 как описано выше те же настройки только в vxlan назначить адрес ноды первой настройки в моем случае
Далее также настроить mtu.
Если у вас все правильно настроено то, пойдут пинги и возможно делать подключения по ssh, если предварительно например, изнутри ВМ задать адреса из одной подсети. Если выполнить анализ сети:
Далее можно настроить более удобный вариант настройки сети без мостов через функционал виртуального коммутатора portgroup.
Для этого необходимо создать xml сети со следующим:
Можно создать новую сеть или отредактировать предыдущую с этими параметрами, но в моем случае добавляю еще одну сеть.
Как описано выше, а в ВМ уже следующим образом:
Далее сохранить и перезапустить ВМ как описано выше, а на одном из виртуальных коммутаторов можно добавить транковый порт с определенными тегами от физического порта, то есть предварительно с подключенным на один из физических портов сервера с транковым тегированным трафиком от физического коммутатора.
И можно добавить порт с тегом 120 для ВМ:
На стороне другого виртуального коммутатора на другой ноде другого кластера, где нет транка от физического коммутатора добавить точно также этот порт то есть:
Плюс добавить сеть как описано выше.
Выводы
В этой статье я описал лишь малую толику того, что может Open vSwitch. В реальной ситуации, когда виртуальные окружения работают на целом кластере виртуальных машин, управлять всем этим оркестром с помощью одной лишь команды ovs-vsctl уже не получится, зато можно будет использовать контроллер OpenFlow, но это тема для отдельной статьи. z
Open vSwitch активно используется в коммерческой платформе Xen Cloud.
Как-то понадобилось интегрировать Open vSwitch (OVS) c Р-виртуализацией плюс Р-хранилище(РП), может пригодится и не только с РП.
Текущая версия РП на момент статьи была 7.0.13-31, ядро в этой версии 3.10.0-1062.12.1.rv7.131.10.1, что соответствует версии RedHat 7.7, а версия OVS, который идет в составе репозитория РП была 2.0.0. Список функционала на OVS 2.0.0 можно посмотреть тут. Ключи для РП можно взять тут.
Цель была попробовать настроить VXLAN и виртуальный коммутатор в качестве альтернативы родным к технологии kvm-qemu и libvirt мостам. Если использовать голый OpenSource kvm-qemu, то там с OVS все в порядке, но захотелось это попробовать с РП, где не просто голый kvm-qemu+libvirt, а много патчей к этой связке и есть vstorage.
Open vSwitch и KVM
Сеть в KVM
Настройка сети — самый важный момент при работе с KVM. По умолчанию используется Usermode или default, когда базовая система работает как маршрутизатор между внешней и гостевой сетью. Гостевая ОС может получать доступ к внешним сетевым сервисам, но не видна из сети. IP выбирается автоматически при помощи DHCP из диапазона 192.168.122.0/24 , интерфейс основной ОС всегда имеет IP 192.168.122.1 . Для доступа к сервисам нужно самостоятельно настроить маршрутизацию. После установки libvirtd должен создать ряд NAT-правил iptables .
Правила iptables после установки KVM
Второй вариант — Bridged, когда интерфейс гостевой ОС привязывается к физическому интерфейсу и VM доступна извне без допнастроек. Этот вариант чуть сложнее в настройках, так как из-за перестроек можно потерять SSH-подключение. Поэтому при отсутствии локальной консоли (Java/веб-аплета у провайдера) пользоваться им нужно только после тщательного тестирования, и мы его рассматривать не будем.
В первом варианте удобнее настроить KVM так, чтобы она назначала гостевой системе один и тот же IP-адрес. Это можно сделать прямо в конфигурационном файле /etc/libvirt/qemu/networks/default.xml или вызвав
Далее добавляем параметр host в секции dhcp :
Редактируем сетевые настройки для виртуального хоста
И так для каждого узла. После чего перезапускаем сеть.
Теперь можем указать маршрут к сервису в основной системе:
По умолчанию VNC в хостовой машине слушает только локальный порт. Поэтому при подключении с помощью VNC-клиента нужно обязательно пробрасывать порты.
Изменить эту ситуацию можно несколькими способами: добавив параметр --vnc,listen=0.0.0.0 и при необходимости указав другой порт --vncport 5901 .
Аналогичные настройки есть в сетевых установках хоста.
Чтобы не менять установки для каждой VM, проще изменить это поведение глобально:
Описание сценариев
Ниже показан стандартный классический с мостами вариант настройки кластера из трех нод Р-виртуализация плюс Р-хранилища без OVS.
На схеме опущена и не показана сеть Р-хранилища, она обычно идет отдельным интерфейсом предназначенного только для блочного уровня и в этом тесте не участвует. Ее можно настраивать без мостов, и как вариант ее тоже можно задействовать через OVS. Например настроить на OVS агрегацию для Р-хранилища.
Далее схема с использованием вместе с мостами OVS.
Тут уже может быть одна сеть с OVS и одна с мостом. С OVS можно добавлять порты с разными тегами в portgroup и выводить уже на разные ВМ.
Если вернемся к тестируемому сценарию то, его можно увидеть на следующей картинке:
В моем случае было в рамках одного кластера, но это может быть и между разными кластерами за счет туннелей vxlan. Попытаемся представить себе, что это ноды двух разных кластеров.
Туннель поднят на специально выделенном порту одного из серверов каждого кластера. Через туннель выполняется проброс определенного vlan120 в котором определенное количество ВМ со всего кластера рассчитанное на ширину пропускного канала, где средствами OVS можно определить QoS для трафика каждой ВМ. Локальные ВМ этого узла видны через локальный OVS, а ВМ с других узлов видны через физический коммутатор каждого кластера.
Отказоустойчивость OVS обеспечивается за счет добавления в скрипт службы HA(shaman) команд по перебросу туннеля vxlan на другую ноду с OVS, которая будет выбрана по дефолтному алгоритму drs,round-robin за счет службы shaman от Р-Хранилища.
Отказоустойчивость и балансировку порта сервера можно обеспечить за счет агрегации bonding в режиме LACP(802.3ad) c хэшированием layer2+3 или layer3+4, которую также можно настроить средствами OVS.
Благодаря такому принципу виртуальный коммутатор работает как обычная программа на хосте через его сетевой стек не мешая классическим мостам, но конечно при условии что вы не сконфигурируете одинаковые настройки на обоих инструментах (на мостах и OVS).
У виртуального коммутатора есть своя таблица маков
У каждого созданного мною виртуального коммутатора есть какой-то набор интерфейсов (разрешая влан на каком-то интерфейсе мы добавляем порт в определенный виртуальный коммутатор), а также таблица соответствия mac адресов и портов (ее мы смотрим командой ovs-appctl fdb/show ovsbr0). Ручное назначение мак адресов внутри коммутатора не производилось. Portgoup это группа портов в которой на данный момент есть порт vlan120 к которому подключена ВМ.
Теоретически мы можем представить, что когда в какой-то порт коммутатора прилетает фрейм с VLAN тегом, то решение о дальнейшей отправке фрейма принимается на основании таблицы mac адресов соответствующего виртуального коммутатора. Если получен фрейм с тегом 120, то соответственно приниматься решение о форвардинге данного фрейма будет на основании mac таблицы виртуального коммутатора с тегом 120.
Что касаемо VXLAN то, в этом случае static (Unicast). Самый простой вариант — это статичное указание удаленных интерфейсов по типу vxlan. Все сводится к тому, что в конфигурации VNI(vlan vxlan) надо статически задать адреса всех удаленных интерфейсов vxlan, которые терминируют клиентов в указанном VNI. В таком сценарии vxlan будет указывать в IP заголовке как адреса назначения — адреса указанных вручную vxlan. Естественно, если vxlan-ов будет больше двух, то точек назначения пакета при флуде будет уже как минимум две. Указать в IP заголовке нескольких получателей не получится, поэтому самым простым решением будет репликация VxLAN пакета на исходящем интерфейсе vxlan и отправка их юникастом на удаленные интерфейсы vxlan, указанные в конфигурации. Получив данный пакет, удаленный vxlan его декапсулирует, определяет какому VNI данный пакет относится и далее рассылает его во все порты в данном VNI. Помимо этого, так как мы все в курсе, что mac адреса изучаются коммутаторами на основании поля source mac, то после декапсуляции VxLAN пакета интерфейс vxlan ассоциирует mac адрес, указанный как исходящий в оригинальном ethernet заголовке с тоннелем до интерфейса vxlan, от которого данный пакет получен. Как и было сказано ранее — VxLAN тоннель коммутатор воспринимает как простой транковый порт.
Для работы данного режима необходимо только наличие связности между лупбеками всех интерфейсов vxlan.
Static (Unicast) VxLAN — проста как валенок и безотказна, как автомат Калашникова. Ломаться тут нечему.
здесь все более подробно описано по определению маков и flood&Learn в OVS.
Two Physical Hosts¶
The environment assumes the use of two hosts, named host1 and host2 . Both hosts are hypervisors running Open vSwitch. Each host has two NICs, eth0 and eth1 , which are configured as follows:
Configuration Steps¶
Before you begin, you’ll want to ensure that you know the IP addresses assigned to eth0 on both host1 and host2 , as they will be needed during the configuration.
Perform the following configuration on host1 .
Create an OVS bridge:
You will not add eth0 to the OVS bridge.
Boot vm1 and vm2 on host1 . If the VMs are not automatically attached to OVS, add them to the OVS bridge you just created (the commands below assume tap0 is for vm1 and tap1 is for vm2 ):
Add a port for the GRE tunnel:
Create a mirrored configuration on host2 using the same basic steps:
Create an OVS bridge, but do not add any physical interfaces to the bridge:
Launch vm3 and vm4 on host2 , adding them to the OVS bridge if needed (again, tap0 is assumed to be for vm3 and tap1 is assumed to be for vm4 ):
Create the GRE tunnel on host2 , this time using the IP address for eth0 on host1 when specifying the remote_ip option:
Заключение
Ну вот, собственно, мы имеем Windows, запущенную внутри Linux. Конечно, рассматривать KVM для локальной установки, где сильны позиции у VirtualBox и VMware Workstation, не стоит, но при наличии свободных ресурсов на VDS можно быстро развернуть еще одну машину. Скорость, конечно, будет невелика, но для небольших тестов вполне достаточная.
Two Physical Networks¶
Ethernet network for tunnel traffic between hosts running OVS. Depending on the tunneling protocol being used (this cookbook uses GRE), some configuration of the physical switches may be required (for example, it may be necessary to adjust the MTU). Configuration of the physical switching hardware is outside the scope of this cookbook entry.
Strictly speaking this network is not required, but it is a simple way to give the physical host an IP address for remote access since an IP address cannot be assigned directly to a physical interface that is part of an OVS bridge.
Подключение виртуальных машин
Открываем двойным кликом требуемую виртуальную машину. Переходим по кнопке «Показать виртуальное оборудование». Выбираем NIC.
Настройка сетевого интерфейса ВМ в virt-manager
Далее выбираем «Создать на базе» и указываем нашу созданную сеть ovs-lan . Появляется группа портов. Здесь можно ничего не выбирать. Тогда у нас будет обычный trunk-порт с трафиком для всех VLAN ID и обычный трафик не VLAN. Можно привязать его к одному VLAN и получать только одну сеть. В общем, в зависимости от задачи.
Мы же хотим настроить Kerio, но на определенных VLAN ID. Здесь существует несколько вариантов. Можно создавать несколько сетевых интерфейсов с разными VLAN ID. Или создать trunk-порт и внутри Kerio «нарезать» VLAN. Этот вариант предпочтительнее благодаря возможности более гибко маневрировать, не выключая и не перезагружая саму виртуальную машину для применения настроек.
После того как все успешно настроено, запускаем виртуальную машину и смотрим, что у нас изменилось на нашем коммутаторе:
Видим, что виртуальная машина автоматически подключилась к порту vnet50 .
Переходим к интерфейсу управления Kerio. Идем в раздел «Интерфейсы», далее выбираем наш интерфейс, который подключили к VLAN. Открываем его двойным кликом, выбираем вкладку «Виртуальная ЛВС → Добавить или удалить виртуальные ЛВС» и перечисляем нужные VLAN’ы. После этого жмем ОK, и у нас появляются требуемые виртуальные интерфейсы. Далее настраиваем их, как обычные физические интерфейсы, подключенные напрямую в нужные коммутаторы.
Обзор интерфейсов Kerio с подключенными VLAN ID
Развертывание РП
Краткая инструкция по установке:
команда регистрации ноды к выше описанному пункту 5:
комнда включения HA к пункту 10:
и проверка HA, где вывод должен быть примерно такой:
Установка и запуск
Open vSwitch уже можно найти в репозиториях многих дистрибутивов и портах FreeBSD, так что в большинстве случаев для его установки не понадобится особых усилий. В некоторых дистрибутивах, однако, может потребоваться ручная установка системы из исходных текстов, в особенности если дистр включает в себя устаревшую версию Open vSwitch.
Чтобы установить систему из исходников, необходимо сделать следующее:
Если же предполагается установка модуля ядра, configure следует вызвать с опцией «--with-linux»:
После этого можно загрузить модуль ядра с помощью insmod:
Для корректной работы коммутатора также необходим запуск сервера конфигурации, который будет принимать запросы на изменение настроек коммутатора от утилит управления (он должен работать на всех узлах, участвующих в виртуальной сети):
После этого базу настроек необходимо инициализировать:
Наконец, можно запустить сам коммутатор, а точнее демон, ответственный за его работу:
Setup¶
This guide assumes the environment is configured as described below.
Four Virtual Machines¶
Each host will run two virtual machines (VMs). vm1 and vm2 are running on host1 , while vm3 and vm4 are running on host2 .
Each VM has a single interface that appears as a Linux device (e.g., tap0 ) on the physical host.
For Xen/XenServer, VM interfaces appears as Linux devices with names like vif1.0 . Other Linux systems may present these interfaces as vnet0 , vnet1 , etc.
Troubleshooting¶
If connectivity between VMs on different hosts isn’t working, check the following items:
Виртуализация уже давно стала частью инфраструктуры практически каждого предприятия. Любой администратор использует или хотя бы пробовал сервер виртуализации. Мы уже рассматривали, как развернуть сервер виртуализации, поэтому в сегодняшней статье речь пойдет о другом: об Open vSwitch для объединения физических и виртуальных сетевых узлов и его преимуществах.
Представь, что у тебя есть готовая инфраструктура с гипервизорами и виртуалками внутри. Задача: предоставить определенной группе виртуальных машин IP-адрес в одном широковещательном домене, другой группе — в другом, а самому гипервизору — в третьем. То есть разместить их в различных сетях.
Такая ситуация может возникнуть по разным причинам. Приведу несколько примеров.
Самый простой способ реализовать такую схему — это включить один сетевой интерфейс в одну сеть, другой в другую и настроить мосты соответствующим образом. Нельзя сказать, что такой подход на 100% правильный или неправильный, но он вполне рабочий. И значит, имеет право на жизнь. А как быть тем, у кого всего один сетевой интерфейс? В любом случае наиболее правильный метод, если есть коммутатор второго уровня (L2), — это разделить сеть на логические сегменты. Проще говоря, построить сеть на VLAN’ах.
Testing¶
Pings between any of the VMs should work, regardless of whether the VMs are running on the same host or different hosts.
Using ip route show (or equivalent command), the routing table of the operating system running inside the VM should show no knowledge of the IP subnets used by the hosts, only the IP subnet(s) configured within the VM’s operating system. To help illustrate this point, it may be preferable to use very different IP subnet assignments within the guest VMs than what is used on the hosts.
Плюсы и минусы KVM
Технология предоставляет полную виртуализацию на аппаратном уровне. Поэтому, в отличие от популярных LXC и OpenVZ, KVM может запускать в принципе любую ОС, не только Linux (Windows, FreeBSD. ), и Linux, отличающийся от конфигурации основной системы. Если нужна виртуальная машина, не совпадающая параметрами с основным хостом, то выбора особо нет. Включение в ядро было большим прорывом. Теперь поддержка виртуализации в ОС не требовала установки гипервизора (как Xen) и могла быть реализована в любом дистрибутиве, включая настольный. Из коробки доступен VNC, дающий возможность управлять виртуальным сервером с момента загрузки (то есть когда еще не работает SSH), как будто из локальной консоли. Проект активно сотрудничает с другим подобным решением QEMU, задействованы некоторые утилиты и общий формат файла образа Qcow2.
Минусы, конечно, тоже есть. Куда же без них. Главный — процессор должен иметь аппаратную поддержку виртуализации Intel VT-x или AMD-V. Проверить их наличие можно вручную или при помощи утилит:
Также о поддержке технологий говорят флаги в CPU:
В зависимости от производителя процессора будет загружен свой модуль ядра (kvm-amd.ko либо kvm-intel.ko).
Проверяем поддержку KVM
Другие статьи в выпуске:
Накладные расходы чуть выше, чем при использовании LXC и OpenVZ. Причин тому две.
KVM-контейнер запускает свою копию ядра и окружения, и под них требуется память. LXC и OpenVZ же используют ядро и системные вызовы сервера. Поэтому при одинаковых характеристиках на хостинге у них совершенно разные возможности. При создании KVM-контейнера под него сразу резервируются все ресурсы согласно установкам. Это хорошо видно в htop. Стоит добавить ОЗУ в KVM, как сразу на это значение увеличивается объем занятой памяти. Выйти за лимиты VM не может, они устанавливаются жестко. В этом даже и плюс, можно сразу рассчитать будущую нагрузку на своем сервере, а ресурсы никто не позаимствует.
И VM работают относительно стабильно в плане производительности. В то время как при OpenVZ-виртуализации ресурсы выделяются динамически по мере надобности и каждый виртуальный сервер использует ровно столько ресурсов, сколько ему сейчас нужно. Незанятые ресурсы остаются свободными. Поэтому он и популярен у хостеров, ведь можно всегда напихать чуть больше VM, и именно поэтому виртуальные машины, созданные с запасом, могут работать то быстрее, то медленнее. Иногда оптимизация VM под OpenVZ — настоящая мука: непонятно, почему сервер стал работать по-другому — из-за новых настроек или внешних факторов.
Администрировать KVM сложнее, так как прозрачный доступ к файлам, процессам, консолям и сети контейнеров отсутствует, это приходится настраивать самостоятельно. Перестройка параметров VM в KVM (CPU, RAM, HDD) не очень удобна и требует дополнительных действий, включающих перезагрузку ОС. В том же OpenVZ это можно сделать на лету. Сам проект не предлагает удобных графических инструментов для управления виртуальными машинами, только утилиту virsh, реализующую все необходимые функции. Но, поискав в Сети, можно найти несколько интерфейсов, хотя для индивидуального использования одной или нескольких VM их обычно ставить нет смысла. К тому же много open source проектов, активно развивавшихся во время большого интереса к виртуальным машинам, сегодня стали коммерческими, хотя некоторые по-прежнему предлагают обрезанную free-версию. В репозитории пакетов есть virt-manager, предлагающий графический интерфейс для управления KVM и другими типами VM, поддерживающими virtlib, как установленных локально, так и удаленно через SSH.
В качестве веб-интерфейсов можно порекомендовать старенький, но еще рабочий WebVirtMgr, бесплатный UVMM UCS Core Edition, openQRM Free Community Edition и другие. Кроме того, существуют специальные дистрибутивы вроде Proxmox VE, в котором все необходимые инструменты для создания и управления VM на базе KVM и LXC уже есть (правда, он подходит для bare metal установки, а не на удаленный VDS).
Пример вывода настроек OVS и ВМ
Здесь кусок конфига ВМ, где сетевые интерфейсы по команде:
Железо
Для этого конечно нам понадобится железо. Минимальные требования РП это три сервера в каждом по три диска, можно конечно и два если все SSD, но в моем случае один SSD остальные HDD. Далее сеть не менее 10 гигабит два порта, в моем случае повезло было 20 гигабит два порта и дополнительный порт 5 гигабит для ввода в кластер тегированного трафика для OVS в обход классическим мостам или другими словами параллельное использование классических мостов Р-виртуализации с OVS. В общем в моем случае повезло в наличии был Synergy c 3 лезвиями, корзинами с JBOD дисками и встроенным коммутатором.
Тесты
Еще имеются дополнения для управления OVS через NM, но в этом случае функционал OVS ограничен. Поэтому возможна параллельная работа, либо с отключением NM при необходимости.
Также были успешно проверены живые миграции ВМ с сетями от OVS, если на каждой ноде имеется экземпляр сети вместе с OVS то, проблем с миграцией нет, так же как и в стандартной конфигурации кластера Р-виртуализации с дополнительными сетями для ВМ.
На рисунке выше был запущен ping изнутри ВМ в сторону ВМ из внешней сети и выполнена живая миграция ВМ с одной ноды с установленным OVS на другую ноду с установленным OVS, красным помечена задержка во время этой миграции ВМ. Параметры ВМ были следующие 4 vCPU, 8GB RAM, 64GB disk.
Точно такая же задержка происходит и в классике с мостами, то есть для ВМ ничего не поменялось, а сетевой стек теперь работает через OVS.
По мимо этого производились успешные подключения по ssh с разными ВМ расположенными на разных нодах между туннелем vxlan и с ВМ за физическим коммутатором. Для проверки работы выключали туннель или анализировали пакеты через tcpdump как описано выше. Если не назначить MTU как описано выше то, будут проходить только ping, а через ssh не получится подключится.
Введение
Без качественных управляемых коммутаторов просто невозможно наладить правильную работу крупной сети и добиться оптимальной пропускной способности и взаимодействия между ее элементами. Хороший коммутатор предоставляет такие необходимые возможности, как организация виртуальных сетей (VLAN), QoS, агрегация каналов, зеркалирование трафика и даже функции брандмауэра. Настолько же важную роль коммутаторы играют и в виртуальных сетях, однако до недавнего времени решения, реализующие программные коммутаторы, предлагали только коммерческие организации, которые просили за них немалые деньги. За тот же Cisco Nexus 1000V для систем VMware vSphere приходилось отдавать около тысячи долларов, что пустяк в сравнении с остальными расходами на сетевую инфраструктуру, но, тем не менее, дополнительная трата средств. Вдобавок это привязка к другому коммерческому решению, за которое придется отдать еще больше. Сегодня, когда полностью открытые решения на базе KVM и Xen уже достигли того уровня развития, при котором они могут составить конкуренцию коммерческим продуктам виртуализации, нам нужен такой же открытый коммутатор, не привязанный к коммерческим решениям.
К счастью, такой продукт есть, и носит он имя Open vSwitch. Это многоуровневый коммутатор с открытым исходным кодом, разрабатываемый совместными усилиями Citrix, Red Hat, Canonical, Oracle и других компаний (в команде разработчиков есть даже человек из FreeBSD Foundation). Open vSwitch может работать как на уровне ядра, так и в пространстве пользователя, предлагая следующие возможности:
Коммутатор имеет распределенный дизайн, позволяющий установить компоненты системы на множество физических машин и управлять общей виртуальной сетью, используя протокол OpenFlow, другими словами — используя любой совместимый с этим протоколом интерфейс удаленного управления коммутаторами.
Как работает OpenFlow
Сегодня мы рассмотрим, как установить и начать использовать 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.
Схема, которую будем реализовывать
Другие статьи в выпуске:
Напоминаю: исходим из того, что сервер виртуализации уже установлен и настроен. Также установлен пакет bridge-utils и настроен сетевой мост br0. В системе присутствуют некоторые виртуальные машины, подключенные через этот сетевой мост.
Установка и первоначальная настройка
На самом деле установка Open vSwitch сводится к установке одного пакета:
После установки никаких изменений не происходит, кроме запуска сервиса OVS. Создадим коммутатор:
Посмотрим, что к нему подключено:
Мы видим, что создан коммутатор br1 с подключенным интерфейсом br1 . Если требуется, можно этот порт настроить, например задать ему определенный VLAN или порт как trunk с ограничениями по конкретным VLAN’ам. Далее подключим к нашему коммутатору свободный сетевой интерфейс ОС.
Схема подключения OVS и физического интерфейса
По умолчанию этот порт начинает работать как обычный и транковый порт, пропуская все VLAN’ы. Далее можно сделать этот порт транковым для указанных VLAN ID. Или можно оставить как есть, тогда порт будет пропускать все VLAN ID. У нас структура большая, сеть может каждый день меняться, поэтому оставим как есть.
Следующим шагом обнуляем конфигурацию интерфейса eth0 и отключаем его от TCP/IP-стека операционной системы:
Далее вместо eth0 подключаем к TCP/IP-стеку ОС новый внутренний интерфейс br1 коммутатора br1. Приятная новость: OVS автоматически применяет и сохраняет свою конфигурацию, поэтому ничего особо делать не придется. Интерфейс OVS управляется, как обычный интерфейс операционной системы, а значит, идем в /etc/network/interfaces и делаем необходимые изменения — меняем eth0 на br1 , eth0 пишем как manual:
И все! Никаких дополнительных настроек bridge, как в случае с мостом.
Подключаем наш интерфейс к порту коммутатора, на котором настройки такие: trunk-порт для всех VLAN, для VLAN ID 1 трафик не тегирован. То есть порт пропускает транком все VLAN ID и трафик без VLAN вообще. Запускаем сеть командой ifup br1 , после этого мы в сети. В некоторых случаях это может не сработать из-за правки файла настроек сети. Тогда можно попробовать запустить интерфейс вот так:
Проверяем пингами доступность.
Посмотрим, что изменилось у нас на виртуальном коммутаторе:
Как видим, в коммутатор подключено уже два интерфейса: физический интерфейс коммутатора eth0 и интерфейс операционной системы br1.
Теперь займемся виртуальными машинами.
Установка KVM
Плюсы KVM в том, что она работает из коробки и что процессоры серверов хостеров однозначно поддерживают эту технологию. Поэтому вполне реально при наличии свободных ресурсов подгрузить в VDS еще одну виртуальную машину (или несколько). Конечно, под фактически двойной виртуализацией они будут работать не так быстро, как на железе, но если большая нагрузка не планируется, то этого вполне должно хватить. Более того, у некоторых хостингов есть rescue-инструменты, дающие возможность подмонтировать другую файловую систему (в hetzner это rescue/LARA ), подменить имеющуюся и даже установить свою ОС. При некотором умении можно по тарифам Linux абсолютно легально использовать Windows.
Наша задача — установить под KVM Win и настроить доступ. KVM работает со всеми версиями Win, включая и последние. Но Win капризней к ресурсам, поэтому тариф следует подбирать с учетом минимальных системных требований и накладных расходов на ОС и виртуализацию. На Digital Ocean, например, Win2012R2 при 4 Гбайт ОЗУ сильно тормозит, а если выделить 6+ Гбайт, то уже вполне нормальный отклик. В различных дистрибутивах и даже версиях процесс немного отличается, но в основном это касается названий пакетов. Мы будем использовать Ubuntu 16.06. Ставим пакеты.
Проверяем поддержку KVM.
Если такой ответ получен, значит, все нормально. Список поддерживаемых ОС и их правильное название можно получить при помощи osinfo-query .
Список поддерживаемых ОС и их названия
Конфигурационные файлы libvirt находятся в каталоге /etc/libvirt , журналы, в которых нужно искать ответы на проблемы, размещаются в /var/log/libvirt . В /var/lib/libvirt несколько каталогов: в boot система, если не указан путь, будет искать образ для установки гостевой системы, а в images размещать жесткие диски.
Управление виртуальными машинами из консоли производится при помощи утилиты virsh . Параметров много, их все можно узнать, введя:
Вначале просто стоит пройтись и познакомиться, чтобы понять суть. Список ОС пока пуст:
Проверяем, что сеть настроена. По умолчанию используется default (подробнее дальше по тексту).
Если в ответ получаем, что невозможно подключиться, проверяем права доступа на сокет и каталоги выше (в основном в этом проблема).
И перезагружаем модули:
Далее два варианта. Можно самостоятельно установить операционную систему или взять уже готовый образ с установленной ОС. Первый шаг в общем отличается тем, что нужно подготовить диск, запустить VM и установить ОС стандартным способом. Создадим диск размером 25 Гбайт.
Если в будущем нужно изменить размер диска, то используется команда resize:
Некоторые параметры очевидны, поэтому кратко:
Параметр --vnc имеет смысл только на сервере без GUI, при наличии интерфейса KVM сразу откроет окно через SDL. Также можно подключиться локально при помощи virsh:
Удаленно также можно зайти с использованием любого VNC-клиента, при необходимости используя port forwarding (см. ниже).
Коннектимся к Windows, запущенной под KVM
После установки ОС можно приступать к работе. Второй вариант позволяет использовать уже готовый диск с установленной ОС. Его можно скопировать с готовой системы, сконвертировать при помощи qemu-img convert, которая поддерживает форматы дисков практически всех систем виртуализации. Или взять с сайта проекта Cloudbase.
Запуск почти не отличается от предыдущего, убираем, если не нужен, cdrom и добавляем --import .
В дальнейшем можно управлять поведением VM при помощи virsh start|reboot|shutdown|suspend|resume|destroy|undefine|edit|autostart|info и так далее.
Настройки VM хранятся в отдельных XML-файлах в каталоге /etc/libvirt/qemu , имя соответствует параметру --name . Можно их просмотреть, отредактировать при необходимости, скопировать при помощи virsh. Например, нужно изменить настройки сетевого адаптера.
Скопируем настройки в файл.
Теперь в любом текстовом редакторе правим параметры второй машины, указываем новый виртуальный диск и можем запускать второй экземпляр. Для клонирования есть и другой вариант.
Настройки виртуальной машины
Заключение
Описанная в статье конфигурация позволяет очень гибко и быстро добавлять любое количество сетевых интерфейсов практически любой конфигурации. Таким же образом можно переносить виртуальные серверы в сети клиентов, держа сам гипервизор далеко. Как видишь, настройка не сложнее, чем стандартный сетевой мост, а функциональность намного больше!
А что такое 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). Допустим, нам необходимо сделать так, чтобы каждая виртуальная машина автоматически подключалась к нашему коммутатору во время старта. Нет ничего проще. Для начала создадим два стартовых скрипта для управления виртуальной сетью:
Первый будет автоматически поднимать виртуальный сетевой интерфейс, созданный эмулятором, и подключать его к коммутатору. Второй, соответственно, отключать. Для управления коммутатором здесь используется стандартная утилита ovs-vsctl, подробнее о которой я расскажу ниже, хотя мы могли бы использовать для тех же целей старый добрый brctl (команда «brctl addif $ $1»), и сути это бы не поменяло.
Теперь создадим виртуальный коммутатор. Сделать это можно опять же с помощью brctl:
Или вызовом утилиты ovs-vsctl:
Далее подключаем к свитчу физический сетевой интерфейс:
И запускаем виртуальную машину:
После запуска виртуальная машина автоматически получит собственный виртуальный интерфейс (tap0, tap1, tap2 и так далее), который будет подключен к коммутатору с помощью стартового скрипта. Просмотреть информацию о свитче и подключенных машинах можно с помощью одной из двух следующих команд:
Теперь коммутатор готов к работе и настройке. В случае использования более высокоуровневых средств управления виртуальными машинами, вроде графического virt-manager, процесс будет еще проще. Достаточно выбрать в настройках сети подключение с помощью Linux Bridge и перейти к чтению следующего раздела статьи.
Чтобы использовать Open vSwitch в сочетании с virt-manager, достаточно прописать в настройках сети имя нужного коммутатора
Читайте также: