Автор Тема: Удаленное подключение к Центру Управления  (Прочитано 41089 раз)

0 Пользователей и 1 Гость просматривают эту тему.

kosyak_kpol

  • Jr. Member
  • **
  • Сообщений: 52
    • "Лаборатория электроники"
    • Email
Re: Удаленное подключение к Центру Управления
« Ответ #30 : Сентября 23, 2019, 11:52:58 »
1. Спасибо за информацию.

2. Если я правильно понял, то проверка канала пинг-ом является "глобальной", и предназначена выдавать предупреждение даже в случае, когда в течение интервала пинга (30 секунд) ЦУ не имел событий для отправки удалённому ДО?

Здесь напрашивается прямое решение минимизации ложной тревоги "Нет связи с ЦУ", а именно:

- уменьшить интервал посылки пинга "Дежурным Оператором", например, в два раза (опрашивать раз не в 30 секунд, а в 15);
- реагировать сообщением "Нет связи с ЦУ" не по первому "не-ответу" на пинг, а по второму (т.е. в случае двух подряд неудачных пингов).

При этом, мы сохраним максимальное время реакции системы на аварию канала (не более 30 секунд). Но избавимся от ложных тревог, обусловленных случайными потерями ответов на пинг (вызванными, например, кратковременными флуктуациями канала или "тормознутостью" сетевого процесса на "дальней" машине с ЦУ). Так будет меньше "ложняков".

Верно?

3. Если я правильно трактую взаимосвязи между ДО и ЦУ (см. скриншот), то ДО получает от ЦУ только "флаг" (извещение) о наличии нового события (сокет с рабочих портов 5050 и 5051). В данном контексте не важно, - "запрашивает" ли инициативно ДО Центр управления или наоборот, - ЦО инициативно "информирует" ДО.
А вот "вычитывает" событие, похоже, сам ДО - непосредственно из Базы данных(?).

Или это не соответствует действительности? Иначе, зачем нужны ещё два сокета, открытых непосредственно между приложением ДО и процессом MSSQL (рабочие порты: 56837 - 49187 и 56839 - 49187)?

То есть, событие "Потеря связи с Базой данных" генерируется по результатам действия совершенно другого механизма, нежели пингование IP-адреса машины с ЦУ(?)

Если это так, то в моём случае нужно точно выяснить (у девушек-операторов удалённого ДО), какое именно событие "всплывает" при появлении проблемы:

"Нет связи с ЦУ" или "Потеря связи с БД"

и на основании этого уже двигаться дальше...

Спасибо, ещё раз за помощь.



« Последнее редактирование: Сентября 23, 2019, 16:15:24 от kosyak_kpol »
г. Севастополь, ООО "Лаборатория электроники", http://elab.com.ru, инж. сервисного отдела Константин Полозов.

kosyak_kpol

  • Jr. Member
  • **
  • Сообщений: 52
    • "Лаборатория электроники"
    • Email
Re: Удаленное подключение к Центру Управления
« Ответ #31 : Сентября 09, 2021, 12:45:14 »
Здравствуйте, уважаемая техподдержка.

Пользуясь последней возможностью «вскочить в вагон уходящего поезда» технической поддержки «Феникс-4» задам вопрос. История такая:

при подключении удалённого рабочего места с ПО «Дежурный оператор» (далее – дальний «ДО») к ПЦН (v49.200) посредством VPN возникает проблема, заключающаяся в том, что лента событий в окне «ДО» не обновляется автоматически. То есть, событие на ПЦН приходит и нормально отображается в локальном «ДО». А в дальнем «ДО» это событие появляется в «ленте» только если нажать кнопку «СБРОС», например. Или переключиться между окнами. Все остальные функции работают быстро и чётко: чтение журнала событий; открытие карточки объекта, и т.п.

Приведу пример для понимания проблемы. На дальнем «ДО» запрашиваем «Отчёт, снятие запрета». На локальном «ДО» при этом мгновенно отображается «Запрос состояния прибора» и его результат. А на дальнем «ДО» – «тишина и мёртвые с косами стоят»… - события появляются только после нажатия кнопки «Сброс».

Создаётся впечатление, как будто IP-адрес клиента с дальним «ДО» исчез из клиентов на ПЦН или зачислен в список «мёртвых». Но адрес есть, события для рассылки назначены и все адреса пингуются с обеих сторон. Причём, «ломается» рабочая схема «на ровном месте»: дальний «ДО» может проработать долго и счастливо (недели), а после очередного переподключения к ЦУ «впасть в кому». Перезапуск ЦУ проблему не решает. Рестарт Виндовс – то же. Ситуация разрешается сама-собой, через длительное время (дни). По этой причине пользоваться этой схемой нельзя. Ошибка эта давняя, но сформулировать её спровоцировало окончание срока поддержки…

Собственно вопросы:
- почему дальний «ДО» может таким образом ломаться?
- каким образом ЦУ производит оптимизацию клиентов, внедрённую ещё в версии 1.43.45.х?
- что посоветуете?

