Архитектура — это не список функций. Это набор инженерных решений, которые определяют, где система выиграет, где проиграет и почему.

Большинство распределенных хранилищ при заполнении примерно на 95% начинают работать в 2-3 раза медленнее. В наших тестах производительность упала всего на 4–9%. Причина в архитектуре MIND uStor. В этой статье разберем, как устроена модель хранения данных, как организован ввод-вывод и за счет чего система сохраняет производительность даже при высокой утилизации дискового пространства.

В первой статье мы рассмотрели типичные проблемы программно-определяемых хранилищ (SDS): падение производительности по мере заполнения, дополнительные затраты на отказоустойчивость и сложность эксплуатации. Эти ограничения характерны для большинства систем такого класса, поэтому при разработке uStor нам пришлось искать баланс между производительностью, надежностью, эффективностью использования дискового пространства и сложностью реализации.

Здесь разберем, как устроено размещение данных, каким образом кластер сохраняет производительность при заполнении свыше 90%, как работают RF- и EC-пулы, а также почему iSCSI-таргет реализован в пространстве пользователя. Отдельно остановимся на компромиссах, которых потребовала реализация этих решений.

Фундамент: трехуровневая архитектура

Аппаратный слой (Фундамент): использует стандартные серверы x86 с локальными накопителями (NVMe, SSD, HDD), объединенные в высокоскоростную сеть Ethernet (от 10 до 100+ GbE) с поддержкой RDMA (RoCEv2). Это обеспечивает независимость от вендорного «железа» и позволяет начать с кластера из трех узлов, линейно наращивая мощность.

Программный слой (Интеллектуальное ядро): включает ключевые распределенные компоненты, работающие на узлах кластера:

1.      Плоскость данных. Включает два основных компонента:

a.      Подсистема хранения. Отвечает за непосредственное хранение данных и реализована на базе компонента uStor-диск (OSD - Object Storage Daemon). Это программный демон, взаимодействующий с каждым физическим диском напрямую. Он выполняет операции ввода-вывода, обеспечивает журналирование и проверку целостности данных с использованием сквозных контрольных сумм (CRC32C). Каждый uStor-диск работает автономно, что устраняет централизованные узкие места.

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

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

3.  Плоскость администрирования предоставляет полный набор интерфейсов (WEB-интерфейс, RESTful API, CLI) для управления и интеграции, реализуя принцип «простота Day-2». Встроенные возможности мониторинга и экспорта метрик позволяют глубоко отслеживать состояние и производительность системы.

Модель хранения данных: размещение и балансировка

Основная логическая единица хранения – образ (Image), представляющий собой виртуальный блочный диск. Каждый образ создается внутри пула хранения и наследует его параметры: способ защиты данных (RF или EC), домены отказа и правила размещения.

По умолчанию данные записываются блоками по 128 КиБ. И здесь возникает вопрос: как отслеживать эти блоки? Хранить информацию о расположении каждого блока невозможно: в крупном кластере их количество достигает миллиардов и сама карта быстро становится узким местом. Поэтому блоки объединяются в логические группы. Каждому блоку по фиксированному правилу соответствует определенная группа, а плоскость управления хранит информацию уже о размещении групп на физических дисках.

Такой подход уменьшает объем метаданных и позволяет выполнять большинство операций на уровне групп, а не отдельных блоков. При изменении топологии пересчитывается только карта групп, а при отказе накопителя восстанавливаются лишь относящиеся к нему данные, без перестройки всего кластера.

Размещение данных и балансировка

Следующая задача – распределить группы по дискам максимально равномерно.

Во многих SDS для этого используют консистентное хеширование. Это проще в вычислениях и не требует централизованной карты размещения, но не гарантирует равномерное заполнение накопителей. В результате часть дисков может оказаться перегруженной раньше остальных, а при изменении топологии приходится перемещать значительный объем данных.

В MIND uStor размещение рассчитывается как задача линейного программирования. Алгоритм подбирает распределение групп по дискам с учетом доменов отказа и одновременно минимизирует дисбаланс заполнения. При добавлении или удалении узлов пересчитывается новая карта размещения, после чего перемещаются только те данные, которые действительно нужны для выравнивания.

Такой подход требует более сложных вычислений, чем хеширование, но обеспечивает равномерность заполнения дисков на уровне 96–99%. Это напрямую влияет на производительность кластера: отсутствуют отдельные «горячие» накопители, которые достигают предела раньше остальных и становятся узким местом всей системы.

Именно поэтому производительность сохраняется стабильной даже при утилизации свыше 90%, тогда как во многих SDS в этом диапазоне начинается заметная деградация.

При добавлении нового диска или узла система автоматически пересчитывает размещение и выполняет ребалансировку. Емкость и пропускная способность кластера при этом растут линейно с количеством узлов.

Отказоустойчивость: политика на уровне пула

Единого способа защитить данные не существует. Требования к высоконагруженной базе данных и архивному хранилищу различаются, поэтому схема защиты задается отдельно для каждого пула. В одном кластере могут одновременно использоваться пулы с репликацией (RF) и Erasure Coding (EC).

