Pull to refresh

Comments 14

И как себя ведёт ceilometer при большом числе метрик на обсчёт? А каким образом у вас реализована поддержка availability zone, если neutron их не умеет?

Спасибо.
Сложности при масштабировании ceilometer известны, поэтому в актуальном релизе Helion OpenStack 1.1 он поддерживается в «тестовом режиме» с ограниченным набором метрик. Более детальная информация доступна в официальной документации. Как упомянуто в материалах по ссылке, в следующих релизах для масштабируемого и отказоустойчивого сбора метрик планируется использование OpenStack Monasca.

Ситуация с поддержкой availability zones в текущем релизе также описана в документации. «Из коробки» в данный момент AZ не поддерживаются, и для реализации такой архитектуры требуется привлечение HP Helion OpenStack Professional Services.
Пример такого сетапа:
image
А, просто не поддерживают. Ок, хорошо (лучше, чем если бы «поддерживали»). Вижу доказательства, что думали о реальном продакшене.
HP в своем репертуаре: продает не протестированное говно, пользуясь ажиотажем вокруг стомилллионных инвестиции в разработку OpenStack ( Mirantis ). При этом, судя по багтрекеру, код пишут индусы. Причем невменяемые.
Для корректности — Helion еще в прошлом году был (мирантис получил потенциальную возможность получить 100 миллионов только недавно), а индусы бывают такие что покруче большинства русских разработчиков (простая математика — сколько их там миллиардов уже?). Если что — в любой компании в Кремниевой долине их работает огромное количество, да и президент MS нынче кто?

Но с общим смыслом комментария (а именно то что это просто попытка взгрева на ажиотаже) — полностью согласен. До этого все грелись на blade системах (как-то тихо это сдулось уже ибо от них проблем больше чем преимуществ), был openflow (та-же история) и т.д.

Нынче модно опенстек :D
Имплементация Openflow в OVS при правильно вставленных руках отлично работает и решает свои задачи. Что конечно не отменяет факта что кое-кто на Openflow хорошо погрелся, а нормальных коммерческих реализаций в железе до сих пор не появилось.
По сравнению с другими дистрибутивами Openstack (включая сам базовый Openstack), HP Helion — не так уж и плох. Я гонял его вдоль и поперек и кол-во проблем намного меньше чем обычно при кастомной сборке. Но в целом политика HP в плане клауда не понятна. Год назад они купили Eucalyptus (http://www8.hp.com/us/en/cloud/helion-eucalyptus-overview.html) и сделали ставку на него. Cпустя некоторое время опять повернули в сторону Openstack. Выглядит это как метание из стороны в сторону без какой-либо долгосрочной стратегии.
В сторону Эвкалипта поворота не было, его купили, потому что это ценный продукт. Сейчас он вошёл в линейку Helion, но как он будет интегрироваться с другими продуктами в линейке, пока не понятно. Основная ставка в линейке Helion всё равно остаётся на OpenStack и обвязке вокруг него.
ценный продукт — на самом деле не продукт ценный был а Мартен Микос.
DicsyDel и tzong, ситуация с позиционированием Eucalyptus в облачном портфеле HP довольно проста: продукт продолжает развиваться с прицелом на тех заказчиков, которые давно и плотно сидят на сервисах Amazon, используют много смежных продуктов в этой экосистеме либо самописное ПО, работающее со стеком AWS API и при этом по тем или иным причинам хотят часть приклада и данных держать у себя локально в частном облаке, с этими API максимально совместимом.

Для решения всех остальных задач предназначены другие продукты портфолио HP Helion, в первую очередь Helion Platform (OpenStack, Development Platform), Helion CloudSystem и др.
Логично, но HP не такой уж и большой игрок на облачном рынке, чтобы таким аргументом объяснить не дешевую покупку Eucalyptus. Уверен что были еще причины и видения, которые не доступны широкой публике или не оправдались. Помимо этого Eucalyptus, еще когда самостоятельным был, уже очень сильно отставал от функциональности AWS.
Из статьи неясно — для улучшений доступны исходные тексты?
Какая часть наработок возвращена (или будет возвращена) в upstream?
Насчёт коммита назад не скажу, но в силу того, что весь openstack на python, исходные тексты очевидным образом доступны.
Средства развёртывания являются проприетарными и в сообщество не передаются (хотя, говорят, там просто питоновские скрипты). Вся остальная работа идёт прямо в репозиториях OpenStack Foundation, внутренних репозиториев не ведётся.
Sign up to leave a comment.