ru.cisco

 
 - RU.CISCO ---------------------------------------------------------------------
 From : Vladimir Kravchenko                  2:5020/400     29 Jul 2003  12:49:35
 To : Victor Sudakov
 Subject : Re: VoIP accounting: NAS asks RADIUS or vice versa
 -------------------------------------------------------------------------------- 
 

  >> Погоди, я теряю суть вопроса. Если биллинг упал, то он узнать уже
  >> ничего не сможет при всем желании, он лежит :)
  VS> Узнать он должен в момент своего поднятия после лежания.
 
 Hе должен, это ему не надо. Сесси которые не завершены (не получены Stop)
 должны оседать в биллинге в отдельных журналах. Биллинг имеет механизм либо
 ручного закрытия события, либо можно "впарсить" повторно радиусовский
 аккантинг за тот период когда были проблемы. Вообщем все это уже тонкости
 реализации API биллинга для сопряжения с внешними источниками данных, и это
 может быть не только радиус.
 
  >> 1) биллинг работает с RDBMS или другой DBMS 2) DBMS, если нам критично
  >> время downtime, должна иметь стенбай 3) биллинг в идеале - stored
  >> procedure (у нас пока это получается)
  VS> Что-то я сомневаюсь, что такой монстр окупится, разве что у тебя пулы
  VS> на десятки тысяч линий.
 
 Ерунда, в том что я написал выше нет ничего осбенного, это банальные
 вещи. И вложения тут ничем не больше любого другого биллингового решения,
 за тем лишь исключением что на мой взгляд нормального биллинга до сих пор
 не существует, во всяком случае для телефонии.
 
  >> 4) радиусов (tacacs) должно быть несколько 5) если DBMS (биллинг) таки
  >> в дауне то услуги не оказываются, во всяком случае те которые требуют
  >> ауторизации
  VS> То есть как только биллинг упал, всех принудительно сбрасываем с
  VS> пулов?
 
 Зачем? Состояние на момент падения биллинга валидно, если это не так, то
 биллинг баговый и место ему на очередной выставке, а не на площедке у
 ISP/ITSP. Коль скоро оно валидно то пусть народ работает, в тех пределах
 которые ограничены Session-Timeout/h323-credit-time/etc. Результаты
 окончaний этих сессий попадут в биллинг когда он поднимется.
 Это все уже дебри, чесно говоря я уже забыл про что изначально разговор
 был. Биллинг не должен падать, если он упал то это ЧП и все админы должны
 грести на работу поднимать биллинг.
 
  VS> Который www.openradius.net ? Спасибо, посмотрю.  Странно, что его в
  VS> портах FreeBSD нет.
  >> Угу. Там в порты то класть нечего, но если надо - сделаем :)
  VS> Hадо бы. Как минимум корректная регистрация пакета в системе уже
  VS> важна.
 
 Ты ведь наверняка сам знаешь как делается простенький порт? :)
 
  >> У него единственный на мой взгляд серьезный недостаток - не умеет
  >> reload config ala -HUP.
  VS> То есть при изменении users демон приходится перезапускать? А как
  VS> сохраняется state (например, информация о сидящих на пуле абонентах)
  VS> при перезапуске? Или state сохраняется не в самом радиусе?
 
 Hикак, не умеет, не поддерживает. В этом его рулезность, он ничего не
 умеет, он прост как веник. Что бы понять его рульность надо согласится хотя
 бы с частью тех мыслей что я излагал в этом и предыдущих письмах, и тогда
 становится понятным, что увеличение мозгов радиуса вкупе с кривыми руками
 пионеров увеличивают downtime и уменьшают адекватность системы по причине
 багов радиус сервера, а не биллинговой базы.
 
 Достатком openradius является то что у него адекватный и простой механизм
 подключения модулей, вся идеалогия работы радиус сервера укладывается в
 сценарий который пишется на его "языке" - behaviour. Все в твоих руках, как
 хочешь так и делаешь.
 
 Коль скоро зашел разговор, то выскажу свое большое "фе" в сторону
 freeradius и всех прочик клонов цистрона заточенных для работы с sql.
 
 1) какой дебил, интересно, решил что работа radius сервера с sql должна
 укладываться в идеалогию лингвистоновского users.db ? эта структура данных
 вообще для rdbms не применима, например, аккаунтинг который хранится в базе
 в виде отношения многие ко многим (атрибуты <- AV -> событие), атрибутов
 сотни, событий минимум десятки миллионов, AVPair в событии в районе 20 -
 чему равняется денкартово произведение ? Я теперь смертельный номер, надо
 отобразить 5 атрибутов по каждому событию в табличной форме, одна
 результирующая таблица, забыли про костыли и client side, чему равняется
 декартово произведения такой выборки? Это вообще было придумано для какой
 нагрузки? Для трех диалапных сессий в сутки?
 
 2) аналогичный дибилизм с аутентикацией и авторизацией, биллинг оперирует
 счетами, сервисами, тарифными планами, а не Check/Reply Pair, таким образом
 имея два query для получения Check и Reply соответсвенно, биллинг обязан
 выполнить один и тот же алгоритм дважды, только вернуть разные куски из
 результата своей работы. Бред, сивушный.
 
 3) Эти чуваки вообще RDBMS окромя mysql когда нибудь видали? А что такое
 SQL кеш они знают? похоже нет. Если впарсивать значения в sql query на
 уровне клиентского приложения, я не средствами Dynamic SQL, SQL miss rate
 будет 100%, для объема в 100-200 запросов к базе в секунду это труп любого
 сервака, ну пусть не труп, то процентов 30-50 процессоры бедного сервера
 будут заниматься парсингом SQL запросов. Труба.
 
 Hу дальше в этом духе я могу продолжать до бесконечности, проблеммы
 биллинга я думаю тут многим интесна в той или иной форме, но это обсуждение
 уже явно за рамки ru.cisco выходит :)
 -- 
 Vladimir Kravchenko / PK Mostcom JSC / system engineer
 Tel: +7 095 2312255 / UIN: 132038843 / Email: jimson@mostcom.ru 
 --- ifmail v.2.15dev5
  * Origin: Demos online service (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор