Оркестратор поднял инфраструктурные ВМ, затем прикладные. Отчёт о переключении зелёный, но пользователи не входят в 1С. Для DR-платформы операция закончилась успешно: машины созданы, диски подключены, адреса заменены. Для администратора 1С восстановление только началось.
DR-план должен привести не к набору работающих ВМ, а к доступной информационной базе. Для этого отделите автоматические операции от решений администратора и DBA. На каждом переходе нужен наблюдаемый признак успеха: доступна сеть, СУБД открыла согласованную базу, клиент 1С установил сеанс, фоновые задания работают по нужному сценарию.
Порядок запуска ВМ описывает зависимости, но не проверяет 1С
Хайстекс в разборе возможностей Акура описывает rank, или Boot Order. ВМ с рангом 0 составляют инфраструктурный слой и запускаются первыми. Прикладной слой с рангом 1 стартует после загрузки и инициализации служб предыдущего уровня.
У этого механизма есть граница: машины с одинаковым рангом запускаются одновременно. Если сервер СУБД и кластер 1С лежат в одном ранге, порядок между ними не задан. Служба сервера 1С может стартовать раньше, чем СУБД примет подключения.
Один ранг подходит независимым узлам. Зависимые компоненты нужно развести по этапам: сеть и инфраструктурные службы, СУБД, кластер 1С, фоновые задания и обмены. Пользовательская проверка стоит последней, потому что ни один предыдущий этап не подтверждает вход в базу.
Re-IP тоже решает только инфраструктурную задачу. По описанию Хайстекс Акура назначает новый статический адрес или привязывает Floating IP, но не строит сеть и не настраивает коммутаторы. Маршруты, DNS, межсетевые правила и доступ между сегментами должны существовать до переключения.
| Этап переключения | Что делает оркестратор | Что проверяет администратор | Условие перехода |
|---|---|---|---|
| Репликация | Переносит данные ВМ на резервную площадку | Последняя точка укладывается в принятый RPO | Нужная точка доступна для запуска |
| Создание ВМ | Создаёт диски и сетевые подключения по таблицам сопоставления | Выбраны нужные сети, хранилища и учётная запись | ВМ получила ожидаемую конфигурацию |
| Сетевая адаптация | Меняет статический адрес или назначает Floating IP | Работают маршруты, DNS и правила доступа | СУБД и кластер доступны по нужным адресам |
| Запуск инфраструктуры | Включает ВМ по рангам | Службы предыдущего слоя готовы принимать запросы | Следующий слой не стартует раньше зависимости |
| Запуск 1С | Включает ВМ кластера и связанных компонентов | Агент и менеджеры кластера видят СУБД и информационную базу | Тестовый клиент установил сеанс |
| Возврат фоновых операций | Запускает назначенные ВМ и службы | Обмены и фоновые задания включены только на рабочей площадке | Нет двойного выполнения заданий |
Команда запуска подтверждает работу механизма DR. Готовность информационной базы подтверждает только прикладная проверка.
Не закрывайте этап по состоянию «ВМ запущена». Запишите проверку службы или приложения, ради которого машина существует. Для сервера СУБД это готовность принимать подключения, для кластера 1С — успешное соединение с базой.
Такой подход совпадает с логикой контроля 1С после автоматического запуска: выполненная команда и восстановленный пользовательский сеанс — разные результаты.
Точка восстановления ВМ не заменяет восстановление СУБД
Согласованное состояние виртуальной машины ещё не отвечает на вопрос, до какой транзакции восстановлена база. Хайстекс пишет, что Акура создаёт приложение-консистентные точки на уровне ВМ. При этом скрипты Oracle RMAN не встроены в продукт как обязательный мастер с заранее заданными решениями.
Это оставляет выбор точки и порядок восстановления за DBA. Оркестратор может подготовить диски, но не должен угадывать, какие журналы применять и в какой момент открывать базу пользователям.
В разборе Хайстекс приведён показательный сценарий. ВМ с дисками базы разворачивают из базовой точки, а диск с журналами транзакций подключают из более свежей. Затем DBA восстанавливает базу штатными средствами СУБД и подтверждает её согласованность.
Такой сценарий нельзя свести к кнопке «запустить ВМ». Нужно заранее записать:
- какую базовую точку выбирает DBA;
- откуда берутся журналы транзакций;
- кто выполняет восстановление средствами СУБД;
- по какому признаку база готова к открытию;
- кто разрешает запуск кластера 1С.
Если эти решения остаются в голове одного сотрудника, DR-план не автоматизирован. Он лишь переносит ручную операцию на резервную площадку.
После открытия базы проверьте не только форму входа. Запустите чтение данных, одну контролируемую запись и операцию, которая обращается к связанному сервису. Набор зависит от конфигурации, но должен пройти через сервер 1С, СУБД и сеть.
Для сложного перехода полезен тот же принцип, что и при испытании переноса 1С с проверкой копии и отката: пилот заканчивается на рабочем сценарии, а не на запущенной службе.
WORM защищает версию объекта, но не содержимое базы
WORM — это режим «одна запись, многократное чтение». S3 Object Lock запрещает изменить или удалить защищённую версию объекта до заданной даты либо до снятия бессрочной блокировки. Он закрывает риск удаления копии после компрометации учётных данных хранилища.
Для Object Lock в бакете должно работать версионирование. Обзор Selectel по защите копий в S3 уточняет ещё одно ограничение: настройки блокировки распространяются на новые объекты, а уже загруженные объекты сами под защиту не переходят.
Запись поверх защищённого объекта не меняет исходную версию. S3 создаёт новую. Попытку удалить защищённую версию хранилище отклоняет.
Режим удержания тоже меняет модель угроз. В Governance пользователь с правом s3:BypassGovernanceRetention может обойти запрет. В Compliance снять блокировку или удалить объект до конца срока не может даже администратор либо владелец учётной записи. Эти свойства описаны в материале Selectel и обзоре реализаций S3 Object Lock от «Корпорации Дом».
| Что проверяем | Что гарантирует Object Lock | Чего он не проверяет | Кто отвечает |
|---|---|---|---|
| Версионирование бакета | Хранилище может удерживать отдельные версии объекта | Что старые копии уже получили защиту | Администратор объектного хранилища |
| Срок удержания | Защищённую версию нельзя удалить до заданной даты | Хватит ли этого срока для принятого архива | Владелец политики хранения |
Режим Governance | Обычная операция удаления будет отклонена | У кого есть право обхода удержания | Администратор доступа |
Режим Compliance | Запрет нельзя снять до конца срока | Верно ли выбран срок до включения режима | Владелец DR-политики |
| Новые версии объектов | Исходная защищённая версия сохраняется при перезаписи | Содержит ли новая версия пригодную копию | Система резервного копирования |
| Чтение копии | Защищённый объект остаётся доступным | Открывается ли из него база 1С | DBA и администратор 1С |
| Пробное восстановление | Object Lock не участвует в проверке базы | Согласованы ли данные и журналы | DBA |
WORM защищает объект от удаления. Пригодность базы подтверждает отдельное восстановление на изолированной площадке.
Проверка должна читать копию тем же путём, который понадобится при аварии. Если копия хранится в S3, а DR-план не содержит учётных данных, сетевого маршрута и процедуры выгрузки, формальная неизменяемость мало помогает.
Не ограничивайтесь чтением файла. Разверните копию отдельно, восстановите СУБД и откройте базу клиентом 1С. Только этот прогон связывает защиту объекта с задачей бизнеса.
DR и резервное копирование могут конкурировать за одну операцию
Фраза «платформа интегрируется с СРК» не объясняет, что произойдёт во время переключения. Поведение зависит от конкретного продукта.
Хайстекс указывает, что Акура не блокирует сторонние системы резервного копирования и может работать параллельно с ними. Это не отменяет проверки расписаний: две системы могут одновременно читать одни диски, создавать точки либо менять состояние гостевой ОС.
В документации Astra Infrastructure Cloud действует другое ограничение. Аварийное восстановление, штатное задание резервного копирования и копирование через внешний API СРК не выполняются одновременно. DR-план должен заранее определить, какая операция получает приоритет и когда возвращается обычное расписание.
| Операция | Возможный конфликт | Кто принимает решение | Правило DR-плана |
|---|---|---|---|
| Репликация ВМ | СРК одновременно читает те же диски | Администратор виртуализации | Зафиксировать допустимое сочетание операций |
| Создание резервной копии | Платформа блокирует запуск DR-задания | Дежурный администратор | Описать, какую операцию останавливают первой |
| Запуск ВМ на резервной площадке | СРК считает новую ВМ отдельным объектом | Администратор СРК | Не включать её в штатную политику до приёмки |
| Восстановление СУБД | Автоматическая копия захватывает промежуточное состояние | DBA | Возобновить копирование после открытия базы |
| Возврат основной площадки | Две площадки запускают задания по одному расписанию | Администратор 1С | Оставить фоновые задания только на активной стороне |
| Возобновление СРК | Новая цепочка копий создаётся не из принятой точки | DBA и администратор СРК | Зафиксировать исходную точку новой цепочки |
Если платформа допускает параллельную работу, согласуйте расписания и нагрузку. Если операции взаимоисключающие, назначьте приоритет и условие возобновления СРК.
Универсальный интервал здесь только мешает. Длительность зависит от объёма данных, канала, хранилища и механизма СРК. В документации двух рассмотренных платформ нет срока, который можно перенести на произвольный контур 1С.
При замедлении тестового переключения смотрите не только внутрь гостевой ОС. Проверка задержки между ВМ, хранилищем и физическим узлом отделит проблему 1С от конкуренции за ресурсы виртуализации.
Тест DR заканчивается пользовательским сеансом
Полный прогон начинается с подтверждения готовности резервной сети. Затем запускаются инфраструктурные службы, СУБД и кластер 1С. Между ними стоят проверки, а не только задержки по таймеру.
После запуска СУБД DBA выбирает согласованную точку и восстанавливает базу штатными средствами. Администратор 1С открывает её клиентом, выполняет контрольное чтение и запись, проверяет обмены. Лишь затем возвращается расписание резервного копирования.
Документация Astra Infrastructure Cloud указывает RTO менее 15 минут для автоматического переключения критических систем. Этот показатель относится к автоматическому переключению внутри данной платформы. Он не включает выбор точки DBA, восстановление средствами СУБД и прикладную приёмку 1С.
Не переносите эти 15 минут на весь DR-план и другие продукты. Измерьте отдельно инфраструктурный запуск, восстановление базы и пользовательскую проверку. Тогда станет видно, какой участок съедает срок и кому принадлежит работа.
Порядок теста выглядит так:
- Подтвердите доступность сетей, DNS, маршрутов и правил между сегментами.
- Запустите инфраструктурный слой и дождитесь готовности его служб.
- Поднимите сервер СУБД, но не открывайте базу пользователям.
- Восстановите выбранную точку и журналы средствами СУБД.
- Запустите кластер 1С и подключите информационную базу.
- Войдите через обычный клиент под тестовой учётной записью.
- Проверьте чтение, запись, фоновые задания и обмены.
- Возобновите работу СРК из принятого состояния.
Каждый шаг должен содержать исполнителя, наблюдаемый результат и запрет перехода. Например: «DBA подтвердил открытие базы без режима восстановления; до этого кластер 1С не запускаем». Формулировка исключает спор во время аварии.
Что отдать автоматике, а что оставить человеку
Оркестратору отдайте повторяемые инфраструктурные действия: репликацию, создание ВМ, подключение дисков и сетей, Re-IP, запуск по зависимостям. Эти операции хорошо описываются таблицами сопоставления и проверками состояния.
Человек принимает четыре результата:
- резервная сеть доступна нужным компонентам;
- СУБД восстановлена в согласованную точку;
- пользователь вошёл в 1С и выполнил контрольную операцию;
- СРК вернулась к штатному расписанию без второй активной площадки.
В готовом DR-плане у каждой строки есть исполнитель, признак успеха и условие остановки. Если признак нельзя проверить автоматически, шаг не считается автоматизированным. Зелёный отчёт оркестратора тогда остаётся промежуточным сигналом, а не подтверждением готовности 1С.