Eucalyptus (http://open.eucalyptus.com/) позиционируется как открытое (open source) решение для организации доступа к вычислительным ресурсам с возможностью динамического масштабирования системы и балансировки нагрузки. В данной статье (http://blog.openquality.ru/eucalyptus-cloud/) рассматривается архитектура Eucalyptus, вопросы его установки и возможности использования в разработке программных продуктов и предоставлении услуг для пользователей.URL: http://blog.openquality.ru/eucalyptus-cloud/
Новость: https://www.opennet.ru/opennews/art.shtml?num=22850
Мне не понравился эвкалипт - пол года назад он слишком много ошибок выдавал.
Но проект достоин уважения - практически готовый ec2
Да, он непростой, сквозь ошибки приходится продираться, но это возможно.
>пол года назад он слишком много ошибок выдавал.В karmic та же версия, что и в jaunty. Это какбэ намекает нам, что проект перестал развиваться.
А мужики-то и не знают :) Недавно 1.5.2 выпустили и готовятся выпустить 1.6 в сентябре. На мой взгляд, он не перестанет развиваться. Другой вопрос, когда он станет более функциональным и будет ли это по-прежнему open source. Будем надеяться, что будет.>В karmic та же версия, что и в jaunty. Это какбэ намекает
>нам, что проект перестал развиваться.
Это тупой менеджер виртуалок(притом кривой) и никакими "возможностью динамического масштабирования системы и балансировки нагрузки" в нём не пахнет вообще, это не библиотека и не платформа. О чём и сказано у них в faq.С амазоном его роднит только частичная совместимость с ихними жаба-тулзами.
Читал, не нашел. Может, у меня глаза на заднице...Процитируйте плз эти моменты из первоисточника, особенно про то, что это "тупой менеджер виртуалок(притом кривой)"
И еще я так и не понял - при принятии решения, на какой ноде запустить очередной контейнер, контроллер учитывает загруженность нод?
Да, учитывает. CC получает и обрабатывает информацию с каждого NС. Есть два режима: Greedy и RoundRobin. В первом режиме СС начинает с первой ноды, полностью ее загружает и переходит к следующей. Во втором режиме инстансы поднимаются по кругу - по одному на каждой ноде.
Динамическое масштабирование заключается в следующем: вы можете добавлять в облако новые кластеры и ноды, а облако будет задействовать их по мере необходимости. Конечный пользователь поднимает свои инстансы, не думая о том, сколько ресурсов у него есть. Понятно, что есть предел, соответствующий наличию железа, но это предел не для пользователя, а для создателя облака.Балансировка нагрузки есть. Почитайте о режимах Greedy и RoundRobin. Возможно, вы путаете балансировку в контексте облака и балансировку в контексте приложения, которое в нем работает. Балансировка нагрузки в контексте облака есть, а балансировку в контексте приложения нужно организовывать самим.
Это был ответ Oдмину на комментарий №3.>[оверквотинг удален]
>Динамическое масштабирование заключается в следующем: вы можете добавлять в облако новые кластеры
>и ноды, а облако будет задействовать их по мере необходимости. Конечный
>пользователь поднимает свои инстансы, не думая о том, сколько ресурсов у
>него есть. Понятно, что есть предел, соответствующий наличию железа, но это
>предел не для пользователя, а для создателя облака.
>
>Балансировка нагрузки есть. Почитайте о режимах Greedy и RoundRobin. Возможно, вы путаете
>балансировку в контексте облака и балансировку в контексте приложения, которое в
>нем работает. Балансировка нагрузки в контексте облака есть, а балансировку в
>контексте приложения нужно организовывать самим.
Может ли данный продукт обеспечивать режим, когда CC запускает новый инстанс на наименее загруженной в данной момент ноде?
Ихмо режимы Greedy и RoundRobin, как вы их описали, это не балансировка, а пародия на неё.
У нас в наличии было всего две ноды, причем одна из них заведомо слабее другой. По наблюдениям, в режиме Greedy сначала полностью загружалась первая нода (CLC, CC, NC), а потом инстансы поднимались на второй (NC). В режиме RoundRobin инстансы поднимались поочередно.Вот как эти режимы описаны в eucalyptus.conf:
# This option configures the Cluster Controller's scheduling policy.
# Currently, this option can be set to GREEDY (first node that is
# found that can run the VM will be chosen) or ROUNDROBIN (nodes are
# selected one after another until one is found that can run the VM).
#SCHEDPOLICY="ROUNDROBIN"
SCHEDPOLICY="GREEDY"Понятно, что хочется большего. Вопросы на форуме о внедрении собственной полиси задавались, но ответа пока не было. Но это же open source, невозможного нет.