Билинг для 300-500 абонентов.

[Abram 98]

и еще один камень: вы предлагаете любой дистр при установке абиллса. но при этом ваш админ собирает из исходников основные компоненты (радиус сервер тот же). а как потом обновлять эту систему?

Вот за это убивать надо.

[sanyadnepr 305]

 

 

Вопрос открыт. Какие тренды сейчас в биллингах?

Зачем переезжать ? Есть с ноденни серьёзные проблемы ?

Перестал он удовлетворять нашим (моим) требованиям. Хочется значительно большего. Пока смотрели на Нодени+, но есть многооооо вопросов к нему.

 

Почему бы не огласить список потребностей ? А то както ни о чем.

[~AsmodeuS~ 34]

 

и еще один камень: вы предлагаете любой дистр при установке абиллса. но при этом ваш админ собирает из исходников основные компоненты (радиус сервер тот же). а как потом обновлять эту систему?

Вот за это убивать надо.

 

 

 

во первых из исходников собирается только одна программа и то только на линуксе это  freeradius,  а собирается она потому что perl собран в дистрибутиве с потоками а freeradius без потоков, так что с убийством обращайтесь к создателям дистрибутивов

[~AsmodeuS~ 34]

 

стандартная ситуация для серверов доступа которые не могу делать Accounting-On / Accounting-Off

для решить эту проблему есть утилита autozh.pl  её устанавливаете в автозагрузке и она при поднятии сервера скидывает сессии в зап

 

http://abills.net.ua/wiki/doku.php/abills:docs:faq:ru?posle_perezagruzki_servera_dostupa_sessii_vse_esche_visjat_v_billinge

хм. а когда мы были у вас на ком поддержке (где то год-полтора назад), об этом скрипте никто ничего не сказал/не сделал.....

 

 

 

 

возможно у Вас было какое то другое решение  этой проблемы

[Abram 98]

~AsmodeuS~,

FreeRADIUS в git-е лежит готовый для сборки пакетов. В Debian, например, можно прямо в исходниках FreeRADIUS сказать dpkg-buildpackage -b и получить на выходе пакеты.

[~AsmodeuS~ 34]

~AsmodeuS~,

FreeRADIUS в git-е лежит готовый для сборки пакетов. В Debian, например, можно прямо в исходниках FreeRADIUS сказать dpkg-buildpackage -b и получить на выходе пакеты.

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

[Abram 98]

~AsmodeuS~,

Да без проблем. Соберите опять новые пакеты. Можно даже организовать свой репозиторий и подключать его у клиентов.

[NiTr0 583]

 

 

Ммм, я говорил таблица пустая. Наполним, будем смотреть.

dv_calls не наполняется... dv_log - да, но туда записи попадают уже сильно опосля...

 

 

 

если они пропали с мониторинга, то на следующем алайве они опять там будут если за это время были выданы эти ип еще кому то они тоже появятся в мониторинге и система скинет дубликаты ип все ь процесс заёмёт 1 алайв период (это для провайдеров до 5 тис онлайн 5 минут больше 5 тис 10 минут) в любом случае єто быстрее чем перезагружать демон и всех скопом заставлять по новому авторизоваться

Давно появился сброс клиентов с дублирующимися адресами? Я что-то не замечал такого в коде...

 

 

 

во первых из исходников собирается только одна программа и то только на линуксе это freeradius, а собирается она потому что perl собран в дистрибутиве с потоками а freeradius без потоков, так что с убийством обращайтесь к создателям дистрибутивов

CentOS - все прекрасно работает искаропки. Debian - тоже все завелось искаропки в более-менее актуальной версии (в старых типа 0.51 - там да, радиус крашился по причине того что используются глобальные переменные типа $db, в то время как $db должна быть уникальной для каждого потока).

[~AsmodeuS~ 34]

 

Ммм, я говорил таблица пустая. Наполним, будем смотреть.

