Где заканчивается автопилот в DR: разбор оркестрации ВМ, WORM в S3, конфликтов с СРК и задач DBA

Привет, Хабр! Разбирать вопросы после эфиров — полезная практика. В чате трансляции часто поднимают темы, с которыми инженерам приходится сталкиваться на пилотах и в продакшене.

На вебинаре Хайстекс про восстановление в гибридной и мультиоблачной среде мы разбирали сценарии катастрофоустойчивости. Из обсуждения в чате получился список практических тем: оркестрация, гибридное хранение, защита от шифровальщиков и совместная работа с действующей СРК.

Я собрал эти вопросы, уточнил детали у команды разработки и оформил ответы в отдельный разбор. А если захотите посмотреть живую демонстрацию и схемы, ссылка на запись вебинара будет в конце поста.

Оркестрация и параметры запуска при DR

Как настроить очередность запуска ВМ информационной системы в рамках DR-плана?

Машиночитаемая часть плана аварийного восстановления (DRP) в Хайстекс Акура формируется автоматически на основе среплицированных данных. Последовательность старта виртуальных машин на целевой площадке регулируется параметром rank (Boot Order).

Запуск ВМ выполняется пошагово на основе целых чисел, начиная с нуля:

• rank 0 (Инфраструктурный слой): запускаются в первую очередь. Сюда обычно относятся контроллеры домена, сетевые шлюзы и базовые СУБД.

• rank 1 (Прикладной слой): включаются строго после того, как все ВМ с рангом 0 полностью загрузятся и инициализируют свои службы. Это оптимально для серверов приложений и веб-сервисов, зависящих от БД.

• rank 2 и выше: запускаются последовательно после завершения инициализации предыдущей группы.

• Параллельный запуск: все ВМ с одинаковым значением rank внутри одного DR-плана запускаются оркестратором одновременно.

Логическая группировка ВМ в панели управления не ограничивает порядок их старта. Для обработки кросс-системных зависимостей (например, когда веб-сервис одной системы зависит от базы данных другой) достаточно объединить компоненты в единый DR-план и расставить им соответствующие ранги rank.

Можно ли настроить автоматический запуск ВМ-реплик? 

Запуск ВМ-реплик при аварии управляется оркестратором без необходимости ручной сборки конфигураций в момент инцидента.

Предусмотрена ли смена IP-адреса ВМ при запуске реплики?

Да. Оркестрация включает не только подачу команд на включение, но и приведение сетевых и системных настроек ВМ в соответствие с target-площадкой:

• Сетевая адаптация (Re-IP): машине можно принудительно назначить новый статический IP-адрес в целевой сети или привязать плавающий IP (Floating IP).

• Передача метаданных (user-data): настройка параметров ОС на этапе старта через механизмы Cloud-Init / Cloudbase-Init.

• Пост-запускные сценарии: выполнение произвольных команд и скриптов (rc.local) внутри ОС восстановленной машины.

Важно: Акура не создает сетевую инфраструктуру «с нуля» и не настраивает коммутаторы. Целевые подсети должны быть развернуты на DR-площадке заранее, система считывает их ID из инфраструктуры. То же касается проброса портов (Port Forwarding / NAT): решение привязывает порт ВМ к интерфейсу, но сама настройка правил на внешнем файрволе выполняется администратором.

Проверить корректность рангов rank, отработку скриптов и смену IP-адресов можно в фоновом режиме, без влияния на доступность продуктовой среды. Все параметры DR-планов доступны через RESTful API для интеграции с внешними системами управления (ITSM / Orchestration).

Неизменяемость копий и защита от шифровальщиков

На каких типах хранилищ поддерживается immutable backup и как он реализован?

Функционал Immutable Backup предназначен для защиты инфраструктуры от атак программ-вымогателей (Ransomware), преднамеренного удаления данных и для обеспечения соответствия регуляторным требованиям.

Технология поддерживается на любых S3-совместимых объектных хранилищах (в облаках или On-premise), реализующих спецификацию S3 Object Lock. В основе лежит модель WORM (Write Once, Read Many), которая блокирует изменения на уровне самого хранилища и работает в трех режимах:

• Compliance Mode (Безусловная защита): Ни один пользователь — включая администраторов и root-аккаунт — не может удалить или изменить копию до истечения заданного срока.

• Governance Mode (Гибкая защита): Защищает от удаления обычными пользователями и вредоносным ПО, но оставляет администраторам с повышенными привилегиями возможность досрочного снятия блокировки с флагом bypass.

• Legal Hold (Юридическое удержание): Бессрочная юридическая блокировка объекта, действующая до ее ручного снятия авторизованным сотрудником.

Важно: Применение неизменяемых копий требует точного расчета политик хранения (Retention Policy), заблокированные объекты физически невозможно удалить раньше установленного срока для оперативного освобождения места.

Глубина хранения точек восстановления

Какова максимальная глубина хранения точек восстановления? На сколько точек назад можно откатиться? 

В Хайстекс Акура отсутствуют программные или архитектурные ограничения на количество точек восстановления. Глубина архива определяется исключительно политикой хранения (Retention Policy) и доступной емкостью СХД.

Правила хранения задаются количеством удерживаемых точек и настраиваются на трех уровнях:

