OPC UA, резервирование

Программная платформа для систем автоматизации.
Диспетчеризация, Умный дом.
Ответить
nppesn
Сообщения: 2
Зарегистрирован: 05 сен 2019, 12:14

OPC UA, резервирование

Сообщение nppesn » 05 сен 2019, 12:21

Добрый день, планируем к установке https://ih-systems.com/ru/product/intrahouse-scada/

2 вопроса:
1) поддерживается ли OPC UA (Максим Вершинин вроде говорил, что есть плагин)
2) Что насчет резервирования? Будем ставить на основной и резервный сервер

intrahouse
Сообщения: 563
Зарегистрирован: 12 дек 2016, 20:22

Re: OPC UA, резервирование

Сообщение intrahouse » 05 сен 2019, 13:41

nppesn писал(а):
05 сен 2019, 12:21
1) поддерживается ли OPC UA
Плагин OPC UA Client уже есть. Скоро опубликуем.
nppesn писал(а):
05 сен 2019, 12:21
2) Что насчет резервирования? Будем ставить на основной и резервный сервер
Есть разные варианты.

nppesn
Сообщения: 2
Зарегистрирован: 05 сен 2019, 12:14

Re: OPC UA, резервирование

Сообщение nppesn » 06 сен 2019, 05:06

По резервированию, конечный результат хотелось бы такой:
при поломке одного из серверов, покупаем новый, ставим на него Intrahouse, вводим в пункте "репликация" ip работающего сервера - инициализация и заполнение базы данных старыми данными и добавление новых происходит автоматически.

Реализация примерно следующая: между БД серверов настроена репликация. И основной, и резервный сервера кидают данные c INSERT IGNORE, AUTO INCREMENT лучше, чтоб не было, иначе путаница. Запросов к БД будет в 2 раза больше, но не придется разбираться, кто основной, кто резервный.

Дополнительные вопросы к безопасности и авторизации:
3) SCADа может быть многопользовательской с разделением ролей администратора и пользователей? Можно ли увидеть в журнале, действия какого пользователя (оператора) привели к тому, что все пошло не так.
4) Хотелось бы иметь ограничения на возможность команд от оператора, например:
- если пользователь (напр.192.168.1.42) в той же ЛВС, что и сервер (напр.192.168.1.230) - тогда команды от него принимаются, например;
- если пользователь в другой сети (напр.192.168.0.42), то команды он подавать не может, только получает информацию.
Смысл в том, что объекты крупные и управлять ими должен только оператор, диспетчер, подключенный через VPN должен только получать информацию, без возможности подать команды, чтобы не нашлось каких-нибудь злоумышленников. При этом администрирование тоже должно осуществляться только из ЛВС.

intrapro
Сообщения: 458
Зарегистрирован: 13 дек 2016, 09:14

Re: OPC UA, резервирование

Сообщение intrapro » 06 сен 2019, 10:20

nppesn писал(а):
06 сен 2019, 05:06
По резервированию, конечный результат хотелось бы такой:
при поломке одного из серверов, покупаем новый, ставим на него Intrahouse, вводим в пункте "репликация" ip работающего сервера - инициализация и заполнение базы данных старыми данными и добавление новых происходит автоматически.

Реализация примерно следующая: между БД серверов настроена репликация. И основной, и резервный сервера кидают данные c INSERT IGNORE, AUTO INCREMENT лучше, чтоб не было, иначе путаница. Запросов к БД будет в 2 раза больше, но не придется разбираться, кто основной, кто резервный.
Механизм горячего резервирования с репликацией БД (MySQL)

Работают два сервера - основной и резервный, у каждого своя БД, между ними настроена репликация Master-Master по модели Active-Passive (в один момент времени активен только один мастер)

На основном сервере плагины активны, OPC клиенты работают с контроллерами, данные пишутся в БД.
На резервном сервере плагины в стопе, данные не поступают - в БД напрямую ничего не пишется, идет репликация с основного.

При остановке основного сервера резервный берет управление на себя - запускает плагины связи с железом, данные пишутся в БД и накапливаются в binlog для последующей репликации на второй сервер.

При подключении упавшего сервера автоматического переключения не происходит. Нужна процедура синхронизации, в процессе которой проверяется, что репликация с резервного произведена успешно. После этого можно запустить сервер как основной или резервный.
nppesn писал(а):
06 сен 2019, 05:06
Дополнительные вопросы к безопасности и авторизации:
3) SCADа может быть многопользовательской с разделением ролей администратора и пользователей? Можно ли увидеть в журнале, действия какого пользователя (оператора) привели к тому, что все пошло не так.
Да, SCADA позволяет:
- закрыть доступ к PM (разрешено только пользователям с административными правами)
- создать разные наборы экранов для разных пользователей
- настроить политики и правила для различных групп пользователей на права доступа и управления
nppesn писал(а):
06 сен 2019, 05:06
4) Хотелось бы иметь ограничения на возможность команд от оператора, например:
- если пользователь (напр.192.168.1.42) в той же ЛВС, что и сервер (напр.192.168.1.230) - тогда команды от него принимаются, например;
- если пользователь в другой сети (напр.192.168.0.42), то команды он подавать не может, только получает информацию.
Смысл в том, что объекты крупные и управлять ими должен только оператор, диспетчер, подключенный через VPN должен только получать информацию, без возможности подать команды, чтобы не нашлось каких-нибудь злоумышленников. При этом администрирование тоже должно осуществляться только из ЛВС.
Для клиента, подключенного к системе, есть свойство remote, можно будет вытащить его и использовать в правилах.

Ответить