Amazon Web Services *

Привет, хабрасообщество!

Сегодня я, наконец, набрался смелости и имею время рассказать вам о замечательном сервисе, который предоставляет Amazon Web Services: Virtual Private Cloud — VPC.

VPC — это сервис, позволяющий создавать приватные изолированные сети в публичном облаке Amazon. Что же предоставляет VPC?

• Подсети серых адресов
• Полный контроль над адресами
• Динамическое и удобное управление сетевыми устройствами и маршрутизацией
• Поддерживает EC2, RDS, SQS, ElastiCache и другие сервисы
• Многое другое..

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

Привет!

Amazon Web Services предоставили своим пользователям новый сервис обработки видео Elastic Transcoder. Как вы понимаете, основной смысл — транскодирование видео.

Сервис представляет собой некий дата пайплайн. Мы даём ему информацию откуда брать видео, куда и в каком формате класть и всё. Я уже попробовал и хочу вам показать-рассказать что и как.

Недавно встала задача развернуть виртуальный сервер Ubuntu 12.04 на Amazon EC2 для некоего сервиса и присвоить ему доменное имя в существующей доменной зоне, но как известно Amazon меняет публичный и локальный адреса после перезагрузки или выключения машины, поэтому было решено использовать bash (для *nix) и bat (для Windows) для автоматизации обновления динамического адреса для хостинга.

Привет!

Сразу вслед за High-Storage Eight Extra Large Amazon Web Services анонсировали новый тип инстансов для In-Memory вычислений — High Memory Cluster Eight Extra Large Instance.

Итак, технические характеристики нового типа инстанса:

• два восьмиядерных процессора Intel E5-2670 с частотой 2.6 GHz с поддержкой Intel Turbo Boost и NUMA
• 244 ГБ ОЗУ (!)
• два 120 ГБ SSD винчестера
• 10 Гб сеть для Cluster Placement Groups0
• только HVM виртуализация
• только EBS-backed AMI

In God we trust, the rest we automate
— unknown DevOps Engineer

Использование виртуализации и облачных платформ позволяет в десятки раз сократить время, затрачиваемое на запуск и обслуживание IT инфраструктуры. Один человек может манипулировать десятками, сотнями и даже тысячами виртуальных серверов, с легкостью их запускать, останавливать, клонировать, изменять конфигурацию оборудования и создавать на их основе готовые образы систем. Если все ваши сервера имеют одинаковую конфигурацию, то особых проблем нет, можно один раз вручную настроить сервер, сделать на его основе образ и запускать столько машин, сколько вам необходимо. Если же у вас большое количество разных операционных систем с разным набором программного обеспечения или если вам необходимо быстро запускать и останавливать сложные кластерные конфигурации, то обслуживание даже нескольких десятков таких серверов будет занимать очень много времени. Можно, конечно иметь набор разных скриптов и образов на все случаи жизни, которые необходимо будет сопровождать и обновлять, но более рационально использовать один скрипт и несколько образов, а все необходимые параметры передавать при старте системы. Многие платформы для облачных вычислений предлагают, так называемый, механизм метаданных (metadata) или пользовательских данных (user-data), используя этот механизм, вы можете передать скрипту все необходимые данные по настройке конкретной виртуальной машины или даже передать сам скрипт, чтобы он выполнился при старте.

Однажды Ubuntu на ноутбуке перестала запускаться, ругаясь на поврежденную xfs на диске. Мало того, на нем хранился проект, над которым я работаю. Был, правда, git-репозиторий на EC2 машине, однако pem-файл лежал на этом же диске.
Упомяну так же, что не ставил на сервер FTP, доступ по SFTP нельзя было бы получить без ключа.
Конечно можно долго говорить о прелестях резервного копирования, однако пришлось искать способ как восстановить доступ к облачной машине, чтобы не потерять уже сделанную работу.

Привет!

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

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

В данный момент я занимаюсь поиском подходящих серверов для инфрастуктуры моего проекта. Я остановился на EC2 и решил проанализировать, какое решение будет наиболее экономически выгодным для меня. Эта статья по сути является продолжением AWS Insight: Резервации в EC2 — как это работает, но приводит анализ для молодого веб-стартапа (24x7).

Проблема

Сервер должен работать 24 часа в сутки напротяжении X месяцев (количество не определено). Какой вариант (On Demand / Light Utilization Reserved / Medium Utilization Reserved / Heavy Utilization Reserved) выбрать для Micro/Small/Medium/Large серверов?

Привет!

