(RADIATOR) Load Balancing

Hugh Irvine hugh at open.com.au
Mon Sep 10 04:10:19 CDT 2001


Hello Harrison -

On Monday 10 September 2001 17:20, Harrison Ng wrote:

> > Hi,
>
> We are using Ericsson GSN, the primary and secondary failover timer in GSN
> is restricted to merely 6 seconds. After these 6 secs, it drops the call.
>

OK

> So our radiator server need to respond very fast, I mean fast in doing
> username/password authentication, accounting logging, ip address allocation
> and forward accounting information to 3rd party business partners and reply
> back to GSN at last. If we divide 6 secs into 2 halves, there will be only
> 3 secs for primary radius, and 3 secs for secondary radius.
>

Normally, requests should be processed in a relatively small number of 
milliseconds, so you should be in good shape.

> Our first question is it possible to change the behaviour (perhaps an extra
> parameter) of <AuthBy ROUNDROBIN, VOLUMEBALANCE, LOADBALANCE> so that when
> radius proxy does not receive response from the first radius server, then
> just stop it and let the radius server marked failure and reply nothing to
> GSN. Let the radius server sit still until FailureBackupoffTime is reached.
> Do not even try to forward request to the second listed, until the list is
> exhausted.
>

I'm afraid I don't understand the above - why use load balancing at all?

> Second can we set the timeout value (perhaps to zero) for the very first
> accounting forward packet. The RetryTimeout only suitable for
> retransmitting packet. Lost accounting packet is not a concern to us, as
> long as the radius server work very fast.
>

You can use AccountingHandled in the Handler (or Realm) and the 
IgnoreAccountingResponse in the AuthBy RADIUS clause to do this.

> We tried optimize every things such as using radius proxy to distribute
> loading to several radius server, put database server in another unix box,
> field indexing, lots of memory and etc. Maybe our question is a bit
> strange. Perhaps someone can suggest us a workaround. Thanks.
>

I think you will need to do some tests to discover the real-world performance 
of your system, as well as some end user tests to see what is (un)acceptable.

hth

Hugh


-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
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.


More information about the radiator mailing list