Hy all, few questions: Is it possible to use the same sqlippool database for different freeradius servers that belong to a "cluster? Is there drawback, doing this? Is there any chance to acheive consistante ip allocation in a cluster of several freeradius using non sql ippool module? thx
Alexandre Chapellon wrote:
Is it possible to use the same sqlippool database for different freeradius servers that belong to a "cluster?
Yes. Just create an SQL cluster, and point the servers at the cluster.
Is there drawback, doing this?
It will be slower, and database replication may not happen quickly.
Is there any chance to acheive consistante ip allocation in a cluster of several freeradius using non sql ippool module?
The servers will have to communicate with each other before handing out IP addresses. Or, split up the IP pool ranges so that each server has their "own" range that they prefer. i.e. server 1 allocates from pool 1, and then pool 2 if pool 1 is full. Server 2 allocates from pool 2, and then pool 1 if pool 2 is full. There are other, more complicated ways of doing the same thing. Alan DeKok.
Alan DeKok a écrit :
Alexandre Chapellon wrote:
Is it possible to use the same sqlippool database for different freeradius servers that belong to a "cluster?
Yes. Just create an SQL cluster, and point the servers at the cluster.
Is there drawback, doing this?
It will be slower, and database replication may not happen quickly.
Is there any chance to acheive consistante ip allocation in a cluster of several freeradius using non sql ippool module?
The servers will have to communicate with each other before handing out IP addresses.
Is it a featured in freeradius? How does it work?
Or, split up the IP pool ranges so that each server has their "own" range that they prefer. i.e. server 1 allocates from pool 1, and then pool 2 if pool 1 is full. Server 2 allocates from pool 2, and then pool 1 if pool 2 is full.
I thought about it but not managing a huge number of ippool (for different type of users, differents huntgroups, and differents radius servers) would be a great advantage of freeradius among other radius server (I am comapring it with juniper SBR at the moment).
There are other, more complicated ways of doing the same thing.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alexandre Chapellon wrote:
The servers will have to communicate with each other before handing out IP addresses.
Is it a featured in freeradius?
No. That code would need to be written.
I thought about it but not managing a huge number of ippool (for different type of users, differents huntgroups, and differents radius servers) would be a great advantage of freeradius among other radius server (I am comapring it with juniper SBR at the moment).
I'm not sure *any* RADIUS server has this functionality. It's usually done as part of the database replication, etc. The SQL IPPool module can run configurable queries. This means you can populate IP pools on the SQL server based on *whatever* information you want. The queries can then be edited to include key information like huntgroups, etc. The queries can also be edited to be *different* on each server. i.e. order forward by IP on one server, and the reverse on another server. If the databases are in an SQL cluster, this will minimize the possibility of problems. Alan DeKok.
Am Freitag, 26. September 2008 10:05 schrieb Alan DeKok:
Alexandre Chapellon wrote:
The servers will have to communicate with each other before handing out IP addresses.
Is it a featured in freeradius?
No. That code would need to be written.
Think about using DRBD. -- Dr. Michael Schwartzkopff MultiNET Services GmbH Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany Tel: +49 - 89 - 45 69 11 0 Fax: +49 - 89 - 45 69 11 21 mob: +49 - 174 - 343 28 75 mail: misch@multinet.de web: www.multinet.de Sitz der Gesellschaft: 85630 Grasbrunn Registergericht: Amtsgericht München HRB 114375 Geschäftsführer: Günter Jurgeneit, Hubert Martens --- PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B Skype: misch42
Alan DeKok a écrit :
Alexandre Chapellon wrote:
The servers will have to communicate with each other before handing out IP addresses.
Is it a featured in freeradius?
No. That code would need to be written.
I thought about it but not managing a huge number of ippool (for different type of users, differents huntgroups, and differents radius servers) would be a great advantage of freeradius among other radius server (I am comapring it with juniper SBR at the moment).
I'm not sure *any* RADIUS server has this functionality. It's usually done as part of the database replication, etc.
Why enabling replication? Isn't it possible to have one centralized database for all radius server?
The SQL IPPool module can run configurable queries. This means you can populate IP pools on the SQL server based on *whatever* information you want. The queries can then be edited to include key information like huntgroups, etc.
The queries can also be edited to be *different* on each server. i.e. order forward by IP on one server, and the reverse on another server. If the databases are in an SQL cluster, this will minimize the possibility of problems.
I think you missunderstood me. When I talk about cluster, i mean a farm of radius servers reply to several NASes.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
tnt@kalik.net a écrit :
Why enabling replication? Isn't it possible to have one centralized database for all radius server?
Ahem, even a single radius server is so much faster than the database. That arrangement is doomed.
Well, actually here is how i wanted to set things up: Each radius have a local mysql database to locally store accounting data. Each local database is replicated to a central database which couls be used too as a redundancy for accounting if the local one fail (more over centralized accounting database used to process customers request and/or complaints). One centralized mysql database (on another mysql server maybe) to handle IP allocation using rlm_sqlippool. I have aproximatively 15000 users connected concurently. Does it seems to you a too weak or inefficient setup? While my priority is high-availability
Ivan Kalik Kalik Informatika ISP
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alexandre Chapellon wrote:
Each radius have a local mysql database to locally store accounting data.
If nothing will be querying those databases, I suggest *not* using SQL. It's just not needed.
Each local database is replicated to a central database which couls be used too as a redundancy for accounting if the local one fail (more over centralized accounting database used to process customers request and/or complaints).
RADIUS packets can be replicated to the central server and logged there. Database replication will work, but will be a lot of load on the various systems.
One centralized mysql database (on another mysql server maybe) to handle IP allocation using rlm_sqlippool.
Again, using *one* database for *many* RADIUS servers is very likely wrong. i.e. it will be slow, fragile, and is likely to not meet your needs of high availability.
I have aproximatively 15000 users connected concurently. Does it seems to you a too weak or inefficient setup?
Do the math. 15K users, with one accounting packet every 10 minutes. That's 25 packets/s. It's a nice number, but not too high.
While my priority is high-availability
Some parts seem too complex, and others too simple. The IP pool allocation needs to be more robust, and the accounting replication doesn't need as many pieces. Alan DeKok.
Alan DeKok a écrit :
Alexandre Chapellon wrote:
Each radius have a local mysql database to locally store accounting data.
If nothing will be querying those databases, I suggest *not* using SQL. It's just not needed.
Right, nothing will query the database directly on radius servers. But i really need to have one central database that will be queried by webapps to let users know about thier quota left, time of connection etc...
Each local database is replicated to a central database which couls be used too as a redundancy for accounting if the local one fail (more over centralized accounting database used to process customers request and/or complaints).
RADIUS packets can be replicated to the central server and logged there. Database replication will work, but will be a lot of load on the various systems.
Does this central radius server can log all queries proxied to him to an sql database (i know i'm boring with SQL accounting database! :)) If i read you well... it 's not! Am i asking too much from SQL? how else can we achieve it?
One centralized mysql database (on another mysql server maybe) to handle IP allocation using rlm_sqlippool.
Again, using *one* database for *many* RADIUS servers is very likely wrong. i.e. it will be slow, fragile, and is likely to not meet your needs of high availability.
I have aproximatively 15000 users connected concurently. Does it seems to you a too weak or inefficient setup?
Do the math. 15K users, with one accounting packet every 10 minutes. That's 25 packets/s. It's a nice number, but not too high.
While my priority is high-availability
Some parts seem too complex, and others too simple.
The IP pool allocation needs to be more robust, you mean splitting pool by NASes and radius server?... then sqlippool is not really needed anymore? and the accounting replication doesn't need as many pieces.
OK, i trust you but I don't see any chance of having no SQL enabled accounting. It's almost a requirement for me.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alexandre Chapellon wrote:
Right, nothing will query the database directly on radius servers.
Then don't put a database there.
But i really need to have one central database that will be queried by webapps to let users know about thier quota left, time of connection etc...
Then put a database there. But you likely need DB writes only on things like session close, or maybe every hour. Since the RADIUS accounting packets come every 10 minutes, having "quota" information down to the minute is pretty much impossible.
Does this central radius server can log all queries proxied to him to an sql database (i know i'm boring with SQL accounting database! :)) If i read you well... it 's not! Am i asking too much from SQL? how else can we achieve it?
That central server can log *aggregated* data. i.e. it doesn't have to log all of the data "live" as it comes in.
you mean splitting pool by NASes and radius server?... then sqlippool is not really needed anymore?
You can use sqlippool, because it makes management easier. But don't expect it to work across many RADIUS servers with one SQL server. Instead, split the IP pools by NAS && RADIUS server. A little bit of careful planning up front should be able to simplify the system, and make it more robust.
OK, i trust you but I don't see any chance of having no SQL enabled accounting. It's almost a requirement for me.
Note that I never said *no* SQL. I just said you don't need it *everywhere*. Alan DeKok.
Again, using *one* database for *many* RADIUS servers is very likely wrong. i.e. it will be slow, fragile, and is likely to not meet your needs of high availability.
Alan is saying a single MySQL instance is fragile because it's a single point of failure.
Clustered SQL is bad because the synchronization delays could lead to conflicting lease allocations (Conflicted IP addresses etc). The solution (if you're using a pool of addresses) is to split the range and have each RADIUS server allocating a different part of the range. Then there's no chance of the servers allocating duplicate leases even in a clustered SQL environment.
I have aproximatively 15000 users connected concurently. Does it seems to you a too weak or inefficient setup?
Do the math. 15K users, with one accounting packet every 10 minutes. That's 25 packets/s. It's a nice number, but not too high.
While my priority is high-availability
Some parts seem too complex, and others too simple.
The IP pool allocation needs to be more robust,
you mean splitting pool by NASes and radius server?... then sqlippool is not really needed anymore?
and the accounting replication doesn't need as many pieces.
OK, i trust you but I don't see any chance of having no SQL enabled accounting. It's almost a requirement for me. You want to use rlm_detail to spool out your accounting packets to a flat file, then read them back in using a virtual server instance. There are examples included with the server.
This gives you a *huge* buffer, in case of catastrophic power failure, or SQL database failure. The RADIUS server will just keep spooling out Accounting packets to the flat file until the detail file reader can insert them into the SQL database. We use it and it works very well. If you use MySQL with the InnoDB engine, writing to the accounting database that you web application queries should not have a dramatic effect on the time taken for select queries to complete. This is because the InnoDB engine uses a row based locking scheme, as opposed to a table based locking scheme. Arran
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alexandre Chapellon wrote:
I'm not sure *any* RADIUS server has this functionality. It's usually done as part of the database replication, etc.
Why enabling replication? Isn't it possible to have one centralized database for all radius server?
You really don't want that. RADIUS servers use much less CPU time, memory, and disk space than SQL servers. So that design is exactly backwards from what you will need.
The queries can also be edited to be *different* on each server. i.e. order forward by IP on one server, and the reverse on another server. If the databases are in an SQL cluster, this will minimize the possibility of problems.
I think you missunderstood me. When I talk about cluster, i mean a farm of radius servers reply to several NASes.
I was talking about SQL clusters for fail-over and redundancy. Why would you run multiple RADIUS servers for redundancy, and then only one SQL server? That's pointless. So you need multiple SQL servers. Which have to talk to each other. And do SQL replication. And there will be replication delays for IP pool information. So the IP pools will be out of sync... There's a reason not many people do this. It's *hard* to get right. Alan DeKok.
participants (5)
-
Alan DeKok -
Alexandre Chapellon -
Arran Cudbard-Bell -
Michael Schwartzkopff -
tnt＠kalik.net