[RADIATOR] Recommended hardware specifications

[Wallner Martin]

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