боков блог

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

• Сравниваем производительность инстансов на Amazon EC2 Instance Types и Virtual Server
• 10 причин по которым cloud computing это плохо
• Dulance  вернулся в виде  сниппетов с ценой
• Cloud провайдер в России – стартап Oversun Scalaxy
• Пример фреймворка для работы с Terracotta на Amazon EC2 ( terracotta.org )
• Использование amazon EC2 security groups как тегов для запущенных EC2 instances
• Библиотеки для работы с API GoGrid – кстати буквально сегодня goGrid вышли из стадии бета тестирования

Не так давно 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

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

Сегодня мне наконец удалось собственноручно положить 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 EC2 vs GoGrid vs Mosso
• The Private Cloud: Enterprise-ready on and off premise by Stephen Herrod ( at cloudSlam-2009 )
• Defining private clouds – Part 1, Part 2 – by Bernard Golden
• How LinkedIn grew Bumpersticker to be the “Biggest Ruby on Rails app in the World? и Web Scalability Practices: Bumper Sticker on Rails

Как сообщается в Amazon Web Services: Bigger Than Amazon трафик от Amazon Web Services уже превышает трафик от amazon.com – общее количество разработчиков использующих AWS превышает 300 000 и это число растет на 10% каждый квартал. Общий объем трафика позволяет точно говорить о реальной посещаемости проектов базирующихся на AWS лишь косвенно, но основной тренд налицо – использование web services в качестве back-end платформ для самого широкого спектра продуктов ( а AWS используют не только online web ресурсы ) становится всё популярнее и имеет отличные перспективы для дальнейшего роста.

Сравнение разных cloud-провайдеров :

• Comparing the Cloud: EC2, Mosso, and GoGrid,
• Cloud versus cloud: A guided tour of Amazon, Google, AppNexus, and GoGrid
• Comparison: GoGrid Cloud versus Amazon EC2
  

Документ в котором Amazon описывает важные аспекты работы EC2 – архитектура кластера, требования к надежности, защищенности данных и тп : AWS Security White Paper.

Полезная конференция на Amazon Elastic Compute Cloud (EC2) at groups.grid.org

Решения в сфере распределенных вычислений работающие с Amazon EC2 :

• Cloud Management Platform : RightScale
• Data grid, compute grid – GigaSpaces
• Compute grid, map-reduce implementation – gridGain

Проекты работающие на Amazon EC2 :

• Список самых крупных проектов использующих AWS
• “Аська”, в которой рисуют с друзьями :- Рисоваська

…

Полезные статьи посвященные Amazon AWS:

• Scaling Stateful Applications on Amazon EC2
• Elastic Block Store (EBS) – guide and reference from rightScale

Допустим у нас есть хорошо настроенный instance со всеми поставленными package и настроенной средой. Хотим сохранить заработанное в виде AMI на S3. Для начала надо установить на instance Amazon EC2 AMI Tools. В /root/keys/ кладем privateKey и publicKey ( те что получены от amazon ) и Выполняем : ec2-bundle-vol –cert /root/key/PublicKey.pem –privatekey /root/key/PrivateKey.pem –exclude /root/key -u -d /mnt -r i386
(вместо i386 если у нас что то другое – пишем это другое ). Мы используем –exclude – для того чтобы наши ключи не попали в создаваемый образ ( например если собираемся его выложить в public access ).
Загружаем его в s3 : ec2-upload-bundle -b -m /mnt/image.manifest.xml -a -s
Регистрируем его : ec2-register /image.manifest.xml

Help от amazon доступен здесь.

Для erlang есть очень хорошая библиотека для работы с e-mail : erlmail, но вот авторизации на smtp сервере я в ней не обнаружил, а ведь большинство stmp серверов работают с авторизацией. Сделал небольшой патч – авторизация на smtp сервере.
Пользоваться этим можно например вот так :

send_mail(UserEmail, Data) ->
    {ok, Pid} = smtpc:connect(”smtp.server.com”, ?SMTP_PORT),
    smtpc:ehlo(Pid, ?SMTP_SERVER),
    smtpc:auth(Pid, ?MAIL_LOGIN, ?MAIL_PASSWORD),
    smtpc:mail(Pid, ?MAIL_FROM),
    smtpc:rcpt(Pid, UserEmail),
    smtpc:data(Pid, Data),
    smtpc:quit(Pid).

send_mail(UserEmail, MessageSubject, MessageBody) ->
    Data = “From:” ++ ?MAIL_FROM ++ “\r\n” ++ “To:” ++ UserEmail ++ “\r\n” ++ “Subject:” ++
MessageSubject ++ “\r\n\r\n” ++ MessageBody,
    send_mail(UserEmail, Data ).

test() ->
    send_mail(”user@bokov.net”, “this is subject”, “this is message body!”).

Очень давно хотел написать про RightScale – rightScale занимается активным продвижением cloud-решений на базе Amazon Web Services ( S3, EBS, EC2 ) и у них это очень хорошо получается. Для тех кто заинтересовался Amazon EC2 rightScale предоставляет отличную возможность попробовать amazon EC2 в действии – вы можете получить бесплатный trial account на Amazon EC2 и попробовать “прикрутить” Аmazon EC2 к какому то реальному проекту. RightScale занимается активным продвижением Amazon Web Services и проводит семинары посвященные технологиям используемым в Amazon EC2 – например последний семинар был посвящен Elastic Block Storage – вот здесь доступно видео он-лайн семинара, слайды презентации , руководство по EBS.