1. Уровень проекта: дефолтные правила для всего окружения.

2. Уровень группы машин: единая политика на логическую группу ВМ (массовое управление сервисами).

3. Уровень отдельной ВМ: индивидуальная переопределяемая настройка.

Оптимизация в архитектуре Double Storage

При использовании модели гибридного хранения политики ротации для блочного и S3-объектного слоев задаются независимо:

• Блочное хранилище: содержит минимальное количество свежих точек (например, 1–2) для обеспечения минимального RTO и мгновенного запуска ВМ при аварии.

• S3-объектное хранилище: используется для хранения длинных цепочек (5, 10, 50 и более точек). Дедупликация, сжатие и низкая стоимость S3 позволяют хранить глубокий архив без перерасхода бюджета.

Механика сборки и влияние на RTO

При формировании глубоких архивов важно учитывать алгоритм консолидации: для отката на выбранную историческую точку решение последовательно собирает изменения по цепочке инкрементов обратно к базовому полному бэкапу. Чем длиннее цепочка инкрементов, тем больше времени требуется системе на сборку консистентного состояния дисков.

Для исключения ошибок при администрировании в платформе разграничены понятия:

• Снапшот — служебный краткосрочный снимок на стороне гипервизора, создаваемый только в момент снятия реплики.

• Точка восстановления — итоговая единица отката. В интерфейсе по каждой точке отображается вся цепочка (базовый бэкап + инкременты) и список включенных дисков.

Совместная работа с действующей СРК

Конфликтует ли Хайстекс Акура с уже развернутой СРК, которая резервирует те же ВМ, и ограничивает ли её работу?

Акура не блокирует работу сторонних систем резервного копирования и может функционировать с ними параллельно. Однако разворачивание двух систем на одном парке ВМ требует планирования ресурсов:

1. Разграничение задач: резервное копирование фиксирует глубокую историю для точечного восстановления объектов (файлов, таблиц), а DR обеспечивают перезапуск сервисов целиком на резервной площадке.

2. Пропускная способность каналов (WAN/LAN): фоновая репликация Акуры использует сжатие и дедупликацию трафика, но каналы связи должны проектироваться с учетом суммарной нагрузки от репликации и окон бэкапа сторонней СРК.

3. Разведение окон обслуживания: во избежание конфликтов на уровне гипервизора (конкуренция за создание и консолидацию снапшотов ВМ) расписания репликации Акуры и запуски внешних бэкап-агентов необходимо разводить по времени.

Синхронизировать процессы репликации с внешними бэкап-скриптами и расписаниями можно через RESTful API.

Восстановление БД Oracle

Восстановление БД Oracle, если скрипты RMAN уже встроены в продукт или после восстановления файлов резервной копии администратору БД нужно завершать восстановление вручную через CLI?

При восстановлении критичных баз данных важно четко понимать разграничение функций платформы и задач администратора СУБД (DBA):

• Уровень Хайстекс Акура: решение обеспечивает создание приложение-консистентных точек восстановления на уровне ВМ. При аварии Акура разворачивает виртуальную машину, восстанавливает структуру дисков и привязывает сетевой контур. Стандартное восстановление экземпляра (Instance Recovery) выполняется ОС автоматически.

• Уровень специализированных утилит (Oracle RMAN): скрипты RMAN не зашиты в интерфейс как жесткий мастер настройки. Если требуется специфический сценарий — например, докат изменений по архивам журналов (Point-in-Time Recovery через RMAN CLI) — эта процедура выполняется либо вручную администратором БД, либо автоматически через кастомные скрипты инициализации (user-data, rc.local) и вызовы RESTful API.

Сценарий сборки из двух точек

Поскольку Акура работает на блочном уровне, поддерживается сценарий гибкого восстановления СУБД при повреждении основной точки:

1. Из базовой точки разворачивается ВМ с дисками самой базы данных.

2. Из второй (более свежей) точки монтируется диск с журналaми транзакций (Archive Logs / Redo Logs).

3. Администратор БД или скрипт накатывает журналы на базу, собирая актуальное состояние СУБД.

Аналогичный подход применяется как для Oracle, так и для PostgreSQL (на базе WAL-журналов).

Скорость репликации

Какая скорость создания реплики типична и от чего она зависит в первую очередь?

Фиксированной скорости репликации в МБ/с не существует, так как производительность зависит от инфраструктуры заказчика и параметров целевого облака. Важно разграничивать три сценария:

1. Инкрементальная репликация (дельта-синхронизация): в непрерывном режиме передаются только изменившиеся блоки данных. В этом сценарии система достигает минимального показателя RPO в единицы минут.

2. Синхронизация в Double Storage: перенос архивных точек из блочного хранилища в S3 выполняется асинхронно в фоновом режиме.

3. Конвертация бэкапа в DR-реплику: скорость подготовки готовых к запуску томов на целевой площадке напрямую зависит от производительности целевой СХД и скорости выполнения API-запросов гипервизора.

Надежный бэкап строится на точной оркестрации, правильном распределении ресурсов с существующей СРК и понимании механики работы ваших СУБД. Полную запись эфира с архитектурными схемами и живой демонстрацией смотрите по ссылке: запись вебинара «Когда бэкап не успевает: восстановление в гибридной и мультиоблачной среде».