OpenStack Juno milestone-1: тестируем Neutron L3-агент на стенде

Juno официально выйдет в октябре, но milestone-1 уже доступен для тестирования. Мы подняли стенд на прошлой неделе - не из академического интереса, а потому что несколько клиентских инсталляций сидят на Icehouse и там периодически всплывает одна раздражающая проблема с Neutron. Хотели проверить, не починили ли.

Забегая вперёд: что-то починили, но не всё.

Контекст: что не так с Neutron в Icehouse

Если кратко - L3-агент в Icehouse не очень хорошо переживает перезапуск. Ситуация типичная: пакетное обновление системы, перезагрузка хоста, или просто neutron-l3-agent restart после изменения конфига. После этого часть маршрутов на namespace-ах пропадала, и виртуалки теряли связность с внешней сетью. Не всегда, не стабильно воспроизводимо, что особенно неприятно.

Workaround был такой: после перезапуска агента делать neutron router-update <id> --admin_state_up False а потом True для каждого роутера. Это возвращало маршруты. Руками. На каждом роутере. Прелесть.

Стенд для Juno

Подняли три ноды: один контроллер, один сетевой узел, один вычислительный. KVM под Ubuntu 14.04, установка из репозиториев через RDO (там уже есть milestone-пакеты). Базовая конфигурация - GRE-туннели для tenant-сетей, один внешний провайдерский bridge.

Никакой экзотики - ровно то, что стоит в типовой клиентской инсталляции.

Что изменилось в настройке L3-агента

В Icehouse минимальный l3_agent.ini выглядел примерно так:

[DEFAULT]
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
external_network_bridge = br-ex
use_namespaces = True

В Juno появился новый параметр - agent_mode. Принимает три значения: legacy, dvr, dvr_snat. По умолчанию legacy, то есть старое поведение, и это хорошо - апгрейд не ломает существующие конфигурации.

DVR (Distributed Virtual Routing) - это новая фича, которая выносит L3 на вычислительные ноды вместо выделенного сетевого узла. Мы DVR не тестировали - в этом milestone он ещё сырой и явно не для продакшна. Но сам факт появления agent_mode говорит о том, что структура agenta стала чище.

Второй важный момент - параметр handle_internal_only_routers. В Icehouse он был, но его поведение при перезапуске было непредсказуемым. В Juno, судя по коду и нашим тестам, агент при старте теперь делает синхронизацию состояния с сервером Neutron до того, как начинает обрабатывать новые события из очереди. В Icehouse порядок был обратный или как минимум гарантий на него не было.

Как ведёт себя при перезапуске

Тестировали так: создали три роутера, подключили по две сети к каждому, проверили пинг из виртуалок наружу. Потом service neutron-l3-agent restart и смотрим что происходит.

На Icehouse: после рестарта пинги гасли примерно в половине случаев. Восстановление - от тридцати секунд до нескольких минут, иногда никогда без ручного вмешательства.

На Juno milestone-1: три перезапуска подряд - все три раза связность восстановилась автоматически. Время восстановления - порядка десяти-пятнадцати секунд (там, где агент перечитывает состояние роутеров и переустанавливает маршруты). Повторяемость хорошая.

Мы намеренно не называем точные числа - стенд есть стенд, там нет той нагрузки и тех граничных условий, которые есть на реальных клиентских инсталляциях. Но качественно разница заметна.

Nova: что интересного

В Nova в milestone-1 доработали логику live-migration при использовании shared storage. В Icehouse при определённых условиях live-migration виртуалки с эфемерным диском мог зависнуть на этапе pre-migration если у хоста-источника была высокая нагрузка на IO. В Juno добавили таймаут и обработку этого сценария - миграция откатывается корректно, не оставляет машину в состоянии migrating навсегда.

Проверить не успели - на нашем стенде нет shared storage. Но patch в коммитах есть, выглядит адресно.

Что делать с этим знанием прямо сейчас

На Icehouse с Neutron-проблемой живём дальше через сопровождение - мониторим состояние агентов через Zabbix и при необходимости дёргаем router-update скриптом. Некрасиво, но работает.

На Juno переходить сейчас не стоит - milestone это не релиз, API может измениться до октября. Но стенд показал, что направление движения правильное, и к релизу имеет смысл готовить план апгрейда уже сейчас: инвентаризировать роутеры, задокументировать конфигурацию L3-агентов, проверить совместимость плагинов.

Одна практическая рекомендация уже сейчас: если у вас Icehouse и часто перезапускаете L3-агент - добавьте в l3_agent.ini явный use_namespaces = True даже если он там уже стоит по умолчанию. Иногда при апгрейде пакета дефолт менялся, и агент начинал вести себя неожиданно.

Следим за milestone-2, там обещают DVR в более стабильном состоянии.