Резервирование SCADA и высокая доступность: горячий резерв, RAID, работа 7×24

Когда односерверная установка становится риском остановки линии

Один сервер SCADA уместен для пилотной линии, лаборатории или площадки, которая часами может работать без живой мнемосхемы. Он перестаёт быть уместным, когда смена держит производство по этому экрану, когда аварии — рабочий ранний сигнал, или когда с той же машины читают историю для качества и энергоучёта.

Болезненный отказ редко выглядит как эффектный краш. Чаще диск заполняется, обновление Windows зависает, блок питания выходит, сетевая карта отваливается — и замечают это, только когда следующая смена не открывает тренд. Вопрос не в том, откажет ли сервер, а в том, сколько производство протянет без него и останутся ли последние минуты данных, когда он вернётся.

• Непрерывное производство без окна простоя: линия, технологический узел, группа насосных станций водоканала или энергообъект, который не может ждать переустановки
• HMI — рабочее место оператора: пуск и стоп, загрузка рецепта, квитирование аварий идут с этого экрана, а не только с местного пульта
• История лежит на том же диске, что и runtime: отказ диска стирает и живую картину, и доказательства для качества или энергоотчётов
• Драйверы связи стоят только на этом хосте: сессии PLC, OPC и шлюзов падают вместе с корпусом, и даже запасной ПК не видит объект, пока каналы не собраны заново
• Дежурство 7×24 при тонкой ночной смене: дежурный квитирует аварию, но не восстановит образ сервера в два часа ночи

Если верны два или более пункта, односерверная схема — уже не экономия. Это неявное решение, что отказ сервера допустим как остановка производства.

Что горячий резерв и кластер должны держать синхронно

Купить вторую лицензию и поставить второй ПК рядом — ещё не горячий резерв. Переключение работает, только если резерв уже держит рабочую копию всего, что оператору нужно в первые секунды после перехода. Четыре хранилища обычно вспоминают только на первом настоящем отказе: оперативная БД, архивная БД, проект HMI и каналы связи.

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

• Оперативная БД: текущие значения тегов, состояние аварий, блокировки и уставки в памяти. Если резерв отстаёт даже на несколько секунд, смена действует по уже неверной картине
• Архивная БД: тренды, журнал событий и технологические кривые. RAID1 на диске — не то же самое, что реплика на втором узле; разрыв истории после переключения — вопрос качества и аудита, а не только ИТ
• Проект HMI: мнемосхемы, привязки тегов, скрипты, права пользователей и языковые ресурсы. Runtime, поднятый на вчерашнем файле проекта, покажет неверную картину, даже если базы актуальны
• Каналы связи: пути к PLC, сессии OPC UA/DA, каналы шлюзов и то, к какому NIC они привязаны. Каналы только на основном узле означают, что резерв стартует в пустой цех

Практическая проверка: выключить основной узел, пока оператор смотрит тренд и квитирует аварию. Если резерв не показывает те же теги, тот же список аварий и ту же недавнюю историю, пара ещё не является резервной системой.

RAID и сервер, на котором он стоит

RAID1 на дисках баз защищает от отказа одного диска. Он не защищает от отказа материнской платы, зависшей ОС, шифрования обоих зеркал или ИБП, который ни разу не проверяли. Дисковое резервирование и резервирование приложения лежат на разных уровнях; смешение их в одном предложении приводит к тому, что RAID есть, а линия всё равно стоит.

Серверу со SCADA нужны тракты питания, охлаждения и сети, согласованные с той доступностью, которую площадка реально хочет. Два NIC полезны, когда изолируют промышленную сеть от офисной, а не только когда их объединяют ради пропускной способности. RAID1 баз, горячий резерв двух машин и резервный кластер могут стоять в одной комнате и упасть вместе, если делят один коммутатор, один ИБП и один вентилятор шкафа.

• RAID1 на томе базы: отказ диска не должен ронять архив; учебное восстановление всё равно должно доказать, что резервная копия читается
• Два блока питания и ИБП, время работы которого измерено, а не взято с шильдика
• Два NIC с записанным назначением: одна сторона к промышленной сети, другая к офисной или к сети архива, а не два кабеля в один VLAN
• Физическое разнесение пары: две машины в одной стойке уже устойчивее одной; две машины на двух цепях ИБП и двух access-коммутаторах переживают отказ одного шкафа

Уровень, средство резервирования и что должна доказать приёмка

Формулировка «резервирование» в коммерческом предложении не проверяется. Таблица ниже написана так, чтобы третий человек без истории проекта мог провести испытание и зафиксировать да или нет. Третий столбец заполняйте своими цифрами площадки — время переключения, разрыв истории, кто вправе переключать — а не копируйте заводские значения поставщика.

На проектах мы применяем на уровне архитектуры резервные кластеры, горячее резервирование двух серверов, RAID1 для баз, работу 7×24 и обновление интерфейса за секунды. Это пункты приёмки, а не процент доступности на объекте. Хранение данных три года с переносом в архив — отдельное решение уровня данных; его пишут рядом с RAID и репликой, а не вместо них.

Изоляция сетей и права доступа — ровно настолько, насколько нужна доступность

Высокая доступность рассыпается, если офисная сеть может залить промышленную или если одна скомпрометированная учётная запись останавливает оба узла. Это не статья по OT-безопасности; ниже — то, что всплывает на испытаниях переключения и на аудитах предприятия.

На крупных проектах мы выносили промышленную и офисную сети на физически раздельные тракты с гигабитной оптической коммутацией уровня 3, изоляцию двумя сетевыми адаптерами на серверах, RAID1, разграничение полномочий и фильтрацию файлов повышенного риска. Права, роли и аудит настраиваются по требованиям безопасности площадки. Проектные решения и документы предоставляются в рамках проекта и используются при аудитах, приёмке и независимой оценке; выводы опираются на проектные доказательства.

• Изолировать промышленную сеть от офисной, чтобы шторм широковещания или вредоносное ПО с рабочего стола не утащили оба узла SCADA
• Привязать два NIC по функции: технологический трафик на одной стороне, офисный или архивный — на другой, без случайного моста
• Права записи, загрузку рецептов и инженерный доступ закрыть именованными ролями и вести журнал, кто что менял
• Фильтровать типы файлов повышенного риска на хостах SCADA; копия установщика с USB — частый путь, которым оба узла получают одно и то же нежелательное ПО

Если на площадке уже есть программа OT-безопасности, резервирование SCADA должно стоять внутри неё, а не рядом. Испытания из таблицы выше остаются в силе: хорошо изолированная пара, которая не переключается, ещё не является системой с высокой доступностью.