Настройка событий (агент HAMD)

Система событий — механизм АСР «Гидра», посредством которого управляющие воздействия ядра системы передаются на сетевые службы и оборудование. С помощью событий выполняется множество задач, в том числе следующие:

• приостановление и возобновление доступа абонентов к услугам;
• установка параметров оказания услуг абонентам на оборудовании;
• рассылка абонентам уведомлений и напоминаний о платежах.
• управление портами оборудования.

Общая схема

Управление объектами (ОУ) и субъектами (СУ) учета построено на основе событий (events), возникающих при переходе ОУ/СУ из одного состояния в другое. Здесь состояние понимается в широком смысле: изменение атрибутов (в том числе дополнительных параметров, задаваемых пользователем), адресов, связей и привязок ОУ или СУ.

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

Настройки событий

Соответствие друг другу событий, действий и команд задаётся в АСР «Гидра» в настройках событий (Справочники -> События). На рисунке показаны основные взаимосвязи между настройками события.

События

События генерируются системой в момент, определяемый их типом. Как правило, они происходят при переводе СУ, ОУ или связанного с СУ документа (инвойса, платежного поручения) в то или иное состояние.

События добавляются в очередь, которая затем обрабатывается заданиями по агентам. Такой подход позволяет работать с произвольными событиями, которые могут возникать в любом модуле системы, а вызовы процедуры добавления нового события в очередь являются асинхронными, то есть не блокируют выполнение пакета. Кроме того, можно применять события не только для управления устройствами, но и в любых других целях, например, для рассылки 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 (агент управления)

Менеджер HAMD (Hydra Active Management Daemon) — это специализированное приложение, являющееся внешним по отношению к ядру АСР и предназначенное для приёма от него команд и их дальнейшего выполнения. Данный агент, как и другие агенты АСР «Гидра» разработан на языке Python и поставляется в исходных кодах. Процесс установки агента HAMD достаточно прост и описан во вложенной статье.

Менеджер принимает сообщения от ядра АСР по протоколу XML-RPC аналогично агенту HCD. В сообщении передаётся как сам пакет команд, так и дополнительные параметры, необходимые для его выполнения (данные для аутентификации на оборудовании и т.д.). Связь ядра с менеджером инициируется заданием по этому менеджеру.

Подстановки передаются отдельно от шаблона, что позволяет проводить их дополнительную обработку на стороне агента.

После того, как пакет команд выполнен, агент передаёт в систему отчёт о выполнении, в котором содержится результат выполнения каждой команды. Всего возможны четыре варианта: успех, предупреждение, ошибка и неизвестно. Пользователь сам задает то, какой результат вернуть в систему в каждом конкретном случае. Кроме того, вместе с результатом можно передавать и сообщение с расшифровкой проблемы. Подробная и качественная обработка ошибок позволяет легче обнаруживать и устранять проблемы, возникающие при работе системы, что в конечном счёте приводит к экономии рабочего времени и средств.

Для стандартных типов взаимодействия обработка ответов выполняется автоматически. Так, для типа взаимодействия Локально (выполнение shell-скрипта на локальном сервере) ошибкой считается ненулевой код возврата, а в качестве расшифровки ошибки HAMD передает в АСР «Гидра» все, что скрипт выдал за время своей работы на стандартный вывод ошибок (stderr).

В приложении имеется пример скрипта по управлению доступом абонентов программным файрволом с помощью утилиты iptables.

Задания

Задания приводят механизм управления СУ/ОУ в действие. Основная сущность, с которой работают задания — очередь событий.

Суть очереди событий ясна из названия. Событие вместе с набором связанных с ним действий добавляется в хвост очереди, а выполнение действий менеджером идёт с её начала. При этом действия группируются в разрезе каждого устройства, на котором они выполняются. Это позволяет использовать взаимозависимости команд — в зависимости от результата выполнения очередной команды может прерываться выполнение следующих команд на этом же устройстве.

На каждый менеджер создается одно задание АСР «Гидра» в момент перевода менеджера в активное состояние. После создания задание автоматически запускается с определенной периодичностью.

Взаимодействие при управлении ОУ

Взаимодействие сущностей АСР «Гидра» при срабатывании события по ОУ показано на примере управления доступом оконечного оборудования абонента к услугам оператора.

Событие обрабатывается следующим образом:

1. Когда происходит событие, оно добавляется в очередь событий.
2. События, накопившиеся в очереди, обрабатываются заданием и передаются на менеджер.
3. Менеджер выполняет команды на оборудовании (файрвол, коммутатор).

Примеры типовых событий

При работе оператора связи возникают типовые задачи по управлению оборудованием и службами. Все нижеперечисленные задачи решаются с помощью событий:

1. Задание и изменение привязки MAC-порт (IP-MAC-порт).
2. Задание и изменение скорости доступа на шейпере (iptables, ipfw, Cisco...).
3. Включение и отключение доступа абонента к услугам связи (управлением файрволом, разрыв PPP-сессий и т.д.).
4. Включение и отключение абонентского порта при блокировке абонента.
5. Перепривязка оконечного оборудования абонента к другому устройству (переезд).
6. Уведомление абонента о поступлении платежа на его лицевой счет.
7. Уведомление абонента о рекомендуемом платеже за несколько дней до предполагаемого отключения.
8. Уведомление абонента о выставленном ему счете на оплату услуг.

Прямые и обратные действия

Обратные действия необходимы не всегда. Часто бывает достаточно задать только прямое действие. Например, если услуги абоненту оказываются по технологии 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 — запрос состояния агента HAMD
• listreq — получение очереди запросов текущего состояния
• 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> — это идентификатор сетевой службы АСР «Гидра», по которой запрашивается текущее состояние событий. Если продолжить описанный выше пример, то такой службой будет программный файрвол IPTABLES1. Идентификатор этого файрвола можно получить на форме его редактирования.
• login — логин для базовой авторизации на HAMD.
• password — пароль для базовой авторизации на HAMD.
• host — IP-адрес сетевого интерфейса, на котором работает HAMD.
• port — порт, на котором работает HAMD.

Для получения информации о всех параметрах вызова утилиты достаточно запустить её без каких-либо аргументов:

user@server:~$ /opt/hydra/hamd/lib/hamdctl.py