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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
