Новый биллинг. Вопросы.

[dolphinik]

Не сочтите за рекламу.

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

Интересно ваше мнение по поводу возможностей (http://www.expertbilling.ru/page/functionality.html). Чего вам бы хотелось добавить или изменить.

Edited May 8, 2009 by dolphinik

[IvanI]

1 сертификат

[SmokerMan]

А деньги?... :-)

[jab]

 

Только линузятники могли додуматься назвать свой биллинг "Ёбс!"

[dolphinik]

Коротко, легко, запоминаемо :)

По поводу сертификата - это уже больше организационный момент. Интересует именно запрос функционала.

Edited May 5, 2009 by dolphinik

[Makariy]

1) какое количество пользователей сможет держать биллинг при скажем 60 мегабитном канале загрузкой 80 %

2) если в базу собирается детальная статистика то каковы методы её очистки (архивации)

3) вопрос перехода (конвертации БД) из других биллинговых систем

4) реализация платежей через терминалы

 

 

[dolphinik]

1) Сами понимаете, что всё зависит от железа. На 2-ядерном core duo и 8 ГБ оперативной памяти(конфигурация явно "навырост")

 

top - 16:12:41 up 54 days, 4:44, 2 users, load average: 0.70, 0.61, 0.41

Tasks: 79 total, 1 running, 78 sleeping, 0 stopped, 0 zombie

Cpu(s): 1.8%us, 0.0%sy, 0.0%ni, 98.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Mem: 8301980k total, 1999784k used, 6302196k free, 14976k buffers

Swap: 979956k total, 60k used, 979896k free, 1747360k cached

 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

26459 root 20 0 89912 39m 3432 S 1 0.5 201:23.16 nf

10861 root 20 0 27272 10m 3552 S 1 0.1 125:00.70 rad

10908 root 20 0 75076 9708 3384 S 1 0.1 154:37.65 nfroutine

13934 root 20 0 94980 12m 3688 S 3 0.2 327:52.46 core

 

+ от 1 до 35% процессорного времени в пике отнимает сама СУБД.

 

По памяти:

Mem: 8301980 2010688 6291292 0 22960 1750080

-/+ buffers/cache: 237648 8064332

Swap: 979956 60 979896

 

У PostgreSQL размер shared-буферов установлен в полтора гигабайта, чтобы меньше сношались диски.

600 абонентов в базе, в данный момент активно около 200. Ширина канала 50 мегабит. Загрузка в момент top около 50%.

 

Информация о количестве NetFlow статистики по классам считается и пишется, но запись самой NetFlow статистики отключена. С её агрегацией и записью получается 15-20% загрузка процессора постоянно.

 

Работа с БД из ядра системы сведена к необходимому минимуму за счёт адаптивного кэширования, поэтому производительности на этом железе должно хватить и на 10 000 абонентов.

 

Месяц назад нагрузочное тестирование по числу RADIUS авторизаций дало следующие результаты:

Машина Duron 1.8 Ггц

1 ГБ DDR II

HDD Samsung 320GB

 

CHAP Auth: ~560/s

MSCHAP2 Auth ~420/s

Radius Acc ~500-700/s (в зависимости от типа пакета )

 

2) Для хранения статистики в базе используется технология партишенов. Вся статистика разбивается в отдельные таблицы по дням (или месяцам в зависимости от типа статистики). Т.е. вы банально удаляете таблицу со старой статистикой, которая вам не нужна. или делаете дамп этой таблицы с помощью pg_dump.

3) Пока не решён.

4) Сейчас есть ОСМП. Говорите что нужно. Этот вопрос можно оперативно решить.

 

 

[Makariy]

хм... интересно

а вот скажем такой функционал:

не хочется гонять локалку по NAS-ам, хочется гонять по свитчам

на доступе (подъезд) Dlink 1008D/RW <-> (дом) RUBYtech 2108 ES-2310C <-> (район) Dlink 3627

городской контент (игры, фтп, торенты в сети NAS) адреса статика по DHCP (+ маршруты по DHCP) , /24 IPN на дом

абонент с отрицательным балансом видит только личный кабинет

ИТОГО: ???? валюта по умолчанию

[vop]

Сразу пожелания, что бы избежать ловушек.

 

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

2. Не превращайте клиента в ip-адрес.

3. Ну и в общем, отделяйте учет клиентов и денег от управлением доступа.

 

[dolphinik]

хм... интересно

а вот скажем такой функционал:

не хочется гонять локалку по NAS-ам, хочется гонять по свитчам

на доступе (подъезд) Dlink 1008D/RW <-> (дом) RUBYtech 2108 ES-2310C <-> (район) Dlink 3627

городской контент (игры, фтп, торенты в сети NAS) адреса статика по DHCP (+ маршруты по DHCP) , /24 IPN на дом

абонент с отрицательным балансом видит только личный кабинет

ИТОГО: ???? валюта по умолчанию

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

 

[Giga-Byte]

на сайте расчет цены до 1000 абонентов с маленьким интервалом :)

а если надо на 1126 абонентов ?

 

ну и как-то не хорошо считать деньги по netflow,

который может прийти с опозданием,

когда обработчик netflow уже не знает что за юзер с таким-то адресом.

 

рассмотрите реализацию учета трафика от mpd5:

As example you can write in your RADIUS configuration something like:

mpd-filter += "1#1=nomatch dst net 10.0.0.0/24",

mpd-filter += "1#2=match dst net 10.0.0.0/8",

