Поделиться
Deckhouse анонсировала разработку собственного слоя управления для DRBD
Компания Deckhouse, разработчик продуктов для построения надёжной корпоративной - инфраструктуры, объявила о разработке собственного слоя управления для технологии репликации данных DRBD (Distributed Replicated Block Device — распределённое реплицируемое блочное устройство). Компания уже провела внутреннюю техническую проверку первой версии решения. Новый компонент заменит используемый ранее LINSTOR в платформе хранения Deckhouse.
Собственный слой управления поверх DRBD — это программный компонент, который координирует работу хранилища в кластере: создаёт ресурсы, конфигурирует репликацию и управляет отказами. Важно отметить, что сама технология репликации DRBD остаётся неизменной. Это проверенное решение, которое продолжает служить основой для транспорта данных. Переход на новый слой управления будет прозрачным для пользователей: миграция не потребует простоя (downtime) и ручного переконфигурирования системы. Изменения касаются только уровня управления, что позволяет сохранить стабильность данных, обеспечить бесшовное обновление и повысить операционную эффективность платформы.
Разработка центрального управляющего узла в кластере (control plane) закрывает ключевую проблему масштабирования инфраструктуры. По мере того, как организации переносят в Kubernetes критичные нагрузки с сохранением состояния (stateful-нагрузки), требования к управляемости хранилища растут. Существующие инструменты управления, такие как LINSTOR, на масштабе сотен кластеров стали требовать повышенного операционного внимания при обновлениях и миграциях схем данных. Кроме того, зависимость от внешнего релизного цикла замедляла внедрение критичных исправлений, а различия в технологическом стеке усложняли глубокую диагностику.
Внедрение собственного слоя управления устраняет операционные риски и ускоряет доставку улучшений. Инженеры Deckhouse получают полный контроль над дорожной картой: критичные исправления больше не ждут релизов внешнего вендора, а выходят тогда, когда это нужно пользователям. Архитектура решения проектируется с учётом требований виртуализации с первого дня, обеспечивая единую логику работы для контейнеров и виртуальных машин.
«Мы начали разработку Control Plane, чтобы взять на себя полную ответственность за надёжность инфраструктуры клиентов. Для нас важно, чтобы скорость улучшения хранилища определялась потребностями пользователей, а не внешними ограничениями. Новая архитектура позволит полностью контролировать цикл обновлений, ускорить выпуск исправлений и обеспечить нативную интеграцию с Kubernetes и виртуальными машинами», — отметил Олег Сапрыкин, технический директор по инфраструктуре компании «Флант».
Особое внимание уделено предсказуемости и безопасности изменений. Control Plane строится как Kubernetes-native компонент по умолчанию. Это означает отказ от сложных схем миграции, требующих ручного контроля, и переход к декларативному управлению ресурсами хранилища как частью кластера. Система будет соответствовать строгим требованиям к цепочке поставок ПО (software supply chain), включая поддержку минималистичных контейнеров без оболочки ОС (distroless-образов), что снижает поверхность атаки и упрощает аудит безопасности.
Короткая ссылка
