Мы разрабатываем собственный слой управления на базе Kubernetes поверх DRBD (Distributed Replicated Block Device). Он заменит LINSTOR в нашей платформе хранения. В статье расскажем, почему мы приняли такое решение, что оно даст пользователям и когда ждать первых результатов.
DRBD (Distributed Replicated Block Device) — это распределённое реплицируемое блочное устройство. Это программное решение с открытым исходным кодом, которое обеспечивает синхронную репликацию данных на уровне блочных устройств между двумя или более серверами.
Проще говоря, DRBD работает как зеркало: вместо двух дисков внутри одного сервера данные зеркалируются между дисками на разных физических машинах через сетевое соединение.
LINSTOR — это слой управления хранилищем, который использует DRBD в качестве транспорта репликации.
Слой управления (control plane) — это программный компонент, который отвечает за то, как DRBD-ресурсы создаются, конфигурируются и управляются в кластере. Он не хранит и не реплицирует данные сам по себе, а координирует работу DRBD — определяет, на каких узлах разместить реплики, как обрабатывать отказы и как применять изменения конфигурации хранилища.
Важно сразу уточнить: DRBD мы не заменяем. Это проверенная временем технология репликации блочных устройств на уровне ядра Linux, и она остаётся в основе нашего хранилища. Мы заменяем слой управления — то, как DRBD-ресурсы создаются, конфигурируются и управляются в кластере.
Контекст: хранилище в эпоху усложнения
За последние годы Kubernetes стал полноценной платформой, на которой работают базы данных, очереди сообщений, аналитические системы и виртуальные машины. Всё больше организаций переносят в Kubernetes критичные stateful-нагрузки — и требования к хранилищу растут вместе с этим.
Наши платформы — Deckhouse Kubernetes Platform (DKP) и Deckhouse Virtualization Platform (DVP) — не исключение. Сценарии использования хранилища становятся сложнее: больше типов нагрузок, выше требования к надёжности, строже политики безопасности, больше кластеров, которыми нужно управлять. Всё это предъявляет новые требования не столько к самому механизму репликации данных, сколько к тому, как этот механизм управляется, то есть к слою управления хранилищем.
Вызов: почему LINSTOR перестал нас устраивать
Когда мы выбирали решение для управления DRBD, LINSTOR был одним из лучших вариантов — зрелый продукт от разработчиков самого DRBD. Проблемы, которые мы видели на старте, казались решаемыми. Со временем, по мере роста масштаба и усложнения сценариев эксплуатации, стало понятно, что ряд архитектурных ограничений LINSTOR не удастся обойти без существенных компромиссов.
Основные вызовы, с которыми мы столкнулись:
Апгрейды и миграции требовали повышенного операционного внимания.
Обновления LINSTOR, включая миграции схемы базы данных, были нетривиальными и требовали ручного контроля. На масштабе сотен кластеров это создавало ощутимую операционную нагрузку и повышало риск инцидентов при обновлениях.
Модель управления осложняла предсказуемость изменений.
LINSTOR использует push-модель, при которой слой управления активно проталкивает изменения на узлы. В ряде сценариев это приводило к неожиданным состояниям и усложняло диагностику.
Критичные улучшения зависели от внешнего релизного цикла.
Когда мы находили проблемы и готовили исправления, их принятие в upstream зависело от приоритетов и расписания внешней команды. Критичные для нас фиксы могли ждать релиза неопределённо долго, а поддержка форка с растущим количеством патчей — это путь, масштабируемость которого ограничена.
Технологический стек не совпадал с экспертизой команды.
LINSTOR написан на Java, тогда как платформенная разработка хранилища в Deckhouse ведётся на Go. Это создавало барьер: для глубокой диагностики и доработок требовались специфические компетенции, не характерные для остальной команды. Это не претензия к Java как к языку — это вопрос операционной эффективности конкретной команды.
Ограничения в части контейнерных образов и политики цепи поставки ПО.
Среда выполнения Java накладывала ограничения на возможность использования distroless-образов и выполнения строгих требований к цепочке поставок ПО, которые мы закладываем в платформу.
Каждое из этих ограничений по отдельности можно было бы обойти. Но в совокупности они сформировали системную проблему: скорость, с которой мы могли улучшать хранилище, определялась не нашими приоритетами, а внешними ограничениями. Для платформы, которая берёт на себя ответственность за надёжность инфраструктуры клиентов, это неприемлемо.
Решение: свой собственный слой управления
Мы разрабатываем собственный слой управления для DRBD, спроектированный с нуля под реальные сценарии эксплуатации Kubernetes.
Ключевые принципы, которые мы закладываем:
- Архитектура на базе Kubernetes.
Не адаптация устаревшего подхода, а полноценный слой управления под реальные Kubernetes-сценарии эксплуатации.
- Единый язык программирования.
Это позволяет любому инженеру команды участвовать в разработке, ревью и диагностике — без переключения контекста и выделенной Java-экспертизы.
- Учёт требований виртуализации с первого дня.
Требования виртуализации DVP — работа с виртуальными машинами, миграция — закладываются в дизайн слоя управления с самого начала разработки.
- Полный контроль над релизным циклом.
Дорожная карта и приоритеты управляются внутри команды. Критичные исправления не ждут внешнего вендора — они выходят тогда, когда нужно нашим пользователям.
Что изменится для пользователей Deckhouse
Kubernetes прежде всего. По умолчанию.
Мы строим слой управления под реальные Kubernetes-сценарии эксплуатации — и для контейнеров, и для виртуальных машин, — а не адаптируем внешний инструмент постфактум. Управление хранилищем станет таким же нативным, как управление любым другим ресурсом в кластере.
Быстрее цикл улучшений и исправлений.
Критичные изменения больше не зависят от внешнего вендорского релизного цикла. Мы сами управляем приоритетами и можем реагировать на потребности пользователей с той скоростью, которую считаем правильной.
Прозрачность и предсказуемость развития.
В конце марта 2026 года будет проведено внутреннее техническое ревью. В апреле 2026 года на Deckhouse Conf мы представим доклад с техническим разбором архитектуры, принятых решений и первых результатов.
Нам важна ваша обратная связь — если у вас есть вопросы, которые критичны для вашего хранилища в Kubernetes, расскажите о них в форме обратной связи.