Amazon анонсировал микро инстансы в EC2 – теперь самый дешевый instance в линейке EC2 стоит 2 (два) цента в час и похоже что хостинг на EC2 становится дешевле чем low-cost dedicated – за 2 цента в час ( 15 долларов в месяц ) получаем linux с root/ssh и всеми соответствующими пирогами. Есть конечно и подводные камни – во первых производительность таких micro instance будет явно очень небольшой ( см – Amazon EC2 Micro instance, how fast is it? ), во вторых собственно дискового пространства на таком micro instance нет и для хранения данных в файловой системе надо использовать EBS, что стоит некоторых небольших денег – 10 центов в месяц за каждый Гб хранимых данных плюс 10 центов за каждый миллион операций ввода-вывода.
Posts tagged ‘ec2’
Обновление в Amazon Web Services
и Quadruple Extra Large – 68.4 GB of RAM/ 26 ECU (8 virtual cores* 3.25 ECU) : New EC2 High-Memory Instances
Не так давно amazon анонсировал появление дополнительной зоны в регионе us-east – us-east-1d – теперь у EC2 есть два региона – us-east-1 ( в котором есть 4 зоны us-east-1a, us-east-1b, us-east-1c, us-east-1d ) и eu-west-1 ( в котороем есть две зоны eu-west-1a и eu-west-1c ). Continue reading ‘Регионы и зоны в Amazon EC2’ »
Короткий how-to на тему настройки чистой Ubuntu для работы с EC2 API
Есть такой 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 с этим лучше, но все равно с настоящим выделенным сервером все это не сравнится.
Сегодня мне наконец удалось собственноручно положить instances с 64 битной Ubuntu – запущенный в бесконечной рекурсии скрипт на bash делает своё грязное дело – “съедает” все сокеты, так что ssh ( и все остальное ) ложится намертво. Что делать – ec2-reboot-instances спасет ( все что было в памяти естесственно будет потеряно ), с первого раза reboot не всегда удается – иногда приходится по несколько раз посылать на ребут. Еще полезная штука – AWS Managment Console, которая тоже умеет делать reboot и shutdown, но самое главное в ней всегда можно посмотреть system log. От себя замечу что dedicated box с например FreeBSD в подобных ситуациях ( кто то пожрал сокеты ) ведет себя абсолютно точно также – лежит, и чтобы поднять надо уже его руками поднимать – либо через Managment interface если сервер не совсем старый, или руками Reset нажимать если удаленно он вообще недоступен. Посколько привилигия доступа к managment interface обычно есть у крайне узкого круга лиц, то повисла машина – стучимся до админов, и он уже поднимает упавшее. Попробуйте проделать этот трюк раз 5 за час и узнайте все что думают админы про кривые руки программистов – на ec2 managment interface доступен всем и пинать для того чтобы поднять упавшую ноду никого не надо.
После регистрации на amazon.com/aws у нас есть : Access Number, Access Key ID, Secret Access Key, X.509 Certificate pk-XXXXXX.pem, X.509 Certificate file cert-XXXXXX.pem ( физический смысл этих ключей обсудим позже ). Попробуем создать окружение для работы с веб-сервисами Amazon для Windows: Continue reading ‘Amazon EC2 – getting started – 2’ »
Я несколько раз пытался что то написать, но не мог решить с чего же начать рассказывать про Амазон 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’ »