Российская распределенная СХД. Как все устроено

Этой весной команда «Рэйдикс» подготовила и выпустила первую версию ПО для создания распределенной блочной СХД, работающей на серверных платформах «Эльбрус-4.4» на базе микропроцессоров «Эльбрус-4С».

Полезность такого симбиоза видна невооруженным взглядом — сборка СХД на базе отечественного железа и отечественной операционной системы становится вполне привлекательным продуктом внутреннего рынка, в частности для заказчиков, имеющих фокус на импортозамещение.

Однако потенциал разработанной операционной системы не ограничивается российскими серверными платформами. В настоящий момент тестируется и отрабатывается совместимость со стандартными серверами x86-64, которые широко распространены на рынке. Помимо этого, продолжается «допиливание» продукта до желаемой функциональности, которая позволит осуществлять его реализацию за пределами российского рынка.

Ниже мы представим небольшой разбор того, как устроено программное решение (получившее название RAIDIX RAIN), позволяющее объединять локальные носители серверов в единый отказоустойчивый кластер хранения с централизованным управлением и возможностями горизонтального и вертикального масштабирования.

Особенности распределенной СХД

Традиционные СХД, выполненные в виде единого программно-аппаратного комплекса, имеют общую проблему, связанную с масштабированием: производительность системы, упирается в контроллеры, их количество ограничено, наращивание ёмкости путем добавления полок расширения с носителями не даёт увеличения производительности.

При таком подходе общая производительность СХД будет падать, поскольку с увеличением ёмкости прежнему количеству контроллеров необходимо обрабатывать больше операций доступа к возросшему объему данных.

RAIDIX RAIN поддерживает горизонтальное блочное масштабирование, в отличии от традиционных решений увеличение узлов (серверных блоков) системы приводит к линейному росту не только ёмкости, но и производительности системы. Это возможно поскольку каждый узел RAIDIX RAIN включает в себя не только носители, но и вычислительные ресурсы для ввода-вывода и обработки данных.

Сценарии применения

RAIDIX RAIN предполагает реализацию всех основных сценариев применения распределенной блочной СХД: инфраструктура облачного хранения, высоконагруженные базы данных и хранение аналитики Big Data. Также RAIDIX RAIN может составить конкуренцию традиционным СХД при достаточно высоких объемах данных и соответствующих финансовых возможностях клиента.

Публичные и частные облака

Решение обеспечивает эластичное масштабирование, необходимое для развертывания облачной инфраструктуры: производительность, пропускная способность и объем хранения увеличиваются с каждым добавленным в систему узлом.

Базы данных

Кластер RAIDIX RAIN в all-flash конфигурации является эффективным решением для обслуживания высоконагруженных баз данных. Решение будет доступной альтернативой продуктам Oracle Exadata для Oracle RAC.

Аналитика больших данных

Совместно с дополнительным ПО возможно использование решения для выполнения аналитики больших данных. RAIDIX RAIN обеспечивает значительно более высокий уровень производительности и простоты обслуживания по сравнению с кластером HDFS.

Архитектура решения

RAIDIX RAIN поддерживает 2 варианта развертывания: выделенный (внешний или конвергентный) и гиперконвергентный (HCI, hyper-converged-infrastructure).

Выделенный вариант развертывания

В выделенном варианте кластер RAIDIX RAIN представляет собой классическую программную СХД. Решение развертывается на необходимом количестве выделенных серверных узлов (не менее 3х, сверху количество практически не ограничено), ресурсы которых полностью утилизируются для задач хранения.

Рис. 1. Выделенный вариант развертывания

При этом программное обеспечение RAIDIX RAIN устанавливается прямо на голое железо. Приложения, сервисы, вычислительные ресурсы, использующие RAIN для хранения информации, размещаются на внешних хостах и подключают к нему по сети хранения данных (классическая архитектура ЦОД).

Гиперконвергентный вариант развертывания

Гиперконвергентный вариант предполагает совместное размещение вычислительных мощностей (гипервизор и производственные VM) и ресурсов хранения (программная СХД) ЦОД на одном множестве узлов, в первую очередь это актуально для виртуальных инфраструктур. При таком подходе ПО RAIN устанавливается на каждый хост (узел) инфраструктуры (HCI) в виде виртуальной машины.

