День добрый.
Суть проблемы: есть openvpn сеть контроллеров (wb6.7…wb6.9) 50+штук.
В контроллерах стоят 3G модемы;
Контроллеры установлены в таких местах, где нагрузка на GSM сеть очень высокая;
Установлено это всё было пару лет назад;
Контроллеры иногда обновляются - update && dist-upgrade раз в неделю;
Сначала после очередного обновления перестали через vpn сеть загружаться странички интерфейса контроллеров, относящиеся к настройке устройств на последовательных портах;
Еще через месяца три (после очередного обновления) веб интерфейс перестал открываться изнутри vpn сети напрочь.
Если подойти к контроллеру ногами и подключиться к wifi - всё работает;
Предположение: загружаемые страничками интерфейса скрипты постепенно потяжелели - и веб-морда отваливается по таймауту, не успевая пролезть через узкий и прерывающийся канал.
Как бы подкрутить таймаут? (до минут пяти хотя бы :-))
Добрый день.
А на чем останавливается загрузка? Интерфейс (http), кстати, совсем не обязательно грузить с самого контроллера, ведь специально сделана возможность указания MQTT адреса.
Логи показывайте, интересно даже.
Ну и опишите, что за кейс требует подключаться к интерфейсу контроллера. Зачем?
Контроллеры реализуют управление и диспетчеризацию дизель-генераторных установок. Панель управления дизеля - модбас устройство у которого прорва параметров (толком не помню сколько, но сотни). Из них оперативно нужно - десяток основных. Остальные бывают нужны крайне редко, посему в скаду не поднимаются. Если хочется посмотреть детально что происходит с дизелем - в скаде есть прямая ссылка на страничку “устройства” контроллера.
Вот что происходит при загрузке страницы:
т.е. из четырех мегабайт main.*.js скачали чуть меньше полутора и обломались по таймауту.
Я не берусь утверждать, что за год скрипты сильно откормились, но факт в том, что год назад это работало, а теперь - работает в четверти случаев примерно.
да, там я окончания процесса так и не дождался. Заканчивается все вот этим:
Да, канал действиельно не толстый. Ну так используйте, как предложил выше загрузку самого интерфейса локальную, а обращение к контроллеру - только по mqtt.
мерзкая особенность нынешней сотовой связи в Москве состоит в том, что когда пытаешься что-то скачать (без разницы - одним куском или пачку мелких файлов) (например, обновить контроллер), то сетевые настройки соты начинают постепенно резать трафик. Пока не зарежут совсем вплоть до отвала VPN. И происходит это тем более злобно, чем выше нагрузка на эту самую соту, к которой подключен контроллер.
Есть места в городе, где просто apt update может не то что обновиться, а проверить наличие обновлений только глубокой ночью.
Грузить не интерфейс, а только данные - дорого. Потому что стоимость скады - вычисляется в количестве тегов, они же сигналы. Прямая ссылка на контроллер - вообще не стоит ничего, а запрос каждого mqtt сигнала - это деньги. А сигналов много и стоить это будет столько, что не найдет понимания у заказчика.
Мы как раз собирались двигаться в обратную сторону - всё, что можно не поднимать наверх - оставлять на контроллере, в том числе интерфейс пользователя, касающийся взаимодействия с железом. Построение графиков параметров, всякие гистограммы, лампочки, кнопочки и вот эту вот всю неземную красоту операторского интерфейса - строить локально силами контроллера.
А наверху оставлять только “групповую работу” - отчеты, общие журналы событий и.т.п., требующее данные более, чем от одного контроллера. И навигацию по узлам. Как только выбран один какой-то узел - переадресация на соответствующий контроллер и никакого взаимодействия с верхним уровнем.
К тому же у контроллера всегда избыток вычислительных ресурсов, а у сервера субд/скады - вечный недостаток.
У нас есть на обслуживании наша же собственная древняя конструкция, где все данные, сколько удалось собрать, тупо сваливаются наверх и разбирательство с ними ведется централизовано на уровне СУБД и скады - это работает омерзительно. В смысле масштабирования и быстродействия. Зато на качество каналов связи, действительно, плевать…
Со всем согласен.
Ну так если нужно зайти “по HTTP” на контроллер - то статику (скрипты, html) можно загружать с быстрого серывера, не нужно тянуть все с самого контроллера. Веб-интерфейс, запущенный в бразузере пользователя работает с контроллером толко по MQTT.
То есть интерфейс может загружаться с локального контроллера, а работать с другим, чей адрес указан в настрйках " Web UI".
Раз уж подключаетесь периодически.
надо попробовать сделать “фиктивный контроллер”, это имеет шанс работать. Делал кто-нть такое?
хм… поднять на соседнем со скадой сервере http proxy?
Можно и прокси. Да что пробовать-то загружаем с любого контроллера с которым связь хорошая интерфейс и в настройках ставим адрес любого другого.
ща поразвлекаемся, пока заказчик дремлет 
это работает. Осталось научиться менять на лету адрес mqtt подключения.
