Логично, но HP не такой уж и большой игрок на облачном рынке, чтобы таким аргументом объяснить не дешевую покупку Eucalyptus. Уверен что были еще причины и видения, которые не доступны широкой публике или не оправдались. Помимо этого Eucalyptus, еще когда самостоятельным был, уже очень сильно отставал от функциональности AWS.
Имея большой опыт работы с enterprise клиентами, могу сказать что зачастую проблема не технического характера а бюрократического. Ты не представляешь как мееееедленно и сложно принимаются решения в больших организациях и именно поэтому очень многие из них до сих пор используют Windows XP, IE6 и Java 6.
Хорошее решение хоть я и сам пострадал от этого ибо активно использую несколько Java-апплетов. Иногда приходится принимать не популярные и жесткие меры, чтобы иметь возможность двигаться дальше.
По сравнению с другими дистрибутивами Openstack (включая сам базовый Openstack), HP Helion — не так уж и плох. Я гонял его вдоль и поперек и кол-во проблем намного меньше чем обычно при кастомной сборке. Но в целом политика HP в плане клауда не понятна. Год назад они купили Eucalyptus (http://www8.hp.com/us/en/cloud/helion-eucalyptus-overview.html) и сделали ставку на него. Cпустя некоторое время опять повернули в сторону Openstack. Выглядит это как метание из стороны в сторону без какой-либо долгосрочной стратегии.
Это отличный пример того что делает конкуренция. Появление такого игрокак как Google (Compute Engine) год назад положил начало очень интересной борьбе которая в течение следующих пару лет сделает клауд реально массовым и дешевым. Гугл снизил прайсы на Compute в среднем на 70%, амазон сделал тоже самое в течение недели. Гугл выпустил SSD диски по смешной цене (Block Storage) амазон через неделю сделала тоже самое еще дешевле. С Нетерпением ждем продолжения. Думаю что в скором времени еще больше вкусностей появится.
У меня это была первая мысль. А что если кому-то не нужно было чтобы эти спутники достигли орбиты, ибо с ними что-то не так. При таком раскладе все улики сгорают в атмосфере и все и не докопаешься что там было запущено. Зная как у нас все пилится и организуется, можно предположить что в космос было отправлено не то что по дукументам должно было быть отправлено, но уже ничего не докажешь. Упс, человеческая ошибка как было в прошлый раз.
Более чем уверен, что не выдадут. Они пару недель назад начали рассылать их тем кто в прошлом году $1500 заплатил. Не честно получится по отношению к этим людям.
Посмотрите как работают наши кронджобы. Мы используем Semaphore Functions: очереди, семафоры и шаред мемори. Все настраивается, можно к примеру запустить пулл процессов и он будет висеть и обрабатывать задачи как толкьо они будут появлятся в очереди. Можно просто переодически запускать крон, он стартует воркеры, делает работу и прибивается. И много других вкусных плюшек.
Я не спорю. Сам встречал проблемы при разработке чего-либо, когда проблема явная, а в интернете либо ничего нет, либо что-то есть но решение проблемы описанно на китайском или японском на соответствующем формуе… :-(
нет в случае EBS. В случае со старым процессом создания снапшотов, можно было скачать его с S3, только с ним ничего сделать нельзя. Он в формате амазона и заэнкрипчен.
Все очень просто:
1. Регистрируетесь на Amazon AWS. Вводите данные своей карточки. Билитесь вы раз в месяц за то что использовали. Тоесть заюзали вы инстансов на 20 баксов, вы автоматом пробилитесь на 20 баксов.
2. Получаете в профиле ключи от API и используете его. Там либо SOAP либо REST. Документации валом. Можите использовать платные сервисы такие как Rightscale (стоит очень дорого) или наш scalr.net. Эти сервисы помогают разворачивать и настраивать вам фермы (группы серверов). Больше инфы можите найти на сайтах. Есть еще вариант использования Amazon Management Console. Это просто графическая оболочка вокруг АПИ.
3. При запуске инстанса вы выбираете image (snapshot) системы. Убунту, ЦентОс, Шапка. И Так далее…
4. Доступ к инстансам такой же как и к обычным серверам. Есть рутовый SSH. Со всеми вытекающими.
5. В случае с БД, есть 3 варианта:
— Испольщовать их SimpleDB (не SQL)
— Использовать их новый сервис RDS. А это уже MySQL 5.1 но этот сервис в бете.
— На своем инстансе установить мускуль или любую другую базу и использовать его.
6. В случае с Ддосом, насколько я знаю у амазона есть защита от ддосных аттак, но точное не скажу. Нужно спрашивать у них.
Тоесть алгоритм развертывания проекта точно такой же за исключением пунтка 1. :-)
Пару примеров чего? Для чего использовать EC2? Я знаю к примеру 2 очень выгодных юзкейса для него:
1. Для дэвелопминга: Запустил сервер потестил остановил. И тестинг происходит на живом окружении а не на денвере каком-то.
2. Для высоконагруженных проектов. В случае с выделенными серверами нужно всегда иметь не маленький запас мощности сервера(ов), к примеру для хабраэфекта. В случае с ЕЦ2, можно скалировать (запускать новые ноды) в зависимости от нагрузки. К примеру ваш проект хостится на инстанте типа m1.small (1GHz Celeron). И 90% случаеев его мощьности полностью хватает. Вы запостили статью на хабре и пропиарили ваш отличный проект. На него ломануись люди. В случае с выделенными серверами, если бы у вас небыло запаса мощности вы бы потеряли 10 милионов доларов прибыли, в случае с ЕЦ2 вы запустите парочку дополнительных инстансов на вермя хабраэфекта и остановите их когда хабраэфект пройдет. Результат: ваш сайт не упал под натиском пользователей хабра. Это довольно утрированный пример, но принцинципы должны быть понятны.
+ Все молчат о самом главном преимуществе клаудов. При котором ты платишь только за то что используешь. Почасовая оплата… На базе этого отлично строится схема горизонтального массштабирования проекта. Не справляется апач с нагрузкой, поднял новый, нагрузка спала, опустил…
Несколько секунд? Вы наверное шутите. Сейчас скорость загрузки больше зависит от клиентского подключения нежели от того где находятся сервера (Если речь идет про современные дата центры). Если приложение пинг-критикал, к примеру игровой сервер линейки или ВОВ, то да, чем ближе к клиенту тем лучше и смысла размещать его далеко нет смысла.
Посмотрите как работают наши кронджобы. Мы используем Semaphore Functions: очереди, семафоры и шаред мемори. Все настраивается, можно к примеру запустить пулл процессов и он будет висеть и обрабатывать задачи как толкьо они будут появлятся в очереди. Можно просто переодически запускать крон, он стартует воркеры, делает работу и прибивается. И много других вкусных плюшек.
1. Регистрируетесь на Amazon AWS. Вводите данные своей карточки. Билитесь вы раз в месяц за то что использовали. Тоесть заюзали вы инстансов на 20 баксов, вы автоматом пробилитесь на 20 баксов.
2. Получаете в профиле ключи от API и используете его. Там либо SOAP либо REST. Документации валом. Можите использовать платные сервисы такие как Rightscale (стоит очень дорого) или наш scalr.net. Эти сервисы помогают разворачивать и настраивать вам фермы (группы серверов). Больше инфы можите найти на сайтах. Есть еще вариант использования Amazon Management Console. Это просто графическая оболочка вокруг АПИ.
3. При запуске инстанса вы выбираете image (snapshot) системы. Убунту, ЦентОс, Шапка. И Так далее…
4. Доступ к инстансам такой же как и к обычным серверам. Есть рутовый SSH. Со всеми вытекающими.
5. В случае с БД, есть 3 варианта:
— Испольщовать их SimpleDB (не SQL)
— Использовать их новый сервис RDS. А это уже MySQL 5.1 но этот сервис в бете.
— На своем инстансе установить мускуль или любую другую базу и использовать его.
6. В случае с Ддосом, насколько я знаю у амазона есть защита от ддосных аттак, но точное не скажу. Нужно спрашивать у них.
Тоесть алгоритм развертывания проекта точно такой же за исключением пунтка 1. :-)
1. Для дэвелопминга: Запустил сервер потестил остановил. И тестинг происходит на живом окружении а не на денвере каком-то.
2. Для высоконагруженных проектов. В случае с выделенными серверами нужно всегда иметь не маленький запас мощности сервера(ов), к примеру для хабраэфекта. В случае с ЕЦ2, можно скалировать (запускать новые ноды) в зависимости от нагрузки. К примеру ваш проект хостится на инстанте типа m1.small (1GHz Celeron). И 90% случаеев его мощьности полностью хватает. Вы запостили статью на хабре и пропиарили ваш отличный проект. На него ломануись люди. В случае с выделенными серверами, если бы у вас небыло запаса мощности вы бы потеряли 10 милионов доларов прибыли, в случае с ЕЦ2 вы запустите парочку дополнительных инстансов на вермя хабраэфекта и остановите их когда хабраэфект пройдет. Результат: ваш сайт не упал под натиском пользователей хабра. Это довольно утрированный пример, но принцинципы должны быть понятны.