Below is our old aaa design. We first begin with radiator as radius server. Problems with radiator are;
1 – Require single line from database, this means uses a single line row and multiple columns for user definition in the database. Thus adding new attributes requires table update (subscriber table) and also radiator configuration update. You can use advance radiator configuration like multiple select statement for each user attribute but this will result unnecessary database traffic.
2 – Multithread problem of radiator, actually perl.
For the performance issue we just use multiple radiator behind a proxy server which is used for load balancing. For the proxy radius we are using freeradius which much more faster than radiator (even in simple proxy configuration). Each radiator has its own subscriber table. All tables are replicated from a central subscriber table, this may result in unsync data between the radiator servers. But for the session table, we are using central database build on postgresql.
We are planing to upgrade system to freeradius and mysql based fully geo redundant configuration.
On this approach;
freeradius is used for AAA server;
– Multitread, much more better performance
– Multiple row for each subscriber, easy to deploy new subscriber attributes
– Easy to deploy additional aaa features like quota server
mysql cluster is used for subscriber authentication and accounting ;
– Better geo redundancy with mysql cluster integration
– Second mysql server with archive engine is used for data backup. Simple script is used to delete all old accounting data from the central mysql cluster. Archiving is done at the radiator level, freeradius replicate-to-realm feature is used to send all accounting data to another freeradius+mysql (with archive engine) nearly zero performance degradation in the main system. Also this kind of approach can be used for session table.
Freeradius archiving :