Система событий — механизм , посредством которого управляющие воздействия ядра системы передаются на сетевые службы и оборудование. С помощью событий выполняется множество задач, в том числе следующие:
Управление объектами (ОУ) и субъектами (СУ) учета построено на основе событий (events), возникающих при переходе ОУ/СУ из одного состояния в другое. Здесь состояние понимается в широком смысле: изменение атрибутов (в том числе дополнительных параметров, задаваемых пользователем), адресов, связей и привязок ОУ или СУ.
{graphviz}
// Управление ОУ (общая схема)
digraph G {
size="5,5"
graph [style=filled]
node [style=filled, shape=box, color=black, fillcolor=white]
"ОУ" [shape=ellipse]
"ОУ"->{"Состояние 1"; "Состояние 2"} [dir=none]
subgraph cluster_0 {
color=white
"Состояние 1"->"Событие"->"Состояние 2" [constraint=false]
"Событие" [shape=parallelogram, fillcolor=red, width=2, height=0.25, fixedsize=true]
}
"Событие"->"Действия"
"Действия"->"Агент" [label="Команды"]
"Агент" [shape=ellipse]
}
{graphviz} |
Событие вызывает набор связанных с ним действий (actions), которое преобразует эти действия в набор команд. В свою очередь, команды с помощью протокола удалённого управления передаются на выполнение агенту HAMD — специальному внешнему приложению, непосредственно взаимодействующему с сетевыми службами или оборудованием.
Соответствие друг другу событий, действий и команд задаётся в в настройках событий (Справочники -> События). На рисунке показаны основные взаимосвязи между настройками события.
{graphviz}
digraph G {
size="5,5"
graph [style=filled]
node [style=filled, shape=box, color=black, fillcolor=white]
"Управление СУ/ОУ"->{"События"; "Действия"; "Очередь команд";}
"События"->"Возможные события" [dir=none]
"Возможные события" [shape=record, style=rounded, label="{Привязка | Адрес | Состояние | Состояние\ родителя | Поступление\ платежа | Рекомендуемый\ платеж | Выставление\ счета | Подключение\ услуги | Отключение услуги}"];
"Действия"->"Возможные действия" [dir=none]
"Возможные действия" [shape="record", style=rounded, label="{SNMP-команда | Команда\ RSH/SSH/Telnet | Shell-скрипт}"];
}
{graphviz} |
События генерируются системой в момент, определяемый их типом. Как правило, они происходят при переводе СУ, ОУ или связанного с СУ документа (инвойса, платежного поручения) в то или иное состояние.
События добавляются в очередь, которая затем обрабатывается заданиями по агентам. Такой подход позволяет работать с произвольными событиями, которые могут возникать в любом модуле системы, а вызовы процедуры добавления нового события в очередь являются асинхронными, то есть не блокируют выполнение пакета. Кроме того, можно применять события не только для управления устройствами, но и в любых других целях, например, для рассылки Email-сообщений, SMS-уведомлений, факсов и т. д.
В настройках событий указываются:
Действие для представляет собой набор шаблонов команд в текстовом виде. Для использования в шаблонах предусмотрены специальные подстановки, которые при обработке команды агентом заменяются на конкретные значения атрибутов, идентификаторов и других параметров ОУ и СУ (например, подстановка
$TERM_PHYS_ADDR может быть заменена на значение 00-1A-B1-DF-24-A4). При этом в существует как жёстко запрограммированный набор подстановок, так и набор, задаваемый пользователем с помощью параметризованных подстановок. Например, дополнительные параметры ОУ могут представляться подстановкой (
$TERM_OBJ_ADD_PARAM[add_param_id], где add_param_id — идентификатор дополнительного параметра).
Действия при настройке события добавляются двумя группами — прямой и обратной. Для каждого действия может быть задано действие, ему противоположное. Это позволяет системе управления при необходимости с помощью обратного действия корректно отменять изменения, сделанные на оборудовании прямым действием.
Команда имеет свой тип взаимодействия (SNMP, RSH, SSH, локальный и т.д.), определяющий протокол, по которому эта команда будет передаваться на управляемое устройство.
Следует отметить, что деление команд на типы взаимодействия с точки зрения ядра |
Менеджер HAMD (Hydra Active Management Daemon) — это специализированное приложение, являющееся внешним по отношению к ядру АСР и предназначенное для приёма от него команд и их дальнейшего выполнения. Данный агент, как и другие агенты разработан на языке Python и поставляется в исходных кодах. Процесс установки агента HAMD достаточно прост и описан во вложенной статье.
Менеджер принимает сообщения от ядра АСР по протоколу XML-RPC аналогично агенту HCD. В сообщении передаётся как сам пакет команд, так и дополнительные параметры, необходимые для его выполнения (данные для аутентификации на оборудовании и т.д.). Связь ядра с менеджером инициируется заданием по этому менеджеру.
Подстановки передаются отдельно от шаблона, что позволяет проводить их дополнительную обработку на стороне агента.
После того, как пакет команд выполнен, агент передаёт в систему отчёт о выполнении, в котором содержится результат выполнения каждой команды. Всего возможны четыре варианта: успех, предупреждение, ошибка и неизвестно. Пользователь сам задает то, какой результат вернуть в систему в каждом конкретном случае. Кроме того, вместе с результатом можно передавать и сообщение с расшифровкой проблемы. Подробная и качественная обработка ошибок позволяет легче обнаруживать и устранять проблемы, возникающие при работе системы, что в конечном счёте приводит к экономии рабочего времени и средств.
Для стандартных типов взаимодействия обработка ответов выполняется автоматически. Так, для типа взаимодействия Локально (выполнение shell-скрипта на локальном сервере) ошибкой считается ненулевой код возврата, а в качестве расшифровки ошибки HAMD передает в все, что скрипт выдал за время своей работы на стандартный вывод ошибок (stderr).
В приложении имеется пример скрипта по управлению доступом абонентов программным файрволом с помощью утилиты iptables.
Задания приводят механизм управления СУ/ОУ в действие. Основная сущность, с которой работают задания — очередь событий.
Суть очереди событий ясна из названия. Событие вместе с набором связанных с ним действий добавляется в хвост очереди, а выполнение действий менеджером идёт с её начала. При этом действия группируются в разрезе каждого устройства, на котором они выполняются. Это позволяет использовать взаимозависимости команд — в зависимости от результата выполнения очередной команды может прерываться выполнение следующих команд на этом же устройстве.
На каждый менеджер создается одно задание в момент перевода менеджера в активное состояние. После создания задание автоматически запускается с определенной периодичностью.
Взаимодействие сущностей при срабатывании события по ОУ показано на примере управления доступом оконечного оборудования абонента к услугам оператора.
{graphviz}
digraph G {
size="7,7"
graph [style=filled]
node [style=filled, shape=box, color=black, fillcolor=white]
rank=source
"Абонент" [shape=ellipse, fillcolor=lightpink]
subgraph cluster_1 {
color=lightblue
rank=max
"Оконечное оборудование" [shape=ellipse]
"Оконечное оборудование"->{"Состав"; "Атрибуты оборудования"}
"Состав" [shape=record, label="{Порт\ 1 | Порт\ 2 | ... | Порт\ N}"]
}
subgraph cluster_2 {
color=darkseagreen2
rank=min
"Файрвол" [shape=ellipse]
"Коммутатор" [shape=ellipse]
}
subgraph cluster_3 {
color=mistyrose
rank=min
"Событие"->"Действия"->"Команды"
}
"Абонент"->"Оконечное оборудование"
"Оконечное оборудование"->{"Коммутатор"; "Файрвол"}
"Очередь событий" [shape=record, label="{Событие\ 1 | Событие\ 2 | ... | Событие\ N}"]
"Событие"->"Очередь событий"
"Очередь событий"->"Менеджер"[label="Задание"]
"Менеджер"->{"Файрвол"; "Коммутатор"} [label="Команды"]
}
{graphviz} |
Событие обрабатывается следующим образом:
При работе оператора связи возникают типовые задачи по управлению оборудованием и службами. Все нижеперечисленные задачи решаются с помощью событий:
Обратные действия необходимы не всегда. Часто бывает достаточно задать только прямое действие. Например, если услуги абоненту оказываются по технологии PPPoE, то для события на отключение услуги необходимо задать действие, которое разрывает текущую PPP-сессию с помощью SNMP-команды или CoA-запроса по протоколу RADIUS. Ясно, что в этом случае задавать обратное действие бессмысленно, потому что однажды разорванная сессия уже не может быть восстановлена со стороны сервера.
Обратные действия, однако, могут быть полезны в случае, когда управляемое оборудование обладает собственной памятью, в которой сохраняются состояния выполненных на них команд. В этом случае при изменении параметров абонента выданные оборудованию команды нужно корректно отменять.
Например, в случае, если на шейпере абонент идентифицируется по статическому IP-адресу его оборудования, и по какой-то причине у абонента изменился IP-адрес, необходимо задать обратное действие на событие При подключении услуги Интернет-трафик вх. В этом случае система, обнаружив, что значение подстановки $TERM_IP_ADDRESS изменилось, автоматически выполнит отменяющее событие (удалит правило шейпера для старого IP-адреса), а затем снова выполнит прямое действие, но уже с новым значением IP-адреса.
Предположим, что необходимо настроить события на включение и отключение услуги Доступ в Интернет, которые будут разрешать или ограничивать доступ абонента в Интернет на программном файрволе iptables.
1. В настройках событий (Справочники->События) на вкладке Типы объектов найдите позицию номенклатуры, по которой будет происходить событие. В данном случае такой позицией будет Программный файрвол.
2. В настройках действий для программного файрвола (вкладка Действия) создайте новое действие Разрешить доступ в интернет и настройте его как показано на рисунке ниже. Настройка Тип взаимодействия задает протокол, по которому будут выполняться команды, входящие в данное действие. Список доступных подстановок можно получить, нажав на специальную кнопку в правой части поля ввода команды.
Включенная галочка Игнорировать ошибки в настройках действия означает, что если любая входящая в него команда завершится ошибкой, то дальнейшее выполнение других действий по этому же событию будет продолжено; в противном случае выполнение будет прервано. Аналогичная галочка Игнорировать ошибки в настройках конкретной команды означает то же самое, но в пределах одного действия.
Подстановка $TERM_IP_ADDR в теле команды при ее выполнении менеджером будет заменена на IP-адрес оконечного оборудования абонента, по которому произошло событие.
Аналогичным образом создается действие Запретить доступ в интернет, оно отличается от разрешающего действия только содержимым команды.
3. Вернитесь на вкладку События и создайте новое событие как показано на рисунке ниже.
Тип привязки объекта позволяет выбрать тип привязки, с помощью которой абонентское оборудование связано с файрволом. Это полезно в случае, когда на одном и том же абонентском оборудовании задано несколько типов событий, которые обрабатываются разными сетевыми службами. Например, доступ и пропускная способность канала могут регулироваться на одной и той же сетевой службе — файрволе. Указание разных типов привязки позволяет обрабатывать эти события отдельно, несмотря на то, что они происходят на одной сетевой службе.
4. Привяжите действия Разрешить доступ в интернет и Запретить доступ в интернет к созданному в п. 3 событию. Результат показан на иллюстрации к п. 1. Подробнее о прямых и обратных действиях рассказано ниже.
Настройка событий завершена, осталось настроить только абонентское оборудование.
5. На форме редактирования тестового абонента откройте его оборудование и перейдите на вкладку Привязки. Привяжите это оборудование к сетевой службе, для которой задано событие (на рисунке ниже это служба IPTABLES1, имеющая тип Программный файрвол). В поле Тип привязки нужно указать именно тот тип, который задан в настройках события, в противном случае событие не сработает.
6. Выставьте абоненту инвойс по его оборудованию, если он не был ранее выставлен, и попробуйте изменить состояние услуги доступа на вкладке Услуги формы редактирования абонента. В нижней части экрана должно появиться сообщение По <оборудование абонента> произошло событие "При подключении услуги Доступ в интернет" для IPTABLES1. Если такое сообщение не появляется, нужно проверить настройки события и настройки привязки.
Иногда возникает ситуация, когда оборудование, ограничивающее доступ абонента к услугам, перезагружается или выходит из строя, при этом появляется необходимость восстановить текущее состояние выполненных ранее событий. Это делается с помощью командной строки утилитой hamdctl. Данная утилита не производит какой-либо выгрузки информации по текущему состоянию. При выполнении запроса текущего состояния, происходит повторное выполнение всех неархивных событий по указанному объекту и менеджеру активного оборудования (агенту HAMD).
Список возможных команд:
srvstatus — запрос состояния агента HAMDlistreq — получение очереди запросов текущего состоянияrequest — добавление запроса текущего состояния в очередьremovereq — удаление запроса текущего состояния из очередиДля восстановления текущего состояния hamdctl
/opt/hydra/hamd/lib/hamdctl.py -u http://login:password@host:port request object-id:<object-id> |
Примечание: в новых версиях менеджера hamd (начиная с версии 1.1.2.1) вместо скрипта /opt/hydra/hamd/lib/hamdctl.py нужно использовать утилиту /opt/hydra/hamd/bin/hamdctl.
Здесь:
<object-id> — это идентификатор сетевой службы login — логин для базовой авторизации на HAMD.password — пароль для базовой авторизации на HAMD.host — IP-адрес сетевого интерфейса, на котором работает HAMD.port — порт, на котором работает HAMD.Для получения информации о всех параметрах вызова утилиты достаточно запустить её без каких-либо аргументов:
user@server:~$ /opt/hydra/hamd/lib/hamdctl.py |