Блог

Моя компания собирается написать новый общедоступный веб-сайт в SharePoint (например, Windows Server 2008 RC2, SQL Server 2008 RC2 и т.д.), И мы рассматриваем возможность использования Amazon EC2 для его размещения. Я читал, и мне сказали, что экземпляры могут исчезать (часто из-за ошибки пользователя, но также пакетно), поэтому я скептически отношусь к тому, что EC2 — лучшая идея для нас.

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

1) Крайне важно, чтобы наш веб-сайт был доступен для широкой публики как можно чаще (обычно время работы составляет 99,9%). По соглашению об уровне обслуживания Amazon EC2 доступность составляет 99,95%, и это нормально, но что произойдет, если мы достигнем этого сценария с 0,05%? Будет ли потерян наш экземпляр E2? Можно ли их восстановить? Если да, то что нам нужно сделать, чтобы гарантировать восстановление до не слишком старой версии нашего сайта?

2) Я читал об Amazon Elastic Block Store (EBS) и о том, как это сохраняется независимо от срока службы экземпляра. Если я правильно понимаю, EBS подобен жесткому диску, поэтому, если экземпляр потерян, мы можем запустить новый экземпляр с помощью нашего EBS для восстановления последней версии, в то время как «локальное хранилище экземпляров» будет потеряно, если экземпляр также будет потерян. Это правильно?

3) Являются ли «зарезервированные экземпляры» более стабильным вариантом? т. Е. Они с меньшей вероятностью исчезнут? Если они все же исчезнут, какие преимущества для восстановления они предлагают, если таковые имеются?

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

Большое спасибо.

Кевин

Мы полагаемся на 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 (Эластичная балансировка нагрузки). Таким образом, если экземпляр недоступен, запросы будут автоматически перенаправляться другим работоспособным экземплярам. Что касается ваших данных, вы можете либо сохранить их в других сервисах AWS (таких как S3, SimpleDB и EBS), которые имеют встроенную избыточность, либо создать собственное решение, используя аналогичные методы резервирования.

Соглашение об уровне обслуживания равно нулю, когда мы узнали, что:

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 в Ирландии). Это физически изолированные центры обработки данных с различными сетями электропитания, пойменными равнинами и т.д. Но при качественном быстродействующем подключении к внутренней сети. Возможно, даже вероятно, что AZ может стать недоступным в какой-то момент, я не думаю, что все AZ в регионе когда-либо были недоступны.

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

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

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

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

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