🥇Нови метрики на обектните хранилища

Летящая крепость от Nele-Diel

Отбор на объектно-ориентированное S3 хранилище Mail.ru Облачное Хранилище перевела статия за това какви критерии са важни при избора на обектно хранилище. Следва текст от името на автора.

Когато става дума за обектно хранилище, обикновено хората мислят само за един показател — цената за ТБ/ГБ. Разбира се, този показател е важен, но той прави подхода едностранчив и приравнява обектното хранилище на инструмент за съхранение на архиви. Освен това, такъв подход намалява значението на обектното хранилище за технологичния стек на предприятието.

Избирайки обектно хранилище, си струва да обърнете внимание на пет характеристики:

производителност;
масштабируемост;
съвместимост с S3;
реакция на сривове;
целостност.

Тези пет характеристики — нови метрики на обектното хранилище, наред с цената. Нека разгледаме всички тях.

Производителност

Традиционните обектни хранилища не се отличават с производителност. Доставчиците на услуги постоянно жертвали производителността в преследване на ниски цени. Въпреки това, с модерните обектни хранилища всичко е различно.

Скоростта на различните хранилища приближава или дори надвишава Hadoop. Съвременните изисквания за скорост на четене и запис: от 10 ГБ/с — за твърди дискове, до 35 ГБ/с — за NVMe.

Тази пропускна способност е достатъчна за Spark, Presto, Tensorflow, Teradata, Vertica, Splunk и други съвременни вычислителни фреймворкове в стека за аналитика. Фактът, че MPP бази данни се настройват на обектни хранилища, говори за това, че те все по-често се използват като основно хранилище.

Ако вашата система за съхранение не осигурява необходимата скорост, не можете да използвате данните и да извлекете стойности от тях. Дори ако извличате данни от обектно хранилище в структура за обработка в паметта, все пак ще е необходима пропускна способност за преминаване на данни в паметта и от нея. При остарелите обектни хранилища такава не е достатъчна.

Това е основният момент: новият показател за производителност е пропускната способност, а не латентността. Тя е необходима за мащабируеми данни и това е стандарт в съвременната инфраструктура за данни.

Въпреки че тестовете на производителността са добър начин за определяне на производителността, тя не може да бъде точно измерена преди стартиране на приложението в среда. Само след това може да се каже къде точно е тясното място: в софтуера, дисковете, мрежата или на ниво изчисления.

Мащабируемост

Масштабируемостта се разбира като количеството петабайти, които могат да се поберат в едно пространство на имената. Доставчиците декларират лесна мащабируемост, но премълчават, че при увеличаване на обема, масивните монолитни системи стават крехки, сложни, нестабилни и скъпи.

Новият показател за мащабируемост е броят на пространствата на имената или клиентите, които можете да обслужвате. Метриката идва директно от хиперскейлърите, където строителните блокове на хранилището са малки, но се мащабират до милиарди единици. Това е облачна метрика.

Когато стандартните блокове са с малки размери, те лесно се оптизират, тоест се осигурява сигурност, контрол на достъпа, управление на политиките, жизнения цикъл и актуализациите без прекъсване на работата. И в крайна сметка се осигурява производителност. Размерът на строителния блок е функция на управляемостта на зоната на отказ, така се изграждат високоустойчиви системи.

Мултиклиентността има много характеристики. Въпреки че параметърът говори за това как организациите предоставят достъп до данни и приложения, той също така се отнася до самите приложения и логиката за тяхната изолация помежду им.

Характеристики на съвременния подход към мултиклиентността:

В рамките на кратко време броят на клиентите може да нарасне от няколко стотин до няколко милиона.
Клиентите са напълно изолирани един от друг. Това позволява им да стартират различни версии на същия софтуер и да съхраняват обекти с различни конфигурации, разрешения, функции, нива на сигурност и обслужване. Необходимо е, когато се мащабират нови сървъри, актуализации и географски региони.
Хранилището е еластично мащабируемо, ресурсите се предоставят при поискване.
Всяка операция се управлява от API и се автоматизира без човешка намеса.
Софтуерът може да бъде разположен в контейнери и да използва стандартни системи за оркестрация, като Kubernetes.

Съвместимост с S3

Amazon S3 API — всъщност стандарт за обектни хранилища. Всеки доставчик на софтуер за обектно хранилище заявява за съвместимост с него. Съвместимостта със S3 е бинарна: или е реализирана напълно, или я няма.

На практика могат да се появят стотици и хиляди гранични сценарии, при които нещата не вървят при използването на обектно хранилище. Особено при доставчици на proprietary софтуер и услуги. Основните му сценарии на приложение са директно архивиране или резервно копиране, затова причините за извикване на 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: Архитектура S3. 3 години еволюция на Mail.ru Cloud Storage.

Какво друго да прочетете:

Източник: habr.com