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


381

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



также «микро» доступно только в том случае, если вы используете EBS-копии.
Али

1
Тома Instance Store намного быстрее и не используют сетевое хранилище!
Мэтт

Я лично использую хранилище экземпляров для того, чтобы выгрузить в него свою коллекцию MongoDB и запустить ее на S3 по двум причинам. Во-первых, он отделен и не будет снижать скорость записи на моем 10-томном EBS RAID. Во-вторых, это намного быстрее, чем EBS, и, поскольку он поставляется с моим экземпляром, для меня нет смысла создавать дополнительные тома EBS для выполнения дампа и уничтожать их после помещения их на S3. надеюсь, что это помогает, а не конструктивно мой ..
Мазияр

2
Я на полпути к руководству пользователя AWS (700 страниц). Внимательно прочитайте о EBS и Instance Storage. Я до сих пор не могу понять, почему есть такие различия. И еще более озадачен тем, почему Instance store эквивалентен S3, но назван по-другому. Вопрос должен быть вновь открыт, чтобы получить больше вклада в полезные ответы.
Полимераза

Ответы:


293

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

Вот почему

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

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

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

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

Когда не до

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


4
Да, выше были и мои мысли ... Надеюсь, что-то здесь напишет о своих предпочтениях для экземпляра store для сравнения ...
HelloWorldy

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

44
На самом деле я переключаю большинство своих поддерживаемых EBS экземпляров EC2 на использование хранилищ экземпляров. Это действительно зависит от того, чего вы хотите достичь. Я переключаюсь из-за лучшего ввода-вывода и потому, что я рассматриваю каждый экземпляр EC2 как одноразовый в любой момент, или: он сломается в любую минуту, и я потеряю все, что есть в таком экземпляре. Такая архитектура помогает получить настоящую систему высокой доступности. См. Также stu.mp/2011/04/the-cloud-is-not-a-silver-bullet.html
Джим Сохо,

2
@Jim: По крайней мере, когда я писал ответ год назад, вы получили гораздо лучший ввод-вывод, добавив несколько экземпляров EBS в программную конфигурацию RAID, чем используя хранилище экземпляров. Также гораздо быстрее запускать заменяющий экземпляр из резервной копии EBS, чем из резервной копии S3 (хранилище экземпляра загружается из S3, что может быть медленным). Я не сделал много на AWS за последние 6 месяцев или около того; все могло измениться.
Эрик Дж.

2
Кажется немного односторонним - хотя можно запускать экземпляры с EBS-Backed и уделять большое внимание утилизации, я думаю, что новички, просматривающие этот пост и впоследствии создающие экземпляры EBS-Backed, опасны, потому что они, вероятно, не будут поддерживать это тот же акцент на вторичной переработке, которая, возможно, является наиболее важным компонентом любой облачной инфраструктуры. И значительное большинство людей, которые смотрят на это, наверняка являются новичками в этом деле
Питер Берг

69

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.


1
Есть ли существенное улучшение производительности ввода-вывода с томами типа EBS IOPS по сравнению со стандартными? Предположим, что сказанное выше справедливо и для томов EBS IOPS.
Honzajde

4
Обе технологии развиваются. Я пишу этот комментарий в 2014 году, когда у меня есть «Provisioned IOPS» EBS, но «хранилище экземпляров» теперь SSD, что даже быстрее, чем раньше !! Эфемерное хранение всегда выигрывает с точки зрения скорости. Поэтому я использую и то, и другое - сохраняю «постоянные» вещи на EBS, имея все временные файлы, журналы, базу данных «TempDB», файл подкачки и другие вещи в Instance-store. ВЫГОДА ОТ ОБА!
Алекс

Что делать, если вам нужна распределенная база данных, которая должна хранить свои данные в распределенном и постоянном режиме. Разве вам не нужен EBS, потому что хранилище экземпляров не является постоянным?
CMCDragonkai

@CMCDragonkai Конечно, вы делаете. В настоящее время существует множество вариантов, например, AWS начал предлагать хранилище на основе SSD. Я бы посмотрел на них и заново сделал анализ (один против RAID и т. Д.). Я также хотел бы получить самые большие экземпляры из-за пропускной способности сети. EBS все еще остается проблемой в таких случаях, как t1.micro.
до

Часть этого ответа о производительности сети довольно устарела - в течение достаточно долгого времени существовало множество экземпляров, которые могут быть «оптимизированы для EBS» за небольшую дополнительную плату, а некоторые - по умолчанию (без дополнительной оплаты). ), которые имеют выделенные сетевые интерфейсы к EBS, ср. docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html
Йосип Роден

41

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


6
Netflix также дает те же рекомендации.
Kingz

2
Итак, где вы храните свои постоянные файлы на основе блоков?
CMCDragonkai

17

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

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


S3 имеет встроенную избыточность. У EBS их нет , поэтому вам необходимо развернуть избыточное программное обеспечение поверх него.
Pacerier

2
@Pacerier Это неправильно, согласно официальной документации на docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html
Йосип Родин

16

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

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

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


13

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

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

Акцент мой.

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

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


9

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

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

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

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

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

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

4

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

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


2

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

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

введите описание изображения здесь

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

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


0

Если вы запускаете несколько экземпляров и назначаете запланированный сервис экземпляра 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 час в день, что невозможно сделать, когда вы используйте инстанс-магазин , тогда это будет другая история.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.