Команда об'єктного S3-сховища переклала статтю про те, які критерії є важливими при виборі об'єктного сховища. Далі текст від імені автора.
Коли йдеться про об'єктне сховище, як правило, люди думають лише про одну характеристику — ціну за ТБ/ГБ. Звичайно, ця метрика важлива, але робить підхід однобоким і прирівнює об'єктне сховище до інструменту для зберігання архівів. Плюс такий підхід зменшує важливість об'єктного сховища для технологічного стеку підприємства.
Вибираючи об'єктне сховище, варто звертати увагу на п'ять характеристик:
- продуктивність;
- масштабованість;
- сумісність із S3;
- реакція на збої;
- цілісність.
Ці п'ять характеристик — нові метрики об'єктного сховища нарівні з вартістю. Розглянемо їх усі.
Продуктивність
Традиційні об'єктні сховища не вирізняються продуктивністю. Постачальники послуг постійно жертвували їй у гонитві за низькими цінами. Однак із сучасними об'єктними сховищами все інакше.
Швидкість різних сховищ наближається до Hadoop і навіть перевершує її. Сучасні вимоги до швидкості читання та запису: від 10 ГБ/с – для жорстких дисків, до 35 ГБ/с – для NVMe.
Такої пропускної спроможності достатньо для Spark, Presto, Tensorflow, Teradata, Vertica, Splunk та інших сучасних обчислювальних фреймворків у стеку аналітики. Той факт, що MPP бази даних налаштовують на об'єктні сховища, говорить про те, що воно все частіше використовується як основне сховище.
Якщо система зберігання не забезпечує потрібну швидкість, ви не можете використовувати дані і витягувати з них значення. Навіть якщо ви отримуєте дані з об'єктного сховища в структуру обробки пам'яті, все одно знадобиться пропускна здатність для передачі даних в пам'ять і з неї. У застарілих об'єктних сховищ її недостатньо.
Це ключовий момент: новий показник продуктивності – пропускна спроможність, а не затримка. Вона потрібна для даних, що масштабуються, і це норма в сучасній інфраструктурі даних.
І хоча тести продуктивності - хороший спосіб визначення продуктивності, її неможливо точно виміряти до запуску програми в середовищі. Тільки після нього можна сказати, де саме вузьке місце: у програмному забезпеченні, дисках, мережі чи рівні обчислень.
масштабованість
Під масштабованістю розуміють кількість петабайт, які розміщуються в один простір імен. Постачальники заявляють про легку масштабованість, але замовчують у тому, що з масштабування масивні монолітні системи стають крихкими, складними, нестабільними і дорогими.
Новий показник масштабованості — кількість просторів імен або клієнтів, яких можна обслуговувати. Метрику беруть безпосередньо із гіперскейлерів, де будівельні блоки сховища невеликі, але масштабуються до мільярдів одиниць. Загалом це хмарна метрика.
Коли стандартні блоки мають невеликі розміри, їх легше оптимізувати, тобто забезпечити безпеку, контроль доступу, управління політиками, життєвим циклом та оновленнями без переривання роботи. І нарешті забезпечити продуктивність. Розмір будівельного блоку – функція керованості області відмови, саме так будуються високостійкі системи.
Мультиклієнтність має безліч характеристик. Хоча параметр говорить про те, як організації надають доступ до даних та додатків, він також відноситься і до самих додатків, і до логіки їхньої ізоляції один від одного.
Характеристики сучасного підходу до мультиклієнтності:
- За короткий час кількість клієнтів може зрости з кількох сотень до кількох мільйонів.
- Клієнти повністю ізольовані один від одного. Це дозволяє їм запускати різні версії того самого ПЗ і зберігати об'єкти з різними конфігураціями, дозволами, функціями, рівнями безпеки та обслуговування. Це необхідно, коли масштабуються нові сервери, оновлення та географічні регіони.
- Сховище еластично масштабується, ресурси надаються на запит.
- Кожна операція управляється API та автоматизується без участі людини.
- ПЗ можна розмістити у контейнерах та використовувати стандартні системи оркестрації, наприклад Kubernetes.
Сумісність із S3
Amazon S3 API – фактично стандарт для об'єктних сховищ. Кожен постачальник програмного забезпечення для об'єктного сховища заявляє про сумісність з ним. Сумісність із S3 двійкова: або вона реалізована в повному обсязі, або її немає.
На практиці можливі сотні та тисячі прикордонних сценаріїв, коли при використанні об'єктного сховища щось не йдеться. Особливо у постачальників пропрієтарного ПЗ та послуг. Його основні сценарії використання - пряме архівування або резервне копіювання, тому причин для виклику API небагато, варіанти використання однорідні.
Значні переваги ПЗ з відкритим вихідним кодом. Воно покриває більшість прикордонних сценаріїв, враховуючи розмір та різноманітність додатків, операційних систем та апаратної архітектури.
Все це важливо для розробників програм, тому варто тестувати роботу програми з постачальниками сховищ. Відкритий вихідний код спрощує процес – легше зрозуміти, яка платформа підходить для вашої програми. Постачальник може використовуватися як єдина точка входу в сховища, отже, він задовольнить ваші потреби.
Відкритий вихідний код означає, що програми не прив'язані до постачальника і більш прозорі. Це забезпечує довгий життєвий цикл програми.
І ще кілька зауважень щодо відкритого вихідного коду та S3.
Якщо ви запускаєте програму для роботи з великими даними, S3 SELECT на порядок підвищує продуктивність та ефективність. Це відбувається за рахунок використання SQL для вилучення зі сховища лише тих об'єктів, які вам потрібні.
Ключовий момент – підтримка повідомлень бакетів. Бакетні повідомлення спрощують безсерверні обчислення – важливий компонент будь-якої мікросервісної архітектури, яка надається як послуга. З огляду на те, що об'єктне сховище — фактично хмарне сховище, ця можливість стає вирішальною, коли об'єктне сховище використовують хмарні програми.
Нарешті, реалізація S3 має підтримувати Amazon S3 API-інтерфейси шифрування за сервера: SSE-C, SSE-S3, SSE-KMS. Ще краще, якщо S3 підтримує захист від несанкціонованого доступу, який справді безпечний.
Реакція на збої
Показник, який, ймовірно, часто не беруть до уваги, — те, як система обробляє збої. Невдачі трапляються з різних причин, і об'єктне сховище має обробляти їх усі.
Наприклад, є єдина точка відмови, метрика цього дорівнює нулю.
На жаль, багато систем зберігання об'єктів використовують спеціальні вузли, які мають бути активовані для правильної роботи кластера. До них відносять вузли імен або сервери метаданих – це створює єдину точку відмови.
Навіть там, де передбачено кілька точок відмови, першорядне значення має здатність витримувати катастрофічні відмови. Диски виходять із ладу, сервери виходять із ладу. Ключовий момент – створення програмного забезпечення, призначеного для обробки збоїв як нормального стану. При виході з ладу диска чи вузла таке програмне забезпечення продовжить працювати без змін.
Вбудований захист від стирання та деградації даних гарантує: ви можете втратити стільки дисків або вузлів, скільки у вас є блоки парності – зазвичай це половина дисків. І лише тоді ПЗ не зможе повертати дані.
Відмова рідко перевіряється під навантаженням, але така перевірка є обов'язковою. Моделювання збою під навантаженням покаже сукупні витрати, понесені після збою.
Консистентність
Показник консистентності у 100% також називають строгою консистентністю. Консистентність є ключовим компонентом будь-якої системи зберігання, але строга консистентність зустрічається досить рідко. Наприклад, Amazon S3 ListObject не є суто консистентним, він консистентний тільки в кінці.
Що мається на увазі під суворою консистентністю? Для всіх операцій після підтвердженої операції PUT слід виконувати наступне:
- Оновлене значення видно під час читання з будь-якого вузла.
- Оновлення захищене резервуванням від збою вузла.
Це означає: якщо висмикнути штекер у середині запису, нічого не загубиться. Система ніколи не повертає пошкоджені чи застарілі дані. Це висока планка, яка має значення для багатьох сценаріїв: від трансакційних додатків до резервного копіювання та відновлення.
Висновок
Це нові метрики об'єктного сховища, які відображають моделі використання в сучасних організаціях, де продуктивність, консистентність, масштабованість, домени відмови та сумісність із S3 – будівельні блоки для хмарних додатків та аналітики великих даних. Рекомендую використовувати цей список на додаток до ціни під час створення сучасних стеків даних.
Про об'єктне сховище Mail.ru Cloud Solutions: .
Що ще почитати:
- .
- .
- .
Джерело: habr.com