FreeBSD anyone?

[Dusty Doris]

> Hi Dusty,
>
>> Now, I'm running freeradius 1.0.5 on freebsd 5.4.  We handle about 75,000 
>> logins per day between 3 servers and are using openldap as a backend, which 
>> stores about 400,000 users.  We use radrelay to push all the accounting 
>> into a mysql db.
>
> Can you comment on the accounting record rate that you're achieving? We're 
> currently testing FreeRadius and I'm seeing a performance ceiling of about 
> 200 accounting records per second.
>
> Matthew.

I will have to take a look tomorrow to see what kind of data is coming in. 
But, I will let you know the architecture I am using, in case it interests 
you.  Our billing system pulls from our accounting database periodically, 
so we don't need real-time information on all our accounting records.

We have three main radius servers.  We setup each of the radius servers to 
log all accounting to a detail file and we then use radrelay to push the 
data to our sql servers.  This makes the accounting part of our AAA much 
quicker between the NAS and the radius server.  The radius server just has 
to log it to a file and move on, so the accounting response comes very 
quickly.  This is especially apparent during high loads as we don't need 
to wait for an sql resource to come available.

The sql servers are two mysql 4.1 servers on freebsd 5.4.  They are 
running in a multi-master setup.  The two servers share an IP with CARP, 
which is built into freebsd.  CARP will setup one server as the master and 
that server will answer all ARP requests for that IP.  If the interface 
goes down (or if carp is shutdown by script/manual invervention), then the 
other machine will automatically take over that IP and then become the 
master sql server.

The whole point of this setup is for reliability of our data rather than 
availability of the sql server.  If one of the sql servers goes down, the 
other will take over the master role.  When the dead server comes back up, 
it will assume the slave role and will update itself to be current with 
the master or we can manually update it if we wish.

If both sql servers go down, or a small transition time between switching 
masters, or perhaps the radius load is just too high to accept all the 
requests we are getting, then the detail file on the radius servers will 
begin to grow.  When the radius accounting server comes back up or the 
packets coming in slow down to an rate lower than the sql server can 
accept it, radrelay will then catch up the accounting server.

We do occassionally see times where there was too much data coming in at 
once and the accounting server will post warnings to the log file and the 
detail files will begin to grow.  However, its never been more than a few 
minutes and radrelay quickly catches the servers back up to date when the 
rates return to a lower level.

Our authentication structure is quite different as we are looking more for 
availability.  But in the accounting world, we can afford to delay the 
records if needed.

I'll take a look at the data coming in tomorrow and let you know what kind 
of numbers we are seeing.  If you'd like I can also send you any 
information you'd like about CARP or our mysql setup.

I've also tested using another method which we chose not to implement. 
With this method I setup the accounting in a configurable-failover 
scenario.  First we would send the accounting data directly to the sql 
server.  If that failed, then the data would be populated into the detail 
file to quickly return an accounting response and radrelay would pick it 
up and deliver to the accounting server when it can.

This worked quite well, but we chose to go with just radrelay instead. 
By doing just radrelay we could make the radius accounting server open up 
a large number of connections to itself vs spreading out the connection 
pool among our main radius servers.

Hope that is helpful.

-Dusty