FreeRadius high availability lab

[Alan DeKok]

On Nov 7, 2017, at 4:14 PM, Norman Elton <normelton at gmail.com> wrote:
> 
> It's interesting to read this, as the suggestions mirror what I've
> learned over the years.

  That's experience for you.

> This is on a single university campus, so everything is geographically
> local. But we have two DCs, a FreeRADIUS server in each. The servers
> each have a floating "primary" address, which magically floats to the
> other box using keepalived. So if Server A fails, Server B adopts
> failed IP address. NAS's (in our case, switches & APs) never have to
> deal with failover. Makes things SO much smoother. Holy cow was this a
> "lightbulb moment".

  Yeah.  The NAS implementations of fail-over are *terrible*.  Even equipment costing $100K often just does primary + secondary.  With fail-over when the primary goes down... and never fail-back until the system reboots.

  Remember: NASes are dumb.  RADIUS servers are smart.  Put the smarts into the RADIUS server and/or the network.  Don't rely on the NASes for *anything* other than network access.

> We have a database as the "authoritative record", but everything is
> Redis-cached on each FreeRADIUS server. It's a bit of a chore to keep
> the cache synchronized, but it means that FreeRADIUS is completely
> self-sufficient. We use rlm_perl to read this cache when responding to
> requests, and to log accounting updates back to the Redis cache.

  That should be possible with unlang.  Maybe a bit more awkward than Perl, but is should work.

> There
> are helper scripts (on other servers) which grab those updates and log
> them to the database. If there is a flurry of updates, then the Redis
> cache queues up for a few seconds while the database catches up. But
> FreeRADIUS chugs along, even if the database server completely blows
> up. This happened for the first time 2 weeks ago. RAID controller
> died. The Redis cache queued up all the requests until we got the
> backup database server online. Fun times.

  Yup.

  The detail file and detail reader does this, too.  Arguably not as catchy as Redis, but it works.

  We're working on making the detail file reader faster in v4, too.

> I'm curious if rlm_redis + unlang would be more performant than
> rlm_perl + perl script. Haven't had time to test this yet.

  Send the scripts over and we'll take a look.  If they're useful to you, they're probably useful to other people, too.

  Alan DeKo.