Amazon Web Services *

Даже у таких монстров облачной индустрии, как Amazon случаются проблемы с оборудованием. В связи с недавними перебоями в работе US East-1 датацентра, данная статья может быть полезной.

Варианты построения высокодоступных систем в AWS. Преодоление перебоев в работе

Отказоустойчивость является одной из основных характеристик для всех облачных систем. Каждый день множество приложений проектируются и разворачиваются на AWS без учета этой характеристики. Причины данного поведения могут варьироваться от технической неосведомленности в том, как правильно спроектировать отказоустойчивую систему до высокой стоимости создания полноценной высокодоступной системы в рамках сервисов AWS. В данной статье освещается несколько решений, которые помогут преодолеть перебои в работе оборудования провайдеров и создать более подходящее решение в рамках AWS инфраструктуры.
Структура типичного Интернет приложения состоит из следующих уровней: DNS, Load Balancer, веб сервер, сервер приложения, база данных, кэш. Давайте возьмем этот стек и подробно рассмотрим основные моменты, которые необходимо учитывать при построении высокодоступной системы:

• Построение высокодоступной системы в AWS
• Высокая доступность на уровне веб сервера / сервера приложения
• Высокая доступность на уровне балансировки нагрузки / DNS
• Высокая доступность на уровне базы данных
• Построение высокодоступной системы между зонами доступности AWS
• Построение высокодоступной системы между регионами AWS
• Построение высокодоступной системы между различными облачными и хостинг провайдерами

Часть 2

Привет хабравчане!

Недавно сменил место работы, но всё так же поглощён облачными технологиями. И проектов у меня теперь будет гораздо больше, а с ними и статей, я надеюсь, интересных.

Итак, потребовалось создать метрики по параметрам, которые Cloud Watch считать не умеет. Можно мерять много чего, но, например, возьмём Load Average. Этот странный, но понятный всем параметр, объясняет состояние системы. В целом, мы можем оценивать здоровье сервера по этому состоянию. Естественно, не всегда, но как пример LA идеален.

Что же нам для этого нужно?

1. Amazon CloudWatch Command Line Tools
2. Несколько скриптов

Начнём приготовления на сервере.

1. В папке /opt создадим папку — aws
2. Распакуем утилиты командной строки в папку /opt/aws/mon
3. Ключ и сертификат pk-**.pem и cert-**.pem. Уложим в папку /opt/aws/keys
4. Нужную папку c Java симлинком направим на /usr/java/latest

Компания Amazon объяснила причины обесточивания дата-центра в регионе East-1 в Северной Виргинии, в результате чего 30 июня в офлайн ушли Instagram, Netflix, Pinterest и другие сайты.

Причиной названа некорректная работа дизель-генераторов, точнее, распредилительного щитка (switchboard), который должен был переключить систему с одного канала на другой. После скачка напряжения «генераторы запустились нормально», но если один из дата-центров East-1 запитался от генераторов без инцидентов, то во втором дата-центре «каждый генератор в отдельности не смог обеспечить стабильное напряжение после их запуска», объясняет Amazon. В результате, сеть автоматически не перешла на питание от генераторов, и в UPS’ах вскоре кончился заряд.

В очередном падении AWS не было бы ничего необычного, если бы не причина сбоя. Энергоснабжение дата-центра в регионе US-EAST-1 (Северная Виргиния) нарушено из-за грозы. Ушли в офлайн Netflix, Instagram, Pinterest и многие другие сайты.

Согласно статус-репортам, потеря энергоснабжения начались около 20:21 PDT (сегодня в 07:21 МСК). Через 28 минут подача электричества в дата-центр было восстановлено, и компания Amazon приступила к восстановлению пострадавших томов и инстансов. Эта работа продолжается до сих пор. По состоянию на 10:19 МСК было восстановлено примерно 50% пострадавших инстансов и 33% пострадавших томов.

Amazon сообщает, что из-за потери питания в некоторых восстановленных томах EBS могут быть потерянные кластеры: если ваш оказался среди них, то в консоли AWS в колонке “Status Checks” вы увидите статус “Impaired”. В этом случае для верификации данных рекомендуется запустить утилиту fsck или chkdsk.

В этой статье – как скопировать объект и корзину (bucket) из Amazon S3 в хранилище блобов Windows Azure.

