(RADIATOR) Threading support (again)

[Hugh Irvine]

Hello John -

Radiator is not multi-threaded, as the support in Perl (and some  
modules) is not there.

In my consulting practice I usually design systems with a "frontend"  
radiusd process which proxies to a number of "service" radiusd  
processes such as "dialup", "dsl", "vpn", wireless", etc.

I tend to find this easier to design, understand and operate (eash  
"service" is generally split into authentication and accounting  
instances as you describe).

Identical setups are installed on all of the Radiator hosts which are  
grouped behind two load balancers.

The problem that you describe with spikes in request volume due to  
links and/or devices bouncing is well known, and i have written rate- 
limiting hooks which you will find in "goodies/hooks.txt".

Note that this sort of problem is really a NAS problem, not a RADIUS  
problem per-se.

We are available on a contract basis for design, implementation and  
so on.

hope that helps

regards

Hugh


On 25 Aug 2007, at 07:45, John Morrissey wrote:

> Looking through the archives, it's been a long time since someone's  
> kicked
> the threading horse.
>
> We've been running Radiator on a fairly substantial RADIUS  
> installation (a
> dozen or so machines in three locations across the United States) for
> several years now, making use of an LDAP directory for account  
> storage.
> (Hugh or Mike, feel free to e-mail me privately if you need more
> information.) Unfortunately, OpenLDAP libraries do not seem well  
> behaved
> when Radiator forks, although it's been a while since we've tried.
>
> Our largest problem with a monolithic process is that we've had  
> occasional
> problems where device outages cause thousands of subscribers to
> reauthenticate simultaneously. This overwhelms our authentication  
> radiusd
> instances, causing UDP network queues on that port to skyrocket,  
> eventually
> leading to a cascade failure that is obnoxious to recover from, to  
> say the
> least. Our RADIUS servers are by no means underpowered, but it's  
> just not
> cost-effective to maintain a huge (and otherwise idle) hardware  
> pool just to
> handle occasional huge spikes like this.
>
> Additionally, we're starting to deploy machines with four CPU cores  
> as their
> price has dropped substantially. We like sticking to a fairly standard
> configuration, so we'd like to avoid "wasting" hardware that  
> Radiator will
> never use (we have auth and accounting split into two Radiator  
> instances).
> We could run more radiusd processes on different ports or IP  
> addresses, but
> this seems wasteful and complex.
>
> Lastly, we're looking at implementing simultaneous use restrictions  
> and are
> concerned that the state refresh (SNMP in some cases, locally  
> implemented
> interfaces to proprietary devices in others) will block radiusd  
> excessively.
> We're also looking at proxying to more customers, and are concerned  
> that
> unreachable or underperforming proxy destinations will cause the same
> behavior.
>
> We had considered implementing rate limiting to handle our first  
> concern
> above, but that doesn't get us anywhere with the others. To that  
> end, I'm
> toying with the idea of adding a new process model to Radiator  
> somewhat akin
> to Apache's prefork MPM, with a number of child processes (not  
> threads)
> running round-robin on the incoming UDP port or handling work  
> directed at
> them via some sort of IPC from a central request handler process.
>
> I haven't dived into the code yet to see how non-trivial this will  
> be, and I
> thought I'd ask around here first to see what everyone's thoughts  
> are. I
> know that a threaded model hasn't been implemented due to alpha- 
> quality
> thread support in Perl, and I haven't looked into its current state  
> yet.
> That's part of the reason I'm keen on using separate worker processes
> instead of threads.
>
> thanks,
> john
> -- 
> John Morrissey          _o            /\         ----  __o
> jwm at horde.net        _-< \_          /  \       ----  <  \,
> www.horde.net/    __(_)/_(_)________/    \_______(_) /_(_)__
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.



NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.