CBT для OpenStack без привязки к системе хранения и аварийное восстановление для любых платформ. Разбор релиза «Хайстекс Акура 4.6»
- 2 мин.
В релизе «Хайстекс Акура 4.6» мы интегрировали механизм отслеживания измененных блоков (Changed Block Tracking, CBT) в агент внешней репликации из OpenStack, добавили поддержку DR-сценариев в технологию Direct2Target (D2T), которая передает трафик между агентами в обход контроллера, и перевели внутреннюю базу данных на PostgreSQL.
Полная и инкрементальная репликация из OpenStack независимо от типа хранилища
Главное архитектурное нововведение версии 4.6 — механизм CBT, который инженеры Хайстекс реализовали на уровне QEMU/KVM. Новое решение устраняет привязку к Ceph и дает возможность выполнять полную и инкрементальную репликацию из OpenStack с любыми системами хранения Cinder.
Изменённые области диска определяются на уровне QEMU/KVM с помощью карт битовых изменений (Dirty Bitmaps) без установки дополнительного программного обеспечения внутрь защищаемой гостевой операционной системы. Первая репликация выполняется в полном объеме, а при последующих циклах передаются только изменённые блоки, при условии, что исходная виртуальная машина продолжает работать, а ее процесс QEMU не останавливался и не перезапускался.
Для соответствия регламентам безопасности Bitmap Manager поддерживается в двух вариантах размещения: удаленном (в управляющей зоне без установки сервисов на compute-ноду, со связью по SSH/TCP и NBD over TCP с TLS PSK) и локальном (в виде контейнера прямо на гипервизоре OpenStack с обменом через локальные UNIX-сокеты), что полностью исключает потребность в SSH и сетевом NBD-доступе.
Рис. 1. Варианты размещения Bitmap Manager: удаленное (в управляющей зоне) и локальное (на compute-ноде OpenStack).
Рис. 2. Схема взаимодействия агента репликации, Bitmap Manager и API OpenStack при вычитке измененных блоков.
Поддержка сценариев аварийного восстановления в D2T
Технология D2T впервые появилась в «Хайстекс Акура 4.5» для миграции виртуальных машин на площадки, где развернуть промежуточное объектное хранилище невозможно или нецелесообразно: агент записывает данные сразу на диски целевой платформы. В новой версии мы адаптировали D2T под DR-сценарии, в том числе когда прямое API-подключение к целевой площадке недоступно.
D2T определяет, куда попадают данные, а за то, как они идут по сети, отвечает интегрированная в процессы D2T технология Receiver Mesh: агенты репликации обмениваются данными напрямую, минуя контроллер «Хайстекс Акура». Вместе это позволяет строить сценарии переноса и восстановления в изолированных контурах, где недоступны ни объектное хранилище на приемной стороне, ни прямой сетевой маршрут к нему.
Также в релизе добавлена поддержка форматов образов (raw, qcow2, VMDK, OVA, ISO) и повышена стабильность работы пользовательского интерфейса.
Переход внутренней базы данных на PostgreSQL
Мы перенесли внутреннюю базу данных «Хайстекс Акура» на PostgreSQL. Это архитектурное решение модернизирует базовый стек платформы и закладывает основу для масштабирования продукта и его долгосрочной поддержки. Для пользователей переход проходит бесшовно и не требует изменения привычных рабочих процессов.
Совместимость, резервное копирование и безопасность
В новой версии оптимизированы производительность и надежность агента файлового резервного копирования, расширена поддержка современных операционных систем и ядер Linux, включая RHEL 9.8, RHEL 10.2 и Ubuntu 26.04. Наряду с этим мы внесли плановые исправления безопасности.
Версия «Хайстекс Акура 4.6» уже доступна. Действующие клиенты могут получить дистрибутивы и инструкции по обновлению в личном кабинете.
Задайте вопрос команде разработки или оставьте заявку на тестирование.