Failover для SCADA: Актив-пассив или актив-актив и как не потерять данные при переключении
2026-04-14 09:42
Отказоустойчивость SCADA - это не «второй сервер в стойке». На практике решают три вещи: как дублируется состояние, как быстро происходит переключение, что происходит с historian и клиентами. Выбор между актив-пассив и актив-актив зависит от допустимого простоя, риска потери данных и зрелости эксплуатации.
Ниже - инженерный разбор архитектуры failover, репликации, RPO/RTO и чек-лист квартального теста.
Короткий ответ
Актив-пассив проще в сопровождении: один узел ведет запись и обслуживает операторов, второй готов принять роль при сбое. Актив-актив дает меньше простоя при отказе узла, но требует строгой синхронизации состояния, аккуратной работы с historian и понятных правил split-brain. Чтобы не терять данные, фиксируйте RPO/RTO, проектируйте репликацию и кворум, и регулярно отрабатывайте failover на стенде и на площадке.
Ключевые термины: RTO и RPO
RTO (Recovery Time Objective) - сколько времени допустимо, пока SCADA недоступна или деградирована.
RPO (Recovery Point Objective) - сколько исторических данных можно потерять при аварии (например, до 30 секунд записи historian).
Если RPO/RTO не согласованы с бизнесом, архитектура будет либо избыточной, либо опасно слабой.
Актив-пассив: когда это лучший выбор
Плюсы: - проще отладка и обновления (rolling по регламенту); - меньше риска рассинхронизации приложений; - предсказуемая нагрузка на БД и historian.
Минусы: - простой при переключении может быть заметнее; - пассивный узел «простаивает» по вычислительным ресурсам (часто это приемлемо).
Типичный сценарий: производственные линии, где 1-3 минуты переключения допустимы при редких отказах, а главное - не потерять целостность данных.
Минусы: - сложнее согласовать запись в historian и единый «источник истины»; - выше требования к сети, кворуму и процедурам обновления; - ошибки проектирования дают split-brain и дубли данных.
Типичный сценарий: крупные диспетчерские центры, много клиентов, жесткие требования к доступности.
Репликация: что именно должно дублироваться
Минимальный перечень для SCADA-кластера:
конфигурация проекта и версии;
runtime-состояние (теги, alarms, batch context - по возможности платформы);
базы событий и журналов;
historian (или его реплика/зеркало);
сертификаты, DNS/VIP, параметры интеграций.
Важно разделить синхронную и асинхронную репликацию: асинхронная дешевле по задержке, но ухудшает RPO при сбое.
Потеря данных при переключении: типовые причины
буфер записи historian не сброшен на диск до отказа;
два узла одновременно считают себя мастером;
клиенты продолжают писать в «старого» мастера;
рассинхрон времени между узлами;
некорректный VIP/DNS TTL и «залипшие» соединения.
Архитектурные паттерны (упрощенно)
Элемент
Актив-пассив
Актив-актив
Вход клиентов
VIP на мастер
балансировка + sticky сессии
Запись historian
один writer
строго один writer или шардирование
Обновление
staged switch
требует процедуры и тестов
Split-brain риск
ниже
выше без fencing/STONITH
Конкретные механизмы зависят от вендора SCADA, но принципы одинаковы.
Чек-лист регламентного теста failover (раз в квартал)
Проводите в согласованное окно, с письменным планом и откатом.
Подготовка - Утверждено окно работ и ответственные (АСУ ТП, ИТ, производство). - Зафиксированы baseline: RTO/RPO, версии ПО, конфигурации. - Сделаны бэкапы конфигураций, БД, historian (по регламенту). - Проверены мониторинг, алерты, каналы связи с ПЛК.
Сценарий 1: отказ активного узла - Имитация отказа (питание/сеть/сервис) по плану. - VIP/кластер переключился на резерв в пределах RTO. - Клиенты HMI переподключились без ручного вмешательства (или по регламенту). - Нет разрывов записи historian выше допустимого RPO.
Сценарий 2: деградация сети к ПЛК - Поведение тегов и alarms предсказуемо. - Нет «ложной нормы» на экранах. - После восстановления нет дублей событий в журнале.
Сценарий 3: восстановление и failback - Возврат на основной узел без потери данных. - Проверена репликация после failback. - Нет зависших сессий и «мертвых» блокировок БД.
Пост-анализ - Зафиксированы фактические RTO/RPO и отклонения. - Обновлен runbook и список улучшений до следующего квартала.
Типовые ошибки проектирования
historian с двумя независимыми writer без координации;
отсутствие fencing при split-brain;
тест failover только «на бумаге»;
игнорирование времени и NTP между узлами;
обновления без проверки кластера на стенде.
Где уместен СТАБУР
Надежность верхнего уровня опирается на стабильный нижний: предсказуемые теги, корректные статусы связи, единые шаблоны проектов. На практике failover проще стандартизировать, когда ПЛК и SCADA-интеграция выровнены по объектам, в том числе в проектах на базе решений СТАБУР.
Заключение
Выбор актив-пассив или актив-актив - это компромисс между доступностью и сложностью. Без четких RPO/RTO и квартальных тестов кластер превращается в иллюзию отказоустойчивости. Проектируйте единого writer для критичных данных, защищайтесь от split-brain и фиксируйте результаты тестов цифрами, а не «вроде сработало».
FAQ
Можно ли сделать актив-актив без кворума?
Технически иногда да, но риск split-brain обычно неприемлем для производственной SCADA.
Что важнее для historian: RTO или RPO?
Для аналитики чаще критичен RPO. Для оператора на смене - RTO доступности клиента.
Как часто тестировать failover?
Минимум раз в квартал плюс после каждого крупного обновления.
Нужен ли отдельный стенд-кластер?
Желательно: иначе тесты на боевом контуре становятся рискованными.
Что делать, если переключение ломает интеграции?
Проверять VIP, сертификаты, ACL и таймауты на стороне OPC/REST/SQL.