Дані - це життєва сила будь-якого бізнесу. Вони створюються, обробляються, використовуються, і зберігаються з приголомшливою швидкістю - у периферійних обчисленнях, у хмарах і в ЦОД-ах - і це ключ до досягнення конкурентної переваги в цифровому світі, в якому ми живемо. Дані та ІТ-технології сьогодні підвищують конкурентоспроможність бізнесу, починаючи від невеликих компаній і закінчуючи великими транснаціональними. Дані постійно збільшуються як у ціні, так і в розмірах, а й у складності практично щодня. Тому ініціативи, які дають змогу компаніям успішно працювати сьогодні і залишатися конкурентоспроможними в майбутньому, є пріоритетними - вони не можуть чекати. При цьому ініціативи модернізації, орієнтовані на дані, зміщують фокус із цифрової трансформації, орієнтованої на інфраструктуру, на створення цінності, орієнтованої на дані, і зводять дані в ранг найважливішого активу компанії. Однак цей рівень трансформації дуже складний, оскільки дані розростаються до «петабайтових масштабів», а їх потрібно якось систематизувати, аналізувати, а потім і використовувати, часто в реальному часі.

Епоха, заснована на даних, вимагає еластично масштабованих георозподілених платформ об'ємом від «десятків терабайтів» до «петабайтів», що дають змогу ухвалювати правильні рішення у важливі моменти. Ці платформи повинні охоплювати кілька систем і баз даних у різних географічних регіонах і щодня обробляти «мільйони і мільйони» записів без втрати даних. Вони повинні підтримувати всілякі робочі навантаження аналітики, штучного інтелекту і машинного навчання, що використовують об'єднані набори даних. Це можливо тільки при використанні сучасних архітектур даних, які забезпечують високошвидкісну передачу даних між цими компонентами, щоб потім використовувати дану платформу для прийняття рішень в режимі реального часу. Сучасні рішення, побудовані на цих принципах, можуть допомогти організаціям подолати проблеми, пов'язані з:

  • Продуктивністю: виконання вимог угод про рівень обслуговування (SLA) для прискорення доступу до даних.
  • Масштабованістю: стійкість до зростання даних і додатків під час задоволення потреб бізнесу в доступі до даних у режимі реального часу.
  • Економією: розв'язання проблем із даними за допомогою платформ, що забезпечують баланс між продуктивністю та сукупною вартістю володіння.
  • Високою доступністю: максимально можливий час безвідмовної роботи критично важливих додатків.

Перше рішення, яке спадає на думку - це системи зберігання з блоковим доступом і бажано з NVMe дисками. Але це дорого і не завжди практично. У цьому разі потрібно розглядати масштабовані з можливістю гнучкого георозподілу системи зберігання з файловим або блоковим доступами. Ці системи недорогі, розширюються до сотень терабайт/петабайт і мають єдиний глобальний простір імен-global namespace або єдиний пул зберігання. Такі системи зазвичай розподіляються за кількома одиницями/десятками/сотнями/тисячами вузлів зберігання для забезпечення високої продуктивності, довговічності та надмірності. Кожен вузол зберігання зазвичай містить комбінацію жорстких дисків (HDD) і твердотільних накопичувачів (SSD/SSD NVMe) для забезпечення оптимального балансу між ємністю, продуктивністю і вартістю. Дані автоматично реплікуються по декількох вузлах, гарантуючи, що дані залишаються доступними та захищеними навіть у разі різних збоїв обладнання.

Одним із таких рішень, на яке варто звернути увагу, є платформа/програмне забезпечення від компанії Scality-Scality RING, яка вже зарекомендувала себе більш ніж 10 років.

Історія Scality

Цікава історія створення компанії Scality. Scality була заснована 2009 року Жеромом Лекатом, Джорджіо Реньї, Деніелом Бінсфельдом, Сержем Дюга і Бредом Кінгом. З 2011 року компанія постійно отримувала для свого розвитку фінансування від різних венчурних фондів, а в 2018 році компанія отримала від HPE стратегічні інвестиції в розмірі 60 млн $. А трохи раніше, в 2014 році було підписано, ще тоді з компанією НР, дистриб'юторську угоду. Щоправда у 2015 році подібну угоду було підписано і з іншими гравцями на цьому ринку. Scality впродовж багатьох років незмінно отримувала визнання IDC у номінації-об'єктно-орієнтованих сховищ, а в найпершому магічному квадранті Gartner з розподілених файлових систем та об'єктних сховищ Scality була взагалі визнана лідером і відтоді це лідерство не втрачає. Компанія має офіси в Парижі (Франція), Лондоні (Великобританія), Сан-Франциско і Вашингтоні (США), а також Токіо (Японія), зі штатом співробітників у 14 країнах світу.

