Алгоритм биллинга

[mlevel]

Роботаю над биллингом, задачу написания ядра немогу додумать. Как лучше организовать его роботу: в виде запущеного демона или запускать по крону? И вообще какие основние задачи полагаються на ядро распеделенного биллинга? Просьба не ругать, а лучше по возможности дать что-то на почитать на ету тему. Спасибо!

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Гость]

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

вы разработчик, вам и решать, а иначе просто не беритесь

[ADRE]

хмм.... мнебы хотелось чтобы биллинг накручивал мне деньги на сотовом, а не только пакеты считал...

[Soldier]

Ясное дело - лучше службой.
Я просто не понимаю, как можно отрабатывать по крону. Ну сформировалась флоу-статистика за 15 минут, ну считал ты её, спирсал деньги и ждем новые 15 минут.
Клиент сидит на помегабайтной оплате, скорость у него 20 мбит/с. На балансе осталось рублей 15. Стоимость рдного мб, скажем, 0,7 рубля. Он качнул с торрента порнуху, ушел в минус и деньги ты с него не возьмешь, он тупо платить не станет, за предъявленный счет. Это уже пройденный этап.

Пиши биллинг как службу и соблюдай модульность.

[ADRE]

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

[Soldier]

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

Ну начнем с того, что на формирование флоу-статистики сервером доступа тоже уходит время. И в реальном времени обсчитать трафик может даже такой хлам как УТМ.
При этом, желательно, чтобы машина под биллингом обсчитывала только трафик и больше ничего (никаких на ней баз, серверов доступа, мониторинга, вэб и прочего).
Есть еще вариант - Поднять машину, которая считает трафик отдельно, а потом инфу кидает на биллиинг, но это будет лишним гемором и в реальном времени посчитать и отрезать не удастся.

[ADRE]

Есть еще вариант - Поднять машину, которая считает трафик отдельно, а потом инфу кидает на биллиинг, но это будет лишним гемором и в реальном времени посчитать и отрезать не удастся.

а такую чтуку как sntp на свиче?

[ADRE]

snmp )

[Soldier]

snmp )

угу. Хорошая штука. Только есть 2 но(!).
Есть у тебя локалка размером с город. Покупал ты циски, работал у тебя биллинг с цисками идеально. Раз пришла партия трикомов. Что делать? Перегонять весь биллинг на работу с уже 2мя типами железок? А потом железка-циска сломалась и решил её заменить трикомом. Ох и геморно это. Реализация страшная.

А еще вариант - руководство решило урезать бюджет и приобрело свитчи с которых трафик ну ни как не снимишь. Свитчи управляются, но трафик не снимается.

Или еще лучше - Сетка не полностью управляема или вообще неуправляема. Тогда что? нарезать трафик с роутера - какой-нибудь циски которая загнется от такой нагрузки.

snmp - протокол управления сетью, но его не всегда реально применить. Тем более, что топикстартер не указал как у него сеть собрана и что в ней живет.

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

[ADRE]

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

[mlevel]

Интересно, как ето в real time считать трафик получается? Дамп сбрасываеться раз в ~минуту + учитываем время на обработку данных + время на обновленйе статусов и блокировку абонента. Да и по SNMP не серйозно считать трафик на свитчах...

[ADRE]

ну варианты - разные: фаер, сисько, приблуды к фаерам, нетфлоу.

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

[mlevel]

Если сисько или другие железки, то там есть нетфлоу, на софтовом роутере - ipcad, ng_netflow + flow-tools, ng_ipacct. Имхо фаером считать трафик неудобно + ресурсозатратно + нет нужной детализации. А чтобы не уйти в минус, наверное нужно расчитивать возможний скачаний трафик и сравнивать с балансом на счету, и блочить немного заранее .

[ADRE]

немного заранее заблочишь клиенты в панику кинутся лучше маленький минус чем большой плюс, канал заузить не получиться? типа осталось 5метров ->скорость 33.6 кбс _)))
--
ты сам ответил на свой вопрос. - демон лучше

[mlevel]

В принципе нормальный вариант, надо теперь подумать над реализацией.

-----
Да, сошелся на варианте с демоном..)
Но некоторые дополнительные задачи(например смена тарифа с 1-го числа и пр.) будут работать по крону.