Разница между схемами хорошо видна на практических примерах.

EC 3+2 (три блока данных и два блока четности) выдерживает отказ любых двух дисков или узлов из пяти при накладных расходах 40%. В схеме EC 8+2 тот же уровень отказоустойчивости достигается уже с дополнительными расходами около 25%, однако для работы требуется больше узлов.

Репликация RF3, напротив, требует втрое больше дискового пространства, зато обеспечивает минимальную задержку и максимально простое восстановление, поскольку системе достаточно считать готовую копию без вычисления недостающих данных.

Выбор между RF и EC зависит от характера нагрузки: репликация подходит для сервисов, чувствительных к задержкам, а Erasure Coding для задач, где важнее эффективное использование емкости хранилища.

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

Защита данных определяется не только выбранной схемой, но и доменами отказа.

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

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

Восстановление и ребалансировка

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

Оставшиеся uStor-диски считывают доступные копии или EC-фрагменты и восстанавливают недостающие данные на исправных накопителях.

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

Отсутствие единой точки отказа

Конфигурация кластера хранится в распределенном реестре с алгоритмом консенсуса Raft и реплицируется между несколькими управляющими узлами.

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

Стресс-тест: производительность при заполнении 95% и 19 сценариев отказов

Теоретические преимущества архитектуры имеют смысл только в том случае, если подтверждаются практикой. Поэтому работу MIND uStor мы проверили в серии нагрузочных и отказоустойчивых тестов.

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

* Значения задержек для RF3 будут опубликованы после завершения проверки результатов.

При увеличении заполнения с 5 до 95% производительность снизилась всего на 4–9% по IOPS. Для распределенных систем хранения это важный показатель: во многих SDS при аналогичной загрузке падение производительности значительно выше из-за неравномерного заполнения накопителей.

В MIND uStor нагрузка распределяется равномерно между дисками, поэтому в кластере не возникает отдельных узлов, ограничивающих производительность всей системы.

Для трехузловой конфигурации (24 SATA SSD, сеть 100 GbE) были получены следующие максимальные показатели:

• EC — до 795 тыс. IOPS, 3160 МиБ/с, задержка 0,4 мс при чтении и 1 мс при записи;

• RF3 — до 1,205 млн IOPS, 4930 МиБ/с, задержка около 0,3 мс при чтении и 0,6 мс при записи.

Разница объясняется особенностями схем защиты. Репликация работает с готовыми копиями данных, тогда как Erasure Coding требует дополнительных вычислений при записи и восстановлении.

19 сценариев отказов

Помимо нагрузочных испытаний система прошла 19 сценариев отказов – от выхода из строя отдельных накопителей до каскадных сбоев управляющих компонентов. Во всех случаях данные были сохранены, а восстановление выполнялось автоматически.

Наиболее показательные результаты:

Отказ нескольких дисков (R.2–R.3). Кластер корректно восстановил данные как при выходе из строя нескольких накопителей на одном узле, так и при отказах на разных серверах.

Сетевая изоляция узла (R.6–R.7). При потере связи кластер сохранил доступность хранилища, а после восстановления соединения автоматически синхронизировал узел без вмешательства администратора.

Сбой службы uStor-диска (R.16–R.17). Экземпляры службы были автоматически перезапущены примерно за 10 секунд. Сбой не затронул ядро операционной системы и не потребовал перезагрузки узла.

Отказ компонентов управления (R.18–R.19). При выходе из строя управляющего узла лидер был автоматически переизбран, а управление кластером продолжилось без потери конфигурации.

Алгоритм ввода-вывода: протоколы доступа

MIND uStor поддерживает два класса протоколов доступа к данным:

Первый – стандартный iSCSI, обеспечивающий совместимость с существующей инфраструктурой. 

Второй – собственные протоколы uStor, ориентированные на сценарии, где критична минимальная задержка.

iSCSI: реализация в пространстве пользователя

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

В MIND uStor iSCSI реализован в пространстве пользователя. Вместо обработки сетевых прерываний используются выделенные потоки, которые в режиме polling непрерывно опрашивают очереди запросов. Под высокой нагрузкой они закрепляются за определенными ядрами процессора, что позволяет сократить задержки и сделать их более предсказуемыми.

Такой подход увеличивает загрузку процессора: даже при отсутствии запросов потоки продолжают работать. Это осознанный компромисс в пользу стабильной производительности под высокой нагрузкой.

Производительность масштабируется в двух направлениях. Производительность отдельного шлюза растет с увеличением числа рабочих потоков, а общая производительность подсистемы — с добавлением новых iSCSI-шлюзов.

Отказоустойчивость через многопутевой доступ (MPIO)

Все шлюзы работают в режиме Active-Active.

Образ одновременно доступен через несколько шлюзов, а на стороне клиента DM Multipath объединяет все пути в единое блочное устройство по идентификатору NAA.

