Alexandre Chapellon wrote:
Each radius have a local mysql database to locally store accounting data.
If nothing will be querying those databases, I suggest *not* using SQL. It's just not needed.
Each local database is replicated to a central database which couls be used too as a redundancy for accounting if the local one fail (more over centralized accounting database used to process customers request and/or complaints).
RADIUS packets can be replicated to the central server and logged there. Database replication will work, but will be a lot of load on the various systems.
One centralized mysql database (on another mysql server maybe) to handle IP allocation using rlm_sqlippool.
Again, using *one* database for *many* RADIUS servers is very likely wrong. i.e. it will be slow, fragile, and is likely to not meet your needs of high availability.
I have aproximatively 15000 users connected concurently. Does it seems to you a too weak or inefficient setup?
Do the math. 15K users, with one accounting packet every 10 minutes. That's 25 packets/s. It's a nice number, but not too high.
While my priority is high-availability
Some parts seem too complex, and others too simple. The IP pool allocation needs to be more robust, and the accounting replication doesn't need as many pieces. Alan DeKok.