Комментарии 94
Прям 1С какой-то.
Вы сделали правильный выбор, OpenNebula — отличное облако с предельно простой и в тоже время хорошо продуманной архитектурой.
Довольно минималистичное и в тоже время очень мощное решение, а главное, что оно очень просто кастомизируется и дополняется.
В последнем релизе (5.4) запилили простую настройку федераций и отказоустойчивых кластеров (для бэкенда), теперь не нужно заморачиваться с долгой настройкой и репликацией на уровне бд.
Присоединяйтесь!
А подскажите, я правильно понимаю, что OpenNebula — это такой аналог AWS для себя? То есть, такая скалируемая штука с виртуалочками и API + куча разных полезных сервисов, типо S3 и так далее?
В целом да, но не совсем.
OpenNebula предоставляет вам единый интерфейс с виртуалками, виртуальными сетями, датасторами и темплейтами.
Вы можете строить из этого всего скалируемые сервисы, есть aws-совместимый API.
Сервисов типа S3 или Glacier нет, но ничто не мешает вам развернуть тот же ceph и использовать его S3-совместимый API.
напишите в комментариях о том какой я м***к и ничего не понял, но в целом не думаю, что ситуация кардинально поменялась.
У меня всегда следующая аналогия:
У BMW 7 серии, кроме кучи ништяков, есть задние колеса, которые подруливают вместе с передними. Это сложно, модульно, много электроники, не надежно, а если сломается то сложно починить. Но тем не менее это существует и работает. И стоит это кучи денег, все это похоже на RedHat Openstack.
В ситуации с ванильным OS, тебе дают схемы и софт\часть софта, чтобы ты сделал свой BMW 7, дешево и сложно, но оно того стоит, если оно тебе нужно.
А если тебе нужен трактор, который едет на всем, не имеет подвески и не ломается, то конечно, проходим мимо.
Ну, как бы да. Это выбор между тем, что бы использовать клалифицированную помочь или сделать все самому. Я не совсем понимаю, как вы представляете сложные комплексные системы без такого вот vendor lock-in?
Видимо, разобравшись, стать вендором самому.
Ну, во-первых, существенное отличие в том, что эта вся штука находится у вас. И второе главное отличие — это не lock-in, так как у вас есть возможность все это настроить самому и поддерживать это решение. Вам не продают черную закрытую коробку.
Но это сложно. И по другому не получится, потому что иначе никто бы не платил за другие облака.
То есть никто не предлагает в аренду спецов, которые могут настроить OpenStack на Debian или Ubuntu? Не RadHat'ом же единым.
Тот человек да, а я вот нет. Вот есть сертификации openstack: https://www.openstack.org/coa/, она вроде не привязана прямо к RHEL.
del
В общем, в 2012-м мы развернули OpenStack, на тот момент это был Essex, запустили проект, прожили с такой облачной инфраструктурой до 2014-го года, кажется до релиза Grizzly включительно. Сил и желания поддерживать его дальше не было, и OpenStack был с позором выпилен.
Вы бы еще про Cactus релиз написали. В 2017 году, ага. Во-первых, с тех пор OpenStack стал сильно лучше (но все еще не идеал, конечно). Во-вторых, вне зависимости от релиза, OpenStack надо уметь готовить — это я вам говорю с высоты 6 лет опыта, ~20 проектов разного масштаба и назначения и просто консультаций без числа.
Если отбросить сарказм, то продукт действительно стал лучше по всем перечисленным вами параметрам.
- кастомизацию стало делать проще, т.к. архитектурно продукт теперь гораздо больше выверен, с точки зрения изоляции функций облака в пределах выделенных сервисов и большего количества точек для интеграции. То, для чего раньше приходилось патчить код глубоко внутри, сейчас в подавляющем большинстве случаев достижимо через плагины. Дьявол, разумеется, в деталях.
- компонентов, если речь идет о высокоуровневых подсистемах, таких как Keystone или Glance, стало больше, каждый из них несет свой набор функций. Но, по-прежнему, для минимально работоспособного облака вам будет достаточно набора из Keystone, Nova, Glance и Neutron (консерваторы могут ограничиться nova-network, да, оно еще поддерживается). Каждая из подсистем по-прежнему имеет свой набор сервисов, вынесенных в отдельные процессы, каждый выполняет отдельно выделенную функцию. В указанном минимальном наборе у вас будет крутиться 9 сервисов на контроллере (+инфраструктура: БД, RabbitMQ и т.д. ) и 3 на compute ноде. Подобный подход к архитектуре может быть не слишком удобен на небольших инсталляциях, но позволяет достаточно гибко масштабировать систему в долгосрочной перспективе.
- надежней OpenStack стал. Не в последнюю очередь благодаря развитию обширной инфраструктуры функциональных и нагрузочных тестов. Ну и усилиями вендоров, разумеется. Да, проблемы случаются, но зачастую они связаны с неправильным проектированием конкретного облака.
- документация OpenStack всегда находится в положении догоняющего, это факт. Тем не менее ответ на большее число простых вопросов она способна дать. Конкретно вашу проблему можно решить просто через т.н. provider networks либо через DVR.
Если вам действительно интересно, могу рассказать больше.
— 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 install
Все так, Neutron в своей изначальной инкарнации был большой болью для разработчиков и операторов. После волны фрустраций коммьюнити конкретно за него взялось и смогло привести в состояние, пригодное для работы в сравнительно большом продакшене. Тому есть подтверждение, где-то с год назад мы проводили исследование его работоспособности (~200-250 нод) и даже выкладывали результаты в блог. Все это давно уже история, не вижу смысла тратить на это время.
Можно только порадоваться за вас, что скромные возможности OpenNebula полностью удовлетворяют потребности вашей компании. Тем не менее и для того "монстра" как OpenStack есть свой потребитель, и это как верно подметили ниже крупные ИТ и Телко компании, которым всегда нужно "чуточку больше". Более того, они инвестируют миллионы в развитие внутренней OpenStack экосистемы и инструментария управления жизненным циклом облака, просто потому что это позволяет в долгосрочной перспективе сэкономить десятки миллионов.
Претензию по поводу статей "как я развернул на 2 машины" лучше отправить их авторам. Лично я ничего плохого не вижу в том, что кому-то интересно поделиться своим опытом.
а обновления это вообще что-то из невозможного.
Кучаговнаипалок одним словом.
Это не есть правда. Например Mirantis Fuel начиная с 7 версии вполне способен развернуть production-ready облако на 50 и более машин. И таки да, из ISO. Он же решает проблему обновлений в пределах релиза.
Полностью избавиться от танцев с бубном, конечно, не получится, все-равно найдутся отдельные взятые клиенты у которых "не взлетает" из-за кривой конфигурации сети или экзотического RAIDа, но в общем случае юзабилити OpenStack за последние годы поднялся на более-менее адекватный уровень, не в последнюю очередь стараниями вендоров.
Fuel еще более «кривой» продукт, шаг в сторону и при обновлении теряешь весь свой ENV со всеми данными, а уж как он хорошо обновляет ceph ноды…
там еще есть очень интересные места в коде типа dd if=/dev/zero of=/dev/{device} причем без разбора, нужен тебе диск или нет.
Ну, поддержка ISO в OpenStack появилась, если не изменяет память, еще в Juno 3 года назад. В чем заключались ваши танцы с бубном, извините, не могу знать, допускаю что это ваш конкретный corner case.
Про недостатки и достоинства Fuel можно долго разговаривать, продукт прошел большой путь и в целом, нашел своего пользователя. В последнем 9 релизе его сильно переделали, тем не менее на этом его разработка прекращается, и остается только поддержка.
Меж тем, Fuel-а больше нет, так что все это уже неважно.
Если кто хочет потыкать в openstack — у OVH public cloud работает на нем. То бишь — если надо что-то быстро тонко сделать, то это не api ovh или вебморда, а nova & neutron.
Мне лично очень нравится управлять виртуалками, сетью и подсетями через него.
Все кому не лень пропагандируют OpenStack
это не пропаганда, это маркетинг, оплаченный вендорами, предоставляющими поддержку
OpenNebula
happy end, хоть и сложным путём
Сервисов типа 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 виноват, что вы сначала обновляетесь, а потому думаете.
С таким подходом вас вообще нельзя допускать к «боевым» серверам.
Вообще мне становится действительно грустно, когда я вижу на хабре подобные статьи с кучей плюсов. «Этот продукт плохой, потому что я сначала делаю, потом думаю/потому что я не умею выбирать продукт согласно своим нуждам/потому что мне он не нравится/потому что меня поцарапал кот...»
Мне тогда не совсем понятно, почему автор сравнивает 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. Мистика какая-то.
Вообще мне становится действительно грустно, когда я вижу на хабре подобные статьи с кучей плюсов.
А мне действительно грустно, что не самое лучшее решение пользуется таким лютым хайпом везде. И новые люди без раздумий вливаются в этот движняк, колются, но продолжают жрать кактус — это ведь популярная вещь, значит так и должно быть.
Додумал сам то, что не написано. Молодцом. С другой стороны, почему я без проблем за вечер обновляю Opennebula, только почитав Release Notes и Breaking Changes. Мистика какая-то.
А в вашем примере, тот путь, который вы пользовались выпилили в новом релизе просто так? Ну и да, один раз в код и палка стреяет, накатывать новый релиз без теста сразу на прод обычно довольно опасно, в любом случае)
Вы в курсе, что можно читать статью целиком, а не по диагонали? Вообще я имею ввиду, что любое даже простецкое действие в OpenStack вырождается в service, api, scheduler, agent демоны. Нам же не надо по-простому, нам надо модульно. Больше модулей богу модулей.
А по простому это как, подскажите?
Задача стояла простая — горизонтально масштабируемое облако на своем железе. С автоматическим расширением кластеров при нехватке ресурсов. В процессе выяснилось что нужно зонирование по типам железных узлов. Вот скажите, разрекламированный OpenStack разве не подходит под эту задачу? Как это можно было понять заранее? Он обещает ровно то, что нужно было для этой задачи. То что он не пришел к успеху в нашем случае, ну не фартануло значит.
Облако или просто кластер, например, на докерах?)
А в вашем примере, тот путь, который вы пользовались выпилили в новом релизе просто так? Ну и да, один раз в код и палка стреяет, накатывать новый релиз без теста сразу на прод обычно довольно опасно, в любом случае)
Я же пояснил, это была часть функционала nova, которую решили вынести в отдельный модуль, но при этом не озаботились обратной совместимостью. Сделали упрощенную схему, а нужный мне функционал висел в качестве wishlist с одним разрабом, который вроде как что-то пытался на эту тему сделать. Я следил за этой темой с полгода, даже кажется в переписку вступал. У меня совершенно нет уверенности в том, что завтра это же не сделают с чем-то еще.
А по простому это как, подскажите?
Опять же мой пример. Надо было мне динамический DNS, чтобы при создании инстанса он автоматом появлялся в назначенной зоне и разрабы сразу же могли с ним работать. Designate в тот момент не существовало. Сначала я попытался сделать хак для nova-compute. Работало ненадежно. Потом наткнулся на проект Moniker, который кстати потом и стал Designate. Даже делал пару контрибьюшенов в этот проект. Сейчас он вроде бы еще бОльшим монстром стал, чем был.
Как я решил эту проблему в Небуле? Добавил два хука — на создание виртуалки и на удаление. Хук — скрипт на руби, который правит зону и просит bind перезагрузить ее. Все. На решение ушел один вечер времени. Работает стабильно уже 3 года, пережил мажорное обновление Небулы без правок.
Облако или просто кластер, например, на докерах?)
Очень смешно. Про докер в то время знал примерно никто. Да и LXC стала взрослой технологией годами позже. Все тогда по OpenVZ еще угорали.
Как я решил эту проблему в Небуле? Добавил два хука — на создание виртуалки и на удаление. Хук — скрипт на руби, который правит зону и просит bind перезагрузить ее. Все. На решение ушел один вечер времени. Работает стабильно уже 3 года, пережил мажорное обновление Небулы без правок.
Ну, то есть по старой системе — наделали своих палок с костылями и прочим. Хуки не очень надежное и прозрачное решение и их так же иногда надо поддерживать.
Пока вы тут, вы помните про хуки, а потом кто-то другой может и забыть и все пойдет по накатной.
Очень странно, что это не укладывается в один демон? С чем это связано, не подскажите?
Ну, кастомизацию же вы делали? Почему у вас не получалось конкретно сделать один демон, которые бы опрашивал часть системы о необходимых изменениях и если что-то случилось, при помощи API делал бы нужные вещи с другой частью системы?
Проблемы с API?
А так, какого черта я вообще должен писать демон просто для того, чтобы как-то ловить события OpenStack?
Потому что (исключительное ИЛИ):
- Вы не освоили вот это.
- Его не было в нужное время
- Злой разработчик забыл нужное вам событие.
Ну и то, что у них это получился не один демон не означает, что вам не хватило бы одного.
Усложние нужно, что бы быть сильно кастомизируемым. Если Вам не нужна такая гибкость, то вам нужен другой продукт.
Простите, но мне это в целом было очевидно после минут 5 чтения документации. Возможно, я не прав, но Вам уже указали, что OpenStack и тогда был сильным overhead для вашей задачи.
Иногда переусложнение не только хорошо, но и плохо.
Дело в не масштабах, дело в гибкости. В данном случае гибкость порожает переусложнение, если вам не нужна данная гибкость, значить OpenStack вам не не подходит.
Это все равно, что обустроить гиганскую кухню, как для большого рестора и готовить там галлонами борщи. Вам не нужно больше 70% фунционала этой кухни, так зачем она вам вообще?
А тем, кому нужна, он отлично подходит, потому что поднимать кучу своих костылей на другой платформе им не очень улыбается.
Пока вы тут, вы помните про хуки, а потом кто-то другой может и забыть и все пойдет по накатной.
Все хуки централизованно декларируются в конфиге, про них невозможно забыть, т.к. при обновлении вы всегда будете видеть их в diff.
Кроме того, вся архитекура OpenNebula представляет ссобой не что иное, как систему вызова хуков. (если можно так выразиться).
У вас есть директория со скриптами называемая драйвером, в которой лежат скрипты для каждого действия, будь то storage-драйвер или compute-драйвер.
Вот например драйвер kvm, а вот драйвер ceph. При каждом действии вызывается соответсвующий скрипт. Просто, не правда ли?
В случае когда обычных хуков вам не хватает, ничто не мешает вам сделать свой собственный драйвер на тот или иной случай. Таким образом переопределить логику какого-либо действия крайне просто. А все изменения можно хранить в git и не опасаться что что-то куда-то потеряется.
PS: Я не критикую OpenStack я просто хочу больше рассказать про архитектуру OpenNebula.
Если вам нужен свой локальный DigitalOcean без всяких наворотов, то Опенстек явно не ваш выбор.
Единственное, чего в Опенстеке по-настоящему не хватает — это аналога вмварного DRS. Мне пришлось его написать самому.
Продукты уровня OpenStack, конечно, могут быть далеки от идеала, но подобные посты ненависти, как уже многократно подтвердили в комментариях выше, будут всегда больше связаны с их неправильным применением (просто не для тих задач/масштабов или с недостаточным пониманием, как делать правильно в данном конкретном случае). Они (эти посты), конечно, могут пригодиться и другим потенциальным пользователям, но только при условии, что будут отброшены эмоции (не должны превалировать над технической частью, создавая ложное впечатление о сути) и по-настоящему хорошо описаны все детали, зачем, как и что из всего этого использовалось (сделаны соответствующие выводы, а в идеале — подтверждены другими специалистами, которые могут знать больше или банально увидеть что-то со стороны).
Не совсем верно. Я работал в Мирантис и могу точно сказать, что статья справедлива. По этой причине собственно и появился MCP, который к OpenStack имеет весьма отдалённое отношение.
Никто не знает что произойдет. Мирантис был оснвым поставщиком денег сообществу: половина PTL была устроена именно в Мирантис. Сейчас часть из них ушла в RH, но большинство ушли в другие сферы. Потянет RH в одно лицо не известно, а новых игроков не видно.
По этой причине собственно и появился MCP, который к OpenStack имеет весьма отдалённое отношение.
Вот ведь как. "А мужики и не знают..." Главное и непосредственное предназначение Mirantis Cloud Platform — обеспечение непрерывного цикла развертывания и управления enterprise-grade облаком. Это задача с которой, увы, так не смог (или не успел, если угодно) справиться Mirantis Fuel.
Все претензии изложенные в статье справедливы, но лишь отчасти и с точки зрения админа, которому начальство выделило пяток серверов и приказало "сделай облако". Инструменты нужно подбирать соответственно целям. Нужно что-то действительно простое, по функциям, архитектуре и внедрению? Берите ту же OpenNebula и не морочьте голову ни себе ни людям.
с точки зрения админа, которому начальство выделило пяток серверов и приказало «сделай облако». Инструменты нужно подбирать соответственно целям.
Именно поэтому ваши коллеги по защите данного продукта тоннами пишут статьи как поставить OpenStack на 2 машины и чтоб было хорошо.
Вы пишите мемуары? Если да, то понятно, напишите также какой отстой Docker в 2013 году, Linux в 1998 и т.д.
Я тоже люблю историю древнего мира.
Достаточно сложно воспринимать текст серьезно после подобных словосочетаний.
В жанре как у меня не хватило … поднять облако.
Когда я начал читать статью подумал что она писалась в 2014 году (с того времени все изменилось).
Схема архитектуры Openstack вброшена так чтобы напугать читателя (реально используется только половина модулей), их не обязательно ставить.
По availability zones — решается элементарно правильным выставлением метаданных, просто автор не разобрался.
Обновления нужно делать строго по мануалам, и перед этим вычистить логи от устаревших настроек (если такие имеются). То что автор все обновлял интуитивно не означает что он прав. Тогда гости даже и не заметят что были какие то действия.
Я думаю автор просто не разобрался и с горя пишет подобные тексты.
И вот молодой студент в развивающимся стартапе купил себе на аукционе тазик-сервачек от 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-и админов и вы готовы взять себе еще столько же админов/разрабов чтобы они решали его проблемы либо купить услуги конторы что приготовит его для вас.
Неправильно рассуждаете, Proxmox и OpenNebula/OpenStack — это две совершенно разные вещи, хоть и используют один и тот же гипервизор.
Proxmox — это infrastructure virtualization, то есть если вы хотите просто поделить ваши bare-metal сервера на много виртуалок со всеми вытекающими: отказоустойчивость, бэкапы, kvm-консоль и т.д., но при этом работать с ними точно так же как и работали бы с обычными серверами (например подключить cd-rom и установить систему), если жизнь виртуалок для вас критична и сменяются они довольно редко, то это решение подойдет вам как нельзя лучше других.
OpenNebula/OpenStack — это уже cloud platform, а значит здесь вас ждут темплейты, виртуальные сети и автоматически скалируемые сервисы. В пару кликов вы можете создать или удалить сразу 100 однотипных виртуалок, вы можете передавать виртуалкам параметры, к которым можно получить доступ изнутри. Бывает, что жизненное состояние виртуальной машины здесь может быть вовсе не важно. А еще у этого всего есть API, так что таким облаком можете пользоваться даже не обязательно вы, но например ваше приложение, которое будет автоматически создавать в нем виртуалки и исполнять в них какой-то код.
с аргументом про infrastructure virtualization vs cloud platform согласен — это немного разные вещи.
Правда все эти возможности на практике приводят к тому, что мы получаем запутанную систему требующую по хорошему как минимум 3-5 bare-metall сервера, при этом не всегда работающую адекватно, сложную в настройке, развертывании и поддержки настолько, что легче предать это все специальную компанию для всей этой радости.
Что это за облако и почему оно удобнее OpenStack я постараюсь рассказать в следующей статье. (Спойлер: это OpenNebula).
Так и не рассказали :-(
Итак, вы решили развернуть OpenStack