Open vSwitch (http://openvswitch.org/) - это виртуальный свитч, котороый позволяет вам строить виртуальную сеть (SDN) поддерживает различные протоколы для мониторнига и управления (NetFlow, sFlow, SPAN, RSPAN, CLI, LACP, 802.1ag и др). Приставка “open” означает что он является opensource продуктом со всеми вытекающими плюсами и минусами.  На просторах интернета найти документацию по нему и руководства по установки не проблема, если вы знаете английский язык. На русском практически ничего нет:(. Далее я расскажу процесс установки его с исходников на Red Hat Enterprise Linux 6.3 (RHEL) и основанной на базе него бесплатной CentOS 6.3 с ядром 2.6.32-279.el6.x86_64. 

В оффициальной документации Open vSwitch по установке на RHEL достаточно подробно написано как это сделать, но я столкнулся с некоторыми проблемами, о которых следует сказать отдельно.

!!! В примере для простоты делаю все операции от root’а, что категорически рекомендуется делать только в образовательных целях.

 

  1. Устанавливаем нужные пакеты для сборки RPM:
    # yum install -y gcc gcc-c++ make rpm-build rpm-devel rpmdevtools git  make python-devel openssl-devel kernel-devel kernel-debug-devel

  2. Клонируем себе исходный код Open vSwitch:
    # git clone git://openvswitch.org/openvswitch openvswitch-1.9.90

  3. Создаем в домашней директории пользователя, от которого будем создавать RPM нужную структуру папок командой:
    # rpmdev-setuptree
  4. Т.к. на помент написания этого поста последняя версия Open vSwitch была 1.9.90, то создаем соответствующий архив:
    # tar pczf ~/rpmbuild/SOURCES/openvswitch-1.9.90.tar.gz ./openvswitch

  5. Далее для сборки необходима более новая версия утилиты autoconf, чем есть в репозитории. Скачиваем и устанавливаем последнюю:
    # wget http://ftp.gnu.org/gnu/autoconf/autoconf-latest.tar.gz
    # ./configure
    # make
    # make install
  6. Переходим в папку с исходниками Open vSwitch и выполняем следующие команды:
    # ./boot.sh
    # ./configure


    Далее можно просто выполнить “make && make install”, но тогда будут проблемы с обновлением/удалением приложения и для следующей установки нужно будет выполнить те же сымые действия.
  7. В папке с Open vSwitch запускаем команду, которая соберет нужную нам rpm:
    # rpmbuild -bb rhel/openvswitch.spec
  8. Аналогичным образом собираем модули для текущей версии ядра:
    # rpmbuild -bb -D "kversion `uname -r`" --target=i686-unknown-linux rhel/openvswitch-kmod-rhel6.spec
  9. Если все прошло успешно (а у меня это было именно так), то устанавливаем полученные rpms:
    # rpm -i kmod-openvswitch-1.9.90-1.el6.x86_64.rpm
    # rpm -i openvswitch-1.9.90-1.x86_64.rpm 

  10. Open vSwitch может заменить собой стандартный модуль bridge и тогда brctl будет работать с Open vSwitch как и с обычными мостами, не подозревая что что-то не так. Для этого отключаем модуль brigde и включаем brcompat, который появился после установки Open vSwitch:
    # rmmod bridge
    # modprode openvswitch
    # modprode brcompat


    Для того, чтобы убедиться, что нужные модели ядра загружены, выполняем команду lsmod.

 

 

Ну и последнее, запускаем  Open vSwitch: 

# service openvswitch restart

… и проверяем, что он работает:

# ovs-vsctl show

 


 

Никогда не знаешь, где упадет OpenStack(c) 
Я, в процессе очередного дебагга.

Те, кто читает мой твиттер (@e0ne), должны знать, что в последнее время я работаю с OpenStack’ом, а именно занимаюсь(конечно, не один я) попытками его запуска на Red Hat Enterprise Linux (RHEL), CentOS, Scientific Linux, etc. Т.к. все это построено на базе полной и непросветной enterpise в виде RHEL, то сборка нового дистрибутива, как правило, у меня начинается со сборки именно под эту ОС. 

Вот я и хочу поделиться своими впечатлениями от сборки последней версии OpenStack’а под RHEL. Началось все с попытки запустить чуть менее чем полностью поломанную версию essex-1. Потом все продолжилось с версией essex-2. Основные моменты, которые мешали мне радоваться жизни - переделки в glance, связанные и security, которые на время поломали работоспособность EC2 API. 

Проект Glance - это услуги по отбору, регистрации и поиску виртуальных «machine images» (VMI). В рамках Glance используется RESTful API, что позволяет делать запрос метаданных VMI и выполнять поиск фактического образа (VMI). (http://openstack.ru/openstack_glance.html)

И тут я решил попробовать запустить все из последней версии исходников, с master’а...

После небольших усилий инстансы (виртуалки) начали запускаться, но были проблемы с сетью. Команда “killall dnsmasq”, подсказанная моим коллегой, решила часть проблем, а именно - выдачу IP адреса виртуальной машине. Далее в логах при загрузке неворуженым глазом были замечены такие проблемы:

 

Что означало, что запущенный инстанс не может получить данный от Metadata Server’а. Т.к. Metadata Server нормально работал в Diablo, то сразу вспомнились 2 вещи:

 

 

Далее по аналогии с Nova API был создан файл /etc/init.d/openstack-nova-api-metadata, который предназначался для запуске сервиса Metadata Server’а. Metadata Server, на первый взгляд, успешно запустился, то я попытался запустить снова инстанс, что мне привело к предыдущей ошибке. Логи Metadata Server’а немного испугали:

 

Мозг сразу начал представлять кошмары, связанные с выводом strace, linux kernel debugger’ом и так далее. Вовремя опомнившись, я полез в Google. Поиск по “exit code 134” ничего полезного не дал. А вот поиск по “iptables-restore buffer overflow” дал нужный результат в виде двух багов iptables: http://bugzilla.netfilter.org/show_bug.cgi?id=641 иhttps://bugzilla.redhat.com/show_bug.cgi?id=545600. Довольно-таки стандартное, на сколько мне известно, переполнение буфера, вызванное функцией strcpy, которую, к слову, не очень-то и рекомендуют использовать. Подробности в этом комментарии: https://bugzilla.redhat.com/show_bug.cgi?id=545600#c6

 

 

Т.к. обновление iptables в RHEL 6.1 - не самая приоритетная для меня задача, то я решил зайти с другой стороны - посмотреть что же делает OpenStack для получения такого результата.

 

 

https://github.com/openstack/nova/blob/master/bin/nova-api-metadata

Metadata Server запускается таким же способом, как и другие REST-сервисы Nova, поэтому проблему нужно было искать где-то дальше. Об этом же говорили и логи, и ошибка, связанная с iptables.

https://github.com/openstack/nova/blob/master/nova/network/linux_net.py

 

Метод metadata_accept() отрабатывает без ошибок и падает все в iptables_manager.apply().

 

Т.к. данный метод используется далеко не в одном месте

 

 

то ошибка где-то в передаваемых параметрах. В качестве параметров к iptables-restore у меня передавалось такое:

 ip-restore-full.jpg

 

 

Зная о баге в iptables и то, что падало все только при запуске Metadata Server’а, то получилось быстро найти нужную команду, которая все ломала:

iptables-restore <<EOF
*nat
:nova-api-metadata-POSTROUTING - [0:0]
-A POSTROUTING -j nova-api-metadata-POSTROUTING
COMMIT
EOF

len(‘nova-api-metadata-POSTROUTING’)==29, что вместе с символом конца строки в языке С давало нам 30 символов и при копировании их в массив из 29 символов давало нам переполнение буффера (см. ссылки на баги выше). Хорошо, проблема найдена, теперь нужно ее устранить. Для этого находим код, где у нас генерируется имя chain’а:

chain1.jpg, chain2.jpg

 

где:

binary_name = os.path.basename(inspect.stack()[-1][1])

Таким образом проблема была в имени исполняемого файла. Переименовав “/usr/bin/nova-api-metadata” в “/usr/bin/nova-metadata ” все заработало. Вопрос лишь в том, насколько долго оно будет работать с таким “фиксом”? 

Более правильное решение нужно делать исправляя код OpenStack’а и/или обновляя iptables. Также интересно как это себя ведет на других RHEL-based дистрибутивах(версия iptables) и ubuntu, но это уже проверю завтра, а пока поставил качаться нужные образы дистрибутивов...

[Update]

Баг с iptables проверен после установки чистой ОС после установки всех апдейтов с помощью команды "yum update" на следующих ОС:

  • RHEL 6.1 x86_64 - iptables v1.4.7, buffer overflow detected
  • RHEL 6.2 x86_64 - iptables v1.4.7, buffer overflow detected
  • CentOS 6.1 x86_64 - iptables v1.4.7 buffer overflow detected
  • CentOS 6.2 x86_64 - iptables v1.4.7 buffer overflow detected
  • Scientific Linux 6.1 x86_64 - iptables v1.4.7 buffer overflow detected
  • Fedora 15 x86_64 - testing in process
  • Fedora 16 x86_64 - testing in process