A: Картинка ниже должна ответить на данный вопрос ( не забываем что в линейке EC2 есть и гораздо более производиельные instance чем m1.medium ),  по теме произвоительности EC2 ( и других клауд провайдеров )  можно посмотреть эту небольшую подборку ссылок – Cloud providers perfomance tests and monitoring.

Q: Трафик с EC2 – сколько стоит входящий трафик и сколько исходящий? Насколько оправдано например будет вынести краулинг веба в EC2 ?
A: Как я и сказал – внешний входящий трафик бесплатный, исходящий наружу стоит некоторых денег – см EC2 pricing. Трафик внутри сети ( в пределах региона ) – бесплатный. Теперь о деталях – исходящий трафик бесплатный до 1 ноября 2010, после будет тарифицироваться по 10 центов за Гб – так что времени бесплатно скачать весь интернет осталось не так много При цене в 10 центов за Гб скачать весь рунет ( по данным яндекса 140 тысяч Гб только текста ) будет стоит 14 000 USD, а если говорить о инкрементальном апдейте в 2 Тб ( что вполне близко к реальности ), то один стоимость трафика достаточно невысока – всего 200 USD. Внешний трафик ( наружу ) – один Гб в месяц – бесплатно, далее в зависимости от объёма цена колеблется от 8 до 15 центов за Гб. Другая приятная для анонимного краулинга особенность EC2 – действительно большой выбор ip адресов – имеется возможность размещения instance в достаточно широком диапазоне подсетей и более того в разных географических регионах.

Q : Как ведут себя instance EC2 в некоторых нештатных ситуациях ( например когда кончаются сокеты или память ), какие там установлены лимиты?
A: Для меня неясно насколько поведение ОС под Xen отличается от ее поведения на настоящем железе, особенно в крайних ситуациях. Очевидно что все настройки лимитов на guest-OS доступны для редактирования, но также очевидно что всё это никак не влияет на настройки host-OS. Официальная точка зрения инженеров Amazon состоит в том, что то все лимиты устанавливаются также как и под реальным железом ( root + ulimit ) и запуск OC под системой виртуализации не играет тут никакой роли. Из найденных пользователями фич можно посмотреть по этому поводу например Get around EC2 filesystem limits (sort of), а вообще подозреваю что поведение будет иметь фичи не столько связанные с тем что мы запускаем сервер под EC2/Xen, сколько зависеть от образа который мы запускаем.

Q: Поддерживается ли hibernate в EC2 ? ( можно ли поднять приложение, “прогреть” кэш и сохранить это состояние, а потом когда нужно быстро поднять сервер? )
A: Для начала каким образом можно было бы сделать Hibernate – для этого необходимо к instance примонтировать EBS устройство ( отформатировать его и тп ) и сделать туда hibernate выключив instance – shutdown в данном случае означает что мы потеряли данный instance навсегда, EBS хранилище при это естесственно остается существовать и его можно примонтировать к любому другому запущенному instance. Таким образом hibernate можно реализовать как например запуск нового instance такого же типа с автоматическим монтированием EBS с hibernate данными и восстановлением состояния системы из данных с этого EBS устройства. Насколько я могу судить эта фича достаточно востребована, но как я вижу, пока не реализована – см. EC2 Hibernate, Hibernating Ubuntu on EBS boot EC2 instances.

ps. Из остального – если хочется что-то cloud computing но на местной, российской площадке – посмотрите на Оверсан Скалакси.

Share/Bookmark

Share/Bookmark

1) Убираем openjdk, gij
apt-get remove openjdk-*
apt-get removel gij-*

2) ставим нормальную java от sun
apt-get install sun-java6-jdk

3) Инсталлируем EC2 API
cd /home/abokov/

unzip ec2-api-tools.zip

4) Конфигурируем переменные окружения : я добавляю это в конец ~/.bashrc
#ec2 deal with stuff
export JAVA_HOME=/usr/lib/jvm/java-6-sun
# setting up Amazon EC2
export EC2_HOME=/home/abokov/ec2-api-tools-1.3-30349
export PATH=$PATH:$EC2_HOME/bin:
export EC2_PRIVATE_KEY=/home/abokov/keys/pk-XXX.pem
export EC2_CERT=/home/abokov/keys/cert-XXX.pem

export EC2_ACCESS_KEY_ID=***
export EC2_SECRET_ACCESS_KEY=***

Готово – проверить можно запустив например ec2-describe-instances.

Share/Bookmark

Для начала про надежность – на amazon ec2 надежность достаточно высокая, на уровне обычного dedicated hosting, есть вопросы с производительностью – по моим ощущениям не стоит ожидать того что одна и та же “тяжелая” задача будет выполняться в одном и том же окружении на amazon ec2 всегда одинаковое время – но это расплата за виртуализацию когда на одном железе одновременно крутится несколько виртуалок – в этом плане goGrid несильно отличается – тот же Xen ( правда amazon ec2 основывается на паравиртуализации, а у gogrid hardware assisted virtualization ). Если по каким то причинам instance повис – он доступен для перезагрузки, просмотра системного лога, можно также сделать с него image. Если по каким то причинам amazon-у надо выключить ваш инстанс – они предоставляют образ с instance ( это очень редкая ситуация, лично у меня такой ни разу не было ). Если goGrid хочет перегрузить ваш инстанс – они его просто перегружают уведомляя об этом постфактум.

