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

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


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

В 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 мир чуточку лучше), – возможно, это и ваш путь.

Комментарии (20)


  1. Joker946
    28.06.2018 11:38

    Добрый день, я мейнтейнер проекта Watcher, было бы здорово, если вы предметно опишите ваши возникшие проблемы с документацией. Мы время от времени её перерабатываем с учётом пожеланий пользователей. Можно продолжить разговор здесь: aschadin@sbcloud.ру (ru конечно же) или на openstack-dev рассылке.
    Спасибо!


    1. anniemelen Автор
      28.06.2018 12:11

      Добрый день!
      Спасибо за Ваш отклик, постараюсь в ближайшее время составить развернутый комментарий на тему документации Watcher. В качестве примеров:

      • Если обратить внимание на раздел Configuring Watcher, можно заметить, что документ содержит массу deprecated options; за актуальной конфигурацией приходится обращаться в Installation Guide.
      • Совсем не помешали бы Sample Configuration File и Sample Policy File.
      • Нет ни одного упоминания про HA...

      Очень выручают схемы, за них отдельное спасибо!


  1. stalk76
    28.06.2018 12:24

    А вы не пробовали Mirantis Cloud Platform, в частности, из соображений автоматизации апгрейда на новые версии OpenStack?


    1. anniemelen Автор
      28.06.2018 13:05

      Нет, у меня был опыт работы только с Mirantis Openstack (в далёком 2016).
      По поводу автоматизации: как и процедуры развёртывания инфраструктуры, так и процедуры ее апгрейда мы пишем сами, не полагаясь на готовые решения. Это во многом обуславливается желанием от начала и до конца контролировать данные процессы.


  1. ayurtaykin
    28.06.2018 13:31

    Наконец-то отличная статья от техносерва)
    Техносерв-cloud уже на queens?


    1. anniemelen Автор
      28.06.2018 13:46

      Спасибо, приятно слышать!
      Пока нет, но уже вот-вот запустим. Если Вы подписаны на блог ТС, то эту новость никак не пропустите.)


  1. desperatenix
    28.06.2018 16:22

    что навсегда закрыл путь апгрейда с предыдущей версии для многих частных облаков.

    c Liberty до Newton с нюансами, но обновляется. Так что все нормально с апгрейдом.


    1. anniemelen Автор
      28.06.2018 16:42

      Здесь имеется в виду, что далеко не все смогли справиться с подводными камнями/проблемами/нюансами… Особенно не повезло малому бизнесу (например, компаниям, в которых один системный администратор отвечает за всю существующую инфраструктуру, включая OpenStack).


      1. desperatenix
        28.06.2018 17:17

        посыл понял =)


      1. rzerda
        28.06.2018 17:51
        +1

        Малый бизнес с одним администратором и OpenStack это такая прогулка на лодке по пруду, только вместо лодки — эсминец. Ну не нужен OpenStack примерно половине организаций, у которых он есть, ибо дорого очень в пересчёте на потраченные силы.


        1. anniemelen Автор
          28.06.2018 19:15

          Вы совершенно правы! Но когда OpenStack находился на пике своей популярности, об этом старались не думать, не закладывали RnD, не просчитывали риски от столкновения с жестоким миром open-source, — его просто хотели, и все. Понимание приходило значительно позже… Была свидетелем подобной ситуации.


  1. tenhi_shadow
    28.06.2018 17:17

    Openstack прекрасен в своём странном поведении, особенно на этапе установки(скажу на RH Openstack 8 ).
    Overcloud deploy выглядит как pyppet Unknown Error практически всегда и это нормально. Отлаживать проблемы устнановки просто нереально, как вообще этим можно нормально рулить, если всё настолько никак в Openstack?


    1. anniemelen Автор
      28.06.2018 18:52

      Я искренне считаю, что OpenStack развивается, идя по пути упрощения установки. Документация становится понятнее, debug — нагляднее, количество known exceptions растёт… Но из-за высокого порога вхождения в тему (в принципе) и использования готовых инструментов развёртывания (в частности) деплой зачастую превращается в боль. Ещё и поэтому мы "пилим" свою автоматизацию, с выверенными конфигами и обработчиками.
      На мой взгляд, сначала стоит задеплоить pure Openstack вручную пару раз, чтобы наработать экспертную базу, а потом постигать логику работы решений автоматического развёртывания. Обычно к этому моменту уже хватает понимания, в какой момент времени инсталляция пошла не по плану, что делать и кто виноват.


      1. arh87
        28.06.2018 22:22

        Сам OpenStack не так сложен, как его малюют. Сложности начинаются с high availability сервисов, и вот тут без автоматизации никуда.


        1. anniemelen Автор
          28.06.2018 22:24

          Не могли бы Вы пояснить, отчего такое разнесение понятий: OpenStack и HA?


          1. arh87
            28.06.2018 22:40

            А как вы организуете балансировку нагрузки и HA для Control plane?


            1. anniemelen Автор
              29.06.2018 07:58

              Мы используем разнообразные программные решения, но не только. Например, балансировка нагрузки у нас заложена архитектурно, на сетевом уровне.


      1. tenhi_shadow
        29.06.2018 12:25

        вручную вообще не рекомендуется, но если вы имеете ввиду почти вручную — packstack, да, это простенько, понятненько и круто. Знаем-плавали.

        Просто сама эта концепция TripleO, Director невероятно умная, красивая(мне даже нравится). Но вот приехал я такой на экзамен RH, начал ставить 8 версию, а она такая хоп и не ставится. Тупо в процессе overcloud deploy на втором часу деплоя — ошибка. И все гайды по troubleshooting просто бесполезны. Вернуть состояние можно, вроде всё ок, но вот реально, почему билд происходит с непонятными сообщениями puppet? К чему вот такая автоматизация установки, которая тебе говорит всё время «Unknown Error» даже в процессе удачного деплоя?

        Ansible вроде уже есть, но были костыляки вроде того, что Ansible вызывал Puppet и делал часть работы — это как вообще так и зачем?


        1. anniemelen Автор
          29.06.2018 12:50

          вручную вообще не рекомендуется, но если вы имеете ввиду почти вручную — packstack, да, это простенько, понятненько и круто. Знаем-плавали.
          Не-а, «вручную» в данном случае означает «полностью вручную», без намека на автоматизацию (и уж тем более не all-in-one, только кластер): установка пакетов из cloud-archive или исходников из репозиториев.
          К чему вот такая автоматизация установки, которая тебе говорит всё время «Unknown Error» даже в процессе удачного деплоя?
          Сочувствую, всегда обидно, когда такое происходит. Можно попробовать оправдать RedHat тем, что это было давно (все-таки 13-ый релиз вышел), но это будет не совсем правдой, — у 8-ки поддержка истекает только в следующем году. Да и простительно ли такое поведение коммерческому продукту?..
          Ansible вроде уже есть, но были костыляки вроде того, что Ansible вызывал Puppet и делал часть работы — это как вообще так и зачем?
          Не знаю таких примеров, где это встречалось?
          Что касается pure Ansible, то проект openstack-ansible — зрелое и универсальное решение, двигающееся в ногу с релизной политикой OpenStack.


  1. celebrate
    29.06.2018 03:59

    Хорошая попытка, Опенстек, но нет. Больше я к тебе не вернусь. Кубернетес форева.