Мои поздравления пользователям Android! С сегодняшнего дня доступно официальное приложение для управления облаком Amazon Web Services с вашего девайса со следующим функционалом:

• Просматривать детали серверов EC2 и метрик CloudWatch
• Фильтровать и сортировать серверы EC2 и метрики CloudWatch
• Останавливать и перегружать серверы EC2
• Просматирвать тревоги из CloudWatch
• Просматривать графики из CloudWatch
• Просматривать автоматические действия для CloudWatch
• Переходить из тревог CloudWatch на EC2 серверы, которые пострадали
• Работать во всех регионах
• Переключаться между разными пользователями

Привет!

Пару месяцев назад я писал AWS Global Start-Up Challenge. Это мероприятие набрало обороты и собрало заявки представителей из 84 стран мира со всех обжитых континентов нашей планеты.

Итак были выбраны полуфиналисты в 4 номинациях по темам:

• Big Data & High Performance Computing
• Business Applications
• Consumer Applications
• Gaming

Привет!

Продолжая тему об экономии денег в облаках, сегодня я расскажу о Spot Instances. Напомню, что в AWS есть как минимум 3 основных вида оптимизации расходов:

• автомасштабирование
• резервирование
• использование спот инстансов

Что такое Spot инстанс?

Это обычный EC2 или VPC инстанс, но есть некоторые нюансы работы:

1. Как было сказано ранее, это обычный инстанс. Вычислительные и сетевые ресурсы, дисковые скорости и всё остальное у машин такое же, как и обычных EC2 инстансов.
2. Вы сами устанавливаете цену, которую будете платить за час использования инстанса. Больше вы платить не будете.
3. Инстанс может быть выключен в любое время, если, например, кто-то предложил цену больше за слот, который вы занимаете, а других нет.
4. Оплата производится за полный час работы инстанса. Часть часа отбрасывается в пользу клиента — в меньшую сторону до полного часа.

На странице стоимости компонентов EC2 на Амазоне есть одна строчка, на которую сначала можно не сильно обратить внимание, но которая может привести к серьезным финансовым затратам — Data Transfer, трафик. Если аренду инстансов и EBS-томов можно запланировать и контролировать, то трафик предсказать довольно сложно, а игнорировать его не даст ежемесячный счет)

Для примера: средний новостной сайт, 30 тысяч посещений в сутки, его вполне потянет небольшой small или даже micro instance. Возьмем полный размер страницы 2 мегабайта, месячный трафик тогда будет (без учета закэшированного контента) — 30000 * 0.002 * 30 = 1800 GB или $216. Получается стоимость Data Transfer даже больше аренды самого инстанса! На S3 ситуация с ценами на трафик точно такая же.

Здесь, в awe.sm, мы с самого начала использовали Amazon AWS для хостинга. За последние три года мы изучили, что хорошо, а что не очень и сформулировали для себя свой собственный набор правил для запуска высоко доступной, высоко производительной системы, которые в некоторых случаях отличаются от того, что советует Amazon.

Мы собираемся поговорить о следующих родственных понятиях:

1. Для людей, которые слышали об Amazon, но еще не имели возможности его использовать, мы покажем все преимущества и недостатки этого сервиса, с которыми мы столкнулись в своей работе.
2. Для тех, кто уже использует AWS, мы проясним некоторые детали и расскажем о лучшей практике использования Amazon для таких высокопроизводительных сервисов, как наш, где непрерывная работа системы является самым высоким критерием.

Это частичный перевод статьи Netflix, касается только проблемных мест перехода c Oracle DB на Amazon SimpleDB и способов их решения компанией.

Где-то в конце 2008 года, у Netflix был всего один датацентр. И этот ДЦ поставил перед нами несколько вопросов. Как единственная точка отказа, к примеру, из-за проблем с электричеством, он мог привести к недовольству наших пользователей сервисом. К тому же, с одновременным ростом трафика потокового вещания и подписок на услуги, Netflix скоро бы переросла этот дата центр — мы видели неизбежную потребность в электроэнергии, лучшем охлаждении, нам требовалось больше места и больше оборудования.

Как вариант, можно было построить новые дата центры. Однако, кроме высоких затрат, это усилие привело бы к тому, что наши технические кадры не смогли бы заниматься новыми продуктами, так были бы заняты расширением ДЦ. К тому же, мы понимали, что управление несколькими дата центрами сложная задача. Строительство и поддержка нескольких дата центров казались нам опасным отвлечением от нашего основного бизнеса.