Рис. 2. Гиперконвергентный вариант развертывания

Взаимодействие узлов кластера RAIN между собой и с конечными потребителями ресурсов хранения (серверами, приложениями) осуществляется по протоколам iSCSI (IP, IPoIB), iSER (RoCE, RDMA) или NVMeOF.

Гиперконвергентный вариант развертывания даёт следующие преимущества:

• Консолидация вычислительных ресурсов и ресурсов хранения (не нужно внедрять и сопровождать выделенную внешнюю СХД).
• Совместное горизонтальное блочное масштабирование вычислительных ресурсов и ресурсов хранения.
• Простота внедрения и сопровождения.
• Централизованное управление.
• Экономия стоечной ёмкости и энергопотребления.

С точки зрения используемых носителей RAIDIX RAIN поддерживает 3 конфигурации:

• All-flash — узлы кластера снабжаются только flash-носителями (NVMe, SSD);
• HDD — узлы кластера снабжаются только HDD-носителями;
• Гибридная — два независимых уровня хранения на HDD и SSD.

Производительная отказоустойчивость

Основная ценность RAIDIX RAIN — оптимальное соотношение производительности, отказоустойчивости и эффективного использования ёмкости хранилища.

В рамках клиентской ИТ-инфраструктуры RAIDIX RAIN также привлекателен тем, что на выходе мы имеем «честный» блочный доступ, что выгодно отличает решение от большинства рыночных аналогов.

В настоящее время большая часть конкурентных продуктов показывают высокую производительность, только при использовании зеркалирования. При этом полезная ёмкость хранилища сокращается в 2 раза и более: однократная репликация данных (зеркалирование) — избыточность 50%, двукратная репликация данных (двойное зеркалирование) — избыточность 66,6%.

Использование технологий оптимизации хранения, таких как EC (Erasure Coding — помехоустойчивое кодирование), дедупликация и сжатие, реализованных в распределенных СХД, приводит к значительной деградации производительности хранилища, что неприемлемо для чувствительных к задержкам приложений.

Поэтому на практике такие решения обычно вынуждены функционировать без использования данных технологий, либо включать их только для «холодных» данных.

Требования по отказоустойчивости

Изначально RAIDIX RAIN разрабатывался с четким набором исходных требований к отказоустойчивости и доступности системы:

• Кластер должен переживать отказ не менее двух узлов, при количестве узлов строго больше 4. Для трех и четырех гарантируется отказ одной ноды.
• Узел должен переживать отказ не менее двух дисков в каждом узле при наличии не менее 5 дисков в узле.
• Уровень избыточности накопителей на типичном кластере (от 16 узлов) не должен превышать 30%
• Уровень доступности данных должен быть не ниже 99,999%

Это в значительной степени повлияло на существующую архитектуру продукта.

Возможности Erasure Coding в распределенной СХД

Основным подходом обеспечения отказоустойчивости RAIDIX RAIN является использование уникальных технологий Erasure Coding. Известные по флагманскому продукту компании EC используются и в распределенной СХД, что позволяет получить производительность сравнимую с зеркалированными конфигурациями. Это касается как случайной, так и последовательной нагрузки. При этом обеспечивается заданный уровень отказоустойчивости и значительно увеличивается полезная ёмкость, а накладные расходы составляют не более 30% сырой ёмкости хранилища.

Отдельного упоминания требует высокая производительность EC RAIDIX на последовательных операциях, в частности при использовании SATA-дисков большого объема.

В целом, RAIDIX RAIN предлагает 3 варианта помехоустойчивого кодирования:

• для 3 узлов оптимальным является использование RAID 1;
• для 4 узлов оптимальным является использование RAID 5;
• для субкластера хранения от 5 до 20 узлов оптимальным подходом является использование сетевого RAID 6.

Рис. 3. Варианты помехоустойчивого кодирования