Загальна інформація

Scality RING (далі просто RING) досить часто використовують як основу приватних хмар компаній і хмарних інфраструктур для зберігання даних. Крім цього, RING - це зріле і перевірене рішення, призначене для роботи з даними застосунків петабайтного масштабу в широкому діапазоні робочих навантажень, включно з довготривалими «озерами даних» для ШІ, аналітикою, резервним копіюванням і створенням архівів даних, доставкою відеоконтенту, даними відеоспостереження та багатьом іншим. RING також надає вбудовані можливості управління даними в гібридній хмарі. Насамперед, RING - це програмне рішення для масштабованого зберігання даних, що розгортається на стандартних серверних платформах x86 архітектури (з серверними процесорами Intel або AMD) для створення єдиного, еластичного та відмовостійкого пулу зберігання. RING використовує розподілену архітектуру хмарного масштабу, призначену для створення практично необмеженого сховища як для традиційних, так і для «хмарних» додатків. Розподіляючи призначені для користувача дані та пов'язані з ними метадані по вузлах зберігання-фізичних серверах, RING усуває типові вузькі місця та єдині точки відмови для досягнення безперервної доступності.

Як було сказано вище, RING - це розподілена система, розгорнута на стандартному серверному обладнанні, починаючи мінімум з трьох серверів зберігання даних. Система може плавно масштабуватися до сотень і більше фізичних серверів з ємністю від 200ТБ до 100+ПБ. RING забезпечує захист і стійкість даних за допомогою локального і географічно розподіленого коду надлишковості - erasure coding* і реплікації, а також вбудованого сервісу - безперервного самовідновлення, для усунення очікуваних збоїв у компонентах платформи, таких як сервери та диски.

Для довідки: Erasure coding (EC)* -один із методів захисту даних, за якого дані розбиваються на фрагменти. Потім вони розширюються і кодуються надлишковими фрагментами даних - кодами надмірності і зберігаються в різних місцях, тобто на різних дисках і серверах. Якщо диск виходить з ладу або дані пошкоджуються, дані можна відновити з фрагментів кодів надмірності, що зберігаються на інших дисках.

Так само RING не має єдиних точок відмови і не потребує простою під час оновлення, масштабування, планового обслуговування або незапланованих системних збоїв. Система продовжує нормально працювати під час таких подій і може автоматизувати процеси відновлення або ремонту (самовідновлення) даних, які постраждали в разі помилки, або збою диска (-ів), або сервера (-ів). RING може самостійно масштабувати доступ до кінцевих точок протоколу-«конекторів», щоб забезпечити вищу сукупну продуктивність для робочого навантаження програми. Програмне забезпечення RING може використовувати популярні дистрибутиви Linux: Rocky Linux, RHEL7 або RHEL8 без модифікації ядра, оскільки такий підхід позбавляє необхідності підтримувати списки сумісності обладнання - HCL. Для з'єднання серверів між собою через внутрішні інтерфейси, як правило, використовуються мережеві адаптери і комутатори зі швидкістю роботи 10/25/40/100Гб/с. Така гнучкість дає змогу розгортати кільця RING, оптимізовані за пропускною здатністю, або кільця RING, оптимізовані за продуктивністю, залежно від конкретних вимог бізнесу. У будь-якому разі програмне забезпечення RING абстрагується від базових фізичних серверів і жорстких дисків. RING розрахований на масштабування використовуючи обладнання різних виробників, поколінь і щільності серверів, що є нормальною частиною життєвого циклу платформи RING. Хоча за статистикою приблизно 80% рішень RING будується на обладнанні від компанії НРЕ.

Архітектура RING

RING - це насамперед набір розподілених програмних сервісів, які дають змогу абстрагувати фізичні сервери та диски в одну масштабовану та відмовостійку службу зберігання даних.

