Преимущества EBS по сравнению с хранилищем экземпляров (и наоборот)
Мне неясно, какие преимущества я получу от EBS по сравнению с хранилищем экземпляров для своих экземпляров на Amazon EC2. Во всяком случае, кажется, что EBS более полезен (остановка, запуск, сохранение + лучшая скорость) при относительно небольшой разнице в стоимости...? Кроме того, есть ли метрика относительно того, больше людей используют EBS теперь, когда это доступно, учитывая, что это все еще относительно ново?
11 ответов
Суть в том, что вы почти всегда должны использовать экземпляры 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 "Аппаратное обеспечение"
Когда запускается экземпляр EC2, виртуальная машина резервируется для запуска экземпляра. Эта виртуальная машина имеет определенные спецификации в зависимости от типа экземпляра: 32-разрядный или 64-разрядный процессор, количество виртуальных ядер, размер жесткого диска и т. Д. Подробная информация о спецификациях экземпляра доступна на http://aws.amazon.com/ec2/.
Когда ваш экземпляр EC2 находится в "запущенном" состоянии, это означает, что он работает на виртуальной машине, и это то, за что вы платите.
Жесткий диск виртуальной машины считается "эфемерным". Термин "эфемерный" происходит от греческого слова "эфемеро", что означает "длится всего один день". Все, что находится на таком жестком диске, следует считать временным. Если данные не скопированы с жесткого диска, если виртуальная машина остановлена, данные будут потеряны. Это включает в себя данные, программное обеспечение и даже операционную систему, которая находится на этих жестких дисках.
Amazon Web Services предоставляет экземпляры EC2 с двумя типами корневых устройств: "EBS-backed" и "instance store".
"Экземпляр Магазин" Экземпляры
Экземпляр "хранилища экземпляров" - это экземпляр EC2, корневое устройство которого находится на жестком диске виртуальной машины. Когда экземпляр создан, базовый AMI копируется на жесткий диск виртуальной машины и запускается. Экземпляр может работать столько, сколько вы хотите, но его нельзя остановить. Поскольку корневое устройство экземпляра является фактическим жестким диском, оно "зависло" на оборудовании, и единственное, что вы можете сделать, - это завершить работу экземпляра. Если вы сделаете это, экземпляр будет удален и никогда не будет восстановлен. Вы также рискуете, что в случае сбоя оборудования виртуальной машины, вы также потеряете что-либо на жестком диске.
Если вы запускаете экземпляр "хранилища экземпляров", будьте готовы оставить его работающим, пока вы не закончите с ним. Обратите внимание, что с вас будет взиматься плата с момента запуска экземпляра до момента его завершения.
Экземпляры, поддерживаемые EBS
Экземпляр с поддержкой EBS - это экземпляр EC2, который использует том EBS в качестве корневого устройства. Тома EBS являются избыточными "виртуальными" дисками, которые не привязаны к какому-либо конкретному оборудованию, однако они ограничены определенной зоной доступности EC2. Это означает, что том EBS может перемещаться с одного устройства на другое в пределах одной зоны доступности. Вы можете рассматривать тома EBS как своего рода сетевое хранилище.
В случае сбоя оборудования виртуальной машины том EBS можно просто переместить на другую виртуальную машину и перезапустить. Теоретически, вы не потеряете данные.
Еще одним преимуществом является то, что тома EBS могут быть легко скопированы и скопированы. Таким образом, вы можете легко создавать резервные копии снимков своих томов, создавать новые тома и запускать новые экземпляры EC2 на основе этих дублированных томов.
Вероятно, самое большое преимущество экземпляров, поддерживаемых EBS, перед экземплярами "хранилища экземпляров" состоит в том, что их можно остановить. Когда вы делаете это, виртуальная машина отключается, а том EBS сохраняется для последующего извлечения. Аппаратное обеспечение становится доступным для использования кем-то другим. Кроме того, в течение этого времени с вас не взимается плата за работу экземпляра EC2. Но вы платите за хранение EBS. Когда вы хотите, чтобы экземпляр запускался снова, вы просто запускаете его снова. Новая виртуальная машина зарезервирована, ваш том EBS подключен, а ваш экземпляр загружен.
Но как насчет жестких дисков виртуальной машины?
Да, эти жесткие диски можно использовать, даже если ваш экземпляр EC2 поддерживается EBS. По умолчанию они недоступны. Если вы используете программы командной строки для запуска вашего экземпляра, вы можете использовать опцию "-b" в команде ec2-run-instances, чтобы подключить диски "хранилища экземпляров" к вашему экземпляру EC2.
Наличие этих дисков может быть полезным, если вы хотите хранить временные данные. Доступ для чтения и записи должен быть быстрее, чем чтение и запись на том EBS, поскольку вы не отправляете данные по сети. Кроме того, вы не будете платить за передачу или хранение данных. Но это работает, только если данные могут быть потеряны в любое время.
Источник: https://skeddly.desk.com/customer/portal/articles/1346918-ebs-backed-versus-instance-store
Я только начинаю использовать EC2, поэтому не эксперт, но собственная документация Amazon гласит:
мы рекомендуем использовать локальное хранилище экземпляров для временных данных, а для данных, требующих более высокого уровня надежности, мы рекомендуем использовать тома Amazon EBS или выполнять резервное копирование данных в Amazon S3.
Акцент мой.
Я занимаюсь анализом данных больше, чем веб-хостинг, поэтому постоянство для меня не так важно, как для веб-сайта. Учитывая различие, сделанное самой Amazon, я бы не предположил, что EBS подходит для всех.
Я постараюсь не забыть взвесить снова после того, как я использовал оба.
EBS похож на виртуальный диск виртуальной машины:
- Прочные, экземпляры, поддерживаемые EBS, можно свободно запускать и останавливать (экономя деньги)
- Может быть сделан снимок в любой момент времени, чтобы получить резервные копии на определенный момент времени
- AMI могут быть созданы из снимков EBS, поэтому том EBS становится шаблоном для новых систем
Хранение экземпляра:
- Локально, так вообще быстрее
- В обычных случаях EBS ввод / вывод не осуществляется за счет пропускной способности сети (за исключением случаев, оптимизированных для EBS, которые имеют отдельную пропускную способность EBS).
- Имеет ограниченное число операций ввода-вывода в секунду. Максимальное количество операций ввода-вывода составляет несколько тысяч IOPS
- Хрупкое. Как только экземпляр останавливается, вы теряете все в хранилище экземпляра.
Вот где можно использовать каждый:
- Используйте EBS для резервного раздела ОС и постоянного хранилища (данные БД, критические журналы, конфигурация приложения)
- Используйте хранилище экземпляров для данных в процессе, некритических журналов и переходного состояния приложения. Пример: внешнее хранилище сортировки, временные файлы и т. Д.
- Хранилище экземпляров также можно использовать для данных, критичных к производительности, когда происходит репликация между экземплярами (БД NoSQL, распределенные системы очередей / сообщений и БД с репликацией).
- Используйте S3 для данных, совместно используемых системами: входной набор данных и обработанные результаты, или для статических данных, используемых каждой системой при запуске.
- Используйте AMI для предварительно запеченных, запускаемых серверов
Большинство людей предпочитают использовать поддерживаемый EBS экземпляр, так как он с состоянием. Это безопаснее, потому что все, что у вас работает и установлено внутри, переживет остановку / остановку или сбой любого экземпляра.
Хранилище экземпляров не имеет состояния, вы теряете его вместе со всеми данными в случае сбоя любого экземпляра. Однако это бесплатно и быстрее, потому что том экземпляра привязан к физическому серверу, на котором работает виртуальная машина.
Для кого-то нового для всего этого, и если случайно приземлился здесь
На данный момент все AMI в разделе быстрого запуска поддерживаются EBS
Также в официальном документе есть хорошее объяснение различий между EBS и Instance store.
& это изображение в значительной степени подводит итог 
Если вы запускаете несколько экземпляров и назначаете запланированный сервис экземпляра AWS в качестве одного из ваших приоритетов во избежание непредвиденных расходов, я бы порекомендовал не использовать хранилище экземпляров.
Как объяснено в документации по EBS Volumes и ответе от j2d3 и Siddharth Sharma, хранилище экземпляров может работать столько времени, сколько вы хотите, но его нельзя остановить. Означает, что служба не может быть запланирована с помощью автоматического запуска / остановки или восстановления экземпляра.
Более того, для этой схемы также нет смысла использовать EBS Backed на Elastic Beanstalk, так как он предназначен для обеспечения непрерывной работы всех необходимых ресурсов. Он всегда будет автоматически перезапускать любые службы, которые вы остановите. 
Рассматривая все остальное, из общей суммы затрат на использование VPC, EBS и ELB, добавленных в EC2-Classic, EC2-VPC с ELB в основном является лучшим выбором, где, в отличие от EC2-Classic, остановленный экземпляр сохраняет связанный с ним Elastic. IP-адреса и том EBS сохраняются автоматически.
В качестве вывода, взяв основную часть вашего вопроса:
кажется, что EBS более полезен (остановка, запуск, сохранение + лучшая скорость) при относительно небольшой разнице в стоимости...?
Ответ - да, но если ваш экземпляр основан на EBS, его можно остановить. Он останется в вашей учетной записи, вы не будете платить за это. Вы будете платить только за объем, но EBS взимается каждый час. Вы также можете учитывать, что среди всех доступных типов вы можете изменять размер тома EBS.
Помимо преимуществ, которые уже перечислены Эриком, он также должен знать, что с точки зрения стоимости S3 может быть или не быть дешевле, чем EBS. Я согласен с тем, что это относительно небольшая разница в стоимости, если вы продолжаете запускать оба типа экземпляров на одной и той же платформе и архитектуре приложения все время.
Однако, если есть сценарий запуска приложения на более дешевом сервисе, перенесите все необработанные задачи и перенесите их в VPC/EBS через конвейер или лямбду в течение короткого времени, скажем, <1 час в день, что невозможно сделать, когда вы используйте инстанс-магазин, тогда будет другая история.