Резервная площадка не поможет, если на ней нет актуальных виртуальных дисков 1С. Гипервизор запустится, но базы и серверные службы останутся на отказавшей СХД.
YADRO добавила асинхронную репликацию в TATLIN.FLEX.PRO и TATLIN.FLEX.EXPRESS. По сообщению mForum, функция защищает виртуальные среды через TATLIN.SATELLITES.VM Guard. Компонент можно развернуть на серверах x86.
Этого достаточно, чтобы включить TATLIN.FLEX в список кандидатов на пилот. Согласовывать архитектуру аварийного восстановления пока рано. В публикации нет RPO, списка гипервизоров, схемы лицензирования и порядка запуска копии.
RPO показывает, сколько последних данных компания готова потерять при аварии. Для 1С эта величина определяется не названием функции, а фактическим отставанием реплики в рабочей конфигурации.
Что добавила YADRO и какие вопросы остались
Связка состоит из TATLIN.FLEX, компонента TATLIN.SATELLITES.VM и функции Guard. Она переносит данные виртуальной среды на удалённую сторону.
Публикация mForum подтверждает саму возможность асинхронной репликации. Но она не описывает полный путь от остановки первой площадки до входа пользователей в 1С.
| Что сообщено | Что не раскрыто | Почему это нужно проекту 1С |
|---|---|---|
| Репликация предназначена для виртуальных сред | Список совместимых гипервизоров и их версий | Без подтверждённой совместимости пилот может остановиться на подключении виртуальной инфраструктуры |
| Функция доступна для TATLIN.FLEX.PRO и TATLIN.FLEX.EXPRESS | Требования к версиям ПО и порядок обновления действующей СХД | Нужно понять, потребуется ли окно обслуживания и можно ли обновиться без перестройки хранения |
| Защиту выполняет TATLIN.SATELLITES.VM Guard | Состав лицензий и ограничения по числу ВМ или объёму данных | Без этих условий нельзя посчитать бюджет двух площадок |
| Компонент поддерживает развёртывание на x86 | Требования к процессорам, памяти, сети и отказоустойчивости узлов | От ресурсов служебных узлов зависит работа репликации после сбоя одного из них |
| Репликация работает асинхронно | Допустимое отставание копии и поведение при разрыве связи | Проекту нужен измеримый RPO, а не только наличие удалённой копии |
| Заявлена защита виртуальной среды | Порядок запуска ВМ и обратного переключения | Реплика должна стать рабочей средой, а затем вернуть нагрузку на основную площадку |
Новость даёт основание назначить пилот. Подписывать по ней архитектуру аварийного восстановления нельзя.
Асинхронный режим означает, что запись на основной стороне и её передача разделены во времени. Поэтому удалённая копия может отставать. Размер отставания нужно измерять под вашей нагрузкой и на вашем канале связи.
Не назначайте RPO по рекламному описанию. Зафиксируйте его после испытания с обычным потоком документов, фоновых заданий и обменов.
Репликация дисков не запускает 1С
Предположим, основная площадка остановилась. На второй стороне сохранилась реплика виртуальных дисков СУБД и серверов 1С.
Для возврата сервиса этого мало. Резервная площадка должна предоставить вычислительные ресурсы, сеть, DNS, доступ к лицензиям и нужные зависимости.
Сначала запускают инфраструктурные службы, от которых зависит контур. Затем поднимают СУБД, проверяют состояние базы и только после этого запускают серверы 1С. Клиентский доступ открывают после проверки тестового сеанса.
Конкретный порядок зависит от вашей архитектуры. Например, сервер лицензирования может находиться на первой площадке. Тогда исправная реплика загрузится, но рабочие процессы 1С не получат лицензии.
Та же проблема возникает с DNS и сетевыми адресами. Если копия ВМ попадает в другую подсеть, одной команды запуска недостаточно. Нужны заранее подготовленные маршруты, правила межсетевого экрана и способ переключить имена.
| Часть контура | Что должна перенести репликация | Что готовят отдельно |
|---|---|---|
| Виртуальные диски СУБД | Данные дисков на резервной стороне | Проверку согласованности базы и порядок запуска экземпляра СУБД |
| Серверы 1С | Диски ВМ с установленной платформой | Лицензии, учётные записи служб и связь с СУБД |
| Сеть | Доступ ВМ к резервной инфраструктуре, если это входит в интеграцию | Подсети, маршруты, DNS, правила межсетевого экрана и адреса публикации |
| Гипервизор | Подключение реплики к среде виртуализации, если оно поддерживается | Ресурсы для запуска, шаблоны ВМ и права администратора |
| Внешние обмены | Данные и настройки внутри реплицируемых ВМ | Доступ к банкам, ЭДО, почте, файловым ресурсам и интеграционным узлам |
| Возврат на основную площадку | Обратное движение данных, если его поддерживает выбранная схема | Окно работ, остановку записи и проверку данных после возврата |
Репликация закрывает перенос данных только как часть сценария. Работоспособность 1С подтверждает запуск всего контура на второй площадке.
До пилота полезно проверить, как виртуализация влияет на размещение служб и лицензий. Для этого подойдёт материал о выборе платформы для виртуальной 1С.
Репликация не заменяет резервную копию
Реплика повторяет изменения основной стороны. Если пользователь удалил данные или шифровальщик испортил файлы, повреждение может уйти на вторую площадку.
Резервная копия решает другую задачу: возвращает состояние на выбранный момент. Поэтому проект защиты 1С должен проходить две независимые проверки.
Первая проверка — запуск реплики после потери площадки. Вторая — восстановление прежней версии базы после логической ошибки, удаления или шифрования.
Смешивать TATLIN.FLEX Guard и TATLIN.Backup v1.5 нельзя. Это разные продукты и разные контуры защиты.
По сообщению iXBT Pro, TATLIN.Backup v1.5 получил асинхронную репликацию виртуальных файловых систем. Она переносит резервные копии на удалённую площадку. Guard в TATLIN.FLEX защищает виртуальную среду на СХД.
YADRO только планирует поддержку неизменяемых WORM-копий и режима Bunker в TATLIN.Backup. Поэтому нельзя приписывать эти свойства текущей функции Guard.
| Событие | Что помогает вернуть работу | Почему одного механизма мало |
|---|---|---|
| Отказ основной площадки | Реплика виртуальной среды на второй площадке | Без подготовленной сети и порядка запуска ВМ останутся выключенными |
| Повреждение базы после ошибочного действия | Резервная копия до момента ошибки | Реплика могла уже получить повреждённые данные |
| Шифрование доступных томов | Изолированная или неизменяемая резервная копия | Обычная доступная копия тоже может попасть под шифрование |
| Потеря связи между площадками | Локальная работа основной системы и контроль очереди репликации | После восстановления канала нужно проверить отставание и синхронизацию |
| Ошибка обновления платформы или конфигурации | Проверенная резервная копия и отдельный план отката | Межплощадочная копия не гарантирует нужную историческую точку |
Для защиты виртуальной 1С нужны оба испытания. Реплика отвечает за потерю площадки, резервная копия — за возврат прежнего состояния данных.
Когда TATLIN.FLEX стоит включить в проект
Главное условие — у компании уже есть или строится вторая площадка. Одна СХД с репликацией не создаёт вычислительные узлы, сеть и лицензии для резервного запуска.
TATLIN.FLEX.PRO подходит для рассмотрения там, где нужна блочная или файловая СХД. В обзоре mClouds указаны FC, iSCSI, NFS v3/v4 и SMB v3. Но выбор протокола сам по себе не подтверждает скорость 1С.
PRO использует два контроллера и поддерживает до четырёх дисковых полок, по данным обзора mClouds. Эта схема защищает от части локальных аппаратных отказов. Она не заменяет вторую площадку.
У младшей TATLIN.FLEX.TWIN тоже два контроллера. В официальных характеристиках YADRO указаны 128 ГБ памяти на контроллер и 256 ГБ на систему. СХД принимает 24 либо 48 накопителей, в зависимости от модификации.
Эти характеристики помогают оценить масштаб системы. Они ничего не говорят о времени запуска виртуальной 1С после межплощадочной аварии.
| Исходная ситуация | Решение по TATLIN.FLEX | Что проверить |
|---|---|---|
| Есть одна площадка и нет резервных вычислительных узлов | Не считать репликацию готовой защитой от потери площадки | Где запустятся СУБД и сервер 1С после остановки основной стороны |
| Есть две площадки, а 1С работает в ВМ | Включить PRO или EXPRESS с Guard в пилот | Гипервизор, версии ПО, сеть, лицензии и полный цикл переключения |
| Нужен возврат данных после удаления или шифрования | Сохранить отдельный контур резервного копирования | Глубину хранения, изоляцию копий и регулярное тестовое восстановление |
| Нужна защита от отказа одного контроллера | Оценить двухконтроллерную конфигурацию | Какие отказы система переносит без остановки доступа |
| Нужна межплощадочная защита | Не подменять её локальной отказоустойчивостью | Канал между площадками, отставание копии и запуск на резервной стороне |
| СХД выбирают под рабочую нагрузку 1С | Испытать систему на копии своей базы | Задержки СУБД, фоновые задания, резервное копирование и деградацию при сбое |
Guard имеет смысл при двух площадках и заранее описанном запуске виртуальной 1С. Для одиночной СХД он не создаст место аварийного запуска.
Подход к проверке кандидата можно взять из материала о том, когда СХД включают в проект 1С. Там решение тоже принимают по сценарию эксплуатации, а не по паспортному числу.
Полезен и соседний разбор испытания СХД на копии базы 1С. Производитель другой, но логика приёмки та же: поставщик показывает функцию, а вы проверяете свой контур.
Как провести пилот Guard для виртуальной 1С
Пилот должен воспроизвести отказ площадки, а не только показать статус «реплика создана». Иначе вы проверите перенос блоков, но не возврат пользователей в базу.
Возьмите копию рабочего контура. В неё должны входить СУБД, сервер 1С и необходимые инфраструктурные зависимости. Боевой контур для первого испытания не нужен.
Сначала зафиксируйте обычную нагрузку и запустите репликацию. Затем остановите исходную сторону так, как предусматривает методика пилота. На резервной площадке поднимите ВМ по согласованному порядку.
После запуска проверьте СУБД и серверные процессы 1С. Откройте базу тестовой учётной записью, выполните чтение и контролируемую запись. После этого проверьте фоновые задания и обмены.
Результат пилота записывайте как наблюдение, а не как оценку «работает». Нужны четыре показателя:
- сколько последних данных отсутствовало в копии при переключении;
- сколько времени прошло от остановки первой стороны до входа в базу;
- какие изменения сети, DNS и лицензий пришлось сделать вручную;
- удалось ли вернуть нагрузку на основную площадку без расхождения данных.
Порог для каждого показателя задаёт компания. Если бухгалтерия допускает потерю только завершённых транзакций, проект должен подтвердить это испытанием. Пресс-релиз такого подтверждения не даёт.
Отдельно разорвите связь между площадками. Проверьте, что происходит с записью на основной стороне, где виден сбой и как возобновляется передача.
Затем повторите испытание с недоступным служебным узлом Guard. Эта проверка покажет, не добавили ли вы в схему новую единственную точку отказа.
Последний этап — возврат нагрузки назад. Аварийный запуск без обратного переключения оставляет команду на резервной площадке без проверенного пути домой.
Решение для проекта
Включайте TATLIN.FLEX.PRO или EXPRESS в короткий список, если 1С работает в ВМ и есть вторая площадка. Новая функция закрывает перенос виртуальной среды между площадками.
Не согласовывайте покупку, пока поставщик не подтвердит четыре пункта:
- совместимость Guard с вашим гипервизором и версиями его компонентов;
- состав лицензий для основной и резервной площадок;
- порядок запуска СУБД, серверов 1С, сети и лицензирования;
- порядок обратного переключения после восстановления основной стороны.
Репликацию и резервные копии проверяйте раздельно. Первая должна поднять 1С после потери площадки. Вторая — вернуть базу к состоянию до логического повреждения.
Если состав контура ещё не определён, запросите проверку архитектуры виртуальной 1С перед закупкой. Здесь решение зависит от гипервизора, СУБД, сети, лицензий и допустимого простоя.
Финальный критерий простой: TATLIN.FLEX проходит отбор после полного аварийного запуска на копии вашего контура. Наличие пункта «асинхронная репликация» в спецификации этого не доказывает.