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

$ ec2-create-placement-group bokov_super_cluster -s cluster
$ ec2-run-instances ami-2de43f55 --type cc1.4xlarge --placement-group bokov_super_cluster -n 8

ami-2de43f55 – это CentOS ( ничего другого пока нет – не поддерживают HVM ? ), 8 – сколько нодов в кластере,
cc1.4xlarge – тип ноды ( Quadruple Extra Large – 33.5 ECU (EC2 Compute Units), 23 GB of RAM, 1690 GB storage ).

HPC кластеры от EC2 базируются на самом мощном инстансе из линейки AWS который запускается под HVM, причем в случае с Cloud Compute cc1.4xlarge стоит дешевле ( 1.60 против 2.40 ) чем в случае простого, не HPC-кластерного, использования. Доступно все это пока только в одном регионе – us-east ( физический локайшн серверов, конечно же пользовать все это можно из любой точки мира ), постепенно думаю что расширят ее и на другие регионы. Как уже упоминалось из операционок доступна сейчас только CentOS, для других ОС Amazon предлагает делать образы самостоятельно, но имхо лучше подождать немного пока этого не сделают. И еще немного по поводу производительности -  как утверждается в New Amazon EC2 Instance Type – The Cluster Compute Instance народ из AWS сделал кластер из 880 HPC узлов с производительностью 41.82 MFlops (запускали High Performance Linpack запущенный на 880 инстансах Cluster Compute (7040 cores) – что пример равно 146 месту в top500 суперкомпьютеров.

Если совсем-совсем честно, то конечно же HVM это все равно Xen и всё равно виртуализация, что имеет свои явные плюсы в виде скорости _скалирования_ кластера, но и по сравнению с “просто железом” верхняя планка по производительности ( в пике? ) все равно будет ниже. Из HPC + cloud computing еще раз хочется отметить Penguin On Demand – это HPC кластеры on demand ( cloud computing!) из “настоящего” hardware, без виртуализации. Penguin-ы уповают на то что их cloud будет сильно быстрее в смысле общего времени выполнения задач. Подробно в POD я пока не копался – остаётся открытым вопрос про API ( свое ПО для управление кластерами Penguin-ов – SkyId ClusterWare + TaskMaster Suite + Integrated Managed Framework, API явно есть, не понятно как из своих приложений управлять кластером ) и про то насколько быстро кластер будет скалироваться – с одной стороны конечно Pay-As-You-Go, но тем не менее SLA не гарантируют и про динамическое изменение размеров кластера сказано что “can be rapidly scaled by Penguin so POD can grow its capacity as needed” ( POD = Penguin On Demand, по умолчанию в нем доступно 1280 ядер, видимо платить надо за все сразу? ), интересно а если надо уменьшить размер кластера ? Еще небольшое замечание – Penguin-On-Demand на сегодня также как и Amazon HPC работает с CentOS.

Share/Bookmark

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

Share/Bookmark

4)  Запускаем через Command line promt c:\ec2\ec2.bat
Если мы видим что похожее на
java version “1.6.0_03″
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)
JRE работает, если нет – скорее всего надо снести все имеющиеся jre и поставить с sun самый свежий

5) Пробуем воспользоваться amazon command line tools : запускаем в том command line promt где стартовала jre команду :
C:\ec2>ec2-describe-images -x all
Эта команда выводит список доступных образов (  у меня эта команда выводит почти тысячу общедоступных public образов )

Если видим подобную картину, то значит всё работает хорошо.

6) Попробуем запустить сервер ( instance )  – для этого получаем список образов владелец которых amazon :
C:\ec2>ec2-describe-images  -o amazon
И выбираем из этого списка  образ c “getting-started.manifest.xml”
IMAGE ami-2bb65342 ec2-public-images/getting-started.manifest.xml amazon available public i386 machine
Имя instance – это ami-2bb65342

