Хабрахабр

OpenStack: вся правда о «королевском» релизе

Воланд у М. Булгакова говорил, что «кирпич ни с того ни с сего никому и никогда на голову не свалится». Может, и так, но, когда два с половиной года назад меня спросили, хочу ли я познать OpenStack, это был тот самый хорошо завуалированный кирпич (а на старте даже не кирпич, а гранитная плита). Именно 2016 год стал для меня так называемой «точкой невозврата», положив начало стремительному освоению концепций открытого мира и в значительной степени повлияв на менталитет, – превратив мою дальнейшую жизнь в праздник. «Праздник», который всегда со мной.

2016 – наши дни

OpenStack не был любовью с первого взгляда. Первым релизом, развернутым мной для тестов, был Kilo, который легко рифмовался со словом «уныло». Просуществовав ровно три недели, он в надежде был заменен на Liberty, который под привлекательной оберткой – release notes – не сумел оправдать завышенных ожиданий. Mitaka не столько привнес новый функционал, сколько содержал в себе массу исправлений и «заплаток», и до сих пор (!) с успехом эксплуатируется в продуктивных средах. Выход Newton, фактически, стал переломным моментом в истории OpenStack, предоставив такое количество архитектурных, логических и, как следствие, конфигурационных изменений, что навсегда закрыл путь апгрейда с предыдущей версии для многих частных облаков. Но именно с релиза Ocata в 2017 году, если верить аналитикам, начался «золотой век» OpenStack, в который входят Pike, Queens и, я искренне на это надеюсь, войдет находящийся на низком старте Rocky.

04 LTS (и продолжает заниматься, потому что нет предела совершенству). В данной статье речь пойдет о последнем стабильном на текущий момент релизе OpenStack – Queens, о некоторых нововведениях и недочетах, – с точки зрения человека, который занимался автоматизацией его развертывания на базе дистрибутива Ubuntu 16.

Неудивительно, ведь его предшественник – Pike, официальная поддержка которого будет длиться еще восемь месяцев, – с отработанной сотнями пользователей и хорошо документированной процедурой апгрейда выглядит более пригодным к внедрению. Про Queens материала в сети не так уж и много (если исключить из выборки официальную документацию и доклады с недавнего OpenStack Summit в Ванкувере), а количество отзывов от облачных провайдеров и системных интеграторов по пальцам одной руки можно пересчитать. Так насколько глубокой оказалась кроличья нора? Наша команда, пристально следившая за процессом разработки Queens с самого начала, пошла дальше многих и с уверенностью пустила «новенького» в продакшн.

(далее по тексту будет обширно использоваться терминология OpenStack; предполагается, что читатель, как минимум, знаком с типовой архитектурой)

Полезные фичи

  1. Приятным бонусом в новом релизе лично для меня стало расширение функционала утилиты nova-manage: теперь можно удалять хосты из одних ячеек (Cells v2) и перебрасывать их в другие! В Pike приходилось писать отдельные запросы к базе, а теперь это доступно «из коробки».
  2. Создание пользовательской роли (_member_ по умолчанию) для Keystone «выпилено» из этапа bootstrap. Причиной тому послужил окончательный переход к API v3, обладающего другими формами механизмов авторизации и аутентификации, что также повышает безопасность инфраструктуры (ведь для пользовательской роли ещё и фиксированный id существовал…) Однако, это вовсе не означает, что пользовательская роль не нужна, – рано или поздно её все равно придётся создать.

    Прогноз: начиная с данного релиза, Identity API v2 объявлен устаревшим; его поддержка, вероятно, полностью прекратится через год (пессимистично – в релизе Stein).

  3. Neutron l3- и dhcp- агенты получили возможность automatic failover – автоматическое переключение (решедулинг) сетей и роутеров с выключенных агентов на активные. Функционал DVR HA включен по умолчанию ([DEFAULT]/router_distributed, [DEFAULT]/l3_ha). DVR/SNAT выделен в отдельный namespace. При создании роутера snat создается по умолчанию, забирая себе еще один IP адрес из внутренней подсети:

    Такая связка позволяет в случае сбоя SNAT-службы быстро переключиться с текущего на резервный роутер l3-агента, запущенного на другой ноде.
  4. Весь функционал Neutron vpn-агента переложен на l3-агент; в его конфиг необходимо внести единственную правку:

    [agent]/extensions = vpnaas

    Наконец-то наличие vpn-агента перестало мешать при построении логики автоматического развертывания в случае включения той или иной роли (ранее, vpn- и l3- агенты были взаимоисключающими: ставишь один пакет – удаляется другой).

  5. Glance-registry (прокси для взаимодействия с базой данных в API v1) объявлена устаревшей службой, конфигурировать отныне можно и нужно только службу glance-api. Без сюрпризов не обошлось, но о них будет сказано чуть позже.
  6. Mamma mia! Heat-dashboard вынесен в отдельный пакет (подключаемую панель) для Horizon. Плагин претерпел множество изменений, но самым неожиданным функционалом стал… drag & drop объектов в процессе генерации шаблонов. Легче один раз увидеть:

  7. В Cinder добавлена поддержка volume multi-attach – возможность подключения одного диска нескольким виртуальным машинам. Пока данный функционал реализован только для ограниченного числа поддерживаемых сервисом драйверов: LVM, NetApp/SolidFire, Dell EMC ScaleIO и Oracle ZFSSA, — в действительности, это очень большой шаг вперед для всего проекта (имплементация механизма заняла больше двух лет).

    Прогноз: для Ceph RBD поддержка Cinder volume multi-attach до сих пор не заявлена; скорее всего, ее стоит ожидать не ранее, чем через год (оптимистично – в релизе Stein).

