Общая часть конфигурации

Слушатели, процессоры и другие сущности контейнера определяются в конфигурационном файле inet-access.xml, либо inet-accounting.xml.

Рассмотрим общую часть XML-конфигурации обоих серверов.

Код
<?xml version="1.0" encoding="UTF-8"?>
<application context="access">
 <!-- Уникальное имя приложения -->
 <param name="app.name" value="InetAccess"/>
 <!-- Уникальный числовой id приложения -->
 <param name="app.id" value=""/>

 <!-- Параметры подключения к БД -->
 <param name="db.driver" value="com.mysql.jdbc.Driver"/>
 <param name="db.url" value="jdbc:mysql://127.0.0.1/abilling?useUnicode=true&amp;characterEncoding=UTF-8&amp;allowUrlInLocalInfile=true&amp;zeroDateTimeBehavior=convertToNull&amp;jdbcCompliantTruncation=false&amp;queryTimeoutKillsConnection=true"/>
 <param name="db.user" value="bill"/>
 <param name="db.pswd" value="abilling"/>

 <!-- Параметры подключения к MQ -->
 <param name="mq.url" value="failover:(tcp://localhost:61616)"/>
 <param name="mq.user" value="bill"/>
 <param name="mq.pswd" value="abilling"/>

 <!-- id модуля -->
 <param name="moduleId" value=""/>
 <!-- id корневого устройства -->
 <param name="rootDeviceId" value=""/>

 <param name="datalog.radius.dir" value="data/radius"/>
 <param name="datalog.dhcp.dir" value="data/dhcp" />
 ....

Параметры:

  • app.name определяет имя приложения, оно используется, например в системе алармов;

  • app.id - уникальный числовой идентификатор приложения среди всех приложений биллинга с данным параметром в XML-конфигурации, значение его не должно меняться всё время жизни системы;

  • moduleId - код экземпляра модуля Inet, к которому относится сервер.

Далее следуют стандартные параметры с настройкой доступа к серверу БД и к MQ-серверу (серверам).

Каждый сервис привязан к своему устройству. В конфигурации каждого из серверов Access и Accounting указывается корневое устройство, от которого, включительно, начинается загрузка в память устройств и сервисов. Код этого устройства указывается в параметре rootDeviceId.

Параметры вида datalog.* определяют каталоги для хранения бинарных логов RADIUS, DHCP, NetFlow-пакетов. Хранение данных Access-сервером необходимо для возможности по запросу предоставления пакетов авторизации сессии в интерефейсе клиента. Хранение данных Accounting-сервером позволяет выполнять переобработку логов. Access-сервер хранит RADIUS (Access-запросы) и DHCP-пакеты. Accounting - RADIUS (Accounting-запросы) и NetFlow-пакеты. Хранение в бинарном виде в файлововй системе позволяет разгрузить БД от большого объёма информации. Логи сохраняются с разбивкой по каталогам устройств-источников.

Каждому устройству может быть сопоставлен свой объект класса-активатора сервисов и объект класса-процессора протокола. Классы объектов указываются в настройках типа устройства, классы должны расширять абстрактные классы ru.avantis.abilling.modules.inet.access.sa.ServiceActivatorAdapter и ru.avantis.abilling.modules.inet.access.sa.ProtocolHandlerAdapter соответственно. В момент старта сервера для каждого устройства, в типе которого указанны классы, создаётся отдельный объект и вызывается метод init, в котором могут быть считаны параметры конфигурации. Все методы объекта класса-обработчика активации вызываются последовательно от устройства далее у всех его предков до корневого узла сервера, что позволяет производить настройки в иерархии устройств.

При создании сервиса на устройстве, к которому оно привязано, вызывается метод serviceCreate объекта класса-активатора. В этом методе возможно указание настроек, которые должны быть добавлены на устройство только при создании сервиса. Этот же метод вызывается, когда сервис был добавлен будущим числом и это число наступило. При удалении сервиса или истечении даты его закрытия на устройстве вызывается метод serviceCancel.

Опции могут быть определены на сервисе и сессии. Помимо опции у сервиса определяется его состояние. С помощью опций сервиса возможно управление параметрами статического доступа. При этом нет необходимости в потреблении сервисом трафика, нет необходимости в сессиях. Опции указываются непосредственно в свойствах сервиса. При изменении статуса сервиса или опций сервиса вызывается метод объекта класса-активатора устройства serviceModify.

Сервис потребляет услуги модуля в ходе сессий, при этом для тарификации используются тарифные планы. Каждая сессия привязана к устройству, не обязательно к тому, к которому привязан сервис. Логика привязки сессии к устройству определяется слушателем (RADIUS, DHCP, NetFlow), об этом будет описано позднее. В конфигурации того устройства, к которому привязана сессия, может быть определено устройство, с которого получается информация по трафику данной сессии. Устройства и интерфейсы определяется переменной: flow.agent.link=<device_id>:<iface_id>

Где:

  • <device_id> - код устройства, с которого снимается трафик;

  • <iface_id> - код интерфейса устройства, через который выходит трафик сессии.

Например:

flow.agent.link=1:-1

Указание другого устройства, отличного от устройства сессии имеет смысл при съёме трафика по протоколу NetFlow с вышестоящего роутера. Код интерфейса при этом должен совпадать с кодом интерфейса, идущим во Flow-записях и обозначающий интерфейс роутера, смотрящий на устройство сессии. Более подробно об это переменной можно просчитать тут.

Сессия сервиса также обладает набором опций, который состоит из опций сервиса и опций тарифного плана. Второй набор опций может менятся в ходе тарификации. Первый - в результате правки сервиса. При изменении параметров сессии в объекте класса-активатора устройства, к которому привязана сессия вызываются метод connectionModify. При завершении - connectionClose. Для старта сессии необходимо наличие NetFlow-трафика по IP-адресу сервиса, либо наличие сигнала (RADIUS, DHCP).,

Как уже указывалось ранее, в конфигурации серверов могут быть указаны слушатели, рассмотрим их.