P.S. Ошибка воспроизведена на двух абсолютно разных ПЦН, на разных ПК с дальними «ДО», через разные каналы связи. Перебраны несколько типов VPN. В локальной сети – всё чётко. Проблема наблюдается только через VPN. Все "нужные" соединения между сервером и клиентом устанавливаются, и по ним бегают пакеты...   :'(
г. Севастополь, ООО "Лаборатория электроники", http://elab.com.ru, инж. сервисного отдела Константин Полозов.

Support

  • Global Moderator
  • Hero Member
  • *****
  • Сообщений: 722
    • Support
Re: Удаленное подключение к Центру Управления
« Ответ #32 : Сентября 14, 2021, 10:15:04 »

- что посоветуете?


Попробуйте вместо IP адресов использовать имена компьютеров.

И еще. Сравните ping в канале, когда у вас работает корректно и когда пропадает.

kosyak_kpol

  • Jr. Member
  • **
  • Сообщений: 52
    • "Лаборатория электроники"
    • Email
Re: Удаленное подключение к Центру Управления
« Ответ #33 : Сентября 14, 2021, 21:20:58 »

- что посоветуете?

Попробуйте вместо IP адресов использовать имена компьютеров.
И еще. Сравните ping в канале, когда у вас работает корректно и когда пропадает.

1. Протокол NetBIOS работает в едином широковещательном домене L2. На текущий момент имею PPTP-VPN, который не обеспечивает связности на L2. Кроме того, использование имён NetBIOS предполагает пребывание хостов в адресном пространстве одной и той же подсети, что, с моей точки зрения, не удобно и не по "фэн-шую".

В вашей инструкции разрешено использовать IP-адреса при настройке доступа с удалённых АРМ. Или есть принципиальные различия в функционировании протоколов обмена между сервером и клиентом при использовании IP, либо имён NetBIOS? Может какой-либо процесс протокола обмена требует широковещательный домен? Не всё в протоколе обмена передаётся юникастом? Тогда скажите об этом в инструкции. Я заметил, что простое перемещение клиента с "ДО" (работающего через IP) в LAN (L2-домен) гарантированно восстанавливает работоспособность схемы. Как тогда это объяснить? Как объяснить, что схема, работающая неделями ломается "вдруг". Ни с того, ни с сего. Просто после переподключения к ЦУ престают приходить новые события. А весь остальной функционал работает. Тут без понимания протокола обмена "поломку" не найти.

А что говорят разработчики по этому вопросу?

2. Пинг не меняется и составляет около 2-х мс.

P.S. Не поленился, - поднял между точками EoIP-тоннель, обеспечивающий L2-связность. Стал ходить пинг до сервера (до ПК с ЦУ) по имени NetBIOS. Пока не менял IP-адреса на Net-имена  (в ЦУ и клиенте с ДО), ибо "мопед не мой" - доступа к серверу нет. Завтра попробую сделать договориться. Проверил текущее "поведение" клиента ДО. Ситуация никак не изменилась.
« Последнее редактирование: Сентября 14, 2021, 21:46:52 от kosyak_kpol »
г. Севастополь, ООО "Лаборатория электроники", http://elab.com.ru, инж. сервисного отдела Константин Полозов.

kosyak_kpol

  • Jr. Member
  • **
  • Сообщений: 52
    • "Лаборатория электроники"
    • Email
Re: Удаленное подключение к Центру Управления
« Ответ #34 : Сентября 14, 2021, 23:18:29 »
Докладываю:

- после поднятия EoIP-тоннеля (поверх PPTP-VPN) "подрихтовал" конфигурации роутеров (убрал лишние сущности, лишние маршруты и, главное, поднял значение MTU в тоннеле EoIP) и ... удалённый клиент с "ДО" заработал!

Хоть и рано радоваться, но радуюсь. За последние 2 недели удалённый клиент с "ДО" ни разу нормально запустить не удавалось! После поднятия L2-тоннеля и поднятия MTU c 1280 до 1454 - заработало. Причём, MTU в L3-тоннеле значения не имело.

Т.е. тоннели уровня L3, в частности, PPTP, L2TP и т.п. не обеспечивают стабильного функционирования схемы! Только "хардкор", только L2...  ;)

Выводы поспешные, но чувствую, что мы на верном пути.

Спасибо техподдержке за "пинок" в нужном направлении, хоть и случайный. Всё же, настоятельно прошу прояснить этот вопрос со стороны разработчиков (так сказать "добить комара"), дабы получить не только эмпирические результаты.

P.S. Конечно, буду нещадно переподключать клиента с "ДО" и оценивать стабильность этого процесса (минимум несколько недель). В случае успеха или неуспеха отпишусь...
« Последнее редактирование: Сентября 14, 2021, 23:27:30 от kosyak_kpol »
г. Севастополь, ООО "Лаборатория электроники", http://elab.com.ru, инж. сервисного отдела Константин Полозов.