У верхній частині архітектурного стека розташований шар служб/сервісів протоколів доступу-рівень конекторів, що забезпечують інтерфейси/з'єднувачі до підсистеми зберігання RING для додатків. Наступний рівень складається з розподілених служб метаданих як для об'єктного сховища S3, так і для файлового, а також механізмів захисту даних, що забезпечують їхню довговічність і цілісність, та процесів самовідновлення, а також набору сервісів управління і моніторингу систем. Найнижчу частину стека системи розташовано/побудовано на розподіленому рівні зберігання, що складається з віртуальних вузлів зберігання і базових «демонів» введення-виведення IO, які абстрагують фізичні сервери зберігання та інтерфейси дисків. В основі рівня зберігання лежить масштабоване розподілене сховище ключів/значень об'єктів, що масштабується, на основі вдосконаленого однорангового протоколу маршрутизації. Цей протокол маршрутизації гарантує, що операції зберігання і пошуку ефективно масштабуються до дуже великої кількості вузлів. Інтерфейси управління та моніторингу RING складаються з: порталу управління, що називається Supervisor UI, і якщо необхідно, то і з інтерфейсу командного рядка CLI.

Конектори RING

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

RING надає такі інтегровані інтерфейси об'єктного та файлового протоколів:

  • AWS S3 API: комплексна реалізація AWS S3 REST API з підтримкою моделі даних bucket і об'єктних даних, пар ключів доступу в стандарті AWS, автентифікації Signature v4/v2 і сумісної з AWS моделі ідентифікації та управління доступом (IAM).
  • REST (sproxyd): вбудований REST API RING з ключами/значеннями надає плоский простір імен для зберігання об'єктів із прямим доступом до об'єктів RING.
  • NFS v4.0 і v3: томи представлені у вигляді стандартних точок монтування.
  • SMB 3.0: томи представлені через загальні ресурси SMB клієнтам Microsoft Windows.
  • FUSE: томи представлені як локальна файлова система Linux.

Рішення RING може одночасно використовувати файлові та об'єктні конектори, і будь-яку їхню кількість, необхідну для забезпечення необхідної продуктивності/пропускної здатності. Конектори не зберігають даних, тому додатки можуть використовувати кілька конекторів паралельно, щоб отримати необхідну кількість IOPS або сумарну пропускну здатність-throughput.

Програмний стек RING і потік запитів

Запити введення-виведення від додатків спочатку надходять у RING на рівень конекторів, а потім конектори направляють ці запити на вузли зберігання RING. Конектори також відповідають за застосування налаштованої політики захисту даних: erasure coding і/або реплікація. При створенні запису нового об'єкта-файлу конектори ділять їх на більш дрібні - «чанки» або фрагменти перед відправкою на вузли зберігання.

Вузли зберігання і демони введення-виведення RING

Серцем RING є вузли зберігання - віртуальні процеси, які володіють і зберігають низку об'єктів, пов'язаних з їхньою частиною простору ключів RING. Кожен фізичний сервер зазвичай має шість віртуальних вузлів зберігання - bizstorenode. Під вузлами зберігання знаходяться «демони» зберігання -biziod, які відповідають за збереження даних на диски в базовій локальній стандартній дисковій файловій системі. Кожен екземпляр biziod - це низькорівневий програмний процес, який керує операціями введення-виведення на конкретний фізичний диск і підтримує зіставлення ключів об'єктів з їхнім фактичним розташуванням на диску. Процеси biziod локальні для сервера, керують тільки локальним, безпосередньо підключеним сховищем і взаємодіють тільки з вузлами зберігання на тому ж сервері. Типова конфігурація - один biziod на фізичний диск, з підтримкою до сотень демонів (до 255) на сервер, так що система може підтримувати сервери зберігання з високою щільністю.

Кожен biziod зберігає корисне навантаження об'єкта і метадані в наборі файлів-контейнерів фіксованого розміру на диску, яким він керує. Завдяки такій контейнеризації система може підтримувати високопродуктивний доступ навіть до невеликих файлів без фрагментації або перерозподілу ресурсів файлової системи. Демони bizoid використовують SSD або SSD NVMe диски з низькою затримкою для зберігання індексних файлів для підвищення продуктивності пошуку. Система забезпечує цілісність даних і перевірку цілісності даних завдяки використанню збережених контрольних сум в індексних файлах і файлах із даними контейнерів, які перевіряються під час читання даних.

Протокол розподіленої маршрутизації RING

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

У відповідь на ці проблеми дослідницьке співтовариство запропонувало низку ефективних протоколів маршрутизації, включно з одноранговими протоколами другого покоління, такими як протокол Chord, розроблений у Массачусетському технологічному інституті. Протокол Chord дуже чуйно реагує на зміни топології системи, причому ці зміни не потребують широкомовної розсилки на всі вузли, а тільки на кілька відповідних вузлів. Це дає змогу алгоритму ефективно працювати в дуже великих кластерах.

