RES: FreeRadius high availability lab

[Alan DeKok]

> On Nov 6, 2017, at 4:33 PM, Claudio Carvalho <claudio at nextdigitalservices.com.br> wrote:
> 
> sorry, I forgot that the service does not carry images, below the link, thanks.
> 
> http://www.nextdigitalservices.com.br/images/radiustopology.png

  I'll echo most of the other comments.  For one, nginx is an odd choice.  It does UDP load-balancing.  It does *not* do RADIUS load balancing.

  This means that you need to break your RADIUS configuration in order to support nginx.  i.e. the servers will see the load-balancer as the source of all packets, and the clients will see the load-balancer as the RADIUS server.  This might not be what you want.

  If all of your NASes are the same, it should probably be fine.

  If you're not doing EAP, it's fine.  If you are doing EAP, you want a RADIUS-aware load balancer.

  The SQL DB is a single point of failure.  Worse, it's a single point of performance loss.  FreeRADIUS can handle 20K packets/s without a problem.  SQL servers typically fall over at about 1K writes/s.

  This means that the smarts of the system should be in FreeRADIUS.  i.e. if the SQL database is down, FR writes to "detail" files, etc.  Then when SQL is back up, FR reads the detail files and writes to SQL.

  You also need to split the SQL database, especially for accounting.  If you're doing monthly billing queries, those queries will *hammer* the SQL DB, and cause problems for FR.  Instead, build a master / slave system.  FR writes to the master.  The master replicates to the slave.  Billing queries are done against the slave.

  NAS fail-over is also terrible.  You're usually better off doing fail-over via VRPP, or something similar.  But again... doing RADIUS-aware fail-over is better than trying to bolt it on externally.

  You also haven't said how many packets/s this system is supposed to handle.  If it's 100 packets/s, this system is overkill.  If it's 2000+ packets/s, your database will die long before the RADIUS servers get 10% busy.

  As I keep recommending on this list, you should be talking about problems, not solutions.  What problem do you have?  What do you need the RADIUS server to do?

  Once we know that, we can recommend a solution.  But until then, I wouldn't recommend using the proposed design.

  Alan DeKok.