Если вы настраивали аварийное восстановление для OpenStack, то знаете частую проблему: при отказе от Ceph организация безагентной инкрементальной репликации требует поиска альтернативных способов отслеживания изменений.
Самым очевидным кандидатом на эту роль выступает механизм QEMU Dirty Bitmaps — это хорошо изученный в экосистеме KVM/QEMU способ отслеживания измененных блоков (CBT). Однако его использование в OpenStack упиралось в отсутствие штатного API на уровне управляющего слоя. Из-за этого приходилось выбирать между двумя крайностями: строить инфраструктуру исключительно на Ceph или ставить агенты внутрь каждой гостевой ОС.
Ниже расскажу, с какими ограничениями сталкивались наши пользователи раньше, как мы переписали логику работы с инкрементальными данными на уровне гипервизора и что еще полезного появилось в релизе «Хайстекс Акура 4.6».
Полная и инкрементальная репликация из OpenStack независимо от типа СХД
Раньше для инкрементальной репликации из OpenStack в «Хайстекс Акура» требовался прямой доступ к Ceph. В версии 4.6 мы вынесли отслеживание изменений на уровень гипервизора QEMU/KVM и полностью сняли это ограничение. Что это дает:
Полную безагентность: больше не нужно ставить сторонний софт в гостевые ОС.
Поддержку любых СХД: решение выполняет инкрементальную и полную репликацию через Cinder.
Первая репликация всегда выполняется полностью. В последующих циклах система вычитывает только изменившиеся блоки через QEMU Dirty Bitmaps.
Важная деталь: так как dirty bitmaps хранятся в памяти процесса QEMU, исходная ВМ должна оставаться включенной между циклами. Если процесс QEMU останавливался или перезапускался, следующая репликация автоматически выполнится в полном объеме, после чего инкрементальная цепочка продолжится.
Чтобы безопасно забирать dirty bitmaps с compute-нод, мы выделили эту логику в отдельный сервис — Bitmap Manager, который выполняет роль ограниченного прикладного шлюза. Учитывая жесткие требования регуляторов и служб безопасности, поддерживаются два сценария развертывания:
Удаленное размещение: сервис запускается в управляющей зоне, подключается к Libvirt по SSH и вычитывает метаданные NBD по TCP. Подходит для контуров, где запрещено ставить сторонние компоненты на compute-ноды.
Локальное размещение: сервисный контейнер разворачивается непосредственно на compute-ноде и общается с Libvirt и QEMU через локальные UNIX-сокеты. Это полностью исключает необходимость открывать SSH и выводить NBD-порты в сеть.
При этом сам внешний агент репликации запускается как отдельная ВМ в OpenStack. Он общается с OpenStack API, который создает snapshot/image и подключает временный том к Агенту. Агент вычитывает данные как из обычного блочного устройства, используя карту блоков, полученную от Bitmap Manager.
Аварийное восстановление для изолированных контуров
Технология Direct2Target (D2T) впервые появилась в «Хайстекс Акура» для миграции виртуальных машин на площадки, где развернуть промежуточное объектное хранилище невозможно или нецелесообразно: агент записывает данные сразу на диски целевой платформы. В версии 4.6 D2T адаптирован под DR-сценарии, в том числе когда прямое API-подключение к целевой площадке недоступно. Поэтому теперь D2T определяет, куда именно попадают данные на целевой стороне. А за сетевую маршрутизацию отвечает интегрированная технология Receiver Mesh: агенты репликации обмениваются данными напрямую друг с другом, минуя контроллер «Хайстекс Акура».
Вместе это позволяет строить сценарии миграции и аварийного восстановления в полностью изолированных контурах, где недоступны ни объектное хранилище на приемной стороне, ни прямой сетевой маршрут к нему.
Дополнительно в рамках D2T расширена поддержка форматов образов — теперь система «из коробки» понимает raw, qcow2, VMDK, OVA и ISO, и повышена стабильность работы пользовательского интерфейса.
Другие изменения в релизе 4.6
Помимо механизмов CBT и D2T, в новую версию вошли платформенные и системные обновления:
Миграция на PostgreSQL. База данных решения переведена на PostgreSQL. Для пользователей процесс обновления проходит без изменения текущих регламентов и рабочих процессов.
Оптимизация работы агентов. Повышена надежность операций подключения и отключения (
attach/detach) временных томов Cinder. Ускорена обработка файловых резервных копий при нестабильном сетевом соединении.Расширение поддержки ОС. Добавлена совместимость с новыми дистрибутивами и ядрами Linux, включая RHEL 9.8, RHEL 10.2 и Ubuntu 26.04.
Требования к инфраструктуре для внедрения CBT
Перед пилотным тестированием рекомендуется проверить соответствие среды следующим условиям:
1. Подготовка и настройка окружения
Выберите один гипервизор и разверните связанный экземпляр Bitmap Manager — на отдельной управляющей машине или локально на compute-ноде.
Настройте аутентификацию по токену и необходимые права Libvirt.
Для удаленного варианта дополнительно настройте SSH-доступ, правила межсетевого экрана и TLS PSK для NBD.
Для локального варианта настройте работу через UNIX-сокеты и изоляцию сервисного контейнера.
Убедитесь, что Bitmap Manager корректно обнаруживает тестовую ВМ и вызывает строго заявленный набор QMP-команд.
2. Проверка CBT и базовых сценариев репликации
Выполните первую полную репликацию виртуальной машины типа boot-from-volume.
Внесите изменения в данные ВМ и убедитесь, что платформа вычитывает исключительно изменившиеся диапазоны блоков.
Подтвердите, что процедура создания снимка запущенной ВМ проходит без остановки процесса QEMU.
3. Валидация жизненного цикла дисков
Проверьте корректность цепочки операций с временными дисками: создание, монтирование (attach), чтение данных, размонтирование (detach) и удаление.
Протестируйте ВМ с максимально допустимым в вашей инфраструктуре числом дисков и проверьте точность сопоставления устройств (disk mapping).
4. Отработка сбойных и специфических сценариев
Выполните остановку или перезагрузку ВМ (power-off / reboot) и подтвердите штатный переход следующего цикла к полной репликации.
Совместно с администратором OpenStack отработайте процедуру восстановления при таймаутах и зависании подключений томов (stuck attachment).
Если сценарии входят в рамки проекта, отдельно проверьте репликацию boot-from-image ВМ, поведение при живой миграции (live migration) и работу в условиях доступа между разными проектами OpenStack (cross-project access).
Дистрибутивы «Хайстекс Акура 4.6» и документация по развертыванию доступны в личном кабинете. Запрашивайте демо по ссылке. А если у вас специфический сетап OpenStack — добро пожаловать в комментарии.