Архітектура RING заснована на Chord, фундаменті для розподіленого зберігання даних, здатного масштабуватися до сотень мільярдів об'єктів. Scality доповнила і запатентувала базовий протокол Chord, щоб забезпечити високий рівень довговічності даних, високу продуктивність, самовідновлення і спрощене управління. Базовий алгоритм організовує вузли зберігання вздовж логічно кругового простору ключів - «RING», при цьому кожному вузлу-серверу відводиться частина цього простору ключів. Кожен вузол володіє діапазоном ключів, обмеженим його власним ключем. RING здатний швидко й ефективно направляти запити на заданий ключ від будь-якого вузла до вузла, що володіє цим ключем.

На малюнку показано приклад з RING на трьох (3) фізичних серверах. Щоб більш ефективно розділити простір ключів, кожному фізичному серверу призначають набір із щонайменше шести (6) віртуальних вузлів зберігання (чорні, помаранчеві та білі шестигранники). Потім ці вузли зберігання логічно розташовуються в кільцевому просторі ключів відповідно до присвоєного їм значення ключа. У цьому спрощеному прикладі вузол зберігання 50 відповідає за зберігання ключів від 40 до 49. Якщо вузол зберігання 50 залишає RING (навмисно або через збій), його ключі будуть автоматично перепризначені та перебалансовані його наступникові - вузлу зберігання з ключем 60 (який у цьому випадку бере на себе відповідальність за ключі в діапазоні від 40 до 59).

Система RING динамічна і здатна швидко адаптуватися до змін у просторі ключів унаслідок приєднання до кластера нових вузлів або навпаки вилучення з кластера. Без перерви в обслуговуванні система автоматично відновлює баланс ключів у просторі ключів під час додавання та вилучення вузлів.

Механізми відмовостійкості RING

  • Scality організовує простір ключів, використовуючи власний формат, що складається з 160-бітних ключів:
  • Перші 24 біти кожного ключа слугують випадково згенерованим полем розсіювання, щоб уникнути випадкових збігів або зближення набору пов'язаних ключів.
  • Наступні 128 біт слугують для корисного навантаження об'єкта-даних.
  • Останні 8 біт представляють клас обслуговування (CoS) об'єкта, пов'язаного з ключем.
  • RING забезпечує гнучкий захист даних використовуючи 2 технології:
  • CoS: класи обслуговування, для кількості збережених копій об'єкта від 1 до 6 (CoS від 0 до 5).
  • EC: erasure coding.

Наприклад, реплікація CoS=5 дає змогу системі витримувати до 5 одночасних відмов дисків, зберігаючи при цьому доступ і зберігання вихідного об'єкта. Будь-який збій змушує систему самостійно відновлювати втрачену репліку з однієї вцілілої копії, щоб автоматично повернути об'єкт до вихідного класу обслуговування якомога швидше. Хоча реплікація оптимальна для багатьох випадків використання, коли об'єкти невеликі, а продуктивність доступу критично важлива, вона створює великі накладні витрати на зберігання порівняно з вихідними даними. Наприклад, об'єкт розміром 100 КБ, що зберігається з CoS=2 (2 додаткові копії, разом 3), займає 3 x 100 КБ = 300 КБ фактичної фізичної ємності на RING. Такі накладні витрати в багатьох випадках прийнятні для невеликих об'єктів, але вони можуть стати дорогим тягарем для об'єктів відео та зображень мегабайтного або гігабайтного рівня - у цьому разі «штраф/penalty» за зберігання об'єкта розміром 1 ГБ становить 200 %, оскільки для трьох реплік знадобиться 3 ГБ дискового простору. Якщо ж ідеться про петабайтні об'єми, то для багатьох компаній цей тягар стає суттєвим, що вимагає більш ефективного механізму захисту даних.

Erasure coding (EC) у RING

RING підтримує erasure coding (EC), щоб забезпечити альтернативний механізм захисту даних порівняно з реплікацією CoS, і який набагато ефективніший для великих об'єктів і файлів. У RING реалізовано метод erasure coding Ріда-Соломона, що дає змогу зберігати великі об'єкти з розширеним набором коду надмірності - parity stripes - замість кількох копій вихідного об'єкта. Основна ідея erasure coding полягає в тому, щоб розбити об'єкт/файл на кілька фрагментів (m) і застосувати математичне кодування для отримання додаткового фрагментів кодів надмірності (k). Опис математичного кодування виходить за рамки цієї статті, але концептуально його можна розуміти як розширення обчислень парності XOR, що використовуються в традиційних RAID-масивах. Отриманий набір фрагментів (m + k) розподіляється між вузлами RING, забезпечуючи можливість доступу до вихідного об'єкта доти, доки доступна будь-яка підмножина з m фрагментів або фрагментів кодів надмірності k. Інакше кажучи, це дає можливість зберігати об'єкт із захистом від k збоїв, витрачаючи лише k / m простору для зберігання.