Все варианты предполагают равномерное распределение данных по всем узлам кластера с добавлением избыточности в виде контрольных сумм (или кодов коррекции). Это позволяет провести параллели с кодами Рида-Соломона, используемыми в стандартных RAID-массивах (RAID-6) и позволяющими отработать отказ до 2х носителей. Сетевой RAID-6 работает аналогично дисковому, однако распределяет данные по узлам кластера и позволяет отработать отказ 2х узлов.

В RAID 6 при отказе 1-2 носителей внутри одного узла их восстановление происходит локально без использования распределённых контрольных сумм, минимизируя объем восстанавливаемых данных, нагрузку на сеть и общую деградацию системы.

Домены отказа

RAIN поддерживает концепцию доменов отказа (fault domain) или доменов доступности. Это позволяет отработать отказ не только отдельных узлов, но и целых серверных стоек или корзин, узлы которых логически группируются в домены отказа. Такая возможность достигается за счет распределения данных для обеспечения их отказоустойчивости не на уровне отдельных узлов, а на уровне доменов, что позволит пережить отказ всех сгруппированных в нем узлов (например, целой серверной стойки). В этом подходе кластер разбивается на независимые подгруппы (субкластера). Количество узлов в одной подгруппе не более 20, что и обеспечивает требование по отказоустойчивости и доступности. При этом количество подгрупп не ограничено.

Рис. 4. Домены отказа

Отработка любых отказов (дисков, узлов или сети) осуществляется автоматически, без остановки работы системы.

Помимо этого, все устройства кластера RAIDIX RAIN защищены от отказа электропитания подключением к бесперебойным источникам питания (UPS). Устройства, подключенные к одному UPS, называются группой отказа по питанию.

Характеристики и функциональность

Рассмотрим основные функциональные характеристики RAIDIX RAIN.
Таблица 1. Базовые характеристики RAIDIX RAIN

В качестве важной функциональной особенности RAIDIX RAIN стоит отметить, что такие сервисы, как инициализация, реконструкция и рестрайпинг (масштабирование), идут в фоновом режиме и им может выставляться параметр приоритета.

Выставление приоритета дает пользователю возможность самостоятельно регулировать нагрузку в системе, ускоряя или замедляя работу данных сервисов. Например, приоритет 0 означает, что сервисы функционируют только в отсутствии нагрузки от клиентских приложений.

Возможности масштабирования

Процедура расширения кластера RAIDIX RAIN максимально проста и автоматизирована, система самостоятельно в фоновом процессе перераспределяет данные с учетом ёмкости новых узлов, нагрузка становится сбалансированной и равномерной, пропорционально повышается общая производительность и ёмкость хранилища. Процесс горизонтального масштабирования проходит «на горячую» без простоев, не требует остановки приложений и сервисов.

Рис. 5. Схема процесса масштабирования

Гибкость архитектуры

RAIDIX RAIN является программным продуктом и не ограничивается определенной аппаратной платформой — его концепция предполагает возможность установки на любое совместимое серверное оборудование.

Каждый заказчик исходя из особенностей своей инфраструктуры и приложений выбирает оптимальный для себя вариант развертывания: выделенный или гиперконвергентный.

Поддержка различных типов носителей позволяют исходя из бюджета и решаемых задач строить на базе RAIDIX RAIN:
1. распределенные all-flash хранилища с беспрецедентно высокой производительностью и гарантированным низким уровнем задержек;
2. экономичные гибридные системы, удовлетворяющие большинству основных типов нагрузок.

Показатели производительности

В качестве заключения покажем немного цифр, полученных в результате тестирования RAIDIX RAIN на конфигурации NVMe-кластера из 6 узлов. Еще раз отметим, что на такой сборке (с серверами x86-64) продукт еще дорабатывается, и данные показатели не являются финальными.

Тестовое окружение

• 6 узлов по 2 диска NVMe HGST SN100
• IB card Mellanox MT27700 Family [ConnectX-4]
• Linux Kernel 4.11.6-1.el7.elrepo.x86_64
• MLNX_OFED_LINUX-4.3-1.0.1.0-rhel7.4-x86_64
• Local raid — raid 0
• External raid – raid 6
• Бенчмарк для тестирования FIO 3.1

Таблица 2. Результаты тестирования

Автор: raidixteam

Источник