Реально полезной фичей GoGrid является то что они предоставляют возможность использовать наряду с виртуалками настоящие железки – то есть часть кластара может быть размещена на “реальном” железе, а часть – на виртуалках – это сильно расширяет возможности для конфигурирования и во вторых открывает для cloud computing приложения которые работают в режиме высокой нагрузки – если взять например некий асбтрактный веб поиск – то на выделенном железе можно разместить поисковый back-end который очень требователен к производительности и сети, и поисковую морду, а на виртуалках держать кластер для индексации и краулинга, каких то периодически возникающих map-reduce задач ( например подсчет Индекса Цитирования – пришло обновление базы – создали кластер из много-много машин – запустили там map-reduce – подсчитали ИЦ, отдали кластер обратно – resources by demand ). В этом смысле потенциальный рынок для GoGrid немного шире, чем у amazon ec2 – на ec2 ввиду того что все размещается только на виртуалках и никоим образом ( почти – кое что всё таки можно – например гарантировать что вируалки размещаются на физически разных боксах используя разные регионы и availability zones ) нельзя конфигурировать физическое размещение серверов – для приложений критичных к сетевым задержкам ( когда желательно чтобы все серверы стояли в одной стойке например ) или для приложений критичных ко времени выполнения когда желательно знать что данная задача будет выполняться столько времени на данном сервере – на ec2 время выполнения тяжелых таском на m1.small отнюдь не постоянно, возможно что на x.large с этим лучше, но все равно с настоящим выделенным сервером все это не сравнится.

Share/Bookmark

сколько денег-времени будет стоить переналить какую нибудь FreeBSD на хостинге, да еще если нужна FreeBSD c русским апачем и ерлангом ?

Как выглядит моя работа со всем этим? Очень просто – запустить новый сервер ( instance ) из командной строки – дело менее чем минутное. Я запускаю Cygwin, хотя тоже самое можно делать из win32 command line – просто я привык к ls и grep, а из него виртуальную машину Java и несколько команд из ec2 command line toolkit. Запускаем виртуальную машину java ( “%JAVA_HOME%\bin\java” -version ), потом последовательно ec2-describe-images, ec2-run-image %имя_image%, ec2-describe-instances – вижу имя машины

потом захожу на неё putty

root в терминале – делаем что хотим

Apache поднят ( 80 порт у меня открыт, как и 22 )

Замечу что поднята не просто какая то там Fedora, а именно та которая мне нужна ( на которую я поставил то что мне нужно как нужно ). Поигрался с erlang, поставил мозг набекрень – всем спасибо – ec2-terminate-instance %имя_instance%.

Если я захочу тоже самое проделать с каким нибудь ЧЧЧ хостингом – это будет пара дней ожидания , и не дай бог я хочу что не то что есть у них . Не говоря, про то что ЧЧЧ хостинг захочет свои двести баксов сегодня – и хорошо если просто яндекс-деньгами можно оплатить, а то ведь есть варианты с тем чтобы отсылать по факсу копию паспорта, etc , а амазону я заплачу ровно за время между ec2-run-instance и ec2-terminate-instance ( больше 10 часов в терминале в день я не выдержу – получаем затраты в 1 $, хотя конечно одной машиной дело не всегда ограничивается но тем не менее ), и  самое главное что услуга оплачивается _потом_. Ведь правда же что есть некоторая разница в том чтобы вложить в проект пару сотен тысяч долларов сегодня на аппаратные ресурсы, или сегодня вложить 200 долларов, и если всё получиться – вложить завтра еще пару тысяч, а уж если и потом получится подключить более значительные инвестиции. Собственный ДЦ тут тоже не очень спасает положение – что-то будет делаться немного лучше и быстрее чем на чужом хостинге, но возможности даже самых лучших системных администраторов ограничены – никто не сможет дать вам пару сотен свежезалитых машин в течении 10 минут и избавиться от них через пару часов, например.

Amazon Elastic Clouds это не технологический прорыв ( ibm это делает уже много и давно – правда простым смертным сей сервис недоступен – выкупать товарный поезд в сотню вагонов, когда тебе нужно одно купе будет не очень хорошей идеей ), но то что они не первые и наверное не самые быстрые, я думаю их не особенно беспокоит потому что они самые удобные.

Остальные статьи про Amazon Elastic Compute Cloud.

В следующей серии – как начать работать с ec2 и получить от этого удовольствие

ps. Стоит еще отметить что в реальной жизни есть еще такая вещь как оплата входящего-исходяшего трафика – но это отдельная история.

Share/Bookmark