suggestions about load-balance/cluster
Hi, I would like to get opinions and suggestions about the best approach to set a load-balance solution. At first I have a lot of ideas but I am not sure if someone know another tips. My goal is to have a setup prepared to manage hundreds of requests between tens of NAS appliances (Redback, Cisco, Alcatel, ...) and also being a proxy between some partners (external home servers) My idea is: 1) Two servers positioned in the board exposed to the internet. +----------------------+ +---------------------+ | Board-Radius A | & | Board-Radius B | +----------------------+ +---------------------+ |_____________________| | +-----------------------------------------------------------+ | LAN (Cluster Zone) | +-----------------------------------------------------------+ | RadiusNode_1 | | RadiusNode_2 | | ........ | | RadiusNode_N | +-----------------------------------------------------------+ My approach is: In the "board zone" would have less of possible configuration, only related to load-balance like. e.g: Board-Radius A & B: <snip> # AUTH+ACCT home_server auth_node_1 { type = auth+acct ipaddr = 10.1.2.1 port = 1812 secret = secret require_message_authenticator = no response_window = 20 zombie_period = 5 revive_interval = 10 status_check = status-server check_interval = 10 num_answers_to_alive = 3 } home_server auth_node_N { type = auth+acct ipaddr = 10.1.2.N port = 1812 secret = secret # other options as last "auth_node_1" } home_server_pool auth_loadbalance { type = load-balance home_server = auth_node_1 home_server = auth_node_N virtual_server = handle-node-auth } ... server handle-node-auth { pre-proxy { if (&Packet-Type == Accounting-Request) { # keep a local copy of all acct packets detail } ... } post-proxy { .... } } # COA home_server coa_node_1 { type = coa ipaddr = 10.1.2.1 port = 3799 secret = secret # other options as last "auth_node_1" } home_server coa_node_N { type = coa ipaddr = 10.1.2.N port = 3799 secret = secret # other options as last "auth_node_1" } home_server_pool coa_loadbalance { type = load-balance virtual_server = handle-node-coa home_server = coa_node_1 home_server = coa_node_N } ... server handle-node-coa { pre-proxy { ... } post-proxy { .... } } .................. # Partner settings (external) home_server auth_partner1 { ..... } home_server_pool pool_auth_partner1 { home_server = auth_partner1 ..... } home_server coa_partner1 { ..... } home_server_pool pool_coa_partner1 { home_server = coa_partner1 ..... } realm partner1.com { auth_pool = pool_auth_partner1 coa_pool = pool_coa_partner1 } # default behavior for local realms. realm NULL { type = radius auth_pool = auth_loadbalance coa_pool = coa_loadbalance secret = secret } realm DEFAULT { type = radius auth_pool = auth_loadbalance coa_pool = coa_loadbalance secret = secret } realm mylocaldomain1.com { type = radius auth_pool = auth_loadbalance coa_pool = coa_loadbalance secret = secret } </snip> Doubts: What the best approach based in the "type" of the pool? Maybe the "keyed-balance" sounds better? I really appreciate all suggestions and tips about my approach. Best regards, ---- Jorge Pereira
On Wed, Oct 21, 2015 at 03:48:53PM -0200, Jorge Pereira wrote:
home_server_pool auth_loadbalance { type = load-balance home_server = auth_node_1 home_server = auth_node_N virtual_server = handle-node-auth } ...
Doubts: What the best approach based in the "type" of the pool? Maybe the "keyed-balance" sounds better? I really appreciate all suggestions and tips about my approach.
I'm looking at doing the same at the moment. load-balance should be OK with e.g. plain PAP etc. As soon as you move to EAP then it'll break, so keyed-balance should be the only real option AFAICT, though I have considered ideas using unlang to choose the proxy server and storing it based on Calling-Station-Id and User-Name in a local redis server with a timeout. But I usually look for the complicated solutions... My likely plan if I go ahead with this is to use keyed-balance probably with Calling-Station-Id (and possibly also User-Name) as the key source. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi Matthew, Good to know that more people are working with it. It would be great to us share ideas. I am looking for another solutions to after research can choose the best approach to be applied. I think that use of keyed-balance will be the best way. But, I really would like to hear more people talking about that. About the ways to based the requests, I have used the Acct-Session-Id which is the key of storage. below a example. "%{redis: HSET %{Acct-Session-Id} Client-Shortname %{client:shortname}}" My gTalk is jpereiran@gmail.com, feel free to add and talk about some ideas. -- Jorge Pereira On Wed, Oct 21, 2015 at 8:59 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Wed, Oct 21, 2015 at 03:48:53PM -0200, Jorge Pereira wrote:
home_server_pool auth_loadbalance { type = load-balance home_server = auth_node_1 home_server = auth_node_N virtual_server = handle-node-auth } ...
Doubts: What the best approach based in the "type" of the pool? Maybe the "keyed-balance" sounds better? I really appreciate all suggestions and tips about my approach.
I'm looking at doing the same at the moment.
load-balance should be OK with e.g. plain PAP etc.
As soon as you move to EAP then it'll break, so keyed-balance should be the only real option AFAICT, though I have considered ideas using unlang to choose the proxy server and storing it based on Calling-Station-Id and User-Name in a local redis server with a timeout. But I usually look for the complicated solutions...
My likely plan if I go ahead with this is to use keyed-balance probably with Calling-Station-Id (and possibly also User-Name) as the key source.
Matthew
-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>
Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Wed, Oct 21, 2015 at 11:11:15PM -0200, Jorge Pereira wrote:
About the ways to based the requests, I have used the Acct-Session-Id which is the key of storage. below a example.
There is no accounting session ID in an auth request... Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi Matthew, In my case, all of my NAS have the Acct-Session-Id during the Access-Request. In another project I create my Acct-Session-Id based in some avps as below example. if (!&Acct-Session-Id) { update { &Acct-Session-Id := "static:%{md5: %{Calling-Station-Id},%{Called-Station-Id}}" } } And save your preferred avps in REDIS using this like a key. The idea of prefix "static" it's only to be different. -- Jorge Pereira On Thu, Oct 22, 2015 at 5:43 AM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Wed, Oct 21, 2015 at 11:11:15PM -0200, Jorge Pereira wrote:
About the ways to based the requests, I have used the Acct-Session-Id which is the key of storage. below a example.
There is no accounting session ID in an auth request...
Matthew
-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>
Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Thu, Oct 22, 2015 at 06:00:10AM -0200, Jorge Pereira wrote:
In my case, all of my NAS have the Acct-Session-Id during the Access-Request. In another project
OK, fair enough. If you make it up yourself then it'll be there to use. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
participants (2)
-
Jorge Pereira -
Matthew Newton