On Jan 22, 2016, at 11:23 AM, Ruslan Kalakutsky <r.kalakutsky@gmail.com> wrote:

It's a question of simplicity and reliability if there are no possible deadlocks or race conditions.

Databases can have multiple clients reading and writing at the same time. This is what databases do.

Automate deployment of radius service on each IPSEC server easier than having another single point of failure.

You'll still have a single point of failure in the database. If the IPSec servers are physically close to the database, this will work. It's not a good idea, but it will work. If the IPSec servers are scattered around the net, this won't work. You're almost always better off centralizing RADIUS, and having a database close to the central RADIUS server. But if you think you know better, it's your network. Alan DeKok.

On Jan 22, 2016, at 12:24 PM, Ruslan Kalakutsky <r.kalakutsky@gmail.com> wrote:

...

Databases can have multiple clients reading and writing at the same time. This is what databases do. I know it. The question is about RADIUS.

Then ask a better question. "Can I use one DB with multiple RADIUS servers" is a vague question. Ask a bad question, get a bad answer.

E.g. if two servers authorize one user simultaneously and user have 'Simultaneous-Use' restriction with only one session than:

Scenario 1: - server 1 and server 2 creates two records at accounting table with AcctStopTime == NULL - server 1 and server 2 checks other records and each found that there are two records - both refuse to auth a user because of limits. Result: user can't auth on both servers.

That's how Simultaneous-Use checks work. Question: Why is this any different for two servers, than for one server where the user logs in twice? Answer: if both servers use the same DB, it's not any different. This isn't a RADIUS question. This is a database question: Q: Will two clients querying the database see a consistent view of the database? A: yes. Q: Will one client querying the database twice see a consistent view of the database? A: yes.

Scenario 2: - server 1 auth user and checks if there a record at accounting table with AcctStopTime == NULL (success) - server 2 auth user and checks if there a record at accounting table with AcctStopTime == NULL (success) - server 1 creates an accounting record - server 2 creates an accounting record Result: user has two sessions instead of possible one session.

This is a database question. Not a RADIUS question. Q: Will a client querying the database get a the correct answer to the query? A: Yes. Always. That's what databases do. 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.

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 how RADIUS was designed to work. Alan DeKok.

On Jan 22, 2016, at 1:30 PM, Ruslan Kalakutsky <r.kalakutsky@gmail.com> wrote:

...

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 experienced developer).

I said go through the *queries*, not the *code*. If you're going to be doing something unusual with SQL, it would be good to look at the queries which are being used.

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.

Again, this is a *DATABASE* issue. If you're not clear on that, then you don't know how databases work.

That's definitely clear. And all servers will be close each other, hosted at cloud provider.

That's no guarantee that the systems are well connected. It's likely, but not definite.

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, isn't?

I didn't say any of that.

I suppose it will be a more complicated schema than mine.

If you're going to invent complexity, it's your problem. I think you're trying to build a complex system without understanding how the pieces work. That's going to be a disaster. Alan DeKok.

On Jan 22, 2016, at 2:55 PM, Ruslan Kalakutsky <r.kalakutsky@gmail.com> wrote:

Is there other failover schema with horizontal scalability you could advise? Because I do not find anything at documentation or wiki.

These systems aren't trivial to build. It requires a deep understanding of both the use-case (i.e. your needs and traffic), the protocols, and the software. There is just no way to say "do X and it will work".

I really appreciate your help. But it is still absolutely unclear for me that I should see from SQL statements. It's usual SELECT and UPDATE clauses, while *real using* of the result is the *internal* application logic. And it is that I ask about.

Once the data is in the application, there is no deadlock problem between multiple applications. Again, the entire *point* of the database is to track shared state. I asked (and answered) a few key questions in my previous message. You clearly don't see why the questions or answers are relevant. Which means you're not clear on how databases work. That won't end well. There isn't much more I can do here. Good luck. Alan DeKok.