Нагрузка автоматически распределяется между всеми доступными путями. При отказе одного из шлюзов операции ввода-вывода продолжаются через оставшиеся без прерывания доступа к данным.

Поскольку все шлюзы обращаются к единому распределенному хранилищу, запись остается согласованной независимо от выбранного маршрута.

Безопасность

Поддерживаются:

• односторонняя и взаимная аутентификация CHAP;

• управление доступом по IQN и IP-адресам;

• глобально уникальные идентификаторы устройств NAA.

Собственные протоколы для современных сред

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

Для сценариев с высокими требованиями к задержкам MIND uStor использует собственные протоколы прямого доступа к распределенному хранилищу.

Протокол ustor

Драйвер интегрируется в стек QEMU/KVM и использует MIND uStor Client Library.

Виртуальные машины обращаются к данным напрямую, минуя iSCSI-шлюзы. Такой подход снижает накладные расходы и подходит для СУБД и других приложений, чувствительных к задержкам и IOPS.

Протокол ustor-blk

Протокол предназначен для физических Linux-серверов.

Он работает в пространстве пользователя и предоставляет образы uStor как обычные блочные устройства Linux. Решение ориентировано на контейнерные платформы, HCI-инфраструктуры и другие сценарии прямого подключения к распределенному хранилищу.

Поддерживаемые платформы виртуализации

Через iSCSI поддерживаются Basis Dynamix Enterprise, Orion soft zVirt, ДАКОМ М SpaceVM. Basis Dynamix Standard использует собственный протокол ustor.

Управление данными: снимки и клоны

Снимки

Снимок (snapshot) фиксирует состояние образа на определенный момент времени без копирования данных.

В MIND uStor используется механизм Copy-on-Write. После создания снимка новые записи направляются в новые блоки исходного образа, тогда как снимок продолжает ссылаться на данные в состоянии на момент его создания.

Создание снимка занимает минимальное время, не требует остановки виртуальных машин и практически не влияет на производительность.

Основные сценарии использования:

• Защита от шифровальщиков. Снимки защищены от изменений со стороны клиентской операционной системы и позволяют быстро вернуть образ к предыдущему состоянию.

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

Управление снимками полностью автоматизируется через REST API.

Полные и связанные клоны

MIND uStor поддерживает два типа клонов.

Полный клон (image-clone) представляет собой независимую копию образа, которую можно разместить в любом пуле хранения с собственной политикой защиты данных.

При создании клона используется механизм Copy-on-Write: неизмененные блоки первоначально разделяются с исходным образом, а новые записи сохраняются отдельно.

Связанный клон хранит только изменения относительно исходного снимка.

Такой подход значительно сокращает потребление дискового пространства при массовом развертывании однотипных виртуальных машин. Вместо хранения множества полных копий система использует общий базовый образ и сохраняет только отличающиеся данные.

Типичные сценарии использования:

• тестирование обновлений и новых версий приложений

• создание копий продуктивных данных для анализа

• развертывание большого числа однотипных виртуальных машин

• миграция образов между пулами хранения с различными политиками защиты

Где применяется MIND uStor

Архитектура системы ориентирована на несколько основных сценариев:

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

uStor предоставляет распределенное блочное хранилище для виртуальных машин и контейнеров. Интеграция с отечественными платформами виртуализации позволяет объединить вычислительные ресурсы и хранение данных в единой HCI-инфраструктуре.

Архивные данные и резервное копирование

Использование Erasure Coding позволяет увеличить полезную емкость хранилища по сравнению с репликацией при сохранении отказоустойчивости.

Универсальные корпоративные СХД

В одном кластере можно одновременно использовать пулы с репликацией для высоконагруженных сервисов и EC-пулы для архивных данных.

Масштабируемые инфраструктуры

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

Высоконагруженные системы

Задержка менее 1 мс позволяет использовать систему для СУБД, VDI-инфраструктур, аналитических платформ и других приложений с интенсивным вводом-выводом.

Объекты КИИ и проекты импортозамещения

Система работает на стандартных x86-серверах, поддерживает аудит административных операций и совместима с Astra Linux SE 1.8.x и Ubuntu 24.04 LTS.

Посчитать сырую и полезную емкость кластера под разные конфигурации и типы резервирования можно в нашем онлайн-калькуляторе

Заключение

При разработке MIND uStor основное внимание мы уделили трем задачам:

• сохранению производительности при высокой степени заполнения хранилища

• выбору схемы отказоустойчивости под требования конкретной нагрузки

• упрощению эксплуатации за счет использования стандартного оборудования и единой системы управления

Чтобы этого добиться, мы использовали несколько архитектурных подходов: оптимизировали размещения данных, внедрили выбор между RF и EC на уровне пулов, реализовали iSCSI в пространстве пользователя и добавили поддержку собственных протоколов доступа.

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

В следующих статьях подробнее рассмотрим сетевую архитектуру, настройку RDMA, интеграцию с платформами виртуализации и особенности эксплуатации MIND uStor в регулируемых средах.