Преимущества EBS по сравнению с хранилищем экземпляров (и наоборот) [закрыто]

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

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

Вот почему

• Экземпляры, поддерживаемые EBS, можно настроить так, чтобы их нельзя было (случайно) завершить через API.
• Поддерживаемые EBS экземпляры могут быть остановлены, когда вы их не используете, и возобновлены, когда они вам снова понадобятся (например, приостановка работы виртуального ПК), по крайней мере с моими шаблонами использования, которые экономят гораздо больше денег, чем я трачу на несколько десятков ГБ хранилища EBS.
• Поддерживаемые EBS экземпляры не теряют свое хранилище экземпляров при сбое (не является обязательным требованием для всех пользователей, но делает восстановление намного быстрее)
• Вы можете динамически изменять размер хранилища экземпляров EBS.
• Вы можете перенести хранилище экземпляров EBS на новый экземпляр (полезно, если оборудование на Amazon, на котором вы работали, становится ненадежным или умирает, что время от времени происходит)
• Запускать экземпляр с поддержкой EBS быстрее, потому что изображение не нужно извлекать из S3.
• Если оборудование вашего экземпляра, поддерживаемого EBS, запланировано для обслуживания , остановка и запуск экземпляра автоматически переносятся на новое оборудование. Я также смог переместить экземпляр, поддерживаемый EBS, на неисправное оборудование, принудительно остановив экземпляр и запустив его снова (пробег может зависеть от неисправного оборудования).

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

EBS все еще может потерпеть неудачу - не серебряная пуля

Имейте в виду, что любая часть облачной инфраструктуры может выйти из строя в любое время. Планируйте свою инфраструктуру соответственно. Хотя экземпляры, поддерживаемые EBS, обеспечивают определенный уровень долговечности по сравнению с экземплярами эфемерного хранилища, они могут и не работать. Иметь AMI, из которого можно запускать новые экземпляры по мере необходимости в любой зоне доступности, создавать резервные копии важных данных (например, баз данных) и, если позволяет бюджет, запускать несколько экземпляров серверов для балансировки нагрузки и избыточности (в идеале в нескольких зонах доступности). ).

Когда не до

В некоторые моменты времени может быть дешевле добиться более быстрого ввода-вывода в экземплярах Instance Store. Было время, когда это было правдой. Теперь есть много вариантов хранения EBS, удовлетворяющих многие потребности. Варианты и их цены постоянно меняются по мере изменения технологий. Если у вас есть значительное количество экземпляров, которые по-настоящему одноразовые (они не сильно повлияют на ваш бизнес, если они просто уйдут), посчитайте соотношение затрат и производительности. Поддерживаемые EBS экземпляры также могут умереть в любой момент времени, но мой практический опыт показывает, что EBS более долговечен.

99% нашей установки AWS пригодны для вторичной переработки. Так что для меня это не имеет значения, если я прекратить инстанс - ничего не потеряно никогда. Например, мое приложение автоматически развертывается на экземпляре из SVN, наши журналы записываются на центральный сервер системного журнала.

Единственное преимущество хранилища экземпляров, которое я вижу, - это экономия средств. Иначе выигрывают инстансы, поддерживаемые EBS. Эрик упомянул все преимущества.

[2012-07-16] Я бы сказал, что этот ответ сильно отличается сегодня.

У меня не было хорошего опыта работы с инстансами, поддерживаемыми EBS, в прошлом году или около того. Последние простои на AWS также сильно разрушили EBS.

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

Избавимся от того, где мы переместили кластер баз данных обратно в железо (= реальное оборудование). Единственным оставшимся элементом в нашей инфраструктуре является сервер БД, где мы объединяем несколько томов EBS в программный RAID и выполняем резервное копирование два раза в день. Что бы ни было потеряно между резервными копиями, мы можем жить с этим.

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

Кроме того, как ведет себя сетевое хранилище, вся сеть является общей для экземпляров EC2. Чем меньше экземпляр (например, t1.micro, m1.small), тем хуже он становится, потому что ваши сетевые интерфейсы на реальной хост-системе разделены между несколькими виртуальными машинами (= ваш экземпляр EC2), которые работают поверх него.

Чем крупнее экземпляр, тем лучше он становится. Лучше здесь значит в пределах разумного .

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

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

Нам нравится магазин экземпляров. Это вынуждает нас делать наши экземпляры полностью пригодными для повторного использования, и мы можем легко автоматизировать процесс создания сервера с нуля на основе данного AMI. Это также означает, что мы можем легко поменять AMI. Кроме того, EBS все еще время от времени имеет проблемы с производительностью.

Эрик в значительной степени прибил это. Мы ( Bitnami ) являемся популярным поставщиком бесплатных AMI для популярных приложений и сред разработки (PHP, Joomla, Drupal, вы поняли). Я могу вам сказать, что поддерживаемые EBS AMI значительно более популярны, чем поддерживаемые S3. В общем, я думаю, что экземпляры с поддержкой s3 используются для распределенных, ограниченных во времени заданий (например, крупномасштабная обработка данных), где, если один из компьютеров выходит из строя, другой просто раскручивается. AMIS, поддерживаемые EBS, обычно используются для «традиционных» серверных задач, таких как веб-серверы или серверы баз данных, которые сохраняют состояние локально и, следовательно, требуют, чтобы данные были доступны в случае сбоя.

