Вы наверняка слышали об OpenStack. Блин, да о нем говорят на каждом более-менее связанном мероприятии. Все кому не лень пропагандируют OpenStack. Модно, молодежно, все уже есть, Open Source, вливайся давай. И вот наслушавшись тонны маркетингового булшита, вы решаетесь: Будем ставить OpenStack!

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

Предыстория

Об OpenStack я узнал на одной из конференций по OSS году примерно в 2012-м. В то время я работал в компании активно использующей большие кластера (100+ машин), однако без виртуализации, оркестрирования (kickstarter + IBM CSM в счет?) и в основном с пакетным исполнением задач: запустил, отработало, забрал результат. Полноценного понимания что такое облака и зачем они нужны еще не было, но интерес возник. Конечно сразу же возникло желание развернуть новую крутую штуку, которая вот прям сейчас сделает все хорошо.

Чуть позже в том же году, такая возможность представилась, правда уже в рамках стартапа. Нужно было развернуть проект, использующий кластеризацию и горизонтальное масштабирование, при этом нужна была изоляция окружений и совместное использование ресурсов одной машины несколькими службами — бюджет все-таки не резиновый.

В общем, в 2012-м мы развернули OpenStack, на тот момент это был Essex, запустили проект, прожили с такой облачной инфраструктурой до 2014-го года, кажется до релиза Grizzly включительно. Сил и желания поддерживать его дальше не было, и OpenStack был с позором выпилен.

Когда-то давно я даже думал написать статью как правильно его ставить, с комментариями на что обратить внимание. Но знаете, я передумал. Не ставьте его лучше вообще. Просто не связывайтесь. Вероятно, часть тезисов уже устарела, напишите в комментариях о том какой я м***к и ничего не понял, но в целом не думаю, что ситуация кардинально поменялась.

Итак, приступим, что же мне не нравится в Openstack и весьма вероятно не понравится вам.

Он чересчур комплексный

Даже не так. Он, *****, МОНСТРУОЗНЫЙ. Нет, взгляните сами.



Когда-то давно, когда мы ставили Essex, там было все относительно просто и понятно. Keystone (служба авторизации), Glance (служба хранилища образов) и Nova (служба управления гипервизорами). Кроме того там еще был Horizon (дашборд) и куча мелких и не очень зависимостей. Каждый узел системы обрастает чуть ли не десятками вспомогательных демонов. На controller node через некоторое время становится страшно смотреть.



Так, когда наш виртуальный кластер приблизился к 20 серверам, controller node стал безбожно тормозить, по непонятной причине. Ну точнее понятной, но мне непонятно, зачем identity service грузила процессор на 100%?

Из комплексности происходит следующий недостаток.

Он запутанный

Архитектура OpenStack достаточно сильно фрагментирована. Есть очень большое количество «движущихся частей», взаимосвязь который между собой не всегда абсолютно ясна. У вас что-то сломалось? Окей, попробуй понять где это что-то сломалось и почему. OpenStack Foundation похоже гордится, что в OpenStack более 20 миллионов строк кода, даже на главную своего сайта вынесли. Так вот, ЭТО НИФИГА НЕ ДОСТОИНСТВО.

Код в большинстве своем написан на Python. Спасибо, OpenStack, благодаря тебе я возненавидел Python и все что с ним связано. Возможно сейчас с документацией получше, но раньше ее практически не было. Логика вполне может начинаться в одном демоне, а потом с помощью запросов через RabbitMQ исполнятся совершенно в другом и даже на другой машине. Стоит ли говорить, что писать собственные расширения для OpenStack совсем не просто. Одно дело если это просто небольшой хак, другое дело если это полноценный подключаемый модуль с новым функционалом. 5 строчками кода вы точно не обойдетесь.

Если вам надо залезть под капот, чтобы понять что там происходит…


Дело в том, что являясь OSS, OpenStack пытается быть kind of unix-way. Т.е. под капотом все эти монструозные службы на самом деле дергают десятки и сотни unix-утилит по собственной логике, которую вам придется изучить и возможно даже дебажить. С документацией, по крайней мере раньше было, все плохо. Зачем вам рассказывать какие именно правила iptables мы добавляем на хост и для чего? У нас же суперкрутое приложение которое делает все само и не требует вашего вмешательства. Хотите добавить свои правила? Нуу, удачи, исходники-то открыты.

Пока вы более-менее вписываетесь в сценарий, предполагаемый авторами — все более-менее окей. Если же вам понадобилось сделать шаг в сторону, ждите трудностей. Запасайтесь man'ами, терпением, возможно вам придется изучить еще несколько несвязанных напрямую с задачей проблем, например как работает RabbitMQ и что ему еще надо?

Из этого проистекает следующая проблема.

Он ненадежный

Казалось бы логично, чем сложнее система, тем менее она надежна. Но видимо эта истина не для всех. Готовьтесь искать источник подземных стуков, запускать демоны в ПРАВИЛЬНОЙ последовательности, много гуглить и читать логи, копаться в исходниках и вот это все.

