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

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

    Comments 22

      0

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

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

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

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

          0

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

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

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

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

            c Liberty до Newton с нюансами, но обновляется. Так что все нормально с апгрейдом.
              0
              Здесь имеется в виду, что далеко не все смогли справиться с подводными камнями/проблемами/нюансами… Особенно не повезло малому бизнесу (например, компаниям, в которых один системный администратор отвечает за всю существующую инфраструктуру, включая OpenStack).
                0
                посыл понял =)
                  +1
                  Малый бизнес с одним администратором и OpenStack это такая прогулка на лодке по пруду, только вместо лодки — эсминец. Ну не нужен OpenStack примерно половине организаций, у которых он есть, ибо дорого очень в пересчёте на потраченные силы.
                    0

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

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

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

                    0
                    Сам OpenStack не так сложен, как его малюют. Сложности начинаются с high availability сервисов, и вот тут без автоматизации никуда.
                      0
                      Не могли бы Вы пояснить, отчего такое разнесение понятий: OpenStack и HA?
                        0
                        А как вы организуете балансировку нагрузки и HA для Control plane?
                          0
                          Мы используем разнообразные программные решения, но не только. Например, балансировка нагрузки у нас заложена архитектурно, на сетевом уровне.
                      0
                      вручную вообще не рекомендуется, но если вы имеете ввиду почти вручную — packstack, да, это простенько, понятненько и круто. Знаем-плавали.

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

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

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

                      0

                      Не совсем понятно, что за решедулинг нейтрона, он всегда существовал(l3_agent_size). Что нового в queens ?

                        0
                        Я, к сожалению, не знаю, что за опция такая l3_agent_size, наиболее подходящими кажутся min_l3_agents_per_router и max_l3_agents_per_router…
                        По поводу решедулинга: «получили возможность», действительно, некорректное высказывание, ведь функционал существовал в ранних релизах, вот только и багов было достаточно. Вспомнить хотя бы баг, когда при падении neutron-server'a отказывал и l3-agent… Новинка в Queens — это выделение DVR/SNAT в отдельный namespace, что в совокупности с включением automatic_l3agent_failover
                        позволяет в случае сбоя SNAT-службы быстро переключиться с текущего на резервный роутер l3-агента, запущенного на другой ноде.

                      Only users with full accounts can post comments. Log in, please.