Биллинговая система NoDeny. Ядро NoDeny

Ядро NoDeny - файл nodeny.pl. Основные процессы ядра NoDeny выполняются последовательно для того, чтобы исключить накладки и конфликтные ситуации. Безусловно, в реальности все процессы происходят параллельно, однако их обработка приводится к последовательной за счет постановки задания в очередь или аналогичными способами. Тем не менее, хотя последовательная обработка исключает возникновение сложнопрогнозируемых пересечений, сама имеет значительный недостаток: необходимо четко контролировать время выполнения каждой операции для того чтобы не было «затыков», т.е чтобы обработка одной операции не затянулась, в следствие чего ожидающие процессы находились бы в забвении все это время.

Положительным моментом является то, что NoDeny разрабатывался значительное время, при этом сеть автора постоянно претерпевала изменения как в топологии так и в требованиях. Это все отразилось в появлении множества нестандартных ситуаций, слабые места которых автор методично исправлял. В итоге имеем довольно надежное оттюнингованное ядро. Тем не менее, администратору следует присматриваться не исчерпался ли запас прочности системы и не пора ли проапгрейдить какое-либо звено.

Одним из средством анализа запаса прочности является слежение за логами и событиями ядра NoDeny. Для того чтобы понять их сущность, желательно разобраться в схеме работы ядра. Больше всего требует к себе внимания процедура получения и обработки данных трафика, полученных от коллекторов.


Получение и обработка данных трафика.

Процедура обработки трафика выполняется через равные промежутки времени, указываемые в настройках, либо непрерывно: получили статистику → обсчитали → записали → получили статистику и т.д. Период запроса статистики указывается в разделе «Операции» → «Настройки» → «Ядро». Чем меньше промежуток времени, тем оперативней будет обновление клиентской статистики, а, следовательно, и финансовой информации клиента, поскольку она привязана к трафику. Таким образом, чем чаще будет происходить срез трафика, тем точнее будет работать процедура блокировки учетной записи клиента - на больших скоростях клиент может значительно «уйти в минус», скачав информации больше лимита в момент между периодами снятия статистики.

Поскольку все в мире дискретно, то абсолютно исключить такую ситуацию невозможно. Уменьшение периода снятия статистики ведет к увеличению нагрузки на ядро, хотя не линейно зависит от времени. А так как коллекторы агрегируют трафик, то они уменьшают количество обрабатываемой информации ядром NoDeny. Таким образом, если выявлен недостаток ресурсов для обработки информации, то кроме увеличения аппаратных мощностей можно попытаться увеличить период снятия статистики.

Если процедура снятия и обработки статистики превышает установленный администратором период, то она не накладывается на последующую, ее запуск произойдет уже после окончания обработки.

Во время работы, собирается статистика времени обработки различных участков описываемой процедуры, эти данные записываются в таблицу traf_info основной базы данных и доступны в веб-админке на странице «статистика».

Каждые x-секунд процедура вызывает подпрограмму обработки авторизаций клиентов, таким образом, если во время обсчета трафика какой-либо клиент авторизуется, то он получит доступ в интернет в течение нескольких секунд и не будет ждать окончания процедуры обработки трафика.


Получение данных от коллекторов трафика.

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

На начальном этапе ядро пытается соединиться сразу со всеми коллекторами, запустив в фоне копию скрипта ipcad.pl (либо netflow.pl) для каждого сервера с коллектором. После этого, ядро, подождав несколько секунд, начинает мониторить папку /usr/local/nodeny/sql на предмет появления в ней файлов со статистикой. При вызове скриптов опрашивающих коллекторы, им сообщаются имена файлов, в которые они должны записать полученные от коллектора данные. В отведенные 60 секунд скрипт должен успеть это сделать.

Исходя из 60 секундного лимита, ipcad.pl распределяет время таким образом: выделяет время на указание ipcad переместить данные в чекпоинт - 5 секунд, время на получение данных из чекпоинта - 20 секунд. Итого 25 секунд. Однако, для перестраховки, в случае когда ipcad не даст ответ при первом обращении (такое бывает хотя и редко), процедура повторяется. Итого ipcad.pl должен уложиться в 50 секунд в худшем случае.

Чекпоинт важное звено в получении точных данных - сначала данные перемещаются в него, а в основной таблице очищаются, NoDeny же считает данные именно в чекпоинте. Если не производить подобное перемещение данных, то некоторый трафик может «проскочить» неучтенным в промежуток между получением данных трафика и обнулением таблицы ipcad с трафиком.

Поскольку перемещение в чекпоинт внутренняя операция ipcad, то таймаут берется небольшим - 5 секунд. Тем не менее, проверяется ответ чтобы быть уверенным, что процесс прошел успешно, иначе повторно могут быть посчитаны устаревшие данные в чекпоинте.

Когда ядро обнаружит, что присутствуют все файлы, оно начнет их обработку. По истечении 60 сек, ядро вне зависимости от присутствия всех файлов, перейдет к их обработке, естественно залогировав ошибку для конкретного коллектора(ов). Данные о трафике обрабатываются построчно. Сначала анализируется последний стоблец данных, по нему определяется как настроен коллектор - на отображение только ip либо же на отображение ip, порта, протокола и интерфейса. Во втором случае проверяется интерфейс на соответствие настройкам.

Если коллектор настроен на вывод статистики без интерфейсов и портов, то понять через какой интерфейс прошел трафик невозможно, а может и не нужно - если настройка серверов не предусматривает таких конфликтных ситуаций. Трафик в таком режиме считается в любом случае. Обратите внимание, что такой режим уменьшает служебный трафик за счет уменьшения информации, т.е возможно снизить нагрузку на сервер (канал), однако лишиться детализации трафика по портам и протоколам.

На разных серверах коллекторы можут работать в разных режимах.

Если в обрабатываемой строке коллектора не выявлено клиента сети - это расценивается как неправильная настройка системы. На самом деле, очевидно, что если есть трафик, который мы никому не можем начислить, то этот неучтенный трафик есть дыра. Причиной может являться неправильно настроенный фаервол, пропускающий клиентов без авторизации с любым (или определенным) ip либо же неправильно настроенное агрегирование ipcad, когда группа адресов агрегируется в сеть. Агрегирование полезная вещь и рассматривается в другом разделе.

Неучтенный трафик записывается в дополнительную базу данных в таблицу traf_lost и доступен для анализа в веб-адмике на странице «Статистика».

После того как определен клиент и определен тип трафика (входящий/исходящий) определяется классификация этого трафика, т.е. определяется направление. Анализируется второй ip с которым происходит обмен трафиком текущим клиентом.

ip удаленной стороны прогоняется по таблице с описанием направлений на предмет попадания в заданную сеть (и порт если указано). Таблица сетей индексируется по 3-му октету, что сокращает время поиска. 3й октет выбран статистически.

Если ip не найден в таблице, то он считается трафиком первого направления (класса №1), за исключением бродкаста и мультикаста - они считаются нулевым направлением. Обратите внимание на то, что мультикаст и бродкаст могут присутствовать в таблице и переопределяться на другое, отличное от нулевого, направления.

На самом деле ip прогоняется по двум таблицам: по таблице с нулевым пресетом и по таблице с клиентским пресетом. Существование двух разных (не обязательно разных) статистик призвано облегчить администрирование. Трафик нулевого пресета должен описывать реальные направления вашей сети, а клиентский пресет - то, как мы оцениваем этот трафик для клиента. Например, имея один канал в интернет мы создаем всего одно направление «интернет канал» в нулевом пресете, а в клиентском направления «мировой трафик», «игровой трафик», «городской трафик».

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