Multiple FreeRadius servers with one PostgreSQL backend
r.kalakutsky at gmail.com
Fri Jan 22 19:30:19 CET 2016
Alan, thanks for a detailed answer.
> I'm not sure what you think will happen here. The SQL queries in FreeRADIUS are just text. Go read them. There's nothing in them which is specific to the server which queries the DB.
I've read them, but I do not know the internal logic of freeradius
server (yes, I can go throw the freeradius code but I'm not an
So, just to summarize I can assume that multiple FreeRADIUS servers
can works with same backend without any issues like deadlocks and they
do not need any state synchronization.
>> Just wonder why do you think it is a bad idea? WIll it be slower, more
>> unreliable or any other reasons? We're going to have a dynamically
>> scalable architecture with a number of VPN gateways from 1 to 100. Of
>> course, SQL server should be optimized to work with this load, but is
>> there any reason to have centralized RADIUS?
> It's networking 101.
> If you have RADIUS servers scattered all over the planet, it's a *terrible* idea to have them connect over TCP to a central SQL server. They should instead proxy RADIUS to a central RADIUS server. UDP is much better than TCP for time-critical traffic.
That's definitely clear. And all servers will be close each other,
hosted at cloud provider.
The point is to be scalable and reliable. So if I have a separate
RADIUS I should have a group of RADIUS servers (maybe with auto
scaling) and I'd have some load balancer in front of with them (and
duplicate this LB too) and them should have a virtual IP and so on,
I suppose it will be a more complicated schema than mine.
More information about the Freeradius-Users