OPC UA, резервирование
-
Добрый день, планируем к установке https://ih-systems.com/ru/product/intrahouse-scada/
2 вопроса:
-
поддерживается ли OPC UA (Максим Вершинин вроде говорил, что есть плагин)
-
Что насчет резервирования? Будем ставить на основной и резервный сервер
-
-
- поддерживается ли OPC UA
Плагин OPC UA Client уже есть. Скоро опубликуем.
@nppesn:- Что насчет резервирования? Будем ставить на основной и резервный сервер
Есть разные варианты.
-
По резервированию, конечный результат хотелось бы такой:
при поломке одного из серверов, покупаем новый, ставим на него Intrahouse, вводим в пункте "репликация" ip работающего сервера - инициализация и заполнение базы данных старыми данными и добавление новых происходит автоматически.
Реализация примерно следующая: между БД серверов настроена репликация. И основной, и резервный сервера кидают данные c INSERT IGNORE, AUTO INCREMENT лучше, чтоб не было, иначе путаница. Запросов к БД будет в 2 раза больше, но не придется разбираться, кто основной, кто резервный.
Дополнительные вопросы к безопасности и авторизации:
-
SCADа может быть многопользовательской с разделением ролей администратора и пользователей? Можно ли увидеть в журнале, действия какого пользователя (оператора) привели к тому, что все пошло не так.
-
Хотелось бы иметь ограничения на возможность команд от оператора, например:
-
если пользователь (напр.192.168.1.42) в той же ЛВС, что и сервер (напр.192.168.1.230) - тогда команды от него принимаются, например;
-
если пользователь в другой сети (напр.192.168.0.42), то команды он подавать не может, только получает информацию.
Смысл в том, что объекты крупные и управлять ими должен только оператор, диспетчер, подключенный через VPN должен только получать информацию, без возможности подать команды, чтобы не нашлось каких-нибудь злоумышленников. При этом администрирование тоже должно осуществляться только из ЛВС.
-
-
По резервированию, конечный результат хотелось бы такой:
при поломке одного из серверов, покупаем новый, ставим на него Intrahouse, вводим в пункте "репликация" ip работающего сервера - инициализация и заполнение базы данных старыми данными и добавление новых происходит автоматически.
Реализация примерно следующая: между БД серверов настроена репликация. И основной, и резервный сервера кидают данные c INSERT IGNORE, AUTO INCREMENT лучше, чтоб не было, иначе путаница. Запросов к БД будет в 2 раза больше, но не придется разбираться, кто основной, кто резервный.
Механизм горячего резервирования с репликацией БД (MySQL)
Работают два сервера - основной и резервный, у каждого своя БД, между ними настроена репликация Master-Master по модели Active-Passive (в один момент времени активен только один мастер)
На основном сервере плагины активны, OPC клиенты работают с контроллерами, данные пишутся в БД.
На резервном сервере плагины в стопе, данные не поступают - в БД напрямую ничего не пишется, идет репликация с основного.
При остановке основного сервера резервный берет управление на себя - запускает плагины связи с железом, данные пишутся в БД и накапливаются в binlog для последующей репликации на второй сервер.
При подключении упавшего сервера автоматического переключения не происходит. Нужна процедура синхронизации, в процессе которой проверяется, что репликация с резервного произведена успешно. После этого можно запустить сервер как основной или резервный.
Дополнительные вопросы к безопасности и авторизации:
- SCADа может быть многопользовательской с разделением ролей администратора и пользователей? Можно ли увидеть в журнале, действия какого пользователя (оператора) привели к тому, что все пошло не так.
Да, SCADA позволяет:
-
закрыть доступ к PM (разрешено только пользователям с административными правами)
-
создать разные наборы экранов для разных пользователей
-
настроить политики и правила для различных групп пользователей на права доступа и управления
- Хотелось бы иметь ограничения на возможность команд от оператора, например:
-
если пользователь (напр.192.168.1.42) в той же ЛВС, что и сервер (напр.192.168.1.230) - тогда команды от него принимаются, например;
-
если пользователь в другой сети (напр.192.168.0.42), то команды он подавать не может, только получает информацию.
Смысл в том, что объекты крупные и управлять ими должен только оператор, диспетчер, подключенный через VPN должен только получать информацию, без возможности подать команды, чтобы не нашлось каких-нибудь злоумышленников. При этом администрирование тоже должно осуществляться только из ЛВС.
Для клиента, подключенного к системе, есть свойство remote, можно будет вытащить его и использовать в правилах.