OpenStack Havana: запускаем пилот частного облака на трёх узлах

OpenStack как тема висел у нас в воздухе примерно год. Читали, следили за релизами, смотрели слайды с OpenStack Summit - но руки не доходили до чего-то серьёзнее стенда на одной виртуалке. В январе один из клиентов на сопровождении поставил вопрос конкретно: хотим пилот частного облака, бюджет на три физических сервера, VMware не рассматриваем. Решили что это хороший повод разобраться по-настоящему.

Выбрали Havana - октябрьский релиз, самый свежий на тот момент. В него вошёл Neutron в составе core-проекта (раньше был Quantum и статус инкубатора), Cinder стабилизировался, Nova проверена несколькими релизами. На бумаге - зрелая история.

Что разворачивали и на чём

Три физических узла под CentOS 6.5. Роли разделили так:

• Узел контроллера - Keystone, Glance, Nova API/scheduler, Neutron server, Cinder API, Horizon. Одна машина, всё управление.
• Сетевой узел - Neutron L3 agent, DHCP agent, metadata agent. Отдельный хост, потому что через него пойдёт весь виртуальный сетевой трафик.
• Вычислительный узел - Nova compute, Neutron OVS agent. Один для пилота, понятно что в продакшне их должно быть больше.

Установку делали через RDO - Red Hat-овский способ поставить OpenStack на CentOS через yum. Альтернативы - DevStack (не для продакшна) и ручная сборка по документации (слишком долго для пилота). RDO даёт packstack --allinone для тестирования и пошаговую установку для чего серьёзнее. Взяли пошаговую.

Нейтронная головная боль

Вот здесь и началось. Neutron - сетевой компонент OpenStack, он заменил старый nova-network и обещает настоящую software-defined сеть: виртуальные роутеры, floating IP, security groups, изоляция тенантов через VXLAN или GRE-туннели. Звучит здорово. На практике у него сложная архитектура и несколько движущихся частей, которые надо правильно скоординировать.

Схема Neutron с OVS (Open vSwitch) выглядит примерно так:

ВМ -> tap-интерфейс -> OVS br-int -> OVS br-tun (GRE/VXLAN) -> сетевой узел
                                                                      |
                                              OVS br-ex -> внешняя сеть

Каждый мост имеет свою роль. br-int - интеграционный мост, куда подключаются ВМ. br-tun - туннельный мост для трафика между узлами. br-ex - мост к физической сети для floating IP.

Первая проблема: физические интерфейсы. Для правильной работы br-ex нужно взять физический интерфейс сетевого узла, добавить его в OVS-мост и убрать IP с самого интерфейса - IP вешается на мост. Это нелогично с точки зрения привычной Linux-сети и легко делается неправильно. Мы сделали неправильно, потеряли связь с сетевым узлом, восстанавливали через IPMI. Урок: заранее готовить запасной network-интерфейс или консоль.

Вторая проблема: MTU. GRE-туннели между узлами добавляют оверхед к заголовку пакета. Если не настроить MTU на виртуальных интерфейсах ВМ меньше стандартных 1500 (для GRE обычно 1454), при передаче крупных пакетов начинается фрагментация или молчаливые потери. ВМ пингуются, SSH работает, а rsync или scp зависает - классический симптом MTU-проблемы. Разбирались несколько часов, пока не вспомнили про туннельный оверхед.

Третья проблема: security groups. По умолчанию Neutron блокирует весь входящий трафик между ВМ и наружу. Это правильно с точки зрения безопасности, но неожиданно когда запустил ВМ и не можешь до неё достучаться даже по ping. Horizon позволяет управлять security groups через веб, но поначалу не очевидно где именно.

Nova и Cinder: значительно проще

На фоне Neutron установка Nova compute и Cinder прошла почти незаметно. Nova на вычислительном узле - это в основном KVM + libvirt, и с этим у нас опыт достаточный. Живая миграция ВМ между узлами в пилоте не настраивали - для одного compute-узла смысла нет, но архитектурно это решаемо через общий NFS или Ceph.

Cinder с бэкендом на LVM - стандартная конфигурация для начала. LVM volume group на отдельных дисках сетевого узла, Cinder подключает тома через iSCSI к ВМ. Том создаётся в Horizon в несколько кликов, подключается к запущенной ВМ без её перезагрузки. Вот это реально приятно по сравнению с ручным управлением дисками в KVM.

Horizon: красивый фасад

Веб-интерфейс OpenStack работает и выглядит достойно. Запустить ВМ из загруженного образа, создать том, назначить floating IP - всё через браузер. Для демонстрации клиенту удобно. Для повседневной работы всё равно уходишь в nova CLI и neutron CLI - там больше контроля и проще автоматизировать.

Что получилось в итоге

Пилот запущен. ВМ создаются, сеть работает, тома подключаются. На это ушло около недели с учётом диагностики сетевых проблем - дольше чем рассчитывали.

Честное впечатление от Havana: Nova и Cinder - рабочие инструменты. Neutron - правильная архитектура, но с порогом вхождения, который не стоит недооценивать. Если раньше не работали с OVS и виртуальными сетями на этом уровне, первые дни будут сложными.

Документация OpenStack объёмная, но местами противоречивая - часть руководств написана под Grizzly и частично устарела. Нашли несколько активных блогов практиков, которые оказались полезнее официального wiki в части Neutron-конфигурации.

Клиент смотрит на результат с осторожным интересом. Решение о расширении пилота до нескольких compute-узлов будет через месяц после эксплуатации.