В условиях импортозамещения и роста требований к отказоустойчивости ИТ- инфраструктуры российским предприятиям особенно важны проверенные инструменты для построения надежных АСУ ТП, SCADA и MES - систем. В связи с этим компания «СкадаСистемы» как дистрибьютор программных и аппаратных решений в области промышленной автоматизации уделяет особое внимание подбору и проверке продуктов, представленных на отечественном рынке, с точки зрения их функциональности, конкурентоспособности и готовности к реальной эксплуатации.
В настоящее время особенно актуальны вопросы выбора аппаратного обеспечения (в частности, промышленных серверов), гипервизоров, обеспечивающих заданный уровень доступности прикладных сервисов и программных платформ верхнего уровня. Для оценки возможностей отечественного технологического стека сотрудниками «СкадаСистемы» было принято решение провести тестирование полностью российского отказоустойчивого комплекса на стенде, максимально приближенном к реальному проекту, с объемом 200 000 технологических параметров и обеспечением непрерывности работы.
Для тестирования были выбраны следующие партнерские продукты:
-
ПО верхнего уровня: «Альфа платформа» (АО «Атомик Софт»);
-
Платформа отказоустойчивой виртуализации: «ГиперСфера» (ООО «СТР»);
-
Аппаратная база: серверы «Рубеж М» (АО «Крафтвэй корпорэйшн ПЛС»).
Описание компонентов решения
Аппаратная платформа: Kraftway «Рубеж М»
В качестве аппаратного обеспечения использованы серверы «Рубеж М» производства компании Kraftway (г. Обнинск), ориентированной на создание доверенных платформ, сетевых устройств и серверов с повышенным уровнем информационной безопасности. Ключевые характеристики задействованных в тесте серверов:
• Процессорная база: энергоэффективные процессоры серии Intel Atom C3000, обеспечивающие стабильную работу при низком тепловыделении.
• Резервирование питания: блоки питания по схеме 1+1 (300 Вт), критичные для обеспечения физической доступности узла.
• Информационная безопасность: специализированные слоты для модулей защиты системного ПО (МЗСПО) и поддержка отечественных операционных систем (Astra Linux, РЕД ОС).
Каждый сервер был оснащен 32 ГБ оперативной памяти, SSD‑накопителем объемом 256 ГБ, набором сетевых адаптеров RJ‑45 и двумя 10‑гигабитными адаптерами SFP+ для организации высокоскоростного обмена данными (для обеспечения режима Fault Tolerance в ПО «ГиперСфера»).
Платформа виртуализации «ГиперСфера»
На серверах «Рубеж М» был развернут кластер под управлением ПО «ГиперСфера» — отечественной платформы виртуализации на базе KVM. Отметим ряд ключевых тезисов про данный продукт.
Российская альтернатива зарубежным гипервизорам для задач высокой доступности
В условиях курса на импортозамещение и ограничений на использование зарубежного ПО, российским предприятиям нужна замена зарубежных гипервизоров для задач высокой доступности. Продукт «ГиперСфера» от компании «СТР» предназначен для решения этого класса задач: это полностью российская платформа отказоустойчивой виртуализации на базе KVM, обеспечивающая доступность до 99,99–99,999% и непрерывную работу приложений без остановки при отказе одного из серверов. По сути, там, где раньше типовым выбором был зарубежный гипервизор, сейчас в российских проектах может использоваться «ГиперСфера» без нарушения требований по импортозамещению и КИИ. Продукт включен в Единый реестр отечественного ПО Минцифры России, что подтверждает его соответствие требованиям для госзаказа и промышленного применения.
Чем «ГиперСфера» отличается от существующих российских платформ виртуализации
Большинство российских платформ виртуализации (zVirt, Basis Dynamix Enterprise, SpaceVM и др.) реализуют классическую схему высокой доступности High Available (HA): гипервизор + внешняя СХД, автоматический перезапуск ВМ на другом узле при сбое и, как следствие, короткий, но всё же простой и риск потери части транзакций. «ГиперСфера», помимо поддержки режима высокой доступности, ориентирована на отказоустойчивость уровня FT: состояние виртуальной машины синхронизируется на двух серверах по сети 10 Гбит/с и при отказе одного из них работа продолжается на втором сервере без перезапуска ВМ и потери данных, обеспечивая доступность до «пяти девяток» без обязательной внешней СХД.Фактически это специализированное решение именно для безостановочной работы критичныхИТ/ОТ-нагрузок, тогда как другие платформы виртуализации больше заточены под «универсальную» серверную виртуализацию и классические дата-центровые сценарии.
Где в АСУ ТП имеет смысл применять «ГиперСферу»
Применение «ГиперСферы» наиболее оправдано там, где простой серверной части АСУ ТП напрямую приводит к останову технологического процесса, нарушению требований промышленной безопасности или риску больших финансовых потерь. Это, в частности, серверы верхнего уровня АСУ ТП (SCADA системы, серверы управления технологическими линиями, архивы данных, серверы видеонаблюдения технологических объектов, узлы производственного диспетчерского управления). Для проектов, где требуются уровни доступности 99,99–99,999% и минимизация влияния человеческого фактора при переключении на резерв, «ГиперСфера» даёт простой для эксплуатации способ построить FT-кластер на российском ПО, не усложняя архитектуру АСУ ТП сверх необходимого. Можно выделить следующие ключевые области применения:
1. Промышленность
Отказ серверной части АСУ ТП может привести к остановке технологических линий, нарушению режимов работы оборудования, снижению производительности и росту риска аварий. В таких архитектурах требуется непрерывное исполнение критичных сервисов:
• системы управления технологическим оборудованием;
• системы диспетчеризации и верхнеуровневые SCADA-системы;
• серверы архивов технологических данных;
• аналитические подсистемы и решения предиктивного обслуживания.
2. Транспорт и городская инфраструктура
В сегменте транспорта и инфраструктуры сбой серверов управления может обернуться транспортным коллапсом или прямыми угрозами безопасности (остановка диспетчерских центров, систем светофорного регулирования, мониторинга тоннелей и т. п.).
3. Системы безопасности и видеонаблюдения
Решение особенно актуально для серверов систем контроля и управления доступом (СКУД), охранно-пожарной сигнализации и видеонаблюдения (VMS), где потеря сервера означает «слепоту» объекта и нарушение регламентов безопасности.
4. Нефтегазовый сектор и удалённые площадки
Для удалённых месторождений, насосных станций, ЛПУ и других объектов, где нет постоянного присутствия квалифицированного ИТ-персонала, критично, чтобы инфраструктура максимально автономно выдерживала одиночные отказы.
А если у системы АСУ ТП есть свой штатный функционал резервирования, зачем использовать «ГиперСферу»?
Действительно, многие современные системы АСУ ТП имеют штатные механизмы резервирования. Однако между «штатным резервированием» (Application-level Redundancy) и «отказоустойчивостью» (Fault Tolerance на уровне железа/гипервизора), которую дает «ГиперСфера», есть принципиальная разница в механике и целях.
Ниже основные причины, почему применение «ГиперСфера» будет оправдано даже при наличии встроенного резервирования в SCADA:
1. Отсутствие «скачка» данных
Штатное резервирование большинства SCADA работает по принципу Active/Standby:
● SCADA: когда основной сервер падает, резервный должен обнаружить потерю связи (Heartbeat), перехватить IP-адрес, запустить службы и подключиться к контроллерам. Это занимает от 5 до 30+ секунд. В этот момент на графиках — «пустота», алармы могут отработать с опозданием.
● ГиперСфера: работает на уровне синхронизации состояния виртуальных машин на двух серверах. Если в одном сервере происходит аппаратный сбой, виртуальная машина продолжит выполнение на втором сервере в ту же секунду. Это переключение практически незаметно как для самой SCADA-системы, работающей внутри виртуальной машины, так и для контроллеров и клиентов, с которыми она связывается - нет никакой процедуры переключения, а значит, нет и потери данных.
2. Защита всей инфраструктуры, а не только SCADA
Штатное резервирование защищает только конкретное ПО (например, сервер ввода/вывода). Но в системе обычно есть и другие критичные компоненты:
● СУБД (SQL Server, PostgreSQL), которая может не иметь своей лицензии на Cluster или AlwaysOn.
● Менеджеры лицензий
● Специфические драйверы связи или OPC-серверы, которые не имеют функционала резервирования
● Специализированные скрипты и сторонние утилиты.
ГиперСфера защищает всю виртуальную машину целиком со всем её содержимым, включая ОС. Не нужно настраивать резервирование отдельно для каждого компонента.
3. Упрощение инжиниринга и настройки
Настройка штатного резервирования в сложных системах требует времени и глубоких знаний:● Нужно настраивать дополнительные сетевые адаптеры для синхронизации связи.
● Следить за идентичностью конфигураций на обоих узлах в разработке и среде исполнения.
● Проверять логику переключения.
С «Гиперсфера» вы просто создаете одну виртуальную машину и устанавливаете туда ваше прикладное ПО так, будто это обычный одиночный сервер. Сложность настройки резервирования переносится с плеч инженера-программиста на уровень инфраструктуры.
4. Обслуживание «на лету» (Maintenance)
Если вам нужно заменить планку памяти или обновить прошивку на одном из серверов:
В случае со SCADA-резервированием вам нужно инициировать процесс перехода на резервный узел всех модулей, надеяться, что он пройдет гладко, и работать на резервном узле.
С ГиперСфера вы просто переводите один физический узел в режим обслуживания, выполняете требующиеся работы, а после переключаете узел обратно в штатный режим, и он автоматически синхронизируется с работающим узлом. Система при этом совершенно не замечает такого переключения.
5. Лицензионная выгода (иногда)
Некоторые вендоры требуют покупать две полные лицензии для работы в режиме Active/Standby. В случае с ГиперСферой прикладное ПО работает только в одном экземпляре, на одном из физических серверов — та же виртуальная машина на втором сервере является лишь постоянно обновляемой резервной копией, что позволяет использовать одну лицензию (если лицензируются одновременно запущенные экземпляры ПО).
*Лицензионная политика вендора прикладного ПО может иметь свои особенности, которые стоит заранее уточнить.
Когда ГиперСфера НЕ нужна:
Если ваш объект допускает потерю данных в течение 30-60 секунд, а бюджет ограничен — штатного функционала SCADA более чем достаточно. Но если мы говорим о непрерывных производствах (нефтехимия, энергетика, крупные ЦОД), где цена секундного сбоя выше стоимости лицензии ПО ГиперСфера, выбор очевиден. В ходе нашего тестирования сфокусируемся на режиме Fault Tolerance (FT). Данный вариант защиты от сбоев доступен на любых серверах, оснащенных 10‑гигабитными сетевыми адаптерами (для сети синхронизации данных) и удовлетворяющих требованиям по вычислительным ресурсам для одновременной работы прикладного ПО и самой «ГиперСферы».
В ходе тестов проверялась способность системы обеспечивать безостановочную работу виртуальных машин с запущенным проектом автоматизации. Основной механизм заключается в синхронизации состояния виртуальной машины на двух узлах кластера: при аппаратном сбое одного из серверов «Рубеж М» выполнение виртуальной машины автоматически продолжится на резервном узле без прерывания сессий и потери оперативных данных.
Программная платформа для систем АСУ ТП, SCADA и диспетчеризации:
«Альфа платформа»
Тестовый проект верхнего уровня был реализован на базе ПО «Альфа платформа» от компании «Атомик Софт». «Альфа платформа» — инструментальная программная платформа для разработки систем АСУ ТП и многоуровневой диспетчеризации, обеспечивающая сбор, обработку, визуализацию и хранение промышленных данных.
Технические особенности тестирования
• Для тестирования использовались серверы Kraftway серии «Рубеж М», которые производитель в общем случае позиционирует как сетевые устройства. Несмотря на относительно скромные аппаратные характеристики, применение данных серверов было согласовано с производителями ПО, участвующими в тесте, и признано допустимым в рамках заявленных требований.
• ПО «ГиперСфера» было развернуто на серверах в соответствии со штатной документацией и функционировало на демонстрационных лицензиях.
• Компоненты ПО «Альфа платформа» были установлены внутри виртуальной машины на базе ОС Windows Server 2016; тестовый проект на 200 000 сигналов был предоставлен компанией «Атомик Софт».
Подготовка тестового стенда
Серверы «Рубеж М» были распакованы, подключены к электропитанию и объединены через сетевой коммутатор в единую сеть (рисунок 1).
Рисунок 1 – Тестовый стенд с серверами Рубеж М
Строго в соответствии с инструкцией производителя был выполнен процесс установки ПО «ГиперСфера». Ввиду большого количества сетевых адаптеров на серверах Рубеж для корректного выбора управляющей и служебной (для синхронизации данных) сетей потребовалась консультация специалиста компании «СТР»; после ее получения дальнейшее развертывание прошло без каких-либо затруднений.
На следующих скриншотах показан веб‑интерфейс ПО «ГиперСфера» с отображением серверов, объединенных в отказоустойчивый кластер, и процессом импорта подготовленной виртуальной машины.
Рисунок 2 — Физические машины, объединенные в отказоустойчивый кластер
Далее через веб‑интерфейс «ГиперСферы» были загружены виртуальные машины с установленным ПО «Альфа платформа» и тестовым проектом. При импорте машин был выбран максимальный сценарий защиты — Fault Tolerance.
Рисунок 3 — Процесс импорта виртуальных машины в ПО Гиперсфера
Виртуальные машины могут создаваться непосредственно в гипервизоре из файлов образов, либо импортироваться через OVF‑файлы. Система поддерживает импорт гостевых ОС семейств GNU/Linux, Microsoft Windows и FreeBSD.
После импорта виртуальные машины были запущены и проверена их базовая работоспособность, в том числе обмен данными между узлами SlaveServer и MasterServer.
Рисунок 4 — Запущенные виртуальные машины с проектом на Альфа платформе
Рисунок 5 — Тестовый проект на Альфа платформе в работе внутри виртуальной машины
Кратко о тестовом проекте
Используемые версии компонентов ПО «Альфа платформа»:
• Alpha.DevStudio‑3.28.8+b10.r130508
• Alpha.Server‑6.4.23+b1.r130439• Alpha.Domain‑1.5.1+b2.r129229
В проекте представлены два узла: SlaveServer и MasterServer. Оба узла обмениваются 200 000 сигналами типа int4, генерируемыми по таймеру с периодом 1 секунда. MasterServer опрашивает SlaveServer по протоколу Modbus TCP и получает данные. В свою очередь, SlaveServer включает в себя модуль HubModule и по внутреннему TCP‑протоколу AlphaLink запрашивает те же данные у MasterServer.
Методика тестирования и сценарии испытаний
Напомним, тестовый стенд состоит из двух серверов «Рубеж М», объединенных в отказоустойчивый кластер на базе решения «ГиперСфера». На виртуальных машинах были развернуты экземпляры Alpha.Server, обрабатывающие проект объемом 200 000 тегов с частотой обновления 1 секунда.
Проверялись следующие сценарии:
1. Тестирование загрузки системы. Мониторинг загрузки центрального процессора (CPU) и оперативной памяти (RAM) серверов при работе системы в штатном режиме.
2. Имитация аппаратного отказа. Физическое отключение питания одного из серверов «Рубеж М» (имитация выхода из строя блока питания или узла в целом).
Результаты испытаний
Тестирование загрузки системы
Проект на «Альфа платформе» на 200 000 сигналов непрерывно функционировал в течение недели, и за этот период система продемонстрировала высокую стабильность.
Потребление ресурсов внутри виртуальных машин оставалось на умеренном уровне: суммарная загрузка процессоров не превышала 55% при штатной работе, а потребление оперативной памяти службой Alpha.Server находилось в диапазоне 1,3–1,7 ГБ.
Информация о средней загрузке серверов представлена на скриншотах ниже:
Рисунок 6 — Данные о загрузке CPU на ВМ SlaveServer
Рисунок 7 — Данные о загрузке оперативной памяти на ВМ SlaveServer
Рисунок 8 — Данные о загрузке CPU на ВМ MasterServer
Рисунок 9 — Данные о загрузке оперативной памяти на ВМ MasterServer
Собранные данные по загрузке были переданы специалистам компании «Атомик Софт». Получено подтверждение, что зафиксированная нагрузка в целом соответствует штатным показателям для проекта, включающего получение, обработку и предоставление данных по протоколам ModbusTCP и AlphaLink при общем объеме 200 000 сигналов.
Имитация аппаратного отказа
На втором этапе тестирования была смоделирована полная потеря питания на ведущем узле кластера. Благодаря выбранному режиму Fault Tolerance процесс переключения на резервный узел прошел незаметно для клиентского приложения (в ходе испытаний использовался OPC UA Explorer, подключенный к Alpha.Server по OPC UA протоколу).
Аналогичное поведение будет соблюдаться и для операторских интерфейсов, реализованных на базе Alpha.HMI.
Скриншоты ниже демонстрируют момент отказа физического сервера, состояние виртуальных машин после события (обе в состоянии «запущена») и поведение клиентского приложения с графиком в момент отключения питания.
Рисунок 10 — Отказ физического сервера после отключения питания
Рисунок 11 — Статусы виртуальных машин после сбоя (обе в состоянии «запущена»)
Рисунок 12 — Клиентское приложение с графиком на момент отключения питания.
High Availability и Fault Tolerance: краткое сравнение
Для справки ниже приведено краткое сравнение подходов High Availability (HA) и Fault Tolerance (FT):
High Availability (высокая доступность) — наиболее распространенный подход, при котором в случае отказа одного сервера кластер обнаруживает событие и запускает сервисы на резервном узле. При этом возникает короткий перерыв в работе и потенциальная потеря части транзакций за время перезапуска.Fault Tolerance (отказоустойчивость) — архитектура, при которой отказ любого отдельного компонента (процессора, памяти, диска) не приводит к остановке бизнес-приложений. Такой подход требует дополнительных ресурсов, поскольку ресурсы для приложений выделяются одновременно на обоих серверах кластера и имеются накладные расходы на синхронизацию.
Обеспечение надежности системы всегда представляет собой компромисс между доступным бюджетом и приемлемым уровнем риска отказа. Конкретный метод выбирается исходя из допустимого времени простоя и масштаба возможных финансовых потерь.
Следует отметить, что на момент проведения испытаний ПО «ГиперСфера» еще не было официально протестировано компанией Атомик Софт на согласованную работу с ПО «Альфа платформа». За дополнительной информацией по совместному использованию продуктов в конкретных проектах рекомендуется обращаться за консультацией в компанию «СкадаСистемы».
Заключение
По итогам тестирования можно сделать следующие выводы:
1. 2. 3. ПО «Альфа платформа» продемонстрировало высокую производительность и масштабируемость. В ходе испытаний система стабильно обрабатывала поток в 200 000 сигналов при умеренном использовании вычислительных ресурсов серверов. Это подтверждает готовность платформы к применению в сложных распределенных проектах автоматизации и диспетчеризации на базе полностью отечественного программно‑аппаратного стека.
ПО «ГиперСфера» подтвердило гибкость и адаптивность к различным аппаратным платформам. Тестирование показало, что система успешно работает даже на компактных серверах (сетевых устройствах), превращая их в полноценные узлы отказоустойчивого кластера. На более производительном серверном оборудовании потенциал платформы по минимизации простоев раскрывается еще более полно.
Аппаратная платформа Kraftway «Рубеж М» показала себя как надежное и доверенное решение для реализации критически важных узлов ИТ/ОТ‑инфраструктуры.
Благодаря использованию отечественных компонентов серверы Kraftway обеспечивают доверенную среду выполнения и минимизируют риски несанкционированного доступа на уровне BIOS и загрузчика ОС.
Успешные испытания подтвердили готовность российского технологического стека к внедрению на промышленных объектах. Связка «Kraftway — СТР — Атомик Софт»обеспечивает не только качественное импортозамещение, но и уровни надежности, соответствующие мировому стандарту «пять девяток» (99,999%). Программно-аппаратный комплекс способен поддерживать непрерывную работу критически важных производственных систем в режиме Fault Tolerance, при этом не требуя использования зарубежных платформ виртуализации, внешних систем хранения данных и сложной кластерной архитектуры.
Команда «СкадаСистемы» уверенно рекомендует данный комплекс для применения в проектах промышленной автоматизации и диспетчеризации. При этом подбор оборудования и программного обеспечения должен выполняться квалифицированными специалистами с учетом требований конкретного объекта.