[RADIATOR] Recommended hardware specifications

[Hugh Irvine]

Hello Martin, Hello Adam -

Many thanks Martin for your most interesting description.

I should also add that we (OSC) are available on a contract basis for  
design and implementation, and re-engineering if required.

We have successfully undertaken similar jobs for many companies all  
over the world.

regards

Hugh



On 4 Mar 2009, at 20:31, Wallner Martin wrote:

> Adam,
>
> adding to Hugh's suggestions I want to add a 'real' setup, working  
> with around 60k Broadband and around 20k Dial-In and special cases  
> (this is a 'grown and merged' system, so to say the 'refined sum' of  
> 4 providers merged together), handling around 40 realms, 40  
> handlers, split over 20 clients (LACs, NAS, MAX-TNT-DialIns).  And  
> yes, the config is a nightmare :-)
>
> We are using two pretty much standard DL380 (G4), dual core  
> processors, servers for the RADIUS-Side and a PGSQL-Servercluster  
> (2x DL380, quad core) for storing the account data. All running  
> CentOS. Additionally we have the company LDAP-Serversystem, that,  
> among other things, is queried by the two radius-servers for  
> authentication and for the 'non-standard' configuration of the user.  
> Additional, on the radius-server there is the IPASS-Software running  
> (both Roaming and Network) ....
>
> Even non-instanced (seperated Authentication from Accounting) the  
> machines are more than able to recover within minutes from 'total  
> desasters', you will have to make sure, that the LDAP's are able to  
> get their wits together when radius starts to hammer on them, the  
> database in the back has no troubles to save the accounting data and  
> even partly process it (we haven a special processing, that allowes  
> only one entry per accountingtype per session (we were, especially  
> in disaster szenarios, ofthen flooded with replies and so on, which  
> all had o go , limiting so the entries in the database drastically,  
> after this and some clever indexing the DB, which was the  
> 'problembringer' by slow responsing to the radius servers, just  
> works without problems).
>
> Additional: with a 'full disaster' (like 'all NAS dead') you might  
> have to put more concern on the ROUTERS doing the NAS than the  
> RADIUS. In my experience, the routers are more likely to stumble  
> than the RADIUS-Server.
>
> I did a stresstest on the labsystem (which is the same style of  
> setup), and the RADIUS-System itself was working up to 5k-10k  
> Requests  per minute (without an actual NAS as client, splitted 2  
> accounting requests by 2 authentication requests). 2-Instance-Setup  
> (splitted accounting/authenticating) brought 15k Requestst per  
> minute authenticating and 5k per minute accounting, while the  
> authenticating queue was a bit stuffed with all the radonline- 
> changes on the database. The issue was solved by changing the way  
> radonline database is handled in a different way than the standard  
> one (which is secure and safe, but SLOOOOOOW .-). the change is  
> similar to the  accounting changes, preprocessing the data before  
> actually writing in the DB...
>
> hope this helps.
> =mw=
>
>
> -----Ursprünxgliche Nachricht-----
> Von: radiator-bounces at open.com.au [mailto:radiator- 
> bounces at open.com.au] Im Auftrag von Adam Armstrong
> Gesendet: Dienstag, 03. März 2009 18:37
> An: radiator at open.com.au
> Betreff: [RADIATOR] Recommended hardware specifications
>
> Hi,
>
> Are there any guidelines or recommended hardware configurations for  
> ~30,000 broadband subscribers? (we'd like to account for a total  
> failure, requiring reauthentication of them all in a relatively  
> short time!)
>
> Does radiator multithread? (i recall reading that it doesn't?)  
> What's the best way to scale it?
>
> Thanks,
> adam.
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



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.