Alan DeKok a écrit : > 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. > > Right, nothing will query the database directly on radius servers. But i really need to have one central database that will be queried by webapps to let users know about thier quota left, time of connection etc... >> 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. > >
Does this central radius server can log all queries proxied to him to an sql database (i know i'm boring with SQL accounting database! :)) If i read you well... it 's not! Am i asking too much from SQL? how else can we achieve it? >> 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, 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. > 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