- В этой теме 32 ответа, 4 участника, последнее обновление 1 год, 3 месяца назад сделано
.
-
Сообщения
-
Предлагаю к обсуждению варианты реализации резервирования серверов на Rapid SCADA. Ссылка. Если есть свой практический опытом, поделитесь.
Вариант 2 за счет сигнала Пульс может постоянно переключать опрос то одним сервером то другим ? То есть выполнить синхронизацию опроса без настроек синхронизации времени на ПК, учитывая возможную установку в разных временных зонах.
Я разносил опрос во времени на 5-й версии на RS485 устройствах, синхронизировав время на двух ПК, работало без проблем.
Остается только проблема физических RS485 на сервере, тут либо два сервера рядом и в каждом интерфейс, либо никак…
Учитывая, что контроллеры как правило slave даже в TCP и часто не имеют возможности 2-х подключений то первый вариант всегда будет сложнее второго, тем более 2-й при условии синхронизации рабочий. Могут помешать только таймауты и перезапуски серверов, но через время нормализуется…
Я за второй вариант. Единственное не нравится, что синхронизация вручную. Должна быть автоматическая. А если в каждом из коммуникатора сделать драйвер, который будет постоянно забирать данные из активного сервера, когда сам находится в резерве?
А чем плох вариант установки SCADA на виртуальную машину в отказоустойчивом кластере с автоматической миграцией виртуальной машины на другой узел кластера при необходимости (сбой узла, техобслуживание, балансировка нагрузки…)? Правда тут сразу возникает проблема как привязать RS-485 к узлам (точнее ВМ) при миграции. Выход — преобразование физический RS-485 — TCP (например у нас так работал проброс USB ключей через USBAnyWhere от Digi (у них же есть и Serial Connectivity
Digi). Речь идет о кластерах MS Hyper-V, ESXi VmWare, в Linux их тоже предостаточно. При перемещении машины ничего не меняется (даже МАС) и перерыва в получении данных не наблюдалось.
У меня Rapid Scada работала именно на таких кластерах (Hyper-V в основном) проблем не замечалось.
Опять же можно всегда ВМ перезапустить если вдруг что то зависнет, время перезагрузки в разы меньше перезагрузки физической машины.Это немножко не то. Нужен так называемый горячий резерв. Виртуализация при функциях управления у нас, например, запрещена. Кроме того всё это запрещённые иностранные технологии. Возможно есть и наши аналоги, не знаю не пробовал. На wmware у нас сделана одна система с кластаризацией, как Вы описали, но это считается дешовой и урезанной версией резервирования. На самом деле так оно и есть.
Хотя сам принцип использования виртуальных машин мне тоже очень нравится. С ними даже как-то спокойнее, чем с реальным железом 🙂В Linux вроде есть все свое ( в смысле отечественное :)) Странный у вас подход к виртуализации конечно, не очень понимаю предпосылки к этому. У нас интернет (в широком смысле этого слова, любые «иные» сети, только под строгим контролем и урезанием протоколов. Интернет с большой буквы запрещен был напрочь 🙂 Как и машины с двумя картами 🙂
А так в контуре производства вообще у нас дублированная кольцевая сеть со 100% резервированием оборудования и ПО…по идее никогда отказать не могла…как бы не так! Там есть такой маршрутизирующий коммутатор (по существу ядро сети) — так вот он отвалился, бекап прошивки оказался некорректным, новая не залилась…в общем ребята на блочном вели режим турбины и котла неделю при замершей картинке…хорошо еще оставили при реконструкции немного «традиционных» приборов и ключей управления…Странный у вас подход к виртуализации конечно, не очень понимаю предпосылки к этому.
Видимо в этом есть какой-то скрытый смысл :). Но это факт, с которым приходится работать. Интернет и электронная почта — это абсолютно запрещённые вещи.Уточнил формулировки и дополнил файл. Выложил по той же ссылке.
Вариант 2 за счет сигнала Пульс может постоянно переключать опрос то одним сервером то другим
Чтобы переключить опрос, пульс должен отсутствовать в течение заданного времени. Иначе опрос будет периодически переключаться и нарушать работу.
Я разносил опрос во времени на 5-й версии на RS485 устройствах, синхронизировав время на двух ПК
Хорошая мысль, добавил в файл.
Единственное не нравится, что синхронизация вручную. Должна быть автоматическая.
Уточнил, что вручную только если один из серверов был выключен в течение длительного времени, и очередь Коммуникатора переполнилась. То есть достаточно редко.
Есть Быстрый шлюз, которому можно отправить команду на синхронизацию после длительной остановки. Но написать такой идеальный алгоритм, который отправит команду автоматически для всех случаев, не знаю как.А чем плох вариант установки SCADA на виртуальную машину в отказоустойчивом кластере с автоматической миграцией виртуальной машины на другой узел кластера при необходимости
Тоже интересно. Поддерживается ли автоматический запуск альтернативной виртуалки при незапланированном отключении основного хоста?
Российские системы виртуализации существуют, но пока вблизи не попадались. Думаю, ещё узнаем про них, когда грянет срок перевода критической инфраструктуры на российские технологии. Пытался понять, какие системы будут относиться к критической инфраструктуре, но классификация сложная.
В любом случае, данный способ предполагает развитую ИТ-службу, которая будет настраивать и поддерживать виртуализацию, что доступно не всегда.Интернет и электронная почта — это абсолютно запрещённые вещи.
Это правильно. Социальная инженерия в руках опытных людей творит чудеса.
Михаил, вы как раз не поняли смысл.
Сервер 1 — опросил, выставил флаг об успешном опросе.
Сервер 2 — получил флаг опроса Сервером 1, теперь опрашивает он и со своей стороны выставляет флаг об опросе.
И так по кругу. А вот если один или второй сервер за какой-то промежуток времени не опрашивает и не меняет флаг опроса, то бразды правления только у одного сервера, пока второй не очухается.То есть постоянный опрос 485-ых приборов по кругу двумя Серверами.
При синхронизации времени двух ПК возникают ситуации с ошибочными данными при
1. Перезапуске сервера, так как опрос происходит сразу, не дожидаясь времени опроса по периоду — Может научить Коммуникатор ждать времени опроса а не запрашивать сразу?
Ну и если происходят ошибки чтения и время опроса увеличивается, а тут второй Сервер по новому периоду опроса начинает спрашивать.
Опять же, можно научить Коммуникатор прерывать опрос, например зная, что опрос происходит в течении 4-х секунд, а период следующего сервера начнется с 10-й секунды, то дать на все про все Коммуникатору 8 секунд, если за то время не поступили все данные — прервать опрос и ждать следующего периода.Поддерживается ли автоматический запуск альтернативной виртуалки при незапланированном отключении основного хоста?
Да, разумеется. там несколько другой механизм. Там идет непрерывная синхронизация памяти активной и пассивной машины а при отказе происходит мнгновенное переключение. Если указан предпочтительный хост то машина при восстановлении его работоспособности автоматически на него вернется. Ну и понятно, что нужна разделяемая СХД.
Там идет непрерывная синхронизация памяти активной и пассивной машины а при отказе происходит мнгновенное переключение.
Интересно.
То есть постоянный опрос 485-ых приборов по кругу двумя Серверами.
Данный подход требует синхронизацию работы каждой линии связи индивидуально и обмена данными между Коммуникаторами на основном и резервном сервере. Это довольно сложно реализовать. Поэтому переключение опроса для Коммуникатора в целом — приоритетный вариант.
Прерывать слишком долгий сеанс опроса, наверное, реализуемо.
@Mikhail ну а если сделать настройку линии связи Коммуникатора (можно только через конфиг файл) ожидать своего времени для опроса при старте линии?
Например у нас опрос раз в минуту, если я в 20 сек запущу линию, происходит опрос, потом в начале следующей минуты произойдет плановый опрос. Вот убрать какой-то настройкой опрос до планового после старта?
Это уменьшит колизии на линии
- Вы должны авторизироваться для ответа в этой теме.