Привет, Хабр. В ноябре 2025 года наша команда выпустила релиз TROK SDS. Это программно-определяемое хранилище корпоративного уровня. Первые клиентские успехи уже есть, но пока под NDA, про это расскажем чуть позже. А сегодня хотелось бы просто поразмыслить над темой хранения данных и объяснить, что и как.
Спойлер тем, кто не хочет читать много букв: TROK SDS создавался для тех, кто не хотел и не хочет покупать дорогие аппаратные СХД или танцевать с бубном вокруг сложных решений вроде Ceph. В основе лежит синхронная репликация данных между узлами. При отказе оборудования система автоматически восстанавливает реплики без вмешательства администратора. Экономия достигается за счет работы на стандартных серверах x86_64, без специализированного железа. Управление через веб-интерфейс. Разворачивается за 40 минут опытными руками из плеч.
Пролог: артефакт надежного хранилища
Это, конечно, вопрос из серии «спасибо, кэп», но без него никуда. Данные в современных инфраструктурах – основа бизнес-процессов. Отказ или потеря доступа к ним даже на 10 минут способны парализовать сервисы, сломать цепочки поставок и остановить производство. Соответственно, чтобы этого не произошло, любой компании нужно найти сервис, закрывающий сей опасный момент.
А что было на рынке?
Мы смотрели на доступные варианты и видели три условных пути, каждый со своими «сюрпрайз-сюрпрайз».
Аппаратные СХД требовали крупных первоначальных вложений и, мягко говоря, подсаживали заказчика на конкретного вендора. Масштабироваться выходило дорого и не быстро.
Управление Ceph тот еще квест. В игру вступают высокая задержка, непредсказуемо�� поведение при восстановлении и постоянная необходимость в опытных инженерах.
Проприетарные программные платформы тоже не панацея. Эксплуатация – в копеечку, а гибкость условная, хоть и решают часть задач.
Исходя из этой картины, мы и задумали TROK – некий оптимальный вариант между всеми сценариями выше. Причем нам было важно, чтобы он подходил компаниям из разных отраслей.
Для облачных провайдеров и дата-центров он может стать идеальным фундаментом, позволяя строить отказоустойчивые частные/публичные облака с линейным масштабированием и гарантированной изоляцией клиентов.
Банки и финтех могут использовать TROK для размещения транзакционных баз данных и хранения журналов операций, где важны целостность с предсказуемой скоростью отклика.
Государственные структуры получают в его лице платформу для быстрого развертывания защищенных хранилищ и внутренних систем, изначально соответствующих регуляторным требованиям.
Промышленным предприятиям решение подойдет для работы с системами управления производством и для создания долгосрочных архивов телеметрии или инженерных данных.
IT-компании и интеграторы оценят возможность быстро разворачивать надежную продуктивную инфраструктуру для заказчиков, экономя время + ресурсы.
Как мы делали TROK
Фактически, мы создавали SDS под самые хардкорные сценарии: виртуализацию, базы данных и корпоративные сервисы, где простои и нестабильные задержки просто недопустимы. Все началось с выбора базовой технологии.
Выбор архитектуры
На столе было два кандидата: распределенная файловая система или работа с виртуальным блочным устройством. Мы стартовали с блочного подхода и получили желанные низкие задержки с высокой производительностью для сценариев с интенсивным вводом-выводом.
DRBD vs RBD
Следующим шагом было сравнение двух технологий виртуальных блочных устройств: DRBD и RBD (от Ceph). Мы собрали два стенда на идентичном «железном» кластере. Результаты были показательными.
DRBD демонстрировал меньшие задержки как на записи, так и на чтении, а потребление CPU и оперативной памяти было на порядок ниже. Но ключевым стал вопрос надежности. В RBD части реплик данных размазаны по многим серверам, и если в строю остается лишь один, данные не собрать. В DRBD же для восстановления данных достаточно работы хотя бы одного сервера с актуальной репликой.
Получилась система без избыточной сложности и с предсказуемым поведением.
Свой контроллер
Финальным решением был выбор между созданием форка проекта Linstor (управляющий слой для DRBD) и разработкой собственного контроллера с нуля. Форк отпал по нескольким причинам: Java как язык, «заразная» лицензия GPL v3 и некоторые неоптимальные архитектурные решения от LINBIT. Поэтому мы написали свой контроллер и агент для управлени�� узлами хранения. На Golang.
блочная репликация на уровне ядра + централизованный контроллер = архитектура TROK
Состав поставки TROK 1.1
Имя файла | Описание |
trok-installer | Консольный установщик пакетов |
trok-installer-gui | Графический установщик пакетов |
trok-webui | Графический веб-интерфейс управления СХД |
drbd-dkms | Модуль ядра DRBD |
drbd-ueficert | UEFI Secure Boot сертификат для подписи DRBD-модуля |
drbd-module-source | Исходники DRBD-модуля ядра |
coccinelle | Инструмент для автоматизированного анализа и преобразования исходного кода на C (включен как зависимость для drbd-dkms) |
drbd-reactor | Компонент для автоматического управления ресурсами DRBD в Linux, обеспечивающий интеллектуальную реакцию на события в кластере |
drbd-utils | Утилиты для управления DRBD-устройствами |
trok-controller | Центральный программный контроллер СХД TROK (управляет всеми узлами (Worker) и обеспечивает согласованность DRBD-устройств) |
trok-auth | Сервис аутентификации СХД TROK |
trok-cp-endpoint | Сервис обработки API-запросов СХД TROK |
trok-worker | Компонент системы управления распределенным хранилищем, который работает на каждом узле кластера и отвечает за локальное управление ресурсами DRBD |
nvmetcli | Оболочка администрирования для хранилищ NVMe |
python3-natsort | Библиотека Python, сортирующая списки с использованием «естественного порядка» сортировки (включена как зависимость для linstor-client) |
python-kmodpy | Модуль-оболочка Python ctypes для libkmod, предоставляющий общие операции с модулями ядра Linux: перечисление установленных модулей, modprobe, modinfo, show_depends и rmmod (включен как зависимость для drbd-dkms) |
resource-agents | Набор скриптов и утилит для управления ресурсами в кластерах высокой доступности |
libqb0 | Реализация библиотеки libqb (включена как зависимость для resource-agents) |
installation-guide.pdf | Руководство по установке TROK |
trok-controller-meta | Мета-пакет для установки ноды контроллера (содержит в себе только зависимости) |
trok-worker-meta | Мета-пакет для установки ноды сателлита (содержит в себе только зависимости) |
trok-gateway-meta | Мета-пакет для установки trok-gateway (содержит в себе только зависимости) |
trok-combined-meta | Мета-пакет для установки комбинированной ноды (содержит в себе только зависимости) |
Роли узлов в кластере
В кластере есть две ключевые роли, которые взаимодействуют друг с другом, – Контроллер и Воркер. Работает это довольно просто.
Controller – мозг системы. Он полностью управляет конфигурацией всего кластера, распределяет ресурсы между узлами, зорко отслеживает отказы оборудования и, обрабатывает команды администратора.
Worker – исполнитель на каждом узле хранения. Можно сказать, что воркер обеспечивает выполнение плана на местах и у него нет право на ошибку.
Для небольших инсталляций, где нет смысла раздувать архитектуру, мы сделали Combined-режим. В нем один узел совмещает в себе обе роли.
Квесты для TROK
Гибкая архитектура нашего продукта отлично ложится на разные типы нагрузок. Например, для виртуализации и частных облаков хранилище будет надежным бэкендом. Через iSCSI или NVMe-over-TCP к нему легко подключаются виртуальные диски для таких гипервизоров, как KVM, Proxmox, VMware или Hyper-V.
Для сервисов 24/7 и баз данных вроде PostgreSQL, Oracle или MongoDB, TROK может стать подходящим инструментом в условиях, где критически важна устойчивость к сбоям дисков и сети (тонкий намек на банковский сектор).
Для задач резервного копирования и архивного хранения наш продукт легко интегрируется с популярными системами вроде Veeam, Bacula или CommVault. Его можно подключить как NFS- или iSCSI-цель. Причем, для доступа к файловому интерфейсу не требуются дополнительные компоненты (в отличие от многих аналогов).
Облачные провайдеры и MSP-компании могут использовать TROK как основу для блочного хранилища в публичных/гибридных облаках. REST API и веб-интерфейс позволяют автоматизировать создание-подключение томов, а горизонтальное масштабирование происходит с автоматическим перераспределением нагрузки при добавлении новых узлов.
Что по лицензии?
Мы подобрались к самой интересной части – лицензированию. Здесь не по модели Нолана «сон внутри сна и внутри сна», максимально прозрачно. Можно выбрать либо подписку, либо бессрочную лицензию + техническую поддержку на 12/24/36 месяцев.
Клиент платит только за объем данных, которые собирается хранить. Пусть будет в качестве примера 10 Тб. Можно спокойно создавать серверы и диски в кластере до бесконечности на этот объем, потому что лицензия не ограничивает количество узлов, лишь бы укладывались в оплаченный лимит по данным. Если нужно больше места, то лицензию придется расширять. Согласитесь, все по-честному.
Жмем кнопочку и…
Ниже сокращенный путь от ISO до готового блочного устройства. Все, как обещали в начале обзора, – около 40 минут.
Установка компонентов. Смонтировать ISO, запустить инсталлятор, выбрать роль узла (Controller / Worker/ Combined). После установки доступен веб-интерфейс администратора.
Настройка сети. Все узлы должны находиться в одной локальной сети без NAT. Рекомендуется сеть от 10 Гбит/с и выше, MTU 9000, задержка между узлами до 3 мс.
Создание ресурса. Через веб-интерфейс задать имя и объем (по умолчанию создается ресурс с 3 копиями).
Пара скриншотов из рабочего интерфейса администратора.
Требования к железкам, чтобы работало
Минимальная инсталляция, чтобы получить баланс надежности и производительности – конфигурация из двух узлов. Если откажет один сервер, кворум сохранится, а данные останутся доступными.
Версии Astra Linux 1.7х (1.7.6, 1.7.6uu1, 1.7.6uu2, 1.7.7, 1.7.7uu1, 1.7.7uu2, 1.7.8, 1.7.9;), 1.8.х (1.8.1, 1.8.2, 1.8.2uu1, 1.8.3, 1.8.3uu1, 1.8.4);
Ядра Linux: 5.4.x, 5.10.x, 5.15.x, 6.1.x, 6.12.x;
2 CPU, 8 ГБ, RAM, 20 ГБ HDD;
Архитектура x86-64 или amd64.
Финалочка
Если попробовать описать TROK одной фразой, получится что-то вроде «золотой середины» в сегменте корпоративных хранилищ. Наш директор по продукту, Антон Ботвинников, дополнительно проводит аналогию с волейбольной командой. В смысле, что если один из игроков упадет, то его подстрахует другой и отобьет мяч. При этом, команда не стоит миллионы и готова оптимизироваться на ходу.
В конечном счете, любая система хранения – это фундамент. Он должен быть крепким, незаметным и не требовать ежедневного подкручивания гаек. Что-то вроде хорошего Wi-Fi: когда все работает, о нем не вспоминают.
В общем, пробуйте, спрашивайте, критикуйте. Комментарии открыты)
___
P.S. а когда все-таки Ceph и больше ничего?
Несмотря на все его сложности, Ceph остается сильным инструментом в некоторых специфичных сценариях. Например, когда необходимо масштабироваться до сотен узлов в едином пространстве для множества команд и сервисов. Или когда проект целиком завязан на объектное хранение и развитую S3-экосистему – здесь, будем объективными, Ceph RGW дает большую гибкость. Наконец, если нужна глубокая, почти точечная кастомизация политик хранения и поведения кластера под нагрузкой, возможности Ceph действительно широки.
В остальных же случаях, когда требуется предсказуемая производительность, операционная простота и экономическая эффективность без головной боли, есть смысл посмотреть в сторону более специализированных решений. Вроде нашего. Тонко намекнули.
