ippool management and cluster

[Alexandre Chapellon]

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
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20080926/f3fcc787/attachment.html>