Amazon анонсировала появление Windows в качестве ОС для EC2 instances. На текущий момент они запустили эту возможность в private beta ( Windows Server в связке с SQL Server ), предоставить доступ к этой возможности для всех желающих планируют не позднее конца 2008 года. Появление Windows в качестве ОС внутри elastic cloud уже давно напрашивалось – в альтернативных Amazon Elastic Compute Cloud решениях windows присутствует и этот продукт пользуется хорошим спросом на рынке распределенных вычислений. Поддержка Windows Server ( и приложений базирующихся на доступных на Windows сервисах ) позволит Аmazon значительно укрепить позиции среди cloud computing провайдеров и даст возможность клиентам создавать на базе Amazon EC2 масштабируемые приложения работающие на гетерогенных архитектурах, включающих в себя windows server, unix, linux, solaris и соответственно создавать приложения которые могут базироваться на сервисах доступных на всех этих платформах.

При необходимости рассылки почты с какого либо сервера внутри Amazon Elastic Compute Cloud Вы обязательно столкнетесь с проблемой того что большая часть smtp-серверов отказываются принимать сообщения с ip которые относятся к сети Amazon EC2 – и их можно понять. Amazon EC2 – идеальная среда-инкубатор не только для креативных стартапов, но и для рассылки спама – поэтому вся сеть себя уже скомпрометировала в определенном смысле. Поэтому даже если вы поставить на instance внутри Amazon EC2 почтовый сервер почта с него уходить все равно не будет, потому что никто не будет ее принимать – выход – сделать relay на какой либо платный сервис вроде authsmtp.com, dnsmadeeasy.com, easydns.com. Второй вариант ( возможно более сложный ) состоит в том чтобы арендовать классический хостинг и сконфигурировать стоящий там smtp сервер так чтобы он мог принимать сообщения с _ваших_ серверов amazon ( если открыть доступ для всей сети Amazon EC2 ваш smtp сервер станет отличным relay для спам проектов внутри Amazon ) – я рекомендую внутри Amazon EC2 выделить сервер с elastic IP на котором поставить Postfix, который в свою очередь будет настроен так чтобы быть relay на Ваш smtp сервер у провайдера.
Далее – как проверить соединение с почтовым сервером и как настроить postfix на instance EC2

Continue reading ‘e-mail и Amazon elastic cloud – как сделать почту в EC2’ »

Amazon EC2 и Amazon S3 теперь являются официальными поставщиками cloud-решений для Oracle – компания анонсировала cloud-лицензии для Oracle Database 11g, Oracle Fusion Middleware, Oracle Enterprise Manager. Политика лицензирования для amazon compute cloud базируется на мощности instance – каждое виртуальное ядро ( virtual core ) считается эквивалентным физическому процессору, при этом политика лицензирования применима к тем продуктам к которым применяется лицензирование основанное на процессорной метрике. При этом для продуктов Standard Edition One или Standard Edition один instance EC2 c 4 ( и менее ) виртуальными ядрами считается одним socket ( и требует одной процессорной лицензии ), а для instance EC2 c более чем 4 ядрами – каждые 4 ядра считаются эквивалентом одному socket ( и требуют соответствующее количество процессорных лицензий ). Oracle Database Standard Edition при этом может быть лицензирована для instance с не более чем 16 виртуальными ядрами, а Oracle Standard Edition One может быть лицензирована для instance c не более чем 8 ядрами. Например для Oracle Database Standard Edition мы имеем 4 instance EC2 c 1 virtual core и 1 instance EC2 c 4 virtual core, тогда общее количество лицензий будет 5 – по 1 лицензии на каждый instance из тех 4 с одним виртуальным ядром, и 1 лицензия на instance c 4 виртуальными ядрами. Также Oracle объявляет о том, что “Basic Limited” и “Premier Limited” поддержки не применимы к instance у которых более чем 8 виртуальных ядер.

Более подробно о лицензировании – Licensing Oracle Software in the Cloud Computing Environment.
Информация в блоге Amazon Web Services.
Официальный пресс релиз – Oracle Unveils New Cloud Computing Products and Services
Статья про Oracle в cloud ( на русском ) – Про Oracle и Amazon EC2

Amazon анонсировал документ посвященный общему описанию системы безопасности своих веб-сервисов – Amazon Web Services: Overview of Security Processes.  Несмотря на то что технических подробностей в документе не описаное, кое-что интересное стоит отметить. Итак, почему мы можем быть уверены что наши данные внутри AWS будут защищенны должным образом? Посмотрим что же обещает Amazon в плане защищенности данных внутри Elastic Compute Clouds ( EC2 ), SimpleDB и Simple Storage Service (S3).

Amazon говорит о том, что дата центры где находятся серверы построены в правильных местах, имеют все уровни физической защиты и опытный персонал. Также говорится о том, что backup данных нет, но зато данные хранятся распределенно, и эта распределенность ничего не стоит пользователям (бесплатна для них:-) ).

C EC2 ситуация следующая – там есть несколько уровней организации доступа – это собственно ОС ( host OS ), поверх нее запущено несколько виртуальных instance c guest OS ( на физически одном host работает несколько instance разных пользователей c разными guest OS), firewall ( регламентирующий доступ по сети к данному instance ) и вызовы API Amazon ( через него работает например Amazon command line tools ) – в целом вся структура должна работать таким образом чтобы данные внутри Amazon EC2 не могли быть доступны неавторизованным пользователям и каждый instance Amazon EC2 должен быть защищен настолько, насколько это возможно без ущерба для гибкости в необходимом для пользователей конфигурировании.
Continue reading ‘Защита данных в веб сервисах Amazon’ »

Я  несколько раз пытался что то написать, но не мог решить с чего же начать рассказывать про Амазон 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’ »