mpd-filter += "2#1=nomatch src net 10.0.0.0/24",

mpd-filter += "2#2=match src net 11.0.0.0/8",

mpd-limit += "in#1=flt1 pass",

mpd-limit += "in#2#Biz=all shape 64000 4000",

mpd-limit += "out#1=flt2 pass",

mpd-limit += "out#2#Biz=all rate-limit 1024000 150000 300000",

 

As result, one ng_bpf node will be created to implement traffic filters and several (two for this example) ng_car nodes for traffic shaping and rate-limiting. Incoming traffic from 10.0.0.0/8 except 10.0.0.0/24 will be passed, other traffic will be shaped to 64Kbits/s. Outgoing traffic to 10.0.0.0/8 except 10.0.0.0/24 will be passed, all other will be limited to 1024Kbit/s. Also traffic that passed mpd-limit rules marked "Biz" will be accordingly accounted and present with that name in AAA accounting requests.

http://mpd.sourceforge.net/doc5/mpd30.html#30 - последний абзац

Edited May 6, 2009 by Giga-Byte

[dolphinik]

При количестве абонентов >1000 цена не изменяется.

Наш обработчик знает у каких абонентов какие адреса. Не очень правильно производить тарификацию через RADIUS Accounting, если он не позволяет считать трафик в разные сети отдельными счётчиками. Как в таком случае посчитать отдельно трафик в другие сети/на локальные ресурсы/в интернет? NetFlow даёт более детальную картину происходящего нежели аккаунтинг протокола RADIUS.

То, что вы показали про mpd, безусловно, интересно, но это его фирменная "фишка", которой в других pptp серверах, и в частности на микротике, нет.

[Giga-Byte]

Наш обработчик знает у каких абонентов какие адреса. Не очень правильно производить тарификацию через RADIUS Accounting, если он не позволяет считать трафик в разные сети отдельными счётчиками. Как в таком случае посчитать отдельно трафик в другие сети/на локальные ресурсы/в интернет? NetFlow даёт более детальную картину происходящего нежели аккаунтинг протокола RADIUS.

То, что вы показали про mpd, безусловно, интересно, но это его фирменная "фишка", которой в других pptp серверах, и в частности на микротике, нет.

верю что знает, и наверное не даёт этот освободившийся адрес в течение некоторого времени.

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

а мне не нужен микротик на 1000 абонентов.

 

хорошо, тогда поясните следующее по netflow.

есть льготная зона, например локальная сеть.

пользователь обменивается данными между другим пользователем.

допустим, трафик идёт между 10.10.20.20 и 10.10.30.30

как ваш коллектор узнаёт, какому пользователю засчитать трафик за входящий, а которому за исходящий?

 

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

[dolphinik]

Для того, который числится в src_ip это будет исходящий, для второго входящим. Коллектор это определяет сам.

[Giga-Byte]

Для того, который числится в src_ip это будет исходящий, для второго входящим. Коллектор это определяет сам.

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

 

[dolphinik]

Не захотите считать входящий/исходящий межабонентский трафик - создадите группу с соответствующими настройками. Это всё очень гибко настраивается :)

[offtop]

а вообще сертифицировать думаете? и как скоро?

[Kostyan]

Для продукта под продажу в первую очередь нужен сертификат.

По продукту - судя по картинкам на пользователя/договор можно завести всего 1 IP, что не есть правильно. так же неувидел возможности вешать несколько услуг/тарифов.

[dolphinik]

а вообще сертифицировать думаете? и как скоро?

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

Пока в планах сертификация на сентябрь-ноябрь.

 

>По продукту - судя по картинкам на пользователя/договор можно завести всего 1 IP, что не есть правильно.

В каких случаях требуется больше одного IP?

 

>так же неувидел возможности вешать несколько услуг/тарифов.

Это пока не реализовано, но есть в планах на ближайшие пару месяцев.

 

 

[Kostyan]

>По продукту - судя по картинкам на пользователя/договор можно завести всего 1 IP, что не есть правильно.

В каких случаях требуется больше одного IP?

1. Второй и более ПК у пользователя и он нехочет ставить у себя роутер.

2. Юрики - 1 договор, несколько адресов подключения

...

[dolphinik]

>Второй и более ПК у пользователя и он нехочет ставить у себя роутер.

А платит как за 1 аккаунт или как за 2?

 

Со вторым пунктом всё понятно.

[~AsmodeuS~]

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

 

Какие преимущества перед другими системами ?

[dolphinik]

Ув. Asmodeus, если вы почитаете начало топика, то увидите что спрашивалось именно по поводу функционала, а не сертификатов и лицензий.

 

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

 

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

 

Если бы у вас была возможность заглянуть внутрь - я думаю вам самими стало бы всё ясно.

 

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

 

К слову, сейчас для абонентов пишется клиентский агент.

Edited May 7, 2009 by dolphinik

[vIv]

К слову, сейчас для абонентов пишется клиентский агент.

Мне, пожалуйста, для Amino 110 не забудьте написать. Когда допишете, я для Popcorn Box тоже попрошу.

 

Серьёзно: розетка "Интернет" ДОЛЖНА!!!! ДАВАТЬ!!!!! интернет! Сунул патчкорд - и есть интернет. Какой, ломом через забор, "клиентский агент"?!

[dolphinik]

Уважаемый, без истерик :)

Клиентский агент - это такая удобная програмка, которая висит в трее показывает баланс и другую интересную информацию.