Вы наверняка слышали об 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).
Комментарии (92)
AxianLTD
13.08.2017 20:28+1Согласен, абсолютно такие же ощущения от OpenStack — fragile, ненадежно, запутано.
kvaps
13.08.2017 21:20+1Вы сделали правильный выбор, OpenNebula — отличное облако с предельно простой и в тоже время хорошо продуманной архитектурой.
Довольно минималистичное и в тоже время очень мощное решение, а главное, что оно очень просто кастомизируется и дополняется.
В последнем релизе (5.4) запилили простую настройку федераций и отказоустойчивых кластеров (для бэкенда), теперь не нужно заморачиваться с долгой настройкой и репликацией на уровне бд.
Присоединяйтесь!
SirEdvin
13.08.2017 22:35+2А подскажите, я правильно понимаю, что OpenNebula — это такой аналог AWS для себя? То есть, такая скалируемая штука с виртуалочками и API + куча разных полезных сервисов, типо S3 и так далее?
kvaps
13.08.2017 23:27+1В целом да, но не совсем.
OpenNebula предоставляет вам единый интерфейс с виртуалками, виртуальными сетями, датасторами и темплейтами.
Вы можете строить из этого всего скалируемые сервисы, есть aws-совместимый API.
Сервисов типа S3 или Glacier нет, но ничто не мешает вам развернуть тот же ceph и использовать его S3-совместимый API.
fessoga5
13.08.2017 23:51+1напишите в комментариях о том какой я м***к и ничего не понял, но в целом не думаю, что ситуация кардинально поменялась.
У меня всегда следующая аналогия:
У BMW 7 серии, кроме кучи ништяков, есть задние колеса, которые подруливают вместе с передними. Это сложно, модульно, много электроники, не надежно, а если сломается то сложно починить. Но тем не менее это существует и работает. И стоит это кучи денег, все это похоже на RedHat Openstack.
В ситуации с ванильным OS, тебе дают схемы и софт\часть софта, чтобы ты сделал свой BMW 7, дешево и сложно, но оно того стоит, если оно тебе нужно.
А если тебе нужен трактор, который едет на всем, не имеет подвески и не ломается, то конечно, проходим мимо.
divanikus Автор
14.08.2017 01:43Совсем не vendor lock-in. Свобода! Долгожданная!
SirEdvin
14.08.2017 07:18+1Ну, как бы да. Это выбор между тем, что бы использовать клалифицированную помочь или сделать все самому. Я не совсем понимаю, как вы представляете сложные комплексные системы без такого вот vendor lock-in?
divanikus Автор
14.08.2017 14:03+1Ну выглядит комично. Вы не хотите завязываться на Amazon, Azure и иже с ними, потому что это vendor lock-in, но вместо этого решаете купить совсем все у одного другого провайдера — RedHat. Подписку, систему, стэк, поддержку. Совсем не lock-in, ага.
SirEdvin
14.08.2017 14:36+3Ну, во-первых, существенное отличие в том, что эта вся штука находится у вас. И второе главное отличие — это не lock-in, так как у вас есть возможность все это настроить самому и поддерживать это решение. Вам не продают черную закрытую коробку.
Но это сложно. И по другому не получится, потому что иначе никто бы не платил за другие облака.
divanikus Автор
14.08.2017 14:46Я все-таки настаиваю, что это lock-in, потому как вам навязывают полный стек технологий, от ОС до прикладных программ и платной поддержки. Вы же не сможете поменять RHEL на Debian или Ubuntu просто потому что захотелось. Вы обязаны есть то что вам дает RedHat, это ли не lock-in?
SirEdvin
14.08.2017 14:51+2То есть никто не предлагает в аренду спецов, которые могут настроить OpenStack на Debian или Ubuntu? Не RadHat'ом же единым.
divanikus Автор
14.08.2017 14:59Человек предлагает RedHat Openstack, чувствуете разницу?
SirEdvin
14.08.2017 15:01+2Тот человек да, а я вот нет. Вот есть сертификации openstack: https://www.openstack.org/coa/, она вроде не привязана прямо к RHEL.
just_wow
14.08.2017 00:33+4В общем, в 2012-м мы развернули OpenStack, на тот момент это был Essex, запустили проект, прожили с такой облачной инфраструктурой до 2014-го года, кажется до релиза Grizzly включительно. Сил и желания поддерживать его дальше не было, и OpenStack был с позором выпилен.
Вы бы еще про Cactus релиз написали. В 2017 году, ага. Во-первых, с тех пор OpenStack стал сильно лучше (но все еще не идеал, конечно). Во-вторых, вне зависимости от релиза, OpenStack надо уметь готовить — это я вам говорю с высоты 6 лет опыта, ~20 проектов разного масштаба и назначения и просто консультаций без числа.
divanikus Автор
14.08.2017 01:44+3Воу, прям вот реально проще кастомизацию сделать стало? Или там компонент меньше стало и они надежнее стали? Или в документации мне реально расскажут что делает neutron чтобы мне стало хорошо?
celebrate
14.08.2017 13:52+1А какие с Нейтроном вообще проблемы? На мой взгляд, это один из наименее проблемных сервисов Опенстека… Даже в версии Кило он работает стабильно. У нас Нейтрон с VLAN-сегментацией, Mirantis Openstack версий Кило и Митака.
divanikus Автор
14.08.2017 13:58-3Наименее проблемный сервис по моему опыту — glance. Вот там реально поставил и работает, хлеба не просит. А neutron… Пока вы в задуманный разрабами сценарий вписываетесь, охотно верю. Стало сильно проще реализовать описанный мною сценарий — доступ виртуалок к провайдерскому роутеру с минимумом хопов?
just_wow
14.08.2017 17:26+2Если отбросить сарказм, то продукт действительно стал лучше по всем перечисленным вами параметрам.
- кастомизацию стало делать проще, т.к. архитектурно продукт теперь гораздо больше выверен, с точки зрения изоляции функций облака в пределах выделенных сервисов и большего количества точек для интеграции. То, для чего раньше приходилось патчить код глубоко внутри, сейчас в подавляющем большинстве случаев достижимо через плагины. Дьявол, разумеется, в деталях.
- компонентов, если речь идет о высокоуровневых подсистемах, таких как Keystone или Glance, стало больше, каждый из них несет свой набор функций. Но, по-прежнему, для минимально работоспособного облака вам будет достаточно набора из Keystone, Nova, Glance и Neutron (консерваторы могут ограничиться nova-network, да, оно еще поддерживается). Каждая из подсистем по-прежнему имеет свой набор сервисов, вынесенных в отдельные процессы, каждый выполняет отдельно выделенную функцию. В указанном минимальном наборе у вас будет крутиться 9 сервисов на контроллере (+инфраструктура: БД, RabbitMQ и т.д. ) и 3 на compute ноде. Подобный подход к архитектуре может быть не слишком удобен на небольших инсталляциях, но позволяет достаточно гибко масштабировать систему в долгосрочной перспективе.
- надежней OpenStack стал. Не в последнюю очередь благодаря развитию обширной инфраструктуры функциональных и нагрузочных тестов. Ну и усилиями вендоров, разумеется. Да, проблемы случаются, но зачастую они связаны с неправильным проектированием конкретного облака.
- документация OpenStack всегда находится в положении догоняющего, это факт. Тем не менее ответ на большее число простых вопросов она способна дать. Конкретно вашу проблему можно решить просто через т.н. provider networks либо через DVR.
Если вам действительно интересно, могу рассказать больше.
divanikus Автор
14.08.2017 18:19О, я уверен что он стал лучше, особенно после таких событий:
— HP: OpenStack's networking nightmare Neutron 'was everyone's fault'
— OpenStack’s Dirty Little Secret: It Doesn’t Scale
Сейчас у меня 90+ узлов в моем облаке Opennebula и возвращаться к этому монстру желания нет никакого.
Я по-прежнему считаю что OpenStack переусложнен. Если вы считаете что он не подходит для малых инсталляций, так перестаньте писать статьи о том «как круто я его развернул на 2 машины».
Openstack is a large collection of complicated projects that join together to form a hard to deploy and harder to run distributed system.
~ 1200 ansible tasks to do a simple openstack installjust_wow
14.08.2017 19:08+2Все так, Neutron в своей изначальной инкарнации был большой болью для разработчиков и операторов. После волны фрустраций коммьюнити конкретно за него взялось и смогло привести в состояние, пригодное для работы в сравнительно большом продакшене. Тому есть подтверждение, где-то с год назад мы проводили исследование его работоспособности (~200-250 нод) и даже выкладывали результаты в блог. Все это давно уже история, не вижу смысла тратить на это время.
Можно только порадоваться за вас, что скромные возможности OpenNebula полностью удовлетворяют потребности вашей компании. Тем не менее и для того "монстра" как OpenStack есть свой потребитель, и это как верно подметили ниже крупные ИТ и Телко компании, которым всегда нужно "чуточку больше". Более того, они инвестируют миллионы в развитие внутренней OpenStack экосистемы и инструментария управления жизненным циклом облака, просто потому что это позволяет в долгосрочной перспективе сэкономить десятки миллионов.
Претензию по поводу статей "как я развернул на 2 машины" лучше отправить их авторам. Лично я ничего плохого не вижу в том, что кому-то интересно поделиться своим опытом.
bblrlo
14.08.2017 12:37за 6 лет так и не запилили возможность установки из iso без танцев с бубном.
а обновления это вообще что-то из невозможного.
Кучаговнаипалок одним словом.just_wow
14.08.2017 16:52Это не есть правда. Например Mirantis Fuel начиная с 7 версии вполне способен развернуть production-ready облако на 50 и более машин. И таки да, из ISO. Он же решает проблему обновлений в пределах релиза.
Полностью избавиться от танцев с бубном, конечно, не получится, все-равно найдутся отдельные взятые клиенты у которых "не взлетает" из-за кривой конфигурации сети или экзотического RAIDа, но в общем случае юзабилити OpenStack за последние годы поднялся на более-менее адекватный уровень, не в последнюю очередь стараниями вендоров.
bblrlo
14.08.2017 16:58-1Я не говорю про деплой хоста из iso, а про деплой ВМ из iso.
Fuel еще более «кривой» продукт, шаг в сторону и при обновлении теряешь весь свой ENV со всеми данными, а уж как он хорошо обновляет ceph ноды…
там еще есть очень интересные места в коде типа dd if=/dev/zero of=/dev/{device} причем без разбора, нужен тебе диск или нет.just_wow
14.08.2017 17:36+1Ну, поддержка ISO в OpenStack появилась, если не изменяет память, еще в Juno 3 года назад. В чем заключались ваши танцы с бубном, извините, не могу знать, допускаю что это ваш конкретный corner case.
Про недостатки и достоинства Fuel можно долго разговаривать, продукт прошел большой путь и в целом, нашел своего пользователя. В последнем 9 релизе его сильно переделали, тем не менее на этом его разработка прекращается, и остается только поддержка.
raskal
15.08.2017 00:14Вы не договариваете. Там dd if=dev/zero of=/dev/{device} bs=1M count=1. Не то, чтобы я как бывший разработчик защищал свое детище или мне сильно нравилась идея затирать диски таким образом, но надо быть чуть более честным :)
Меж тем, Fuel-а больше нет, так что все это уже неважно.
nikitasius
14.08.2017 01:33Если кто хочет потыкать в openstack — у OVH public cloud работает на нем. То бишь — если надо что-то
быстротонко сделать, то это не api ovh или вебморда, а nova & neutron.
Мне лично очень нравится управлять виртуалками, сетью и подсетями через него.
mrobespierre
14.08.2017 02:32+3Все кому не лень пропагандируют OpenStack
это не пропаганда, это маркетинг, оплаченный вендорами, предоставляющими поддержку
OpenNebula
happy end, хоть и сложным путём
onegreyonewhite
14.08.2017 03:45+3После записи
Сервисов типа S3 или Glacier нет, но ничто не мешает вам развернуть тот же ceph и использовать его S3-совместимый API.
решил почитать про OpenNebula.
Мне тогда не совсем понятно, почему автор сравнивает OpenStack «в полном обмундировании» с OpenNebula — у последней конечно же будет меньше сервисов за счёт функционала.
Автор просто выбрал изначально неподходящий под свои задачи продукт и винит в этом сам продукт.
Отличное сравнение привёл fessoga5 с BMW, но я дополню: когда берёшь такой автомобиль, то ты ничего не хочешь в нём менять — ты хочешь ездить с комфортом. Ты приезжаешь в сервис для ремонта и тех.обслуживания. В BMW конечно можно воткнуть японский двигатель, но это будет форменным извращением, ну и возиться потом со всей электроникой не хочется. Зато Лада…
Он чересчур комплексный
Вы в курсе, что можно ставить только то, что нужно, а не всё сразу? Это конструктор.
Спасибо, OpenStack, благодаря тебе я возненавидел Python и все что с ним связано.
А это прям вообще странно! Какая связь? Это всё равно что сказать «ненавижу животных, потому что я однажды обнял ёжика и он меня уколол».
Он ломается. От релиза к релизу.
Вспоминаю как мои коллеги в офисе обновлялись с Ubuntu 14.04 на 16.04 — они обычно не матерятся…
А переход с CentOS 6 на 7 так вообще расстройство — целую тучу скриптов пришлось переписывать.
На то он и релиз, что отличается от предыдущих (минорные релизы не в счёт).
Лучше даже на всякий случай хосты не перезагружать, а то вдруг оно больше не поднимется?
Блин, да как вы вообще так его поднимаете/настраиваете?!
У нас на тестовом облаке, которое работает в офисе одна беда — электричество. Его просто выключают когда вздумается. ИБП хватает, но не надолго. Поэтому частые перезагрузки хоста для нас простые будни. За всё время ни разу не было проблем после перезагрузки. Это уже второе «облако» и у него всё в порядке.
Коллеги из США тоже никогда с такой проблемой не сталкиваются. Может вы просто на почве гнева начинаете искать проблемы, вместо того чтобы найти свои ошибки?
Т.е. ну вот вы наконец-то запилили инфраструктуру своей мечты, все худо-бедно работает как рассчитывали, но не хватает одной мааааленькой детали. А в новом релизе она есть. Ну по крайней мере по Release Notes.
Окей гугл, давай обновим наш OpenStack. И тут выясняется, что функционал, который вы с радостью использовали — выпилили.
«Херак-херак и в продакшн» — а потом OpenStack виноват, что вы сначала обновляетесь, а потому думаете.
С таким подходом вас вообще нельзя допускать к «боевым» серверам.
Вообще мне становится действительно грустно, когда я вижу на хабре подобные статьи с кучей плюсов. «Этот продукт плохой, потому что я сначала делаю, потом думаю/потому что я не умею выбирать продукт согласно своим нуждам/потому что мне он не нравится/потому что меня поцарапал кот...»
Картинка в тему
divanikus Автор
14.08.2017 14:24+4Ох, кажется у вас подгорело, вплоть до обвинений в профнепригодности. Тушите, тушите срочно!
Мне тогда не совсем понятно, почему автор сравнивает OpenStack «в полном обмундировании» с OpenNebula — у последней конечно же будет меньше сервисов за счёт функционала.
Во-первых, не сравнивает. Небула упоминается в конце статьи. Во-вторых, вы вероятно не часто смотрите в ps, сколько демонов опенстека поднимается на контроллер ноде? Даже банально если это nova, glance, keystone и horizon. Сколько демонов опенстека поднимается на компьют ноде? Сколько зависимостей они за собой тащат?
Автор просто выбрал изначально неподходящий под свои задачи продукт и винит в этом сам продукт.
Задача стояла простая — горизонтально масштабируемое облако на своем железе. С автоматическим расширением кластеров при нехватке ресурсов. В процессе выяснилось что нужно зонирование по типам железных узлов. Вот скажите, разрекламированный OpenStack разве не подходит под эту задачу? Как это можно было понять заранее? Он обещает ровно то, что нужно было для этой задачи. То что он не пришел к успеху в нашем случае, ну не фартануло значит.
Отличное сравнение привёл fessoga5 с BMW, но я дополню: когда берёшь такой автомобиль, то ты ничего не хочешь в нём менять — ты хочешь ездить с комфортом. Ты приезжаешь в сервис для ремонта и тех.обслуживания.
Очень смешная аналогия, жалко далека от реальной жизни. Тракторы, машинки, нам бы знаете чтоб работало. Вы видимо предлагаете ваши услуги купить в качестве сервисмэна?
Вы в курсе, что можно ставить только то, что нужно, а не всё сразу?
Вы в курсе, что можно читать статью целиком, а не по диагонали? Вообще я имею ввиду, что любое даже простецкое действие в OpenStack вырождается в service, api, scheduler, agent демоны. Нам же не надо по-простому, нам надо модульно. Больше модулей богу модулей.
А это прям вообще странно! Какая связь?
Копался в большом количестве питон-кода — невзлюбил питон. По-моему логично.
Вспоминаю как мои коллеги в офисе обновлялись с Ubuntu 14.04 на 16.04 — они обычно не матерятся…
А переход с CentOS 6 на 7 так вообще расстройство — целую тучу скриптов пришлось переписывать.
На то он и релиз, что отличается от предыдущих (минорные релизы не в счёт).
Расскажите своим коллегам о Debian уже. Обновлял lenny до wheezy, ни разу не матернулся. И получилось почему-то за полчаса. Может кто-то просто релизы готовить не умеет?
«Херак-херак и в продакшн» — а потом OpenStack виноват, что вы сначала обновляетесь, а потому думаете.
С таким подходом вас вообще нельзя допускать к «боевым» серверам.
Додумал сам то, что не написано. Молодцом. С другой стороны, почему я без проблем за вечер обновляю Opennebula, только почитав Release Notes и Breaking Changes. Мистика какая-то.
Вообще мне становится действительно грустно, когда я вижу на хабре подобные статьи с кучей плюсов.
А мне действительно грустно, что не самое лучшее решение пользуется таким лютым хайпом везде. И новые люди без раздумий вливаются в этот движняк, колются, но продолжают жрать кактус — это ведь популярная вещь, значит так и должно быть.SirEdvin
14.08.2017 14:45+1Додумал сам то, что не написано. Молодцом. С другой стороны, почему я без проблем за вечер обновляю Opennebula, только почитав Release Notes и Breaking Changes. Мистика какая-то.
А в вашем примере, тот путь, который вы пользовались выпилили в новом релизе просто так? Ну и да, один раз в код и палка стреяет, накатывать новый релиз без теста сразу на прод обычно довольно опасно, в любом случае)
Вы в курсе, что можно читать статью целиком, а не по диагонали? Вообще я имею ввиду, что любое даже простецкое действие в OpenStack вырождается в service, api, scheduler, agent демоны. Нам же не надо по-простому, нам надо модульно. Больше модулей богу модулей.
А по простому это как, подскажите?
Задача стояла простая — горизонтально масштабируемое облако на своем железе. С автоматическим расширением кластеров при нехватке ресурсов. В процессе выяснилось что нужно зонирование по типам железных узлов. Вот скажите, разрекламированный OpenStack разве не подходит под эту задачу? Как это можно было понять заранее? Он обещает ровно то, что нужно было для этой задачи. То что он не пришел к успеху в нашем случае, ну не фартануло значит.
Облако или просто кластер, например, на докерах?)
divanikus Автор
14.08.2017 14:58А в вашем примере, тот путь, который вы пользовались выпилили в новом релизе просто так? Ну и да, один раз в код и палка стреяет, накатывать новый релиз без теста сразу на прод обычно довольно опасно, в любом случае)
Я же пояснил, это была часть функционала nova, которую решили вынести в отдельный модуль, но при этом не озаботились обратной совместимостью. Сделали упрощенную схему, а нужный мне функционал висел в качестве wishlist с одним разрабом, который вроде как что-то пытался на эту тему сделать. Я следил за этой темой с полгода, даже кажется в переписку вступал. У меня совершенно нет уверенности в том, что завтра это же не сделают с чем-то еще.
А по простому это как, подскажите?
Опять же мой пример. Надо было мне динамический DNS, чтобы при создании инстанса он автоматом появлялся в назначенной зоне и разрабы сразу же могли с ним работать. Designate в тот момент не существовало. Сначала я попытался сделать хак для nova-compute. Работало ненадежно. Потом наткнулся на проект Moniker, который кстати потом и стал Designate. Даже делал пару контрибьюшенов в этот проект. Сейчас он вроде бы еще бОльшим монстром стал, чем был.
Как я решил эту проблему в Небуле? Добавил два хука — на создание виртуалки и на удаление. Хук — скрипт на руби, который правит зону и просит bind перезагрузить ее. Все. На решение ушел один вечер времени. Работает стабильно уже 3 года, пережил мажорное обновление Небулы без правок.
Облако или просто кластер, например, на докерах?)
Очень смешно. Про докер в то время знал примерно никто. Да и LXC стала взрослой технологией годами позже. Все тогда по OpenVZ еще угорали.SirEdvin
14.08.2017 15:03+1Как я решил эту проблему в Небуле? Добавил два хука — на создание виртуалки и на удаление. Хук — скрипт на руби, который правит зону и просит bind перезагрузить ее. Все. На решение ушел один вечер времени. Работает стабильно уже 3 года, пережил мажорное обновление Небулы без правок.
Ну, то есть по старой системе — наделали своих палок с костылями и прочим. Хуки не очень надежное и прозрачное решение и их так же иногда надо поддерживать.
Пока вы тут, вы помните про хуки, а потом кто-то другой может и забыть и все пойдет по накатной.divanikus Автор
14.08.2017 15:06Конечно сильно удобнее на любую мелкую кастомизацию делать 10 новых демонов. И поддерживать.
SirEdvin
14.08.2017 15:06Очень странно, что это не укладывается в один демон? С чем это связано, не подскажите?
divanikus Автор
14.08.2017 15:08Спросите у архитекторов OpenStack.
SirEdvin
14.08.2017 15:11Ну, кастомизацию же вы делали? Почему у вас не получалось конкретно сделать один демон, которые бы опрашивал часть системы о необходимых изменениях и если что-то случилось, при помощи API делал бы нужные вещи с другой частью системы?
Проблемы с API?divanikus Автор
14.08.2017 15:17Ну вы плохо прочитали? Получилось же, Designate теперь называется. Но это не один демон.
А так, какого черта я вообще должен писать демон просто для того, чтобы как-то ловить события OpenStack?SirEdvin
14.08.2017 16:10+1Потому что (исключительное ИЛИ):
- Вы не освоили вот это.
- Его не было в нужное время
- Злой разработчик забыл нужное вам событие.
Ну и то, что у них это получился не один демон не означает, что вам не хватило бы одного.
divanikus Автор
14.08.2017 16:24Ну вы сами ответили на свой вопрос. Monasca появился в середине 2014, к тому моменту, когда мы уже ушли с OpenStack. Ну и не могу не отметить, что это опять усложнение за счет еще одного десятка модулей.
SirEdvin
14.08.2017 16:37Усложние нужно, что бы быть сильно кастомизируемым. Если Вам не нужна такая гибкость, то вам нужен другой продукт.
Простите, но мне это в целом было очевидно после минут 5 чтения документации. Возможно, я не прав, но Вам уже указали, что OpenStack и тогда был сильным overhead для вашей задачи.divanikus Автор
14.08.2017 16:47Откуда вам известно о том какова была моя задача и что OpenStack именно для нее избыточен? Изначально была мысль поставить его на промышленный кластер с 100+ машинами.
Иногда переусложнение не только хорошо, но и плохо.SirEdvin
14.08.2017 16:54+1Дело в не масштабах, дело в гибкости. В данном случае гибкость порожает переусложнение, если вам не нужна данная гибкость, значить OpenStack вам не не подходит.
Это все равно, что обустроить гиганскую кухню, как для большого рестора и готовить там галлонами борщи. Вам не нужно больше 70% фунционала этой кухни, так зачем она вам вообще?
А тем, кому нужна, он отлично подходит, потому что поднимать кучу своих костылей на другой платформе им не очень улыбается.
kvaps
14.08.2017 17:08+1Пока вы тут, вы помните про хуки, а потом кто-то другой может и забыть и все пойдет по накатной.
Все хуки централизованно декларируются в конфиге, про них невозможно забыть, т.к. при обновлении вы всегда будете видеть их в diff.
Кроме того, вся архитекура OpenNebula представляет ссобой не что иное, как систему вызова хуков. (если можно так выразиться).
У вас есть директория со скриптами называемая драйвером, в которой лежат скрипты для каждого действия, будь то storage-драйвер или compute-драйвер.
Вот например драйвер kvm, а вот драйвер ceph. При каждом действии вызывается соответсвующий скрипт. Просто, не правда ли?
В случае когда обычных хуков вам не хватает, ничто не мешает вам сделать свой собственный драйвер на тот или иной случай. Таким образом переопределить логику какого-либо действия крайне просто. А все изменения можно хранить в git и не опасаться что что-то куда-то потеряется.
PS: Я не критикую OpenStack я просто хочу больше рассказать про архитектуру OpenNebula.
celebrate
14.08.2017 04:59+2Офигеть, реально, 2017 год и релиз Essex… вы специально ждали три года, чтобы написать статью? Давайте тогда уж статью про то, какое кривое и бажное ядро линукс 2.4…
Если вам нужен свой локальный DigitalOcean без всяких наворотов, то Опенстек явно не ваш выбор.
Единственное, чего в Опенстеке по-настоящему не хватает — это аналога вмварного DRS. Мне пришлось его написать самому.
shurup
14.08.2017 06:24Будь это всё прямо-таки правдой, не было бы огромных production-инсталляций на OpenStack у многих крупных ИТ-игроков, которые они поддерживают и развивают вот уже много лет (да и не только крупных — см. последний отчёт; при желании можно найти и какое-то «независимое» исследование по теме). В нынешних реалиях прослеживается ещё и интересный (и, что главное, рабочий!) тренд на комбинацию OpenStack с Kubernetes (недавно писал про eBay и SAP).
Продукты уровня OpenStack, конечно, могут быть далеки от идеала, но подобные посты ненависти, как уже многократно подтвердили в комментариях выше, будут всегда больше связаны с их неправильным применением (просто не для тих задач/масштабов или с недостаточным пониманием, как делать правильно в данном конкретном случае). Они (эти посты), конечно, могут пригодиться и другим потенциальным пользователям, но только при условии, что будут отброшены эмоции (не должны превалировать над технической частью, создавая ложное впечатление о сути) и по-настоящему хорошо описаны все детали, зачем, как и что из всего этого использовалось (сделаны соответствующие выводы, а в идеале — подтверждены другими специалистами, которые могут знать больше или банально увидеть что-то со стороны).
acmnu
14.08.2017 10:01+1Не совсем верно. Я работал в Мирантис и могу точно сказать, что статья справедлива. По этой причине собственно и появился MCP, который к OpenStack имеет весьма отдалённое отношение.
shurup
14.08.2017 12:32Но OpenStack продолжает жить и без Mirantis или вы хотите присоединиться к набирающему популярность мнению, что дни его сочтены? Могут ли быть сочтены, если так и не видно ему замены для тех самых крупных игроков?
o_serega
14.08.2017 13:40+1А откуда взяться замене, если в свое время, благодаря активной агитации, максимум ресурсов было втянуто в разработку openstack.) Да есть opennebula и cloudstack, но они явно не конкуренты опенстеку, там где он реально нужен со всем его функционалом
acmnu
14.08.2017 14:08Никто не знает что произойдет. Мирантис был оснвым поставщиком денег сообществу: половина PTL была устроена именно в Мирантис. Сейчас часть из них ушла в RH, но большинство ушли в другие сферы. Потянет RH в одно лицо не известно, а новых игроков не видно.
just_wow
14.08.2017 16:43+1По этой причине собственно и появился MCP, который к OpenStack имеет весьма отдалённое отношение.
Вот ведь как. "А мужики и не знают..." Главное и непосредственное предназначение Mirantis Cloud Platform — обеспечение непрерывного цикла развертывания и управления enterprise-grade облаком. Это задача с которой, увы, так не смог (или не успел, если угодно) справиться Mirantis Fuel.
Все претензии изложенные в статье справедливы, но лишь отчасти и с точки зрения админа, которому начальство выделило пяток серверов и приказало "сделай облако". Инструменты нужно подбирать соответственно целям. Нужно что-то действительно простое, по функциям, архитектуре и внедрению? Берите ту же OpenNebula и не морочьте голову ни себе ни людям.
divanikus Автор
14.08.2017 16:49-1с точки зрения админа, которому начальство выделило пяток серверов и приказало «сделай облако». Инструменты нужно подбирать соответственно целям.
Именно поэтому ваши коллеги по защите данного продукта тоннами пишут статьи как поставить OpenStack на 2 машины и чтоб было хорошо.just_wow
14.08.2017 18:38+2Вы так говорите, как будто это что-то плохое. Люди пробуют пробуют, разбираются, зачастую успешно, описывают свой опыт. Почему нет? У каждого свои задачи, которые он волен решать так как считает нужным. Я лично не вижу смысла тащить OpenStack туда, где справится что-то более простое.
divanikus Автор
14.08.2017 18:42-2Это создает ложное впечатление о продукте, а потом автор приходит под такой пост и кичиться тем, что вы просто лошары и не осилили.
bblrlo
14.08.2017 21:24к сожалению это просто пиар, который далек от реальности. Год назад внедряли при помощи не безызвестного интегратора(3.14стец какого хренового, как оказалось). Как итог все работает более менее предсказуемо на меленьких окружениях, но стоит увеличить количество хостов>50 или виртуалок за 3к, так начинается всплытие всей багодельни. Я тоже после работы с опенстаком стал ненавидеть питон, потому что его в опенстаке его пихают куда нужно и куда не нужно, потому что слово модное.
shurup
15.08.2017 09:41Что именно «просто пиар» и «далеко от реальности» — что могут быть крупные и рабочие инсталляции у OpenStack в production? Могут, есть факты (приводил выше ссылку на статью про OpenStack+Kubernetes в eBay, где облако обслуживает 160+ тысяч виртуалок, что значительно больше вашего примера). Какими трудами это даётся, тут уже более интересный и сложный вопрос, конечно, но его правильно рассматривать с учётом имеющихся альтернатив, а не абстрактно.
bblrlo
15.08.2017 10:22в этом и заключается «пиар», т.к. в таких средах от родного Опенстака мало что остается, но почему-то считается установкой.
HEKOT
14.08.2017 08:33+3Вы наверняка слышали об Open{$whatEverYouWant}. Блин, да о нем говорят на каждом более-менее связанном мероприятии. Все кому не лень пропагандируют Open{$whatEverYouWant}. Модно, молодежно, все уже есть, Open Source, вливайся давай. И вот наслушавшись тонны маркетингового булшита, вы решаетесь: Будем ставить Open{$whatEverYouWant}!
Я не проводил специальных изысканий на этот счет, но отрицательных отзывов о нем вроде бы не так много, по крайней мере на русском. На первый взгляд все выглядит просто фантастически. Что ж, извольте представить мой личный пост ненависти к Open{$whatEverYouWant}.
…
mikkisse
14.08.2017 09:10С месяц назад решил собрать в лабе RDO. Процесс сборки и инсталляции облака был похож на мазохизм, но зато какое облегчение и чувство выполненного долга, когда ты запускаешь первую виртуальную машину и она работает. Словами не передать.
serg_p
14.08.2017 13:16Статья понравилась. Отлично понимаю о чём. Все проблемы из Unix_Linux Философии. Одна программа- одна задача = непродуманность сборной архитектуры. Отсюда огромный комплекс невскрытых и не описанных зависимостей.
pl239
14.08.2017 15:02В жанре как у меня не хватило … поднять облако.
Когда я начал читать статью подумал что она писалась в 2014 году (с того времени все изменилось).
Схема архитектуры Openstack вброшена так чтобы напугать читателя (реально используется только половина модулей), их не обязательно ставить.
По availability zones — решается элементарно правильным выставлением метаданных, просто автор не разобрался.
Обновления нужно делать строго по мануалам, и перед этим вычистить логи от устаревших настроек (если такие имеются). То что автор все обновлял интуитивно не означает что он прав. Тогда гости даже и не заметят что были какие то действия.
Я думаю автор просто не разобрался и с горя пишет подобные тексты.divanikus Автор
14.08.2017 15:03+2Афтар разобрался, просто availability zones был not implemented. В коде. В доке было все ок. И со многим другим афтар разобрался, иначе как его облако проработало 1.5 года? Только вот сил дальше терпеть не было.
iit
15.08.2017 07:05+1И вот молодой студент в развивающимся стартапе купил себе на аукционе тазик-сервачек от hetzner для того чтобы держать там свои проекты типа диплома. И понял он что машинка с 8-ю ядрами и 32гб RAM мягко говоря много для сервера для сайтов. Решил попробовать виртуализацию и попробовал поставить на него OpenStack.
3 месяца ковыряния его, чтение их толстенного гайда которому нельзя верить вплоть до того что даже примеры не работают, проблемы с neutron, постоянно глючащий и отваливающийся horizon и прочие танцы с бубном были обеспечены. В общем хлебнув горя студент решил плюнуть на опенСрак и попробовать альтернативы. openCloud в отличии от openStack вообще не поднялся — от слова совсем. поставил openNebulа — а для нее нужна сетевая шара которая постоянно отваливалась.
студент не стал выпендриваться и накатил старый добрый proxMox куда запилил kvm и было ему счастье.
Сервер работает уже 5 лет и помимо всяких "дипломных проектов" своих и брата, локального gitlab и ownCloud для обоих. Пару лет на нем поднялся openVpn и в отдельной сети пара-тройка сайтов для жены и тещи.
Итоги
proxMox — если в одинокий разраб или небольшая конторка и вам нужно несколько виртуалочек с php / node.js + mysql/postgres
openCloud/openNebula — если вы контора побольше и у вы готовы уделить пару часов в день вашего админа для его обслуживания.
openStack — если у вас куда больше 20 серверов и 10-и админов и вы готовы взять себе еще столько же админов/разрабов чтобы они решали его проблемы либо купить услуги конторы что приготовит его для вас.
kvaps
15.08.2017 10:40Неправильно рассуждаете, Proxmox и OpenNebula/OpenStack — это две совершенно разные вещи, хоть и используют один и тот же гипервизор.
Proxmox — это infrastructure virtualization, то есть если вы хотите просто поделить ваши bare-metal сервера на много виртуалок со всеми вытекающими: отказоустойчивость, бэкапы, kvm-консоль и т.д., но при этом работать с ними точно так же как и работали бы с обычными серверами (например подключить cd-rom и установить систему), если жизнь виртуалок для вас критична и сменяются они довольно редко, то это решение подойдет вам как нельзя лучше других.
OpenNebula/OpenStack — это уже cloud platform, а значит здесь вас ждут темплейты, виртуальные сети и автоматически скалируемые сервисы. В пару кликов вы можете создать или удалить сразу 100 однотипных виртуалок, вы можете передавать виртуалкам параметры, к которым можно получить доступ изнутри. Бывает, что жизненное состояние виртуальной машины здесь может быть вовсе не важно. А еще у этого всего есть API, так что таким облаком можете пользоваться даже не обязательно вы, но например ваше приложение, которое будет автоматически создавать в нем виртуалки и исполнять в них какой-то код.
o_serega
Два чаю господину!