Як спрощений приклад припустимо, що об'єкт розміром 9 МБ буде зберігатися з використанням схеми erasure coding EC 9+3. RING розрахує 3 додаткові фрагменти коду надмірності EC розміром 1 МБ, які необхідно зберегти. Таким чином, для захисту від трьох одночасних відмов дисків знадобиться 33 % простору (3 МБ/9 МБ), що значно менше, ніж 200 % простору, що знадобилося б для зберігання 3 копій одного й того самого об'єкта в разі використання реплікації CoS=2.

Якщо говорити конкретніше про реальну реалізацію в RING, то великі об'єкти будуть розбиватися на фрагменти по 4 МБ, які будуть індивідуально закодовані відповідно до налаштованої схеми EC (5+7, або 7+5, або 8+4, або 9+3). Так, у разі об'єкта розміром 100 МБ він буде розбитий на 25 фрагментів (25 x 4 МБ), і до кожного фрагмента розміром 4 МБ буде застосовано EC для розрахунку фрагмента коду надмірності. У RING EC фрагменти даних зберігаються у відкритому вигляді, без будь-якого кодування, тому при звичайному доступі на читання не відбувається зниження продуктивності через декодування.

Швидке відновлення і самовідновлення в RING

Для забезпечення гнучкості при зберіганні даних різного типу і розміру RING зазвичай налаштовується на змішану політику захисту даних CoS/EC з порогом заздалегідь заданого розміру об'єкта для визначення CoS - для об'єктів невеликого розміру і EC - для об'єктів великого розміру. За замовчуванням цей поріг розміру становить 60 КБ, але його можна налаштувати для оптимізації під конкретні розміри файлів і вимоги до їхньої довговічності.

Система RING призначена для підтримки та обслуговування працездатності за найрізноманітніших збоїв, включно з відмовами дисків, серверів, мереж і навіть усього ЦОД, і забезпечує захист даних у цих умовах. У RING реалізовані процеси самовідновлення, які відстежують і автоматично усувають збої компонентів. Це включає в себе відновлення відсутніх фрагментів даних через відмови дисків або серверів, відновлення «балансу даних», коли вузли «залишають» і/або «приєднуються» до RING. Так при відмові диска або навіть усього сервера запускаються фонові операції відновлення, щоб відновити відсутні дані об'єкта з його вцілілих реплік або фрагментів коду надмірності EC. Процес перебудови завершується після відновлення вихідного класу обслуговування - CoS або вихідної кількості фрагментів і фрагментів коду надмірності EC.

Сфери застосування

Серед прикладів користувачів RING, наданих Scality, - американський замовник банківських послуг, який використовує дане рішення як агрегатор усіх своїх даних, що підлягають виявленню шахрайства через Splunk, з обсягом у десятки ПБ. Європейська платформа для оптимізації цін на авіаперевезення Amadeus використовує Scality для своєї роботи на базі Splunk, а оборот даних становить 1 ПБ на день. Французька компанія SeqOIA, що займається дослідженнями в галузі геноміки, використовує RING як сховище великих обсягів даних, і воно досить швидке, щоб виконувати деякі операції, які потребують високої продуктивності. Також це програмне забезпечення вже протестовано і працює з багатьма знайомими вам бізнес-додатками:

Не останню роль під час експлуатації рішення Scality RING відіграє надійне та валідоване обладнання, яким є обладнання від компанії Hewlett Packard Enterprise (HPE). Далі наведено рекомендації для вибору тієї чи іншої серверної платформи HPE для різних навантажень і обсягу.

Варто зауважити, що мінімальний поріг дискового простору в системі RING, який необхідно ліцензувати дорівнює 200 ТБ.

Підсумки

Немає універсального рішення для зберігання даних. Серед сучасних архітектур файлове, блочне та об'єктне сховища – це три способи зберігання даних у «хмарі» та на «землі». Кожен тип зберігання пропонує свої унікальні переваги для різних випадків використання.

Щоб вибрати оптимальний варіант, компаніям необхідно враховувати кілька факторів, таких як швидкість доступу до даних, масштабованість, доступність, безпека, вартість та характер даних.

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

Автор статті - Михайло Федосєєв, архітектор інфраструктурних рішень Lantec.