Posts tagged ‘elastic compute clouds’

По горячим следам презентации в мейл.ру хочется немного дополнить мои ответы на вопросы из зала :
Q : Какова производительность EC2 instance ( по сравнению с реальным железом )?

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 но на местной, российской площадке – посмотрите на Оверсан Скалакси.

Обновление в Amazon Web Services

  • 2 новых типа instance высокой мощности :64 бита – Double Extra Large с 34.2 GB RAM, and 13 ECU (4 virtual cores *3.25 EC2 compute Unit=ECU), 64-bit platform
    и Quadruple Extra Large – 68.4 GB of RAM/ 26 ECU (8 virtual cores* 3.25 ECU) : New EC2 High-Memory Instances
  • Небольшое снижение цен за instances ( в eu-west по прежнему дороже чем в us-east ) : Amazon EC2 – Now an Even Better Value
  • Новый сервис для реляционных БД ( обещается прозрачный провижионинг, скалирование и прочие радости ) : Introducing Amazon RDS – The Amazon Relational Database Service
  • И довольно таки неожиданные заявления о наличии у EC2 потенциальных уязвимостей : Vulnerability identified in Amazon’s cloud computing
  • Amazon EC2 – Ubuntu at google groups
  • 5 лет назад была анонсирована первая из технологий Amazon Web Services – Amazon Simple Queue Service – самые важные события в AWS за последние 5 лет
  • Короткий how-to на тему настройки чистой Ubuntu для работы с EC2 API

    Continue reading ‘Настройка Ubuntu для работы в EC2’ »

    Есть такой resource provider – goGrid – GoGrid возник в недрах “обычного” провайдера ServePath, по всей видимости в какой то момент там “уперлись” в неэффективное использование железа, плюс потребности рынка в resources on demand имеется – возник cloud provider GoGrid. Несмотря на достаточно агрессивный маркетинговый спич goGrid направленный в основном на сравнение с amazon ec2 и упирающий на 100% надежность ( в отличие от amazon ec2 – по словам goGrid маркетологов ) – в реальности всё немного по другому.

    Для начала про надежность – на 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 с этим лучше, но все равно с настоящим выделенным сервером все это не сравнится.

     

     

    Я  несколько раз пытался что то написать, но не мог решить с чего же начать рассказывать про Амазон EC2. Всё таки по сравнению с мировой революцией и выходом человека в космос сервис амазона это не такая значительная веха в истории человечества. На самом деле это не совсем так – Амазон сделал очень удобную технологию на которой базируются уже многие сотни вполне успешных проектов и у этой технологии огромное будушее. Вкратце это выглядит так – вы платите амазону небольшие денежки ( 10 центов в час за один сервер через кредитку ) и в ответ получаете сервер ( Fedora ) c root-вым доступом, который виден снаружи : http, ssh – открываем/закрываем доступ как хотим – у нас же root. То что установлено – можно подправить – заходим через ssh, конфигурируем там все как хотим – сохраняем image под своим именем, потом когда просим новый сервер – просто говорим что хотим загрузить на сервер тот самый наш image.
    Денег такое счастье стоит совсем немного, особых проблем ( в виде например втыкания железа в стойки ) за собой не тянет. Основная фишка – это то что можно оперативно “заказывать” и “выключать” ( и соответственно не платить! ) более-менее любое количество серверов.
    Дешево ли 0.10 $ в час за некий не шибко мощный сервер ( примерно 75 $ в месяц или 900 $ в год ) ? Аренда чего то похожего ( наверное все таки dedicated ) будет стоить около 200$ в месяц или 2400$ в год. Конечно dedicated в стойке я так подозреваю будет побыстрее чем разделяемый одновременно несколькими виртуальными ОС ( см. Защищенность данных в Amazon Web Services )  за 10 центов в час, но тем не менее это всё таки почти тоже самое ( root доступ :-) ), и денег стоит дешевле. И самое главное – сразу забываем про стойки, дц и прочее – нужен сервер – легким кликом говорим амазону хочу N серверов ( instance в терминологии амазона ) на котором будет стоять вот этот мой image с пропатченным моими кривыми ручками моим родным русским апачем. И еще – я хочу не один, а пару сотен таких серверов в ближайший час. И через несколько минут я их получаю. Со свеженалитыми, белоснежно чистыми ос загруженными с моего image ( сколько денег-времени будет стоить переналить какую нибудь FreeBSD на хостинге, да еще если нужна FreeBSD c русским апачем и ерлангом ? :-) . Нагрузка на проект выросла – нажал кнопочку – добавил в кластер сколько нужно серверов, упала нагрузка – прибил лишние.
    Конечно сделать систему гибко масштабируемой чтобы от плюс-минус серверов всё так же работало сложнее чем сразу прибить гвоздями все в расчете на N серверов, а потом вытаскивать прибитые гвозди и забивать новые когда появились деньги на расширение аппаратного парка. Конфигурация small AMI ( того за который надо платить 0.1$ в час – но есть мощнее, и дороже) на самом деле неплохая – Dual Core AMD 2.6 GHz
    Continue reading ‘Amazon elastic clouds – getting started’ »

    Get Adobe Flash playerPlugin by wpburn.com wordpress themes