>> 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. >> Alan is saying a single MySQL instance is fragile because it's a single point of failure.
Clustered SQL is bad because the synchronization delays could lead to conflicting lease allocations (Conflicted IP addresses etc). The solution (if you're using a pool of addresses) is to split the range and have each RADIUS server allocating a different part of the range. Then there's no chance of the servers allocating duplicate leases even in a clustered SQL environment. >> >>> 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, > you mean splitting pool by NASes and radius server?... then sqlippool > is not really needed anymore? >> and the accounting >> replication doesn't need as many pieces. >> > OK, i trust you but I don't see any chance of having no SQL enabled > accounting. It's almost a requirement for me. You want to use rlm_detail to spool out your accounting packets to a flat file, then read them back in using a virtual server instance. There are examples included with the server. This gives you a *huge* buffer, in case of catastrophic power failure, or SQL database failure. The RADIUS server will just keep spooling out Accounting packets to the flat file until the detail file reader can insert them into the SQL database. We use it and it works very well. If you use MySQL with the InnoDB engine, writing to the accounting database that you web application queries should not have a dramatic effect on the time taken for select queries to complete. This is because the InnoDB engine uses a row based locking scheme, as opposed to a table based locking scheme. Arran >> Alan DeKok. >> - >> List info/subscribe/unsubscribe? See >> http://www.freeradius.org/list/users.html >> >> > ------------------------------------------------------------------------ > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html