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

Схема, которую будем реализовывать
Схема, которую будем реализовывать

Напоминаю: исходим из того, что сервер виртуализации уже установлен и настроен. Также установлен пакет 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
Схема подключения OVS и физического интерфейса
Схема подключения OVS и физического интерфейса

По умолчанию этот порт начинает работать как обычный и транковый порт, пропуская все 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.

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

Продолжение статьи доступно только подписчикам

Вариант 1. Оформи подписку на «Хакер», чтобы читать все статьи на сайте

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта, включая эту статью. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Вариант 2. Купи одну статью

Заинтересовала статья, но нет возможности оплатить подписку? Тогда этот вариант для тебя! Обрати внимание: этот способ покупки доступен только для статей, опубликованных более двух месяцев назад.


2 комментария

Подпишитесь на ][, чтобы участвовать в обсуждении

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

Check Also

Tips’n’Tricks из арсенала андроидовода. Самые интересные, полезные и нестандартные трюки с Android

Многие годы мы рассказывали про самые разные способы оптимизировать, модифицировать и твик…