LANBilling vs UTM

[Guest]

Большая просьба к пробовавшим обе эти системы в реальной работе - поделитесь, пожалуйста, своими наблюдениями и впечатлениями. У меня сейчас стоит задача выбора биллинга под FreeBSD, весь в раздумьях. Особо интересует требовательность агентов, собирающих информацию о траффике с Ethernet к процессору и надежность их работы в плане отсутствия пропусков пакетов. Насколько я понимаю, обе системы производят сбор статистики через BPF, а это, по моим наблюдениям, не очень хорошо. Потери пакетов при учете траффика для меня весьма критичны, т.к. предполагается тарифицировать не только внешний траффик, но и внутрисетевой траффик между маршрутизаторами, а там потоки данных довольно приличные летят. Буду благодарен за любую информацию из практики использования этих систем.

[Guest]

Насколько могу судить, сетевые агенты lanbilling'а меньше грузят процессоры чем коллекторы utm. Это было проверено экспериментально.

[Guest]

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

[krab]

ipcad, например

[AlterDen]

У меня 3 машины с LanBilling'ом. Один с агентом для Киски, и два ethernet агента.

Сервер на котором для киски агент, у меня сложилось ощущение что больше 1-3%(P4-2400Mhz) не занимается никогда(ну кроме обработок отчетов суточных, запрос статистики и тп., и то это mysql загружает машину). Обмен у нас не быстрый но многопоточный+NAT. На этом серваке сидит 130 человек и 2Мб интернет. Полет нормальный

 

Один сервак Cel-1700 с eth-агентом

21:59:50 up 44 days, 6:51, 1 user, load average: 0.02, 0.02, 0.00

72 processes: 70 sleeping, 2 running, 0 zombie, 0 stopped

CPU states: 0.3% user, 0.3% system, 0.0% nice, 0.0% iowait, 99.2% idle

Mem: 256560k av, 251992k used, 4568k free, 0k shrd, 40516k buff

68608k active, 157452k inactive

Swap: 1662688k av, 22072k used, 1640616k free 151500k cached

 

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND

2788 root 9 0 5376 5272 380 S 0.1 2.0 167:53 LBcd

Тоже не напрягается, как видишь. 50 пользователей. вечерняя загрузка...

 

Мне нравится LB. И поддержка всегда подскажет. И стабильно пашет. Мы уже 3-й год на нем. Обновления, улучшения.

 

Не сочтите за рекламу, это просто взгляд пользователя.

А про UTM я не могу ничего сказать, тк. не знаю

[Guest]

У меня 3 машины с LanBilling'ом. Один с агентом для Киски, и два ethernet агента.

 

Это в трех разных местах стоят машины? Ну в смысле, зачем три ланбиллинга?

[AlterDen]

Это в трех разных местах стоят машины? Ну в смысле, зачем три ланбиллинга?

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

[stanm]

Насколько могу судить, сетевые агенты lanbilling'а меньше грузят процессоры чем коллекторы utm. Это было проверено экспериментально.

 

почти 2000 пользователей, 800ГБ в месяц , используется ndsad - его в top'e вообще почти не видно, а ядро жрет меньше ресурсов, чем NAT, который натит этот трафик.

 

Логичный, кстати, вопрос: а ты сохранение всей детальной статистики не пробовал в Лaнбилингe включать?

ИМХО, загнется он моментально.

А в UTM вся деталька по умолчанию сохраняется. Потому что БД для детальки специальная. А в лaнбилингe они эту детальку в SQL суют.

[Guest]

Это в трех разных местах стоят машины? Ну в смысле, зачем три ланбиллинга?

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

 

А на сколько там большой трафик от агентов? И что будет, если связь с агентом потеряется?

[MS]

А в UTM вся деталька по умолчанию сохраняется. Потому что БД для детальки специальная.

Это какая такая специальная?

[Guest]

А в UTM вся деталька по умолчанию сохраняется. Потому что БД для детальки специальная. А в лaнбилингe  они эту детальку в SQL суют.

 

Насколько необходима деталька в виде компонента биллинга с точки зрения начисления оплаты?

[mevg]

C точки зрения оплаты - совсем не нужна.

Но:

1. каждый второй клиент спрашивает -а поддерживает ли ваш биллинг ведение детальных логов?

2. разбор спорных случаев с клиентами провайдера. Обычно после предоставления детальной статистики большинство вопросов юзера снимаются.

[martini]

UTM в gigabase складывает статистику а потом МСКУЛ, кстати никто не придумал как на страничке клиента выдать детальную статистику в UTM5 ?

[stanm]

UTM в gigabase складывает статистику а потом МСКУЛ

 

несколько неверно. В gigabase сладывается детальная статистика. В мускул она никогда не попадает. В мускул складывается информация по списаниям, что есть по сути агрегированная статистика.

 

кстати никто не придумал как на страничке клиента выдать детальную статистику в UTM5 ?

Это не надо придумывать, оно и так есть.

http://www.netup.ru/index.php?news=52

 

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

 

Включается изменением настроек, описано в документации.

[Guest]

C точки зрения оплаты - совсем не нужна.

Но:

1. каждый второй клиент спрашивает -а поддерживает ли ваш биллинг ведение детальных логов?

2. разбор спорных случаев с клиентами провайдера. Обычно после предоставления детальной статистики большинство вопросов юзера снимаются.

 

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

 

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