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

2016 – наши дни

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


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

Про Queens материала в сети не так уж и много (если исключить из выборки официальную документацию и доклады с недавнего OpenStack Summit в Ванкувере), а количество отзывов от облачных провайдеров и системных интеграторов по пальцам одной руки можно пересчитать. Неудивительно, ведь его предшественник – Pike, официальная поддержка которого будет длиться еще восемь месяцев, – с отработанной сотнями пользователей и хорошо документированной процедурой апгрейда выглядит более пригодным к внедрению. Наша команда, пристально следившая за процессом разработки 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: проделать упомянутые телодвижения до установки пакетов. Кстати, этот баг до сих пор не закрыт.
   

   UPD: в процессе написания статьи баг наконец подтвердили и выставили средний приоритет. Мейнтейнером на время решения проблемы (циклических зависимостей пакетов Nova друг от друга) был предложен еще один workaround: сначала ставить пакет nova-common, затем – nova-compute. В ближайшее время можно ожидать версию пакетов 17.0.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.

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

В 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 показал себя крепким, не перегруженным новыми фичами, без торчащих отовсюду «костылей» релизом, задав высокую планку своему преемнику.

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

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