Досадные баги

(перечисленные ниже баги были обнаружены при развертывании OpenStack Queens на дистрибутиве Ubuntu 16.04.4 LTS (Xenial Xerus); существует вероятность, что они не проявятся на других дистрибутивах Linux)

  1. В сообществе Linux существует такое понятие, как «мейнтейнер» (maintainer) – специалист, сопровождающий/обслуживающий/ведущий некий программный компонент (в конкретном случае, бинарный пакет). Так вот, мейнтейнеры Ubuntu снова (баг существовал еще в релизе Pike) предоставили пакеты для штатного time-series database сервиса – Gnocchi. Их установка в окружении Python 2.7 через apt «ломает» некоторые связанные сервисы, запущенные под libapache2-mod-wsgi: Keystone, Cinder, Nova Placement, Horizon. Печальный случай, когда хочешь использовать единый способ доставки пакетов в систему. Впрочем, если для Gnocchi хотя бы попытались собрать пакеты, то для Octavia по-прежнему существуют только pip и git.
  2. Я не берусь утверждать, но, возможно, те же самые мейнтейнеры приложили руки к созданию пакетов nova-compute. По крайней мере, это объяснило бы, почему при их установке на систему (сборки ядра 116, 119 и 124; версии пакетов начиная с 17.0.1 и заканчивая 17.0.4) установщик «вываливается» с ошибкой:

    Setting up nova-compute-libvirt (2:17.0.1-0ubuntu1~cloud0) ...
    adduser: The user 'nova' does not exist.
    dpkg: error processing package nova-compute-libvirt (--configure): subprocess installed post-installation script returned error exit status 1
    dpkg: dependency problems prevent configuration of nova-compute-kvm: nova-compute-kvm depends on nova-compute-libvirt (= 2:17.0.1-0ubuntu1~cloud0); however: Package nova-compute-libvirt is not configured yet.

    Дело вот в чем: во время установки запускается скрипт, который должен создать системную группу nova и системного пользователя nova. Скрипт отрабатывает с ошибкой, инсталляция падает, а в автоматизацию добавляется workaround: проделать упомянутые телодвижения до установки пакетов. Кстати, этот баг до сих пор не закрыт.

    Мейнтейнером на время решения проблемы (циклических зависимостей пакетов Nova друг от друга) был предложен еще один workaround: сначала ставить пакет nova-common, затем – nova-compute. UPD: в процессе написания статьи баг наконец подтвердили и выставили средний приоритет. 0. В ближайшее время можно ожидать версию пакетов 17. 5, лишенную этого недостатка.

  3. Тестируя работу сервиса Neutron FWaaS, выяснилось, что при удалении фаервола с distributed роутера происходит… ровным счетом ничего. Фаервол из статуса «online» переходит в вечный статус «pending delete», и решить проблему можно, либо используя запросы к базе, либо удалив роутер целиком (данный баг существовал еще в релизе Pike). Основная проблема на текущий момент заключается в том, что фикс (который реально решает!) был предложен несколько месяцев назад, но до сих пор не попал в последний стабильный релиз.
  4. Уже на этапе нагрузочного тестирования инфраструктуры обнаружилось, что «neutron-openvswitch-agent EATING CPU AAAAAAA» – в режиме простоя openvswitch-агент загружал одно из процессорных ядер на 100%:

    $ ps aux | grep 16233
    neutron 16233 99.5 0.0 311112 143156 ? Rs 19:47 67:11 /usr/bin/python2 /usr/bin/neutron-openvswitch-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/openvswitch_agent.ini --log-file=/var/log/neutron/neutron-openvswitch-agent.log $ time strace -c -p 16233
    % time seconds usecs/call calls errors syscall
    ------ ----------- ----------- --------- --------- ----------------
    100.00 0.000362 0 95725 epoll_wait
    0.00 0.000000 0 15 read
    0.00 0.000000 0 6 open
    0.00 0.000000 0 6 close
    0.00 0.000000 0 6 stat
    0.00 0.000000 0 15 fstat
    0.00 0.000000 0 20 sendto
    0.00 0.000000 0 79 41 recvfrom
    0.00 0.000000 0 2 setsockopt
    0.00 0.000000 0 94 epoll_ctl
    ------ ----------- ----------- --------- --------- ----------------
    100.00 0.000362 95968 41 total real 0m10.300s
    user 0m0.324s
    sys 0m2.576s

    Решение проблемы было найдено разработчиками сервиса в кратчайшие сроки; фикс предоставлен в версии пакетов Neutron 12.0.1-0ubuntu1.1.