Вместо того, чтобы встать на этот путь, мы выбрали более радикальный. Мы перешли на решение IAAS (инфраструктура как сервис), предлагаемое в то время веб-сервисом Amazon. Со множеством уже работающих центров обработки данных, многократным уровнем избыточности различных сервисов (таких как, S3 и SimpleDB), AWS обещал лучшую доступность и маштабируемость за относительно короткое время.

Отдавая различные сетевые и фоновые задачи в аутсорсинг, Netflix сосредоточилась на своем основном бизнесе, поставке фильмов и сериалов.

В процессе перехода на инфраструктуру AWS мы сформулировали набор лучших практик, необходимых для работы с AP системами, такими как SimpleDB.

Привет!

Вчера я написал статью о производительности EBS. Оказалось, что наиболее производительным будет RAID 10 из EBSoв. Помимо того, что RAID быстрее, это ещё и экономически более выгодно. Минимальная стоимость в месяц EBS диска с 2000 IOPS (минимальный размер 200 GB)

200 * $0.125 + 2000 * $0.10 = $225

Тот же объём информации в 200 GB в RAID10, состоящий из 8 стандартных EBS по 50 GB:

8 * (50 * $0.10) = $40

Исходя из расчётов, RAID дешевле более чем в пять с половиной раз.

Привет!

Очень много в интернете позитива/негатива об EBS. Так же не мало тестов на их производительность. Я решил сам провести несколько тестов и сделать небольшое исследование по этому поводу.

Итак, в тесте участвовала машинка m1.large к которой были примаунчены диски:

• EBS Standard, 100 GB
• EBS IO-1 500 IOPS, 100 GB
• EBS IO-1 1000 IOPS, 100 GB
• EBS IO-1 2000 IOPS, 200 GB
• 8xEBS Standard, 30 GB, RAID 10
• Ephemeral, 450 GB

Были проведены несколько тестов:

# hdparm -tT /dev/xcdX

# dd if=/dev/zero of=tempfile bs=5M count=1024 conv=fdatasync,notrunc
# echo 3 > /proc/sys/vm/drop_caches
# dd if=tempfile of=/dev/null bs=5M count=1024

# sysbench --num-threads=16 --test=fileio --file-total-size=5G --file-test-mode=rndrw prepare
# sysbench --num-threads=16 --test=fileio --file-total-size=5G --file-test-mode=rndrw run

Исходя из недавнего отчета IWGCR (International Working Group on Cloud Computing Resiliency) каждый год сервисы облачных вычислений недоступны, в среднем, в течение 7.5 часов. Компании, которые частично или полностью используют облака для своих приложений и сервисов, в этом году пострадали несколько раз. Давайте рассмотрим самые большие отказы в работе облачных сервисов в 2012 году.

Привет!

Вы используете утилиты командной строки для управления серверами и сервисами AWS? Как же надоело обновлять и качать их из разных мест. Да и неоднородность команд тоже не радует…

AWS официально выпустили консолидированный CLI, который в последствии будет включать в себя все доступные сервисы. А сейчас можно управлять

• Amazon Elastic Compute Cloud (Amazon EC2)
• Elastic Load Balancing
• Auto Scaling
• AWS CloudFormation
• AWS Elastic Beanstalk
• Amazon Simple Notification Service (Amazon SNS)
• Amazon Simple Queue Service (Amazon SQS)
• Amazon Relational Database Service (Amazon RDS)
• AWS Identity and Access Management (IAM)
• AWS Security Token Service (STS)
• Amazon CloudWatch
• Amazon Simple Email Service (Amazon SES)

Доброго дня всем поклонникам электронных книг!

Этот пост будет небольшим и посвящён он будет тому, как можно официально и бесплатно отключить рекламу (Special Offers) в новом Kindle Paperwhite (хотя способ, как я понимаю, актуален для всех поколений и моделей Kindle). Сегодня ко мне приехал мой Paperwhite with Special Offers, и я сразу же начал курить Гугл в поисках относительно безопасного и проверенного метода избавления от рекламы (нужно заметить, что процессу чтения эта реклама в принципе не мешает, просто не люблю я её).

Привет!

Новая радость для тех, кому важен размер. Amazon Web Services анонсировали монструозный сервер со следующими параметрами:

• 117 GiB of memory
• 35 EC2 Compute Units (16 virtual cores)
• 24 hard disk drives each with 2 TB of instance storage
• 64-bit platform
• I/O Performance: Very High (10 Gigabit Ethernet)
• Storage I/O Performance: Very High
• EBS-Optimized Available: No
• API name: hs1.8xlarge