dv_calls не наполняется... dv_log - да, но туда записи попадают уже сильно опосля...

 

 

 

если они пропали с мониторинга, то на следующем алайве они опять там будут если за это время были выданы эти ип еще кому то они тоже появятся в мониторинге и система скинет дубликаты ип все ь процесс заёмёт 1 алайв период (это для провайдеров до 5 тис онлайн 5 минут больше 5 тис 10 минут) в любом случае єто быстрее чем перезагружать демон и всех скопом заставлять по новому авторизоваться

Давно появился сброс клиентов с дублирующимися адресами? Я что-то не замечал такого в коде...

 

 

 

во первых из исходников собирается только одна программа и то только на линуксе это freeradius, а собирается она потому что perl собран в дистрибутиве с потоками а freeradius без потоков, так что с убийством обращайтесь к создателям дистрибутивов

CentOS - все прекрасно работает искаропки. Debian - тоже все завелось искаропки в более-менее актуальной версии (в старых типа 0.51 - там да, радиус крашился по причине того что используются глобальные переменные типа $db, в то время как $db должна быть уникальной для каждого потока).

 

 

1  проверка дубликатов ИП появилась ее летом billd смотрите

2  было более десятка прицидентов по этому решили сделать так, если кто то хочет завести свой реппозиторий  то может сделать но как показала практика собирать радиус и из исходников пока самый оптимальный вариант

[dimka88 19]

 

 

dv_calls не наполняется...

Там активные сессии и не только.

И вот пример:

mysql> explain SELECT c.framed_ip_address
    ->   FROM dv_calls c
    ->   INNER JOIN nas_ippools np ON (c.nas_id=np.nas_id)
    ->   WHERE np.pool_id in ( 1 )
    ->   GROUP BY c.framed_ip_address;
+----+-------------+-------+-------+---------------+------+---------+------+-------+-----------------------------------------------------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows  | Extra                                                     |
+----+-------------+-------+-------+---------------+------+---------+------+-------+-----------------------------------------------------------+
|  1 | SIMPLE      | np    | index | nas           | nas  | 6       | NULL |     1 | Using where; Using index; Using temporary; Using filesort |
|  1 | SIMPLE      | c     | ALL   | NULL          | NULL | NULL    | NULL | 30062 | Using where; Using join buffer                            |
+----+-------------+-------+-------+---------------+------+---------+------+-------+-----------------------------------------------------------+
 

А потом такие запросы

INSERT INTO dv_calls SET started=now(),
       lupdated        = UNIX_TIMESTAMP(),
       status          = '11',
       acct_session_id = 'IP',
       nas_ip_address  = INET_ATON('127.0.0.1'), tp_id='100', uid='10001', user_name='10001', framed_ip_address=167772311, nas_id='1';

И следом маленький фикс разработчика =)

unlock tables;

[sadmin 7]

во первых из исходников собирается только одна программа и то только на линуксе это  freeradius,  а собирается она потому что perl собран в дистрибутиве с потоками а freeradius без потоков, так что с убийством обращайтесь к создателям дистрибутивов

во всех дистрах такое ? (centos, debian, ubuntu)

возможно у Вас было какое то другое решение  этой проблемы

нет, не было. и про скрипт ничего никак никто не знал. Відредаговано 2014-11-04 11:23:04 sadmin

[Maxxx 444]

 

 

Вопрос открыт. Какие тренды сейчас в биллингах?

Зачем переезжать ? Есть с ноденни серьёзные проблемы ?

Перестал он удовлетворять нашим (моим) требованиям. Хочется значительно большего. Пока смотрели на Нодени+, но есть многооооо вопросов к нему.

 

Добавлю еще. Техподдержки просто нету.

[Батон 1]

А озвучте, пожалуйста, если не большой секрет, ваши требования. Хотя бы тезисно. И нам интересно, насколько ваши требования совпадают с нашими (как вы говорите - "в тренде"), ну и людям совет вам дать наверное легче будет.

[NiTr0 583]

 

 

Там активные сессии и не только.

Угу, активные сессии. 2-3к записей для БД - пшик... Даже если бы вообще индексов не было.

 

 

 

И следом маленький фикс разработчика =)

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

[Abram 98]

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

IP ищется при авторизации, а вносится при первом аккаунтинге. Возможен вариант, когда авторизация придёт, а аккаунтинг - нет (NAS по каким-либо причинам не поднял сессию - например, в случае PPP не согласовал с клиентом шифрование, в случае DHCP - клиент не откликнулся на OFFER).

[NiTr0 583]

IP ищется при авторизации, а вносится при первом аккаунтинге.

Ну сессия создается при авторизации, занимая ип. Если аккаунтинг не пришел - сессия умирает. Если я ничего не попутал в алгоритме (давно ковырял код). Відредаговано 2014-11-04 18:07:15 NiTr0

[~AsmodeuS~ 34]

 

во первых из исходников собирается только одна программа и то только на линуксе это  freeradius,  а собирается она потому что perl собран в дистрибутиве с потоками а freeradius без потоков, так что с убийством обращайтесь к создателям дистрибутивов

во всех дистрах такое ? (centos, debian, ubuntu)

.

 

 

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

[Abram 98]

 

IP ищется при авторизации, а вносится при первом аккаунтинге.

Ну сессия создается при авторизации, занимая ип. Если аккаунтинг не пришел - сессия умирает. Если я ничего не попутал в алгоритме (давно ковырял код).

 

А должна создаваться при первом Accounting.

Когда-то с этим была проблема; был даже от тебя патч.

У я себя решил так: есть с IP-адресами, где записывается время последней выдачи адреса. Адрес считается свободным, если его нет в dv_calls и последняя выдача была больше n секунд назад.

Таблица полностью сразу заполняется адресами и update-ится только время выдачи.

Из всех рассмотренных вариантов этот оказался самым быстрым. Коллизии возможны, но крайне маловероятны.

[NiTr0 583]

в дебиан и в убунту так в других были прицеденты

В дебиане все как раз вполне хорошо. Прецеденты были из-за глобальных переменных БД, которые несовместимы с многопоточным перлом. Из-за чего и собирался радиус без потоков вручную.

 

А должна создаваться при первом Accounting.

Почему? Почему бы не внести сессию в БД, со статусом "в процессе"?

 

У я себя решил так: есть с IP-адресами, где записывается время последней выдачи адреса. Адрес считается свободным, если его нет в dv_calls и последняя выдача была больше n секунд назад. Таблица полностью сразу заполняется адресами и update-ится только время выдачи.

А теперь ситуация - клиент начинает долбить авторизацию в 100500 потоков, но не согласовывается с сервером и режектится. В случае с записями таблице сессий - в худшем варианте займется N адресов по кол-ву брасов (при реконнекте на брас клиента с тем же CID/логином ему выдается старый ип), в твоем случае - засирается временный пул адресов.

 

Коллизии возможны, но крайне маловероятны.

А чтобы их не было - и используется лок.

[dimka88 19]

Угу, активные сессии. 2-3к записей для БД - пшик... Даже если бы вообще индексов не было.

Вы так не шутите. Для одного запроса в секунду вернет 2-3к строк, а для 300 запросов в секунду 300*2к или 3к , то есть не мало. Не самый оптимальный алгоритм, постоянно дёргать базу, ей и так есть чем заниматься.

И вопрос, какова вероятность образования deadlock?

 

 

А чтобы их не было - и используется лок.

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

Відредаговано 2014-11-05 06:23:39 dimka88

[sadmin 7]

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

Получается, что вы даже не пытались. А достаточно 2 дистра основных проверить - и все.

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

Это похоже на профессионализм? Это у вас такая "реклама"?

[~AsmodeuS~ 34]

 

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

Получается, что вы даже не пытались. А достаточно 2 дистра основных проверить - и все.

 

 

 

Мы пытались но список дистрибутивов не вели так как ситуация когда не стратует  или после обновление все просто падает, а клиенты в большинстве случаев не разбераются в проблеме, а сразу наезд идёт что все плохо биллинг не работает и все и клиент звонит 10 раз в "час что всепропало"  потом оказывается он просто переустановил биллинг или обновил его и не посмотрел как все собрано. И это у каждого 3 клиента с линуксом такая ситуация. И выходило что по пару часов день нужно просто объяснять клиентам что они не правы, на что слышать это все фигня давайте чтобы все работало.

 

 

 

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

Это похоже на профессионализм? Это у вас такая "реклама"?

 

 

 

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

Хотя если  честно не могу онять что у Вас с обновлением не работает, все должно чётко обновиться без проблем

[madf 279]

... Не самый оптимальный алгоритм, постоянно дёргать базу, ей и так есть чем заниматься.

Да ну? А разве это не задача базы - слушать вопросы и отвечать на них? Чем это ей еще заниматься?

 

И вопрос, какова вероятность образования deadlock?

...

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

[~AsmodeuS~ 34]

 

 

IP ищется при авторизации, а вносится при первом аккаунтинге.

Ну сессия создается при авторизации, занимая ип. Если аккаунтинг не пришел - сессия умирает. Если я ничего не попутал в алгоритме (давно ковырял код).

 

А должна создаваться при первом Accounting.

Когда-то с этим была проблема; был даже от тебя патч.

У я себя решил так: есть с IP-адресами, где записывается время последней выдачи адреса. Адрес считается свободным, если его нет в dv_calls и последняя выдача была больше n секунд назад.

Таблица полностью сразу заполняется адресами и update-ится только время выдачи.

Из всех рассмотренных вариантов этот оказался самым быстрым. Коллизии возможны, но крайне маловероятны.

 

 

Занесения адресса при аккаунтенге плохой пример, может работать у маленьких провайдеров до 1000-2000 абонентов. У провайдеров с 10 тис онлайн за время между авторизацией и аккаунтингом может пролезть десяток абонентов с уже занятыми адреса.  И всем им в лучшем случае напишет что  не могу подключиться в худшем будет по несколько абонентов с одним и тем же адресом и будут разрывать тех поддержку с вопросом почему у меня нет интернета. А тех поддержка не очень скоро как показал практика может отследить такую проблему. В ABillS такие ситуации исключены  но если даже и возникает дубликаті адресов отмечаются для удобства понимания ситуации.

[Abram 98]

 

У я себя решил так: есть с IP-адресами, где записывается время последней выдачи адреса. Адрес считается свободным, если его нет в dv_calls и последняя выдача была больше n секунд назад. Таблица полностью сразу заполняется адресами и update-ится только время выдачи.

А теперь ситуация - клиент начинает долбить авторизацию в 100500 потоков, но не согласовывается с сервером и режектится. В случае с записями таблице сессий - в худшем варианте займется N адресов по кол-ву брасов (при реконнекте на брас клиента с тем же CID/логином ему выдается старый ип), в твоем случае - засирается временный пул адресов.

 

Коллизии возможны, но крайне маловероятны.

А чтобы их не было - и используется лок.

 

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

Не проблема, записывай вместе с блокировкой IP сразу и UID, кем он заблокирован. При повторной попытке авторизации если за пользователем (или наверное правильнее за UID+CID) есть уже заблокированный, но не используемый IP - выдавай его же повторно.

Занесения адресса при аккаунтенге плохой пример, может работать у маленьких провайдеров до 1000-2000 абонентов. У провайдеров с 10 тис онлайн за время между авторизацией и аккаунтингом может пролезть десяток абонентов с уже занятыми адреса.

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