7) Создаем (запускаем) instance указывая в качестве параметра имя.
C:\ec2>ec2-run-instance ami-2bb65342
должно быть что то вроде
C:\ec2>ec2-run-instances ami-2bb65342 -k gsg-keypair
RESERVATION r-3be02b52 841167328091 default INSTANCE i-d2c719bb ami-2bb65342 pending gsg-keypair 0 m1.small 2008-08-06T13:43:45+0000 us-east-1b
Имя созданного instance – i-d2c719bb.

Ждем некоторое время и проверяем состояние созданного instance
C:\ec2>ec2-describe-instances i-d2c719bb
RESERVATION r-3be02b52 841167328091 default
INSTANCE i-d2c719bb ami-2bb65342 ec2-67-202-18-11.compute-1.amazonaws.com domU-12-31-38-
00-3A-44.compute-1.internal running gsg-keypair 0 m1.small 2008-08-06T13:43:45+00
00 us-east-1b
Имя ( видимое снаружи ) созданного instance это ec2-67-202-18-11.compute-1.amazonaws.com.
Если проверить состояние instance сразу после создания, то его статус будет pending – т.к. запуск instance и загрузка ОС занимает какое то время.

9) Пробуем получить доступ к созданному instance по http – открываем 80 порт ( для всех создаваемых нами instance )
C:\ec2>ec2-authorize default -p 80
GROUP default
PERMISSION default ALLOWS tcp 80 80 FROM CIDR 0.0.0.0/0_
Теперь в браузере можно открыть http://ec2-67-202-18-11.compute-1.amazonaws.com
В браузере вы должны увидеть страничку по умолчанию от Fedore

10) Получаем доступ к ec2-67-202-18-11.compute-1.amazonaws.com по ssh. Открываем 22 порт :
C:\ec2>ec2-authorize default -p 22
GROUP default
PERMISSION default ALLOWS tcp 22 22 FROM CIDR 0.0.0.0/0

11) Настраиваем putty :
- генерим пару ключей для ssh ( на основе цифровых сертификатов )
c:\ec2>ec2-add_keypair test_keypair
где test_keypair – это имя которое мы хотим дать генерируемой пар ключей
эта команда выводит в консоль приватный ключ – выглядит это примерно так ( замазано мной – это же реальный ключ )

Копируем этот ключ прямо из консоли (-как есть ) и сохраняем в файл my_private_key_data – я советую сохранять этот файл навсегда – он может понадобиться например в случае если Вы работаете в группе и Вашим коллегам понадобится доступ к созданным Вами instance – в этом случае Вам надо будет поделиться ключами – и секретным и публичным. Запускаем puttygen и открываем в нем этот файл (my_private_key.ppk ) – пункт меню “load private key file”. Теперь сохраняем публичный ключ ( save public key ) и приватный ключ ( private key ) – например в c:\ec2\public_key_putty и c:\ec2\private_key.ppk  – внимание private_key.ppk отличается от my_private_key_data потому что у putty свой формат хранения ключей ( в том числе и для такой конвертации ключей в формат putty и используется puttygen ).  Этот private_key.ppk прописываем в putty в качестве приватного ключа

В качестве имени машины указываем ec2-67-202-18-11.compute-1.amazonaws.com – после коннекта терминал будет спрашивать имя юзера – root. Пароль спрашивать не должен. Настройки WinSCP выполняем аналогичным образом.

ps. Здесь можно найти пример установок для Linux.

pps. В случае если с amazon EC2 работает группа разработчиков возникает ряд проблем связанных с разделением ключей ( для того чтобы получить доступ к instance необходимо иметь приватный ключ такой же который был указан при создании instance ( точнее один из тех ключей которые лежат в /root/.ssh ) ). Я рекомендую особенно не мудрстовать с разделением прав доступа и организацией групп пользователей с разными правами и ключами, а просто раздать всем одну пару ключей ( плюс соответсвующие им putty ключи ) – это значительно упрощает жизнь.

Если же так получилось что все используют разные ключи и команда ec2-describe-keypairs выводит список из нескольких используемых в системе ключей всегда ( особенно при ec2-run-instance ) используйте ключ -k my_keypair для явного указания пары ключей, иначе инстанс будет запущен с ключами по умолчанию и они скорее всего не являются вашими ключами и соответственно ssh доступа к запущенному instance не будет.

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