«Королевский» факап

Спойлер

Окончательное подведение итогов состоится не раньше выхода Rocky, однако позицию фаворита будет сложно пошатнуть.
Glance, от которого никак нельзя было ожидать подвоха, в этом релизе был номинирован на премию The Most Epicfail Service, учрежденную мной лично, и лидирует с большим отрывом от конкурентов – плохо документированных, с трудом поддающихся дебагу сервисов, – Designate, Octavia и Watcher.

В OpenStack Queens разработчики внедрили новый метод загрузки образов – web-download, который позволяет конечному пользователю «залить» образ по ссылке. Когда-то давным-давно, когда Image API v1 еще не был объявлен устаревшим и ему на смену не пришел API v2, этот функционал существовал. Казалось бы, что могло пойти не так?..

Преследуя простую цель оттестировать опцию, я отключаю один из методов, перегружаю сервис, и понеслась! В конфиге службы glance-api оба метода загрузки образов – напрямую и по ссылке – включены по умолчанию ([DEFAULT]/enabled_import_methods).

CRITICAL glance [-] Unhandled error: ValueError: tuple.index(x): x not in tuple
ERROR glance Traceback (most recent call last):
ERROR glance File "/usr/bin/glance-api", line 10, in <module>
ERROR glance sys.exit(main())
ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 97, in main
ERROR glance fail(e)
ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 71, in fail
ERROR glance return_code = KNOWN_EXCEPTIONS.index(type(e)) + 1
ERROR glance ValueError: tuple.index(x): x not in tuple

Повозившись с патчем, снова перегружаю сервис:

glance-api[26538]: ERROR: Value for option enabled_import_methods is not valid: Value should start with "["
systemd[1]: glance-api.service: Main process exited, code=exited, status=4/NOPERMISSION
systemd[1]: glance-api.service: Unit entered failed state.
systemd[1]: glance-api.service: Failed with result 'exit-code'.

Серьезно, что ли?! Опция в конфиге приобрела следующий неадекватный вид:

[DEFAULT]/enabled_import_methods = [glance-direct]

Конечно, мной был заботливо открыт баг. Разработчики на время решения проблемы даже вывесили объявление о данном, известном им, поведении (known issues) и отправили коммит в master ветку проекта. Спустя два месяца после открытия бага фикс «ушел» в будущий релиз; счастливым обладателям Queens придется подождать версию пакетов Glance 16.0.2.
Все хорошо, что хорошо кончается.

«Не теряй голову, качай мыщцы»

За время работ по автоматизации развертывания (подразумевающих также этапы конфигурирования и функционального тестирования) Queens показал себя крепким, не перегруженным новыми фичами, без торчащих отовсюду «костылей» релизом, задав высокую планку своему преемнику.

Эта цитата из трека Atlantida Project, на мой взгляд, самым лучшим образом описывает весь спектр ощущений, получаемых от взаимодействия с продуктом. Впрочем, несмотря на то, что Queens – семнадцатый (!) по счету релиз OpenStack, общая тенденция сохраняется на протяжении многих лет: «непредвиденное не предвидимо непредвиденной интуицией». С другой, — когда дело доходит до внедрения относительно молодых сервисов, начинается вышеупомянутый «праздник»: разбирайся как хочешь в скудной документации, готовься сутками напролет просматривать код и сидеть на популярном баг-трекере. С одной стороны, процедура развертывания штатных сервисов (Keystone, Glance, Swift, Cinder, Nova, Neutron, Horizon) с базовыми настройками давно отлажена и не вызовет проблем даже у начинающего инженера.

А на деле, занятие «опенстеком» качает мозг быстрее любой логической игры, развивает полезные навыки в геометрической прогрессии, постоянно держит в тонусе и уж точно не дает скучать. Однако, все эти страдания – всего лишь побочные эффекты стокгольмского синдрома. А если вы готовы почти на ощупь пробираться сквозь черноту консолей, ведомые потребностью реализовать себя (и сделать open-source мир чуточку лучше), – возможно, это и ваш путь. OpenStack решительно не был моей любовью с первого взгляда, доводя до белого каления и полуобмороков, но определенно заслуживает толику любви теперь.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть