Обновился пакет FreeRADIUS

Еще бы FreeNibs подтянуть...

Гы-гы, в пятёрку... Их всего штук 6 (не считая совсем убитых поделок).

А вот интересно, имеет ли кто-то из здесь обитающих опыт использования FreeRADIUS для серьезных задач, точнее для авторизации dialup/vpn/VoIP под более менее сереьзной нагрузкой? И каковы впечатления от его стабильности и функциональности?

> И каковы впечатления от его стабильности и функциональности?

Никакие. Используем OpenRADIUS как более модульный и универсальный. Да и нагрузку он держит намного лучше. Сейчас средняя загрузка _одного_ сервера с SQL backend-ом (PostgreSQL) -- 10-20 PPPoE авторизаций, 50-70 событий аккаунтинга, 10-20 POP3|IMAP и 5-10 SMTP AUTH в _секунду_.

> 10-20 PPPoE авторизаций, 50-70 событий аккаунтинга, 10-20 POP3|IMAP и 5-10 SMTP AUTH в _секунду_

Не хило так. Даже боюсь спросить сколько у вас клиентов. Хотя, по приблизительным подсчетам, если прикинуть, где-то несколько тысяч наверно

Вроде уже год как под нагрузкой, проблем почти нет, есть свой модуль. Нагрузка dialup/VoIP побольше чем у предыдущего раз в 5.

Раз в пять это 50 - 100 авторизацтий в секунду? И, соответсвенно надо предположить не менее 2000 - 3000 одновременных сессий, несколько десятков тысяч аккаунов? Солидно. А биллинг Вы используете самописный или что-то готовое сопрягли с FreeRADIUS? И СУБД какая c FreeRАDIUS? Postgres? Accounting в него пишете? Не падало?

> Никакие. Используем OpenRADIUS как более модульный и универсальный. Да и нагрузку он держит намного лучше. Сейчас средняя загрузка _одного_ сервера с SQL backend-ом (PostgreSQL) -- 10-20 PPPoE авторизаций, 50-70 событий аккаунтинга, 10-20 POP3|IMAP и 5-10 SMTP AUTH в _секунду_.

У Вас при этом hot-billing? Если нет, то это не нагрузка.

AFAIR для реализации нестандартных вещей OpenRADIUS для обработки каждого пакета вызывает внешний процесс (фактически запускает отдельную программу, на stdin которой передаются исходные данные из пакета а со stdout-a снимаются результаты). При этом при каждом вызове внешняя программа должна соединиться с постгресом, что-то в нём сделать и отдать результат. Так?

У FreeRADIUS-a - модули в виде динамических библиотек. Модуль работы с БД может сделать коннект к базе _один_ раз при старте сессии и обработку данных вести с этим открытым хендлером/сокетом БД, не затрачивая времени на установление соединения с БД. Да и в FR всё реализовано на тредах, а породить новый тред дешевле, чем процесс. Так что по поводу того, что OR держит нагрузку лучше, чем FR в плане скорости обработки я сомневаюсь. У OR одним из архитектурных достоинств является то, что если в модуле обработки бизнес-логики есть ошибка, то максимум раком встанет один процесс, а сервер останется жить. В FR если раком становится модуль, очень вероятно, что гплык и серверу.

> У Вас при этом hot-billing? Если нет, то это не нагрузка.

Да, биллинг полностью в реалтайме. И я, оказывается, не те цифры посмотрел. ;) Это не запросов в секунду, а количество конкурентных (одновременно обрабатываемых). В секунду их на пару порядков больше.

> AFAIR для реализации нестандартных вещей OpenRADIUS для обработки каждого пакета вызывает внешний процесс (фактически запускает отдельную программу, на stdin которой передаются исходные данные из пакета а со stdout-a снимаются результаты). При этом при каждом вызове внешняя программа должна соединиться с постгресом, что-то в нём сделать и отдать результат. Так?

Нет. В OpenRADIUS все обработчики префоркаются при старте, устанавливают соединение с базой (один раз), а затем в цикле обрабатывают запросы из пайпа. Обработчики нагружаются round-robin. В том, что OR построен на процессах, а не на тердах, я вижу его основное преимущество. Он лучше массштабируется. Да и ошибки изолировать намного проще. Как Вы правильно сказали, смерть одного процесса не критична: ядро OR перезапустит обработчик.

>> У Вас при этом hot-billing? Если нет, то это не нагрузка.

> Да, биллинг полностью в реалтайме. И я, оказывается, не те цифры посмотрел. ;) Это не запросов в секунду, а количество конкурентных (одновременно обрабатываемых). В секунду их на пару порядков больше.

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

можно в почту olegg at ukrpack.net