Релиз CloudStack 4.4

Оно настолько нужно, что за весь день мой комментарий первый?

Это для клауд-хостеров, как и openstack. Если бы у Амазончика был логин на лоре, может он бы и отписался

позволяет создавать «облачные» системы

Всё описание - два маркетоидных баззворда. Объяснил, чо...

Отвечать на несуществующий вопрос - так типично для ЛОРа... Я не спрашивал, что такое CloudStack, я поинтересовался его популярностью.

Я тебе и пояснил, что он популярен в узких кругах

Как и openstack? :) Ну... это как сравнивать карточный домик с домом из кирпичей, скрепленных хорошим цементом, построенном на отличном фундаменте. В общем про CloudStack в продакшене - работать какое то время будет, главное на него не дуть. ;)

В общем про CloudStack в продакшене - работать какое то время будет, главное на него не дуть. ;)

Это конечно из личного опыта?

Все же, как оно по сравнению с openstack?

Оно ставится и настраивается за 15 минут, после чего работает. Имеет монолитную архитектуру, и очень легко обеспечить отказоустойчивость.

Ага. Из личного, и весьма печального, опыта.

По поводу отказоустойчивости - выдерни из него вычислительную ноду, и оценишь отказоустойчивость в полном объеме. Естественно, не из пустого с одинокой виртуалкой, а из загруженного процентов на 80-90... Такое небольшое облачко с двумя сотнями серваков на борту.

dober

По сравнению с Openstack - полное фуфло. Но очень красивое. Этакая туповатая блондинка со своей, одной ей понятной логикой. И всеми косяками java, которые решаются только и исключительно перезагрузкой, а иногда и переустановкой управляющего узла.

Скажем так. Это как виндовс с линуксом сравнивать. Первый легко ставится, и автоматически работает. В пределах отведенного ему ограниченного набора функций. Проблем нет, до тех пор, пока тебе не понадобится выйти за рамки этого функционала и задумок разработчиков. Ну, или до тех пор, пока ничего не сломается. И вот тогда начинается настоящий ахтунг.

Кстати, про винду. Она там запускается на qemu с IDE и E1000, обеспечивая себе изрядную порцию тормозов. И без плясок с бубном вендосерваки там работать сколь либо прилично не будут.

Актуально было для версии 4.0 На 4.1 мы так и не перешли, потому что, как выяснилось в процессе тестовой установки, разрабы кое чего там забыли допилить, и потому БД там нифига не собиралась. Такая эпичная бага версии 4.1

В общем переход c CloudStack на Openstack (равно как и переход с GlasterFS на DRBD), который вызывает такое чувство, что его никак и ничем не убьешь, был одной из лучших идей в нашей жизни.

Кстати, про винду. Она там запускается на qemu с IDE и E1000,

Ты вообще не понимаешь, о чем ты говоришь. Так что проходи мимо, трололо.

По поводу отказоустойчивости - выдерни из него вычислительную ноду, и оценишь отказоустойчивость в полном объеме.

Каким боком тут CloudStack?

Ты вообще не понимаешь, о чем ты говоришь. Так что проходи мимо, трололо.

Ну и о чем я, по твоему, говорю?

Каким боком тут CloudStack?

Возможно таким, что облачная платформа должна обеспечивать, в случае выхода из строя какого либо аппаратного узла, две вещи:

1. Авария не должна сказаться на работоспособности оставшихся компонентов системы (с поправкой на возможное падание производительности в следствии распределения нагрузки)

2. Функциональность вышедшего из строя узла должна быть восстановлена, по возможности, автоматически, и передана на наименее загруженные узлы облака.

Еще раз - проходи мимо жирное и тупое трололо. CloudStack - не система виртуализации, так что «про винду. Она там запускается на qemu с IDE и E1000» - это феерический дец!

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

Причем тут платформа, если умирает вычислительный узел?

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

Укажи мне, где именно я написал, что CloudStack это система виртуализации? А заодно расскажи мне, какова конечная цель использования облачной платформы - не важно будет это Cloudstack, Openstack, XCP или VMware vSphere? Или ты Cloudstack поставил, полюбовался на его красивую веб-морду, и так и не стал там запускать ни одной виртуальной машины? Поясню: если в качестве гипервизора в облаке на Cloudstack'е использовать KVM, и попытаться запустить там сервер с Windows на борту (т.е. выбрать при создании новой виртуальной машины в выпадающем меню Cloudstack слово Windows Server XXX), то как раз и можно, после успешной установки и старта системы наблюдать тот эффект, который я описывал: «Она там запускается на qemu с IDE и E1000».

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

А я смотрю, ты вообще то часто говоришь о вещах, про которые не имеешь ни малейшего понятия... :)

man kvm HA

High Availability не является функцией гипервизора. Так что боюсь, что в мануале к KVM, вернее к libvirt, можно найти, максимум, способы автозапуска виртуальных машин после перезапуска физической.

Более того, необходимо обеспечить, в случае работы с облачной платформой, отображение информации о размещении виртуальной машины на физическом узле в БД самой, собственно, облачной платформы.

Иначе толку от облачной платформы чуть больше чем ноль.

High Availability не является функцией гипервизора. Так что боюсь, что в мануале к KVM, вернее к libvirt, можно найти, максимум, способы автозапуска виртуальных машин после перезапуска физической.

Внезапно, да? И в мануале четко расписано, что может CloudStack при работе с разными системами. Например можно подключить ноды с XenServer и получить бенефит HA. Наверное даже не стоит упоминать о том, что в мануале расписано, что будет «когда подыхает аппаратный узел со всеми виртуалками на борту». Я даже не говорю о том, что для начала вменяемые люди собирают тестовый сетап, где моделируют такие ситуации.

Причем тут платформа, если умирает вычислительный узел?
Внезапно, да? И в мануале четко расписано, что может CloudStack при работе с разными системами.

Ну да, действительно внезапно. Ты уж определись пожалуйста, причем тут платформа. Или платформа, исходя из твоих же слов, тут не причем?

И так. Принимаем за данность более позднее твое утверждение, и убеждаемся, что платформа все таки причем то. И именно она отвечает за эвакуацию машин с дохлого хоста. Причем, на самом деле, не важно, Xen ты к ней подключишь или KVM. Или VMware. Не суть.

Вся проблема в том, что CloudStack не работает по мануалу! Теперь возвращаемся к тому давнему сообщению: «По поводу отказоустойчивости - выдерни из него вычислительную ноду, и оценишь отказоустойчивость в полном объеме. Естественно, не из пустого с одинокой виртуалкой, а из загруженного процентов на 80-90... Такое небольшое облачко с двумя сотнями серваков на борту.»

А будет примерно следующее: CloudStack попытается вытащить с мертвого узла машины. И запустить их на других узлах. Процентов 40-60 из этих серваков при эвакуации где то потеряются, да так, что потом задолбаешься их искать, и устанешь от уймы неудачных попыток их запустить. Но эту проблему ты будешь решать потом. А в данный момент ты будешь наблюдать отвратительную картину другой проблемы, без какой либо возможности на нее повлиять - CloudStack из за кривой системы сбора статистики о загруженности ресурсов, будет отправлять в даун виртуалки на живых узлах. В это время тебе звонят клиенты, и их все больше, по мере отключения машин. И наконец ты понимаешь, что придется перезапустить все облако, вырубив все машины. И машинки, после этого действа, включать по одной.

А можно рассмотреть другую траблу. Это когда CloudStack считает машинку включенной, потребляющей память и процессор. Но самой машинки нигде нет. И выход только один - руками править БД. Но структуру БД CloudStack разрабатывал, по всей видимости, какой то в хлам укуренный индус. Она сложна и непонятна. Зато обладает потрясающими взаимосвязями, нарушение которых ведет к тому, что CloudStack перестает видеть свою БД.

И это я еще про доработку CloudStack не упоминал. Без хорошего явиста в его код лучше вообще не соваться. Сам черт ногу сломит.

И именно она отвечает за эвакуацию машин с дохлого хоста.

Виртуалки не хранятся на хостах.

CloudStack попытается вытащить с мертвого узла машины. И запустить их на других узлах.

Это буллшит! Виртуалки хранятся на стораджэ, данные о них в базе. CloudStack ничего не вытаскивает с мертвых узлов.

Процентов 40-60 из этих серваков при эвакуации где то потеряются, да так, что потом задолбаешься их искать, и устанешь от уймы неудачных попыток их запустить.

ШТА? Каким образом они теряются? Стираются со стораджа? Данные о них пропадают из базы?

А в данный момент ты будешь наблюдать отвратительную картину другой проблемы, без какой либо возможности на нее повлиять - CloudStack из за кривой системы сбора статистики о загруженности ресурсов, будет отправлять в даун виртуалки на живых узлах

И каким же образом? Ну вот HA в KVM он не поддерживает. Значит вы сами что-то в своей конторе дописали, что он начал автоматом поднимать мёртвые KVM машины на других хостах, при этом останавливая живые, но виноват CLoudStack?

Это когда CloudStack считает машинку включенной, потребляющей память и процессор. Но самой машинки нигде нет.

И опять KVM c HA?

И это я еще про доработку CloudStack не упоминал. Без хорошего явиста в его код лучше вообще не соваться. Сам черт ногу сломит.

Ага, с этого и надо было начинать. «Мы допилили CloudStack, но теперь он глючит и не работает».