Розгортаємо NVMe-сховище OSNexus QuantaStor Community Edition

Уніфікована платформа програмно-визначеного зберігання даних QuantaStor від OSNexus підтримує роботу з основними протоколами доступу до даних: iSCSI / Fibre Channel (FC), NFS / SMB, S3. Для некомерційного, навчального та тестового використання компанія пропонує QuantaStor Community Edition — повноцінну версію, придатну для ознайомлення перед впровадженням у виробниче середовище. Є тільки два обмеження:

• Максимум 80 ТБ необробленої ємності на сервер
• До 4 серверів у складі кластерного середовища

Цього більш ніж достатньо для тестування, навчання або прототипування архітектури майбутнього рішення.

Призначення масштабованих сховищ

Сучасні додатки генерують величезні масиви даних. Горизонтальне масштабування сховищ дозволяє:

• Додавати нові вузли або сервери в кластер без заміни існуючих;
• Лінійно розширювати ємність без простою або міграції
• Розподіляти навантаження між кількома вузлами, підвищуючи загальну пропускну здатність і IOPS
• Зберігати доступність даних в кластері з реплікацією або кодом стирання (erasure coding)
• Автоматично балансувати дані, забезпечуючи безперервність сервісу
• Розгортати ресурси поступово, по мірі росту

Горизонтально масштабовані сховища добре підходять для:

• Kubernetes/контейнерів;
• Big Data, аналітики, Hadoop/Spark;
• Об’єктного зберігання (наприклад, S3-сумісних рішень);
• Мікросервісної архітектури.

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

Storage Grid

Центральною та однією з найбільш потужних функцій платформи є Storage Grid для побудови масштабованих, високодоступних та керованих з єдиної точки сховищ даних. По суті це технологія створення розподіленого пулу зберігання, де кілька вузлів (серверів) об'єднуються в єдину логічну систему зберігання.

Кілька окремих серверів (в кластерах Scale-Up або Scale-Out) працюють як єдина система з централізованим управлінням, реплікацією між кластерами/вузлами, балансуванням навантаження та оркестрацією ресурсів на рівні всієї інфраструктури.

Grid може включати окремі автономні сервери, HA-кластери (Scale-Up), Scale-Out кластери (наприклад, на базі Ceph).

Тестова галявина

QuantaStor базується на Linux, постачається як операційна система, не потребує додаткового програмного забезпечення, встановлюється на фізичний сервер або як віртуальна машина (VSA).  Для розгортання масштабованого NVMe-сховища потрібні базові серверні платформи з підтримкою достатньої кількості NVMe SSD, запасом процесорних ядер, пам’яті, широкополосними мережевими з’єднаннями. 

Ми зупинилися на сервері ASUS RSA500A-E12-RS12U  з підтримкою до 12 накопичувачів NVMe в конструктиві 1U і розгорнемо на ньому три екземпляри QuantaStor SA.

Конфігурація тестового стенду:

ASUS RS500-E12-RS12U / 1 х AMD EPYC 9124 16C / 128 ГБ DDR5-4800 / Braodcom MegaRAID 9540-M2 / 2 x 480 ГБ M.2 NVMe для встановлення ОС / 3 x 7.68 ТБ U.2 під сховище даних

З практичної точки зору 1U-платформи AMD EPYC / 12 x NVMe є оптимальними для зберігання даних виключно на флеш-пам’яті. Розробники QuantaStor рекомендують два апаратно дзеркальні завантажувальні диски та будь-яку кількість дисків для пулів сховищ.

Ми розгорнули систему зберігання як "віртуальну SAN": три віртуальні машини QuantaStor на одному вузлі Proxmox VE, які потім поєднуються в кластер. Оскільки ми ставили за мету вивчення можливостей та сценарію налаштування, а не погоню за швидкісними характеристиками, ми не «прокидали» диски (PCI Passthrough / HBA Passthrough), а обійшлися використанням віртуальних дисків (QCOW2) для створення пулів зберігання. Для виробничих застосувань цей варіант не підходить.

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

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

Створюємо Storage Grid:

Додаємо сервери в Storage Grid:

Вікно моніторинга виглядає так:

Створення Scale-out кластера із трьох серверів:

Створення OSD (Object Storage Daemon) та журналів (journals/WAL/DB) є ключовим кроком при розгортанні Scale-out кластера на базі Ceph. OSNexus значно спрощує цей процес порівняно з ручним налаштуванням Ceph через командний рядок.

Нагадаємо, про що йдеться.

OSD (Object Storage Daemon) - це основний компонент зберігання даних у Ceph. Кожен OSD керує одним або декількома фізичними дисками та зберігає дані як об'єкти. Саме OSDs відповідають за читання, запис та реплікацію даних. Для кожного OSD потрібен виділений простір на диску.

Журнал (Journal) / WAL (Write-Ahead Log) / DB (Database). У Ceph (особливо з файловою системою BlueStore, яка є стандартною та рекомендованою для сучасних OSD) використовуються WAL (Write-Ahead Log) та DB (Block-level Metadata Database). WAL (Журнал попереднього запису) прискорює операції запису. Усі дані спочатку записуються у WAL послідовно, а потім асинхронно переносяться на основний диск OSD. Це значно покращує продуктивність запису, особливо HDD. DB (База даних метаданих) зберігає метадані блокового рівня для OSD (наприклад, інформацію про те, де зберігаються об'єкти на диску).

Розміщення WAL та DB на більш швидких носіях (SSD або NVMe) у порівнянні з основними дисками даних OSD (HDD) може значно підвищити продуктивність OSD, особливо IOPS.

Процесс cтворення OSD і журналів:

Вікно моніторингу Scale-out кластера:

Ще одним критично важливим компонентом в архітектурі файлової системи Quantum StorNext (SNFS) є StorNext MDS (Metadata Controller). Його основне призначення - керувати всіма метаданими файлової системи, забезпечуючи високопродуктивний спільний доступ до даних для багатьох клієнтів у середовищах з великим обсягом даних.

MDS виконує роль "регулювальника руху" (traffic cop) або «диригента» для всієї файлової системи StorNext. Його основні функції включають управління метаданими, забезпечення спільного доступу, блокування даних, управління простором, відмовостійкість, інтеграція зі Storage Manager.

Створення StorNext MDS:

Обмежимося лише створенням файлового сховища. Аналогічно можна створити блочне та об'єктне сховища.

У QuantaStor/Ceph, файл-пул (або пул для файлового зберігання) - це логічне об'єднання ресурсів зберігання даних усередині кластера Ceph, спеціально виділене для надання файлового доступу (через протоколи, такі як NFS/SMB/CephFS).  Спеціально налаштована конфігурація базових пулів Ceph і пов'язаних з ними компонентів (MDS) призначена для ефективного та масштабованого надання файлового доступу поверх розподіленого об'єктного сховища Ceph.

Створюємо файл-пул:

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

Створюємо мережеву «шару»

Монтуємо мережевий ресурс на робочій станції

Післясмак

Ліцензія QuantaStor Community Edition дає чудову можливість протестувати зрілий корпоративний продукт для потенційного виробничого використання. Обмеження мати лише до 80 ТБ необробленої ємності на сервер, та не більше 4 серверів в розподіленому сховищу навряд чи є обмеженнями взагалі, оскільки для більшості розгортань загальна ємність 320 ТБ здається недосяжною. Ключі дійсні протягом 2 років, потім їх можна поновлювати, безкоштовно.

Інтерфейс керування QuantaStor простий для розуміння. Відповіді на запитання щодо опцій, інтерфейсу або способів виконання завдання легко знайти на сторінці wiki.osnexus.com.