Один аспект, о котором я не упомянул, - это то, что вы можете делать моментальные снимки экземпляра, поддерживаемого EBS, во время работы, что позволяет вам создавать очень экономичные резервные копии вашей инфраструктуры (моментальные снимки основаны на блоках и являются инкрементными).

У меня был точно такой же опыт, как у Эрика на моей последней должности. Теперь на моей новой работе я выполняю тот же процесс, который выполнял на своей последней работе: перестраивать все их AMI для экземпляров с поддержкой EBS - и, возможно, как 32-битные машины (дешевле), но не могу использовать тот же AMI на 32 и 64 машины).

Поддерживаемые EBS экземпляры запускаются достаточно быстро, поэтому вы можете начать использовать API Amazon AutoScaling, который позволяет использовать метрики CloudWatch для запуска дополнительных экземпляров и регистрации их в ELB (Elastic Load Balancer), а также для их выключения при больше не требуется.

Этот вид динамического автоматического масштабирования - вот что такое AWS, и в этом может помочь реальная экономия ИТ-инфраструктуры. Практически невозможно выполнить автоматическое масштабирование правильно со старыми экземплярами, поддерживаемыми s3 «InstanceStore».

Я только начинаю использовать EC2, поэтому не эксперт, но собственная документация Amazon гласит:

мы рекомендуем использовать локальное хранилище экземпляров для временных данных, а для данных, требующих более высокого уровня надежности , мы рекомендуем использовать тома Amazon EBS или выполнять резервное копирование данных в Amazon S3.

Акцент мой.

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

Я постараюсь не забыть взвесить снова после того, как я использовал оба.

EBS похож на виртуальный диск виртуальной машины:

• Прочные, экземпляры, поддерживаемые EBS, можно свободно запускать и останавливать (экономя деньги)
• Может быть сделан снимок в любой момент времени, чтобы получить резервные копии на определенный момент времени
• AMI могут быть созданы из снимков EBS, поэтому том EBS становится шаблоном для новых систем

Хранение экземпляра:

• Локально, так вообще быстрее
• В обычных случаях не входящие в сеть операции ввода-вывода EBS осуществляются за счет пропускной способности сети (за исключением случаев, оптимизированных для EBS, которые имеют отдельную пропускную способность EBS)
• Имеет ограниченное число операций ввода-вывода в секунду. Даже обеспеченные I / O максимально достигают нескольких тысяч IOPS
• Хрупкое. Как только экземпляр останавливается, вы теряете все в хранилище экземпляра.

Вот где можно использовать каждый:

• Используйте EBS для резервного раздела ОС и постоянного хранилища (данные БД, критические журналы, конфигурация приложения)
• Используйте хранилище экземпляров для данных в процессе, некритических журналов и переходного состояния приложения. Пример: внешнее хранилище сортировки, временные файлы и т. Д.
• Хранилище экземпляров также можно использовать для данных, критичных к производительности, когда происходит репликация между экземплярами (NoSQL DB, распределенные системы очередей / сообщений и DB с репликацией).
• Используйте S3 для данных, совместно используемых системами: входной набор данных и обработанные результаты, или для статических данных, используемых каждой системой при запуске.
• Используйте AMI для предварительно запеченных, запускаемых серверов

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

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

Для кого-то нового для всего этого, и если случайно приземлился здесь

На данный момент все AMI в разделе быстрого запуска поддерживаются EBS

Также в официальном документе есть хорошее объяснение различий между EBS и Instance store.

& это изображение в значительной степени подводит итог

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

Как объяснено в документации по томам EBS и ответе от j2d3 и Сиддхарта Шармы, хранилище экземпляров может работать столько времени, сколько вы хотите, но его нельзя остановить . Означает, что служба не может быть запланирована с помощью автоматического запуска / остановки или восстановления экземпляра .

Кроме того, для такого рода схемы не существует также никакой выгоды использовать EBS Опираясь на Elastic Beanstalk как он предназначен для того , чтобы все ресурсы , которые нужны продолжают работать . Он всегда будет автоматически перезапускать любые службы, которые вы остановите. Рассмотрение всего остального , из общей суммы расходов на использование VPC , EBS и ELB , добавленных к EC2-Classic , EC2-VPC с ELB является в основном лучшим выбором, где, в отличие от EC2-Classic , остановленный экземпляр сохраняет связанный с ним Elastic IP-адресаи объем EBS сохраняется автоматически.

В качестве вывода , взяв основную часть вашего вопроса:

кажется, что EBS гораздо полезнее (остановка, запуск, сохранение + лучшая скорость) при относительно небольшой разнице в стоимости ...?

Ответ - да, но если ваш экземпляр основан на EBS, его можно остановить. Он останется в вашей учетной записи, вы не будете платить за это . Вы будете платить только за объем, но EBS взимается каждый час . Вы также можете учитывать, что среди всех доступных типов вы можете изменить размер тома EBS .

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

Однако, если существует сценарий запуска приложения в более дешевом сервисе, перенесите все необработанные задачи и перенесите их в VPC / EBS через конвейер или лямбду в течение короткого времени, скажем, <1 час в день, что невозможно сделать, когда вы используйте инстанс-магазин , тогда это будет другая история.