Зачастую возникает необходимость проводить мониторинг и сброс питания какого-либо сетевого устройства (сервер, Wi-Fi или GSM роутер, видеокамера и т.д.) в том случае, если оно «зависло». Одним из первых критериев «зависания» можно назвать отсутствие ответа на PING IP данного устройства.
Рассмотрим пример управления электропитанием сетевого устройства и его автоматизированный ресет с помощью модуля Laurent-5 с использованием логических правил CAT по PING. Для конкретики заведем питание испытуемого устройства (в данном случае – Wi-Fi роутер, склонный к зависаниям) через клеммы RELE_1. По умолчанию клеммы RELE1.1 и RELE2.1 замкнуты так, что устройство будет запитано. Если же реле включить, то питание на устройство подаваться не будет.
Для того чтобы модуль Laurent-5 сам проводил операцию PING и проводил сброс питания в случае необходимости, используем систему CAT, позволяющую создавать логические правила через Web интерфейс и задавать реакцию в случае срабатывания события. В WEB интерфейсе модуля выбираем иконку системы CAT:
Далее, создаем новое CAT событие. На первом шаге выбираем первый свободный слот для нового CAT события. На следующем шаге выбираем тип события «PING IP».
Задаем настройки события: частоту проверки PING испытуемого устройства и его сетевой адрес (в данном примере 192.168.0.100). Событие (реакция) сработает, если PING будет неудачным.
Не будем указывать дополнительные условия для события, а так же квоты. В качестве реакции на событие (если оно сработает) отправим Ke команду управления первым реле. А именно, включим реле на 5 с, после чего оно самостоятельно вернется в исходное состояние.
Назовем данное событие как «Простой PING» (более сложный вариант рассмотрим далее).
Должно появится сообщение об успешном создании события, а также должны увидеть этот элемент CAT в общем списке. По умолчанию вновь созданное событие выключено. Включим его.
Каждые 10 минут по времени со старта модуля (время текущего сеанса) модуль будет пытаться посылать PING запрос на указанный IP. Если PING будет провален (предположим, что удаленное устройство «зависло»), RELE_1 будет включено на 5 с (разорвет цепь питания устройства на 5 с).
Однако иногда есть необходимость в более «умном» PING. А если провал был вызван другими причинами (проблемы в сети), а наблюдаемое устройство прекрасно работает? А мы его ресетим без причины?
В таком случае нужно создать более сложную логику, в которой мы будем посылать несколько PING запросов и принимать решение о необходимости ресета, основываясь не на одном результате, а на N попытках PING наблюдаемого устройства. Для этих целей создадим взаимосвязанную группу CAT событий, передающих управление друг другу, основываясь на значениях модифицируемых программных переменных.
План будет следующим. Создадим основное событие по провалу операции PING. Если наблюдаемое устройство на PING не ответило, вместо того, чтобы сразу сбрасывать питание, проведем еще группу контрольных PING запросов. Далее проанализируем результаты контрольных PING (успешных и не успешных) и только после этого примем окончательное решение о необходимости ресета питания наблюдаемого устройства.
Создадим такое основное событие с периодом опроса в 15 минут. В качестве реакции на провал операции PING активируем (включим) обработку CAT событий под номером 2 и 3 (см. далее) и обнулим значения программных переменных VAR_1 – VAR_3 которые будут использоваться для подсчета контрольных PING.
$KE,CAT,2,SET,ON
$KE,CAT,3,SET,ON
$KE,CAT,4,SET,ON
$KE,VAR,1,SET,0
$KE,VAR,2,SET,0
$KE,VAR,3,SET,0
В итоге должно получиться CAT событие вот такого вида:
Далее создадим два события контрольного PING: одно будет срабатывать, если PING провалился, другое – если PING был успешным. Эти два события будут вызываться с максимальным периодом – раз в минуту. При этом будет инкрементироваться переменная VAR_1, если один из контрольных PING провалился, VAR_2 – если был успешным. VAR_3 будет подсчитывать общее число всех контрольных PING.
Предположим, что мы хотим выполнить суммарно не более 5 контрольных PING. По выполнении 5 контрольных PING (успешных или неуспешных) нужно принимать решение. Для контроля и ограничения числа контрольных PING создадим еще одно событие, отвечающее за эту операцию.
Это событие срабатывает по системному времени (прошедшему времени с момента старта модуля). Условие проверяется с частотой 1 Гц. Указав условие «больше 0», по факту такое событие (если включено) будет срабатывать каждую секунду.
Укажем в качестве дополнительных условий для этого события необходимость равенства переменной VAR_3 (общее число выполненных контрольных PING), равным 5.
Если условие будет выполнено (VAR_3 == 5), то: выключим работу контрольных PING (выключим CAT события 2 и 3), выключим также текущее событие (оно нам больше не нужно) и включим события 5 и 6 (создадим их далее), в которых и будем уже проводить анализ контрольных PING и принимать решение о ресете питания.
$KE,CAT,2,SET,OFF
$KE,CAT,3,SET,OFF
$KE,CAT,4,SET,OFF
$KE,CAT,5,SET,ON
$KE,CAT,6,SET,ON
В самом конце создадим еще два события CAT, которые будут анализировать статистику контрольных PING. Условимся, что если хотя бы один из контрольных PING был провален, то принимаем решение о необходимости сброса питания через кратковременное включение RELE_1 (при необходимости, можно увеличить этот порог). В том случае, если все 5 контрольных PING были успешными, ресет питания не делаем, а в порт TCP сервера отправим строку OK.
Для того чтобы «завести» всю это логику, достаточно включить первое основное событие (остальные события пока выключены). После этого каждые 15 минут будет проводиться попытка PING IP наблюдаемого устройства.
Если основной PING будет провален, управление передается на события 2 и 3, выполняющие контрольные PING, а так же активируется событие 4. Оно контролирует общее число выполненных контрольных PING.
Если хотя бы один из контрольных PING будет провален, выполняем ресет питания. В примере ниже показано, что все 5 контрольных PING были неуспешными (см. счетчик срабатывания события CAT_2). Соответственно, сработало условие на ресет питания через RELE.
Купить Laurent-5 на РадиоЛоцман.Цены
