Amazon Web Services *

Сегодня Amazon анонсировали новый инструмент для Amazon Simple Email Service под названием Mailbox Simulator.

Привет всем!

Совсем недавно, в августе 2012, Amazon выпустили новую крутую фичу — EBS с предустановленым количеством IOPS (Input/Output Operations Per Second). Для тех, кто использовует AWS для высоконагруженных проектов и для софта, который очень нуждается в быстром диске это стало манной небесной.

До введения фичи можно было использовать EBS со скоростью до 100 IOPS.

Недавно, наряду с новыми девайсами Kindle, Amazon не прошла стороной и более старую модель 3.
новое обновление включает в себя несколько новшеств, а именно:

1. Шрифт — теперь шрифт более контрастный и четкий. (хотя я ничего не заметил)
2. Родительский контроль — Теперь родители могут запретить Браузер и покупки на AmazonStore
3. Kindle Format 8: с KF8 книги выглядят красивее, с использованием авторских шрифтов и стилей.
4. Whispersync for Voice: теперь можно переключаться с режима чтения и аудио, не теряя места чтения. Whispersync синхронизирует место чтения со всеми девайсами Android, Kindle или PC

О том, как обновиться до версии 3.3 я писал ранее на Хабре.
О том, как обновить читаем в оригинале.

Доброго времени суток, хабровчане!



В данном посте хочу рассказать о своем первом опыте работы с Amazon Product Advertising API. Этот API позволяет Вам производить параметризированный поиск товаров и всей информации, которая с ними связана на сайтах амазона. Также есть партнерская программа про помощи, которой можно в дальнейшем монетизироваться (1. Получаете Партнерский ID, 2. Добавляете его в запросы, 3. Profit? ...). Зарегистрировать партнерку можно тут.

Привет хабр!

Занесла меня судьба в город ветров Чикаго на довольно привлекательное мероприятие — Cloud Connect Chicago 2012. Чем же может быть привлекательной конференция на другой стороне земли? Тем, что можно увидеться, послушать и познакомиться с людьми, опыт которых внушает доверие. Перенять этот опыт — это то, зачем я сюда прилетел.

Итак, о чём же конференция? Как понятно из названия, речь идёт об облаках и о всём, что с ними связано, а именно:

• Облака и безопасность (самая жаркая тема)
• Приватные, публичные и гибридные облака
• Инфраструктура
• Готовность приложений
• Дизайн и архитектура приложений
• Мобильные облака
• … и многое другое

Amazon Glacier

Вкратце — Amazon Glacier — это сервис с очень привлекательной ценой сторейджа, созданный для хранения архивов/бэкапов. Но процесс восстановления архивов довольно сложный и/или дорогой. Впрочем, сервис вполне пригоден для secondary backup.
Подробнее про Glacier уже писали на хабре.

О чём пост

Хочу поделиться Open Source клиентом на Perl для синхронизации локальной директории с сервисом Glacier, также расказать о некоторых ньюансах работы с glacier и описать workflow его работы.

И назвал его Amazon Glacier.
А теперь немного вкусного:
1) Стоимость 1 цент за гигабайт.
2) Только секьюрная передача данных по ssl.
3) Надежность, она же доступность 99.999999999%, что выше чем у s3.
4) Расширяемость, можете хранить сколько хотите данных если у вас есть на это деньги.
5) Простота использования.
6) Поддержка передачи данных из некоторых сервисов амазона, к примеру с s3(я там храню бекапы и думаю перенести их на новое хранилище, думаю это будет очень легко).

Ещё инфа aws.amazon.com/glacier

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

Сегодня начал работу новый проект Amazon Glacier: долговременное хранилище в облаке по невысокой цене $0,01 за 1 ГБ в месяц. Идеально подходит для хранения бэкапов и больших архивов, к которым не нужен частый доступ. Извлечение данных из Glacier занимает от 3,5 до 4,5 часов.

Как везде в AWS, пользователь оплачивает только тот объём ресурсов, которые реально использует, никакой абонентской платы. Загрузка и извлечение архивов, мониторинг статуса возможны через Amazon Glacier APIs. Все файлы автоматически шифруются AES 256 и дублируются в разных дата-центрах, прежде чем APIs возвращают ответ SUCCESS.

В этой части будут рассмотрены следующие варианты построения высокодоступных систем на базе AWS:

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

Первая часть здесь.

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

Добрый день!

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

В качестве инициатора маштабирования будет выступать Cloud Watch. Метрикой будет наша кастомная метрика Load Average.

Итак, начнём-с. Первое, как тру линуксоид, я советую и рекомендую использовать в настройке автоскейлинга утилиты командной строки (Command Line Tools — CLT) по следующим причинам:

• из CLT можно сделать всё;
• удобнее копипастить в консоль, чем кликать мышкой.

Добрый день!

Возник мелкий, но неприятный момент, когда при масштабировании хост, который потушен, чуть более 30-35 секунд ещё принимает запросы. Естественно, эти запросы отработать не могут. Потому возникла идея прежде чем тушить веб сервер, принудительно отключать инстанс от лоад балансера.

Для этого нам нужны утилиты командной строки для ELB: aws.amazon.com/developertools/2536. Распакуем их в папку /opt/aws/elb.

Даже у таких монстров облачной индустрии, как 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.