Переваги 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, наші журнали записуються на центральний сервер syslog.

Єдиною перевагою зберігання екземплярів, яку я бачу, є економія витрат. Інакше екземпляри, підтримувані EBS, виграють. Ерік згадав усі переваги.

[2012-07-16] Я б сказав, що сьогодні цю відповідь значно відрізняю.

Я не мав жодного хорошого досвіду роботи з прикладами, підтримуваними EBS, у минулому році. Останні простої на AWS в значній мірі також були зруйновані EBS.

Я здогадуюсь, що така служба, як RDS, також використовує якусь систему EBS, і, здається, працює здебільшого. У випадках, якими ми керуємо собою, ми позбулися EBS, де це можливо.

Позбавлення від розширення, де ми перенесли кластер бази даних назад на залізо (= реальне обладнання). Єдиним, що залишився в нашій інфраструктурі, є сервер БД, де ми розміщуємо кілька томів EBS в програмний RAID та резервне копіювання двічі на день. Що б не було втрачено між резервними копіями, ми можемо жити.

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

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

Чим більший екземпляр ви отримаєте, тим краще, звичайно. Тут краще - це означає в межах розуму .

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

Отже, загалом, я не бачу жодної користі для підтримуваних EBS примірників. Я швидше додаю хвилину завантаження, а потім запускаю з потенційним SPOF.

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

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

Один з аспектів, який я не бачив, - це той факт, що ви можете робити знімки екземпляра, підтримуваного EBS, під час запуску, що дозволяє вам робити дуже економічні резервні копії вашої інфраструктури (знімки є блоковими та поступовими)

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

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

Цей тип динамічного автоматичного масштабування - це все, що стосується AWS - де реальна економія ІТ-інфраструктури може зіграти свою роль. Зробити автоматичне масштабування практично неможливо зі старими екземплярами, що не підтримуються s3 "InstanceStore".

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

ми рекомендуємо використовувати локальний сховище примірників для тимчасових даних, а для даних, що вимагають більш високого рівня міцності , рекомендуємо використовувати томи Amazon EBS або створювати резервну копію даних на Amazon S3.

Наголос мій.

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

Я спробую згадати, щоб зважити знову після того, як я використав обидва.

EBS - це як віртуальний диск VM:

• Міцні, випадки, підтримувані EBS, можна вільно запускати та зупиняти (економлячи гроші)
• Можна зробити знімок у будь-який момент часу, щоб отримати резервні копії в часі
• AMI можна створити з знімків EBS, тому том EBS стає шаблоном для нових систем

Зберігання примірника:

• Місцеві, так що в цілому швидше
• Немережеві, у звичайних випадках введення / виведення EBS, відбувається за рахунок пропускної здатності мережі (крім випадків, оптимізованих для EBS, які мають окрему пропускну здатність EBS)
• Має обмежений ввід / вивід на секунду IOPS. Навіть передбачений максимум вводу / виводу на кілька тисяч IOPS
• Тендітна. Як тільки примірник зупиняється, ви втрачаєте все в пам’яті екземпляра.

Ось де використовувати кожного:

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

Більшість людей вирішує використовувати екземпляр, що підтримується EBS, оскільки це стан. Це безпечніше, оскільки все, що у вас запущено та встановлено всередині нього, переживе зупинку / зупинку або будь-яку помилку екземпляра.

Магазин екземплярів не має статусу, ви втрачаєте його з усіма даними всередині будь-якої ситуації з помилкою. Однак це безкоштовно і швидше, тому що об'єм примірника прив'язаний до фізичного сервера, на якому працює VM.

Для когось нового у всьому цьому і якщо випадково приземлився тут

На сьогодні всі AMI в розділі швидкого запуску підтримуються EBS

Також в офіційному документі є гарне пояснення щодо різниці між магазином EBS та магазином інстанцій

& це зображення в значній мірі резюмує його

Якщо ви запускаєте кілька примірників і призначаєте службу планової інстанції AWS як один із своїх пріоритетів щодо уникнення несподіваних зарядів , я рекомендую не використовувати примірник-сховище .

Як пояснено в документації EBS Volumes та відповіді j2d3 та Siddharth Sharma, примірник-магазин може працювати стільки часу, скільки вам потрібно, але його не можна зупинити . Означає, що послугу неможливо запланувати шляхом автоматичного запуску / зупинки або відновлення екземпляра .

Більше того, для такої схеми також немає користі використовувати EBS Backed on Elastic Beanstalk, оскільки вона створена для того, щоб усі необхідні ресурси продовжували працювати . Він завжди автоматично перезапускає будь-які послуги, які ви зупиняєте. Переглядаючи всі інші , із загальної плати за використання VPC , EBS та ELB , доданих до EC2-Classic , EC2-VPC з ELB є переважно найкращим вибором, коли на відміну від EC2-Classic , зупинений екземпляр зберігає свою пов'язану Elastic IP-адресиі обсяг EBS зберігається автоматично.

Як висновок , беручи основну частину вашого питання:

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

Відповідь - так, але якщо ваш примірник базується на EBS, його можна зупинити. Він залишиться у вашому обліковому записі, з вас не стягуватиметься плата . З вас буде стягуватися лише обсяг, але EBS стягується щогодини . Ви також можете врахувати, що серед усіх доступних типів у вас є можливість змінити розмір обсягу EBS .

Окрім переваг, які вже перераховані Еріком , слід також знати, що за вартістю S3 може бути, а може і не бути дешевшим, ніж EBS . Я погоджуюся, що це порівняно невелика різниця у вартості, якщо ви продовжуєте працювати обидва типи примірників на одній платформі та архітектурі програми.

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