Разворачиваем 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 ТБ

С практической точки зрения 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.

Процесс создания 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.