Одним из значительных нововведений после 7 июня 2012 года стало усовершенствование функции Copy Blob. При написании этой статьи я использовал материалы команды разработки, которые можно найти здесь: http://blogs.msdn.com/b/windowsazurestorage/archive/2012/06/12/introducing-asynchronous-cross-account-copy-blob.aspx. Что привлекло моё внимание – функциональность copy blob позволяет копировать блобы извне Windows Azure, если они публично доступны. То есть им нет необходимости находиться в Windows Azure.

ЭТО ОЧЕНЬ КРУТО!!!

Недавно передо мной встала задача использования в своем приложении облачного хранилища. Не сталкивавшись с подобным ранее, я думал что эта задача займет больше времени. Но, на мое удивление, уже разработаны достаточно удобные инструменты для взаимодействия. Пример с их использованием описан в данном топике.

Утром рано(мск) эсэмэска мониторинга разбудила меня.
Уже почти три часа лежит часть площадки AWS EC2 us-east-1 (N. Virginia).
К чести амазона, актуальная информация (почему-то без сроков) появляется на status.aws.amazon.com
«Кина не будет — электричество кончилось».

UP: По факту и по статусу Jun 15, 1:38 AM PDT — всё поднялось.

Приветствую любителей облачных вычислений.
Предлагаю посмотреть на сравнение сервисов Windows Azure Blob Storage и Google Cloud Storage (при этом автор не забывает упомянуть и про Amazon AS3).

Я подумал, что неплохо было бы написать статью по сравнению хранилища Google App Engine и Windows Azure. В этой статье мы сравним Windows Azure Blob Storage и Google Cloud Storage.

Вторая и третья части сравнения сервисов хранилищ Windows Azure и Amazon. Остаётся последняя часть — сравнение Windows Azure Blob Storage и Google Cloud Storage.

В первой части этой статьи мы начали сравнение Windows Azure Blob Storage and Amazon Simple Storage Service (S3), посмотрели на базовые концепции и сравнили ценообразование и функциональность, касающуюся контейнеров блобов и корзин. Читать первую часть.
В этой части статьи мы сравним функциональность, касающуюся блобов и объектов, и закроем сравнение сервисов хранилищ обеих систем, сведя получившиеся данные в одну общую таблицу.

Добрый день, уважаемые коллеги.
Предлагаю вам ознакомиться с переводом очередной части сравнения сервисов хранилища двух известнейших облачных платформ. Остальные переводы будут выкладываться по мере оформления.
Первая часть цикла — Сравнение Windows Azure Table Storage и Amazon DynamoDB
В этом цикле статей я хочу сравнить основную функциональность Windows Azure Blob Storage Service и Amazon Simple Storage Service (S3). В этой части мы посмотрим на основные концепции, ценообразование и сравним функциональность контейнеров блобов и корзин. В части II мы будем сравнивать блобы и объекты. В части III я приведу выводы, в части IV — сравнение Windows Azure Blob Storage и Google Cloud Storage.

Здравствуйте.
Предлагаю вашему вниманию перевод первой статьи из цикла сравнения сервисов, предоставляемых Windows Azure и Amazon, который пишется достаточно известным в облачных кругах специалистом — Gaurav Mantri.

В этой статье я сравню Windows Azure Table Storage и Amazon DynamoDB – WATS и ADDB соответственно.

Помните историю о том, как небольшой сайт в облаке от Amazon получил за месяц счёт на $1170? В комментариях многие спрашивали — почему нельзя сделать так, чтобы при достижении некоего установленного лимита (положим, $50), инстанс просто выключался. Меня тоже волновал этот вопрос, но никакого действенного способа защититься от влетающего в копеечку DDoS или, скажем, хабраэффекта, я не нашёл.

Вебмастера, возрадуемся! Сегодня Amazon прислал письмо, в котором пишет следующее:

Публикую краткий пересказ статьи. Советую прочитать ее полный текст на языке оригинала.

Panos Ipeirotis получил недавно счет от амазона на сумму более $1170, в то время как обычно сумма в его счетах значилась около $100.

Кёртис Спенсер (Curtis Spencer) с коллегами из компании Spool разработали легковесный сервер Fake S3, который ведёт себя как настоящий Amazon S3 и помогает тестировать проекты, не гоняя данные в облако и не тратя деньги на трафик. К тому же, для тестирования Fake S3 надёжнее, потому что работает локально. Спенсер говорит, что благодаря Fake S3 они сэкономили около $1000 за последний месяц на одной только оплате трафика.

Установка

gem install fakes3