Некоторые решения на мой взгляд просто спорные. Служба метаданных на виртуальном IP-адресе эмулируемом через iptables? Серьезно? Очень «надежная» работа dnsmasq по выдаче IP виртуалкам. Тысячи их.

И это усугубляется тем что.

Он становится еще больше

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

Например, посмотрите на текущий список служб, каждая из которых добавляет еще несколько демонов на вашу машину:

• Identity service (keystone)
• Image service (glance)
• Compute service (nova)
• Networking service (neutron)
• Dashboard (horizon)
• Block Storage service (cinder)
• Bare Metal service (ironic)
• Container Infrastructure Management service (magnum)
• Database service (trove)
• DNS service (designate)
• Key Manager service (barbican)
• Messaging service (zaqar)
• Object Storage services (swift)
• Orchestration service (heat)
• Shared File Systems service (manila)
• Telemetry Alarming services (aodh)
• Telemetry Data Collection service (ceilometer)

Да, формально не обязательно ставить абсолютно все службы. Но не думайте что какой-то пустячок, которого нет в основной службе можно будет легко и просто добавить в вашу инфраструктуру.

Например, во времена Essex не было простого способа добавить запись о вашей новой виртуалке в ваш DNS-сервис. Руками — пожалуйста. Хуки? Не, не слышали. Я рождения designate так и не дождался.

А еще знаете что?

Он ломается

От релиза к релизу. Т.е. ну вот вы наконец-то запилили инфраструктуру своей мечты, все худо-бедно работает как рассчитывали, но не хватает одной мааааленькой детали. А в новом релизе она есть. Ну по крайней мере по Release Notes.

Окей гугл, давай обновим наш OpenStack. И тут выясняется, что функционал, который вы с радостью использовали — выпилили. Ну потому что. Ну некрасивый он был и вообще, мы лучше сделаем, честно-честно. В следующем релизе. Может быть. А пока вот вам попроще, но ведь работает же! Ну и плевать что не в вашем случае, но работает!

В нашем случае это был функционал сети. Сеть вообще больной вопрос, доставляющий больше всего боли в OpenStack. В общем, наше приложение потребляет трафик из интернета, иногда весьма интенсивно. Конечно это не совсем стандартное требование, но наилучшим для нас вариантом было, когда виртуалки использует собственный хост в качестве роутера, а сам хост уже напрямую отправляет трафик провайдеру. И это можно было сделать в Essex. И это худо-бедно работало.

А в следующем релизе ребята из OpenStack решили что баста, мы выпилим функционал работы с сетью в отдельный модуль (будущий neutron), реализуем что-нибудь простое вроде один роутер на виртуальную сеть ну и играйтесь пока. Т.е. нужно было бы пустить весь трафик целого кластера через единичный узел нашей сети, он бы и стал бутылочным горлышком.

В итоге, OpenStack это такая штука, которая вот действительно, работает — не трогай. Даже не пытайся туда свои рученки совать, п**р. Лучше даже на всякий случай хосты не перезагружать, а то вдруг оно больше не поднимется? Любое обновление — это аврал, нервы, ненависть.

Он сырой (местами)

А еще очень дивное чувство испытываешь, когда тебе нужен функционал, ну, скажем, деление на зоны. Ну вот есть у тебя машины с большими винтами, есть с SSD, есть с видюхами, хочу разбить кластер на зоны, чтобы виртуалка падала на ту машину, у которой необходимый ресурс есть. Ну ок, читаем доку, вроде бы availability zones подходит. Настраиваем, включаем. И ничего. В доке написано что все должно, а на практике ничего. Лезем в код, а там.



Будет реализовано. В следующем релизе. Может быть. Ну ты понял. Смотри предыдущий пункт.

Есть ли плюсы, какие будут выводы?

Лично для меня вывод простой. Ванильную версию OpenStack лучше не использовать. Я не знаю как обстоят дела с вендорскими версиями и у всяких контор, торгующих инсталляциями «под ключ», но как по мне это несколько противоречит самой идеологии «свободного облака». Мы опять получаем vendor lock-in, только под другим соусом.

Хотите попытать счастье с ванильным OpenStack? Нет, ну в целом пожалуйста. Плагинов много, комьюнити большое, маркетингового булшита вообще выше крыши. Удачи, в общем. Но для небольших и средних инсталляций я бы скорее не советовал.

На мой взгляд одна из главных проблем OpenStack проистекает из не совсем верного архитектурного посыла. Стремясь сделать просто для конечного пользователя, они сделали по итогу слишком сложно. Любой допил под свои нужды превращается в кошмар, потому что даже такой простой и банальной вещи как хуки на события не завезли. А как бы это упростило реализацию многих вещей…

В общем после полутора лет борьбы с OpenStack мы от него отказались и перешли на другое облако. Управление инфраструктурой стало простым и приятным, а обновлять версий также просто как apt dist-upgrade.

Что это за облако и почему оно удобнее OpenStack я постараюсь рассказать в следующей статье. (СПОЙЛЕР: это OpenNebula).

https://habrahabr.ru/post/335530/