OpenStack Icehouse: обновляем пилот с Havana без переустановки

Вышел Icehouse - девятый релиз OpenStack. Мы его ждали по конкретной причине: наш пилот на Havana работает с февраля, и за это время Neutron успел несколько раз повести себя непредсказуемо. В анонсе Icehouse обещали улучшения именно в этой части. Решили проверить на практике - и заодно выяснить, реально ли обновиться без сноса кластера.

Что изменилось в Icehouse

Из того, что реально важно для нашей конфигурации:

• Neutron - основной гвоздь программы. Зафиксировали несколько нехороших поведений L3-агента при перезапуске: он мог не восстанавливать маршруты виртуальным роутерам. В Icehouse это переработали.
• Ceilometer - телеметрия. В Havana мы его не включали, потому что он ел ресурсы несоразмерно тому, что давал. В Icehouse заявлена оптимизация хранения метрик через MongoDB, посмотрим.
• Nova - стабилизация API v2 и улучшения в планировщике. Для нашего одного compute-узла это пока не критично, но приятно знать.
• Heat - оркестрация. Не трогали в Havana, пощупаем в Icehouse.

Про обновление без переустановки

Главный вопрос был простой: можно ли обновить работающий кластер через yum update, не заливая всё заново. Теоретически RDO поддерживает это. Практически - мы нашли несколько нюансов.

Общий порядок, которому следовали:

• Остановить все workload на compute-узле. У нас пилот, ВМ клиента можно было мигрировать на VMware-хост пока идёт работа. В продакшне это был бы live migration - он тут недоступен с одним compute-узлом.
• Обновить контроллер первым. Сначала Keystone, потом Glance, потом Nova, потом Neutron. Порядок важен: Nova API и Neutron server должны быть новыми до того, как трогать агенты на других узлах.
• Накатить миграции базы данных. nova-manage db sync, neutron-db-manage upgrade head, cinder-manage db sync. Это нельзя пропускать - схема БД меняется между релизами.
• Обновить сетевой и compute-узлы. Здесь отдельная осторожность с Neutron-агентами: останавливаем агент, обновляем пакет, запускаем, проверяем что он поднялся и зарегистрировался на контроллере.

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

Neutron действительно стал спокойнее

В Havana у нас было два неприятных паттерна. Первый: после рестарта neutron-l3-agent существующие виртуальные роутеры иногда теряли маршрут по умолчанию - пинг наружу пропадал, и надо было вручную через neutron router-update дёргать его обратно. Второй: DHCP-агент периодически не выдавал адрес вновь запущенной ВМ с первого раза, ВМ поднималась без IP и надо было перезапускать её или dhcp-агент.

После обновления на Icehouse несколько дней наблюдений: L3-агент при рестарте восстанавливает маршруты сам, без наших костылей. DHCP-проблему тоже не воспроизвели. Это не значит, что её нет - это значит, что она не воспроизвелась на нашем объёме за несколько дней. Будем смотреть дальше.

OVS-мосты при этом остались ровно теми же - br-int, br-tun, br-ex. Обновление пакетов не трогает существующую конфигурацию OVS, это надо понимать: если что-то было настроено руками в /etc/neutron/, оно останется как есть. Хорошо если конфиг правильный, плохо если там была заплатка под старый баг.

Ceilometer: включили, выключили

Попробовали включить телеметрию. Ceilometer собирает метрики по ВМ: CPU, memory, disk I/O, сеть - через агент на compute-узле и складывает в MongoDB. Идея понятная: одно место для метрик всего облака.

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

Heat: беглый взгляд

Heat - это оркестрация через шаблоны, что-то вроде CloudFormation от Amazon. Описываешь в YAML инфраструктуру (ВМ, сети, тома, floating IP), запускаешь heat stack-create - и оно создаёт всё пачкой. Запускаешь heat stack-delete - убирает.

Написали простой шаблон на тестовую ВМ с сетью и томом. Работает. Для пилота пока избыточно, но как только ВМ больше двух-трёх штук - начинает иметь смысл. Особенно если надо воспроизвести окружение с нуля.

Что дальше

Клиент после Heartbleed и параллельных событий смотрит на расширение пилота чуть задумчивее, чем в марте - апрель выдался богатым. Но Icehouse дал нам главное: Neutron перестал быть источником ежедневного беспокойства. Для сопровождения это существенная разница - одно дело объяснять клиенту новую платформу, другое дело объяснять почему она ведёт себя непредсказуемо.

Пока считаем пилот условно готовым к нагрузочному тестированию. Дальше - добавим второй compute-узел и проверим, как Neutron справляется с миграцией трафика при переключении.