Для запуска сервера нужно указать хост и порт

fakes3 -r /mnt/fakes3_root -p 4567

Теперь в AWS есть marketplace, где одним кликом можно запустить приложение, которое будет крутиться на ec2 instance.
Можно запускать mongo, SAP, RHEL, zend server и многое другое.
Часть софта запускается бесплатно и берется только плата за ec2(к примеру mongodb), часть видимо предусматривает поддержку и запускается с оплатой за месяц поддержки и местами даже с оплатой за часы запущенного софта(к примеру запуск NGinX 0.8 Stack with Production Support стоит $149 в месяц).
Пруфлинк
aws.amazon.com/marketplace/ref=pe_12300_23536850_mkt_eml_lnch

Последние 3 года на российском рынке интернет-торговли сайт Marketplace является одним из главных трендов. На западе это стало популярно уже в 2000-2004 годах, когда Amazon стал огромным интернет-магазином и наладил связи со множеством сторонних поставщиков товаров. Для тех, кто не знает, несколько слов о бизнес-модели. В Marketplace есть товарная витрина, куда поставщики выставляют товары. Клиенты заказывают товары, заказы аккумулируются и распределяются по поставщикам. Marketplace устанавливает розничную наценку, за счет чего и живет.

В данной статье хочу сделать обзор компании, которая предоставляет платформу для обслуживания различных Marketplace.

В 2004г для Amazon был разработан движок с API интерфейсом для размещения товаров от сторонних поставщиков на их Marketplace. Как ни странно, исполнителем этого проекта была компания Ixtens, основанная в России.

Английский разработчик Эван Лейт (Ewan Leith) опубликовал пошаговую инструкцию, как поднять виртуальный микросервер на Amazon, Linode или другом облачном хостинге, который сможет крутить блог WordPress и выдерживать 10 миллионов хитов в сутки (отчёт составлен с помощью Blitz.io), при этом будет стоить всего пятнадцать долларов в месяц.

Инструкция описывает, как последовательно установить Ubuntu 11.10 (Oneiric), MySQL, PHP с PHP FPM, APC и модулем MySQL, Nginx с конфигурацией для WordPress, ну и сам WordPress. После этого сервер работает ещё довольно медленно, но всё меняет установка W3 Total Cache и Varnish, которые вместе с Nginx способны сотворить настоящее чудо.

Выполнить действия из инструкции способен даже человек, не являющийся техническим специалистом.

Здравствуйте!

Сегодня я расскажу как настроить массовую рассылку писем через Amazon SES с нуля.

Для начала нужно иметь аккаунт в Amazon Web Services и прикреплённый к нему метод оплаты сервиса. Если у Вас это есть, смело можем начинать!

Настройка SES

Итак, пройдём в консоль: https://console.aws.amazon.com. В списке сервисов ищем SES. Т.к. мы раньше не имели дела c SES, нас встречает удручающая надпись:

Привет!

В 2009 году на «Rails Rumble» Лехом Кульвером и Крисом Ванстратом был создан замечательный инструмент — Hurl.

Hurl — это RoR приложение, предназначенное для того, чтоб посылать HTTP запросы. В целом, функциональность Hurl схожа с Curl. Идея и методы те же, но предназначение совсем другое.

К сожалению, хостинг, на котором стоит официальный Hurl очень нестабильный и медленный и не подходит для корпоративного использования. Технологии opensource дают нам возможность поднять свой экземпляр Hurl и даже сделать его лучше и удобнее.

Итак мы подняли и улучшили Hurl на своём хостинге — hurl.quickblox.com. Приложение настроено на EC2 инстансе, а данные хранятся на S3.

Как и многие другие интернет-компании, Amazon не разглашает информацию о своей инфраструктуре, в том числе о количестве серверов. Но аналитик из Accenture Technology Labs произвёл собственный подсчёт: у него получилось, что в семи дата-центрах Amazon Web Services должно быть по крайней мере 454 400 серверов.

Интересно, что 70% из них находится в регионе US East (Виргиния).

	Кол-во серверных стоек	Кол-во блэйд-серверов
US East (Виргиния)	5030	321 920
US West (Орегон)	41	2624
US West (Сев. Калифорния)	630	40 320
EU West (Ирландия)	814	52 096
AP Northeast (Япония)	314	20 096
AP Southeast (Сингапур)	246	15 744
SA East (Сан-Паулу)	25	1600
Всего	7100	454 400