BiTel

Добрый день,

Наши тесты NetFlow коллектора с версией 4.4 дают все равно заниженные результаты по сравнению с FlowTools. У нас есть рац предложение. Расскажу немного о том как работает у нас и хотелось бы узнать, об интеграции всего этого дела в BGBilling.

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

За счет такой схемы мы боримся с объемом занимаемой информацией. За 3 месяца прошло оклол 6 терабайт по сети. Информация о них в БД занимает 1,3 ГБ. Если хотите мы всю схему детально выложим.

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

Заранее спасибо,

UP

Какой модуль планируете использовать IPN или VPN

Ну вообще планируем IPN.

Kama s Utra немножко неправильно описал схему, имеющуюся у нас сейчас.
Есть коллектор flow-tools
Есть фильтры к flow-nfilter
Есть скрипт, который достает информацию согласно фильтрам по каждому нашему IP адресу о количестве переданной и принятой информации в виде (Время, IP Адрес, Принято Мб, Передано Мб):


Далее есть база MySQL куда это все прогружается.
Flow-Tools настроены каждые 5 минут создавать новый файл, а также после закрытия предыдущего файла запускать программу обработки, которой и является скрипт.
Получается, скрипт формирует нужную информацию, по нужным адресам и складывает ее в базу MySQL.
В MySQL есть идентичные таблички, называются 5min, 1hour, 1day


Также в MySQL создан триггер:
После добавления в информации в таблицу 5min, округлить время до 1 часа, добавить эту информацию в таблицу 1hour, если первичный ключ (time, ip) уже есть (происходит 11 раз в час, так как периоды 5-ти минутные), то просуммировать информацию по столбцам download и upload.
Тоже самое происходит и в таблице 1day, но время округляется до суток.

Таким образом в таблице 1day мы имеем список IP адресов и информацию об их прокачанном трафике.
Теперь все что нам нужно сделать для определения трафика за месяц, это просто попросить у MySQL:

вот что получаем на выходе

Время выполнения запроса: 1.85с
Оперировать данными можно легко меняя запрос, а также производить группировку по дате, либо IP адресу.

Собственно вопрос, можно ли переделать модуль IPN, чтобы он не использовал свои накопленные данные, а просто просил наш MySQL о трафике для определенных клиентов. Т.е. в IPN нам придется вбить всего лишь IP адреса.

Спасибо.

Ну что нам ждать ответа?

ПЕРЕДЕЛЫВАТЬ модуль наврядли будем, в любом случае в текущей версии.

Ну а если мы будем подсовывать свои данные (время, ip, принято, скачено) в БД непосредственно? Это будет работать? Если да, то куда их надо вставлять. В описании БД не совсем понятно...

будет, а вот, что, куда и как это надо описывать, а на это пока времени нет

Вы называете это технической поддержкой?

Поймите, что коллектор теряет данные. Flow tools не с потолка же берет те данные, которые в ваш Netfolow коллектор не попадают. Даже 10 мб с каждого клиента это уже 10 гб с 1000 клиентов. Уж не говоря о потерях под 7-10%. Не знаю как вам, но для розничных реселлеров трафика это немаловажно.

ПЕРЕДЕЛЫВАТЬ совсем не обязательно, можно дописать новый

когда нам ждать ответа по нашей идее?

А почему не подходит такой метод?
http://wiki.bgbilling.ru/index.php/Связка_с_flow-tools

Ну вообще система у нас работает, генерит минимальное количество данных, которого достаточно для нас. Значения агрегированные. Хотелось бы чтобы именно их билинг тарфицировал.

Обсчет делится на два действия: обработка первичных логов и тарификация.
При обработке логов находится подходящий диапазон адресов (aid), договор(cid), к которому он привязан, услуга(sid) и с разделением за час записывается в таблицу ipn_contract_data_
При тарификации эти данные проходят через тарифное дерево и заполняется таблица contract_account, где указаны договор, месяц, услуга, сумма.

Т.е. можно разделить upload и donwload на две услуги и записывать эти данные в ipn_contract_data_mid_yyyyMM вместо обработки логов.

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

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

Можно узнать примерную конфигурацию машины(в том числе сетевая карта), на котором идет потеря flows, объемы(кол-во пакетов)? Как делятся потоки?

Есть такая штука
http://wiki.openvz.org/Main_Page

Стоит на машине
Intel(R) Xeon(TM) CPU 3.20GHz 4х ядерный
2Гб памяти
320Гб жесткий диск

Созданы контейнеры на этой машине:
1. Flow-Tools с нашим скриптиком
2. MySQL куда скидывается вся агрегированная информация о трафике
3. BGBilling

В первом контейнере запущен flow-fanout, для репликации flow потока на разные хосты, т.к. CISCO не может слать flow больше чем на два направления.
flow-fanout реплицирует поток на flow-tools, стоящий в этом же контейнере и в BGBilling в другой контейнер.
Все это делается в пределах одной физической машины.

В итоге BGBilling считает меньше чем flow-tools

Спасибо.
Забыл спросить примерные объемы netflow трафика, пакетов или мб в сек..

среднесуточный объем каталога flow-tools с максимальным сжатием составляет порядка 350-400Mb и количеством записей ~ 20'000'000

я думаю что проблема в этом:

т.к. flow-fanout работает с flow-tools в рамках одной VPS и OpenVZ как бы не при делах, а вот как только Вы начинаете слать из одной VPS в другую - в дело включается OpenVZ и хост-машина кои могут так или иначе сказаться на результатах ... запустите все на одной VPS-ке и проверьте, так данные тестов будут более точными ...

у нас стоит flow-tools в сутки собирается примерно 8-10Гиг логов

и мы не извращаемся и честно храним их все, и вам советуем

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

ни каких fanout мы не делаем (зачем грузить 2 раза проц/диск)
логи пишет отдельная машина (которая занимается только этим) на локальный диск и раз в час они скриптом переносятся по NFS на сервер и этим же скриптом конвертятся в формат БГ и кладутся БГ в правильную директорию, после чего дергается БГ что бы он загрузил лог за час. Все файлы лежат на NFS сервере и доступны и с БГ и с машин которые пишут лог.

так и мы идем к тому чтобы не использовать fanout, т.е. у нас есть первичный коллектор flow-tools, а отсюда уже и бгбиллинг должен скакать, т.е. мы его должны "скакать" в виде подсовываемых данных о трафике