ippool management and cluster

[Arran Cudbard-Bell]

>>   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