Рекомендуется ли Amazon EC2 для постоянного общедоступного веб-сайта?

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

Зарезервированные инстансы дешевле. Получите их, если планируете какое-то время иметь такой экземпляр. Это просто вопрос стоимости / бюджета.

Никогда не слышал о людях, теряющих инстанс EC2.

Не очень разбираюсь в EBS, но S3 - хороший способ резервного копирования данных.

HTH

РЕДАКТИРОВАТЬ:

Наткнулся на некоторые ссылки, которые могут быть полезны. Ваше здоровье.

http://techblog.netflix.com/2010/12/four-reasons-we-choose-amazons-cloud-as.html

http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html

http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html

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

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

EC2 предназначен для работы аналогично, но он не так инкапсулирован, как S3 и SimpleDB, поэтому вам придется спланировать небольшую работу самостоятельно. Например, если вам нужен веб-сервис с гарантированным временем безотказной работы и доступностью, вы захотите изучить сервис AWS ELB (Elastic Load Balancing). Таким образом, если экземпляр не работает, запросы будут автоматически перенаправляться на другие работоспособные экземпляры. Для своих данных вы можете либо хранить их в других сервисах AWS (например, S3, SimpleDB и EBS), которые имеют встроенную избыточность, либо вы можете создать собственное решение, используя аналогичные методы избыточности.

SLA не имеет значения, когда мы выяснили, что:

1. Экземпляры и тома EBS БЫЛИ потеряны

2. На восстановление после аварии у Amazon уходит более 2 дней, да и то не в полной мере.

Нам повезло, что удалось встать на ноги менее чем за 2 дня. Другие компании застряли без возможности восстановления.

А что рекомендует Amazon? «Не верьте нашей надежности. Заплатите еще 2 или 3 копии вашей системы в разных регионах, и тогда вы будете в безопасности».

Более подробную информацию можно найти здесь:

http://www.zdnet.com/blog/saas/lightning-strike-zaps-ec2-ireland/1382

tldr: AWS очень надежен, если вы знаете, что делаете, и плохая идея, если вы этого не сделаете.

Поскольку вы не знакомы с терминами, вот очень быстрый глоссарий: AZ - зона доступности, есть несколько зон доступности на регион (например, 3 в Ирландии). Это физические изолированные дата-центры с разными электросетями, поймами и т. Д. Но с внутренними сетевыми скоростными соединениями. Возможно, даже вероятно, что в какой-то момент АЗ может стать недоступным, хотя я не думаю, что все АЗ в регионе когда-либо были недоступны.

EBS / Instance Store - это два основных типа хранилища, доступных для экземпляра. Лучший способ описать их: Instance Store - это эквивалент жесткого диска, который вы подключили через sata к материнской плате - это очень быстро. Но что произойдет, если вы выключите свой экземпляр (или если материнская плата выйдет из строя) и захотите немедленно начать работу на другой плате? (Amazon полностью скрывает настройку физического оборудования), очевидно, вы не собираетесь ждать, пока инженер отключит диск от одного сервера к другому, поэтому они даже не предлагают этого. Хранилище экземпляров работает быстро, но временно и привязано к физическому компьютеру. НЕ храните на нем ничего важного. В таком случае EBS представляет собой альтернативу сетевому диску с очень малой задержкой, к которому любой сервер может подключиться, как если бы он был локальным. Вы выключаете сервер, меняете его размер и перезапускаете на совершенно другом сервере на другой стороне центра обработки данных (опять же, физический материал скрыт), не имеет значения, что ваши приливы никуда не делись (по умолчанию они также находятся на нескольких физические диски).

Товарное облачное оборудование. Моя интерпретация того, что «облачное оборудование постоянно выходит из строя - оно действительно рискованно и ненадежно» заключается в том, что да, оборудование AWS не так надежно, как компоненты корпоративного уровня в управляемом центре обработки данных. Это не означает, что он ненадежен, это просто означает, что вы должны встроить отказ как вариант в свой дизайн.

Первое, что следует отметить при разговоре об SLA, - это то, что amazon очень четко заявляет, что SLA применяется ТОЛЬКО в случае отказа одной или нескольких зон доступности. Так что, если вы не понимаете, как работает их служба, и строите только один сервер в одной зоне доступности, а генератор или маршрутизатор выходит из строя, это ваша собственная вина.

Что касается восстановления, это зависит от того, хранится ли все состояние вашего приложения на одном сервере - если это так, не беспокойтесь об облаке. Однако, если вы можете кластеризовать свое состояние на нескольких серверах, сохраните его в RDS или какой-либо другой постоянной базе данных. ИЛИ, если ваш контент меняется так редко, вы можете использовать периодические копии в хранилище s3, все будет в порядке. Стратегия отказа (в порядке предпочтения) может быть кластерной, отказоустойчивой или автоматическим. Для первого у вас есть кластерные серверы, разделяющие состояние - неважно, потеряете ли вы сервер или зону доступности. Во втором случае у вас есть только один активный сервер, но если он выйдет из строя, у вас будет резервное переключение с тем же контентом. Наконец, с автоматическим ремонтом возможны две ситуации: если ваши данные находятся только на одном диске EBS, вы можете запустить другой экземпляр с тем же диском и продолжить. Но если диск EBS или зона доступности выйдет из строя, вам нужно будет подготовить какой-нибудь моментальный снимок в s3, который можно скопировать и запустить с помощью совершенно нового экземпляра.

Зарезервированные экземпляры не более надежны - это одно и то же оборудование, вы просто заключаете контракт, чтобы сказать, что у меня будет x машин на y лет. Это позволяет AWS лучше планировать, а это дешевле для вас.