Поделиться
Гео-кластер: новая архитектура для трубопроводов
Построение региональных автоматизированных систем управления (РАСУ) магистральными трубопроводами ведется не один год. За это время сильно изменились ИТ, расширился круг выполняемых РАСУ задач. На первое место выходит не просто управление трубопроводом, но оптимизация управления. Учесть растущую сложность информационных систем и обеспечить при этом высокую надежность решения поможет новая архитектура, предусматривающая виртуализацию задачи с применением гео-кластера.Взаимодействие клиентов с группой Front-end построено таким образом, что клиент всегда обслуживается процессом, работающим на "ближайшем" узле. Если по каким либо причинам ресурсы "ближайшего" узла не доступны, то на обслуживание клиента автоматически переключается следующий "ближайший" сервер. Front-end-процессы выполняются на каждом узле независимо и взаимодействуют с Back-end-процессами, работающими в пространстве кластера. Для осуществления задач кластера на всех узлах запущены службы синхронизации, репликации данных и балансировки нагрузки. В пространстве Back-end работают все функции чтения, записи, поиска и обработки информации баз данных.
Схема процессов гео-кластера
Изменения, произошедшие на любом из объектов ЛПУ или ГТП, одновременно отражаются на всех остальных узлах. Поскольку кластер обеспечивает избыточность данных и доступ к ним на каждом узле для всех клиентов, то плановый вывод узла из работы не влечет за собой потерю информации и функциональности системы, а непредвиденный выход из строя грозит только потерей информации, поступившей за минимальный промежуток времени. В данном примере кластера из трех элементов, потеря одного узла не лишает систему надежности т.к. избыточность сохраняется. В случае построения кластера на большем количестве узлов возможен отказ большего числа элементов без нарушения работоспособности и надежности. При такой реализации мы добиваемся совершено новых свойств, которые отсутствуют в иерархической структуре.
Новые свойства РАСУ ТП ГТП
Отказоустойчивость на уровне газотранспортного предприятия: Выход из строя любого из узлов не приводит к потере ее целостности. При остановке серверов SCADA на ЛПУ или ГТП диспетчер всегда имеет доступ к системе через остальные узлы. В случае необходимости любая диспетчерская ЛПУ может взять на себя функции другой диспетчерской, в которой возникли проблемы. Даже роль ЦДП можно реализовать в диспетчерской ЛПУ.
Катастрофоустойчивость: За счет географической удаленности узлов (более 100 км), система устойчива к авариям и другим внешним воздействиям. Распределенность объектов более не усложняет задачу, а является дополнительным фактором повышения надежности.
Устойчивость к внутренним сбоям: Появление еще одного уровня надежности делает внутренние сбои отдельного узла менее критичными. Это позволяет в разумных пределах уменьшать требования надежности узлов и выбирать более экономичные серверные решения.
Виртуализация: Логически система упрощается и может быть представлена работой пользователей с одним виртуальным SCADA-сервером. Физическая реализация кластера скрыта от пользователей и касается только системных администраторов. Настройка и администрирование комплекса централизована, а узлы кластера размещаются, преимущественно, на тех объектах, где легко обеспечить их обслуживание технически грамотным персоналом.Гибкость наращивания: Т.к. все узлы идентичны, то автоматизация новой компрессорной станции напрямую не связана с установкой на ней серверов SCADA. Для того, чтобы новый объект был доступен в ДП ЛПУ, достаточно сконфигурировать его в базе данных, обеспечить поступление информации от систем сбора и организовать рабочее место диспетчера. При этом объект будет доступен в ЦДП или соседних ДП ЛПУ автоматически, без дополнительных работ по интеграции. Вообще, не обязательно соблюдать соответствие количества серверных узлов SCADA и ЛПУ. На некоторых станциях достаточно установить только терминалы диспетчеров, АРМ специалистов и периферийное оборудование.
Оптимальное распределение ресурсов: Ситуация "недогруженности" SCADA-серверов малых ЛПУ и "перегруженности" крупных ЛПУ или ГТП исключена, т.к. теперь нагрузка распределяется на весь комплекс. Если весь комплекс в результате увеличения объемов передаваемых данных или подключения новых объектов не справляется с нагрузкой, то необходима установка дополнительных узлов кластера.
Оптимизация обменов между узлами: Так как данные всех ЛПУ и ГТП хранятся в единой базе, пропадает необходимость прямого обмена информацией между узлами. Обмены происходят косвенно через репликацию единой базы. Эти алгоритмы не требуют использования доступа к структуре базы, пересылают бинарную информацию в сжатом и зашифрованном виде, обеспечивая "зеркало" на системном уровне. Они реализованы производителем платформы, встроены в операционную систему, быстрее работают и лучше оптимизированы, чем алгоритмы синхронизации данных на уровне приложений. Тем самым решается одна из ключевых проблем системы с иерархической структурой – длительная синхронизация информации в удаленных базах данных в случае потери обменов между ГТП и ДП ЛПУ.
Дифференцированный доступ к данным: Разграничение зоны ответственности диспетчеров и степени детализации наблюдаемых ими объектов централизовано регулируется доступом пользователей. Эти настройки достаточно гибкие, и их можно выполнить как на этапе конфигурации системы, так и в процессе ее работы.
Делегирование полномочий: В иерархической структуре трудно корректно осуществить процедуру делегирования полномочий управления от ЦДП к ДП ЛПУ и наоборот, т. к. при передаче информации между узлами возможна ситуация, когда права управления либо никому не принадлежат, либо реализуются одновременно в обоих пунктах. За счет единой базы данных атомарность таких операций всегда сохраняется. В новой системе возможна гибкая передача прав наблюдения за объектами и управления.
Короткая ссылка
