-----Original Message----- From: freeradius-users- bounces+d.meyers=lancaster.ac.uk@lists.freeradius.org [mailto:freeradius-users- bounces+d.meyers=lancaster.ac.uk@lists.freeradius.org] On Behalf Of Kanwar Ranbir Sandhu Sent: 17 April 2009 21:52 To: freeradius-users@lists.freeradius.org Subject: RE: failover and load balancing
<snip>
I also believe you're saying that I could load balance, too. In this case, auth and accounting could be done on both machines, and I would still have one freeradius server in use (primary), from the NAS' point of view.
There are probably many better ways of doing it, but the simplest way to load balance across multiple FreeRADIUS servers is just to set each server as 'primary' on an equal number of NASes, i.e. 2 servers = half your NASes with server A as primary, half with server B as primary. A NAS will always talk to its primary server if it can possibly manage it. If all NASes have the same IP for their primary server then you'll have to start doing funky things external to both the NAS and FreeRADIUS to load balance nicely. I guess you could proxy from one server to the other for some requests using unlang rules or similar, but by that point you might as well just handle it on the server it's already hit.
In this scenario, don't the mysql databases on each machine have to be kept in sync? I've assumed that I would have to present one logical database to the freeradius server, even if the database itself is running on multiple mysql servers. That's why I mentioned "database cluster". I don't know if my assumption is correct.
MySQL has replication inbuilt. You can run one server as the master and as many others as you want as slaves. Slaves can't be written to, but can be read from. We're actually using this setup for redundancy in a system we're currently developing. 2 databases within a single MySQL process per server (each of which also runs FreeRADIUS). 1 database is replicated across all the servers, with one server acting as the master. The other database is unique to each server, not replicated. We have a script that runs on the master server every 5 seconds, pulls data from all the 'writable' (i.e. non-replicated) dbs on all the slaves, and writes it to the master replicated db. All systems read data from their local copy of the replicated DB, and write to their local non-replicated DB. It means we can have data that is up to 5 seconds out of date, but at any one point all FreeRADIUS servers have exactly the same view as they read, so it isn't too much of a problem (for us). Please note that we're doing this using rlm_perl and having 2 database handles per perl thread, one for reads and one for writes. I'm not sure if you can separate out the read and write databases like this if you're just using rlm_sql or similar. If you do far more reads that writes (we're writing a lot of logging data back, but if we weren't reads would far outnumber writes) then you might want to consider the simpler system of reading from the local database and just always writing back to the master. You do then run into the issue of the master being a single point of failure for writes, whereas with our system no data is lost, it's just buffered until the master comes back online and the script runs again. Postgres does supposedly have a version in beta for full master-master replication, but every time we've tried to get it running it's crashed on us as soon as we tried to actually write any data. Postgres in general seemed much slower than MySQL for reading the data we needed as well. -- Dan Meyers Network Specialist, Lancaster University E-Mail: d.meyers@lancaster.ac.uk