ADG Оставить заявку
Блог Инфраструктура 4 мин чтения

OpenStack Juno: обновляем тестовый стенд с Icehouse и переписываем Neutron

Juno вышел - обновили стенд с Icehouse без потери данных, но конфиг Neutron L2-агента несовместим. Разбираем diff конфигов и подводные камни миграции.

Контекст момента

OpenStack Juno выпущен в октябре 2014 с улучшенным Neutron, переработанным Ceilometer и поддержкой NFV через механизм ML2-драйверов

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

Итог: данные не потеряли, виртуалки пережили обновление. Но конфигурация Neutron - нет.

Как обновляли

Стенд: три ноды на Ubuntu 14.04, установка через репозитории Ubuntu Cloud Archive. Схема типовая - контроллер, сетевой узел, вычислительный узел, GRE-туннели для tenant-сетей, OVS как backend.

Обновление шло через apt-get dist-upgrade после переключения на Juno-репозиторий. Сервисы перезапускались пакетным менеджером по ходу установки - Nova, Keystone, Glance, Cinder подхватили новые конфиги и поднялись без вопросов. nova-manage db sync прошёл чисто.

А потом мы попытались поднять neutron-openvswitch-agent и он упал.

Что сломалось в Neutron

В Icehouse конфигурация OVS-агента в openvswitch_agent.ini выглядела примерно так:

[ovs]
tenant_network_type = gre
tunnel_id_ranges = 1:1000
integration_bridge = br-int
tunnel_bridge = br-tun
local_ip = 10.0.0.11
enable_tunneling = True

[agent]
polling_interval = 2

В Juno эта структура перестала работать. Причина - переход на ML2-плагин как единственный поддерживаемый механизм. Monolithic OVS-плагин (neutron.plugins.openvswitch.ovs_neutron_plugin.OVSNeutronPluginV2) объявлен deprecated, и конфиг под него агент читать отказывается.

Новая конфигурация живёт в /etc/neutron/plugins/ml2/ml2_conf.ini и выглядит иначе:

[ml2]
type_drivers = gre,flat,vlan
tenant_network_types = gre
mechanism_drivers = openvswitch

[ml2_type_gre]
tunnel_id_ranges = 1:1000

[ovs]
local_ip = 10.0.0.11
enable_tunneling = True
integration_bridge = br-int
tunnel_bridge = br-tun

[securitygroup]
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
enable_security_group = True

[agent]
tunnel_types = gre

Ключевые изменения:

  • type_drivers и mechanism_drivers стали обязательными - раньше это было в плагине, теперь в ML2-конфиге.
  • tenant_network_type превратился в tenant_network_types (множественное число) - и это не опечатка, ML2 поддерживает несколько типов одновременно.
  • tunnel_id_ranges переехал из секции [ovs] в [ml2_type_gre] - логично, но при механическом переносе конфига не очевидно.
  • firewall_driver стал явным - в Icehouse мог подхватываться из другого места, здесь его нужно прописывать в [securitygroup] явно, иначе security groups не работают.

В neutron.conf тоже нужно поправить core_plugin:

core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin

Если оставить старое значение - Neutron-сервер стартует, но при попытке создать сеть падает с ImportError.

Про данные и роутеры

Виртуальные машины не пострадали - Nova не трогает диски при обновлении пакетов, и это ожидаемо. Сети и подсети в базе остались. Роутеры тоже сохранились.

Но после поднятия нового neutron-l3-agent несколько роутеров оказались в состоянии DOWN - не из-за потери данных, а потому что L3-агент при первом старте не восстановил namespace'ы. Пришлось пройтись по каждому neutron router-update <id> --admin_state_up False && neutron router-update <id> --admin_state_up True. Именно тот же workaround, что применяли на Icehouse. Не идеально, но работает.

Что нового в Ceilometer

Ceilometer в Juno получил переработанный pipeline для трансформации метрик. Если вы использовали pipeline.yaml с нестандартными трансформерами - при обновлении его стоит сравнить с новым дефолтом: несколько полей переименованы, и Ceilometer при некорректном pipeline просто не стартует, не говоря зачем.

Сам Ceilometer мы на стенде используем в минимальной конфигурации - считаем vCPU-часы для внутренней отчётности по сопровождаемым стендам. Там обошлось заменой одной строки.

NFV и ML2: почему это важно

Один из главных анонсов Juno - поддержка NFV через ML2-драйверы. Суть: ML2 позволяет подключать внешние механизм-драйверы (SR-IOV, специализированные SDN-решения), не переписывая ядро Neutron. Для нас это пока академически - клиентские инсталляции не требуют SR-IOV. Но сам факт, что Neutron теперь строится вокруг ML2 как единственной архитектуры, важен: это означает, что вся документация, все примеры конфигов и все патчи будут писаться под ML2. Monolithic-плагины - тупик.

Итог

Апгрейд с Icehouse на Juno - не страшно, но Neutron требует внимательной перезаписи конфигов, а не просто apt-get upgrade. Основные грабли:

  • core_plugin в neutron.conf - поменять на ML2.
  • Конфиг OVS-агента - переписать под новую структуру ML2, не пытаться адаптировать старый.
  • firewall_driver - прописать явно, иначе security groups молча не работают.
  • Роутеры после апгрейда - проверить статус, при DOWN дёрнуть admin_state_up.

На клиентские инсталляции Icehouse переводить на Juno пока не планируем - стенд прошёл, но клиентские среды сложнее и там нет окна для таких экспериментов в ближайший месяц. Смотрим на стабильность Juno ещё пару недель.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.