1. Home
  2. intraHouse V4 Cherry
  3. OPC UA, резервирование
Открыто бета-тестирование iH V5

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

  • N

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

    2 вопроса:

    1. поддерживается ли OPC UA (Максим Вершинин вроде говорил, что есть плагин)

    2. Что насчет резервирования? Будем ставить на основной и резервный сервер

    0
  • I

    @nppesn:

    1. поддерживается ли OPC UA

    Плагин OPC UA Client уже есть. Скоро опубликуем.
    @nppesn:

    1. Что насчет резервирования? Будем ставить на основной и резервный сервер

    Есть разные варианты.

    0
  • N

    По резервированию, конечный результат хотелось бы такой:

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

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

    Дополнительные вопросы к безопасности и авторизации:

    1. SCADа может быть многопользовательской с разделением ролей администратора и пользователей? Можно ли увидеть в журнале, действия какого пользователя (оператора) привели к тому, что все пошло не так.

    2. Хотелось бы иметь ограничения на возможность команд от оператора, например:

    • если пользователь (напр.192.168.1.42) в той же ЛВС, что и сервер (напр.192.168.1.230) - тогда команды от него принимаются, например;

    • если пользователь в другой сети (напр.192.168.0.42), то команды он подавать не может, только получает информацию.

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

    0
  • I

    @nppesn:

    По резервированию, конечный результат хотелось бы такой:

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

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

    Механизм горячего резервирования с репликацией БД (MySQL)

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

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

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

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

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

    @nppesn:

    Дополнительные вопросы к безопасности и авторизации:

    1. SCADа может быть многопользовательской с разделением ролей администратора и пользователей? Можно ли увидеть в журнале, действия какого пользователя (оператора) привели к тому, что все пошло не так.

    Да, SCADA позволяет:

    • закрыть доступ к PM (разрешено только пользователям с административными правами)

    • создать разные наборы экранов для разных пользователей

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

    @nppesn:

    1. Хотелось бы иметь ограничения на возможность команд от оператора, например:

    • если пользователь (напр.192.168.1.42) в той же ЛВС, что и сервер (напр.192.168.1.230) - тогда команды от него принимаются, например;

    • если пользователь в другой сети (напр.192.168.0.42), то команды он подавать не может, только получает информацию.

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

    Для клиента, подключенного к системе, есть свойство remote, можно будет вытащить его и использовать в правилах.

    0
Log in to reply