(RADIATOR) Loadbalance

Hugh Irvine hugh at open.com.au
Wed Sep 25 01:45:44 CDT 2002


Hello Ray -

The first thing to do in all cases is to identify exactly what is 
causing the problem - then fix it.

In my experience, it is almost always a slow database that causes 
problems, and having multiple instances of Radiator all waiting on the 
slow database will gain you nothing at all. Similarily, if you are 
losing packets, it is usually due to saturated links, and again, using 
loadbalancing will not help.

In short, make sure your database is really fast (multiprocessor, fast 
SCSI disks on a RAID controller, keep the tables small, and make sure 
the indexes are correct), and make very sure you have sufficient 
bandwidth so you don't drop packets.

As mentioned in my previous mail, using one instance of Radiator for 
authentication and another for accounting is usually the best first 
step, as the authentication will not be affected by the (usually) 
slower accounting.

regards

Hugh


On Wednesday, September 25, 2002, at 01:24 PM, rcortez at info.com.ph 
wrote:

>
> hi hugh,
>
>    does this mean if we ever encounter performance problem
> (i.e. slow auth, lost stop records) we need to separate the
> authetication from accounting. and accquire additional radius
> server to handle accounitng packets. and may be, add a load balancing
> server (radiator)to spread the work among 3 servers?
>
> thanks,
> ray
> ----- Original Message -----
> From: Hugh Irvine <hugh at open.com.au>
> Date: Wednesday, September 25, 2002 10:07 am
> Subject: Re: (RADIATOR) Loadbalance
>
>>
>> Hello Ray -
>>
>> I don't think using loadbalancing in the way you describe will
>> gain you
>> anything.
>>
>> You would probably do better running two instances of Radiator,
>> one to
>> process authentication requests and the other to process
>> accounting
>> requests. This tends to work better, because there are twice as
>> many
>> accounting requests as authentication requests (start and stop for
>> every access). There is usually more overhead involved in
>> processing
>> accounting requests as well, but if it is in a seperate process,
>> it
>> doesn't get in the way of the authentication requests.
>>
>> The loadbalancing is really designed to spread requests across
>> seperate
>> machines, which of course you should have in any case.
>>
>> regards
>>
>> Hugh
>>
>>
>> On Wednesday, September 25, 2002, at 11:40 AM, rcortez at info.com.ph
>> wrote:
>>
>>> hi hugh,
>>>
>>>      in our setup having 2 radius server (wiht 2 instance of
>> radiator> running on each machine) and 1 oracle server. will there
>> be an
>>> advantage if we are going to use radiator loadbalancing if our
>> ras port
>>> grows from the current 1,500 ports to 5,000 ports? d oracle
>> database is
>>> hosting both prepaid and post paid system with peak and off-peak
>> rating> and with credit limit on postpaid customers. all dial-up
>> are terminated
>>> through L2TP. our radius servers are idle most of the time. the
>> highest> utilization that we are getting during peak hour is from
>> 15% to 20%
>>> only. will the radius capacity increase if we add 2 more
>> instance of
>>> radiator on the radius server (having a total of 4 instance per
>>> server). one of the 4 instances will be configured as proxy
>>> (loadbalancer to the 3 remaining instance of radius). do you
>> have a
>>> reference site that uses loadbalancing feature of radiator?
>>>
>>> thank you
>>>
>>>
>>>
>>> ===
>>> 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.
>>>
>>>
>>
>> -- 
>> 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.
>>
>
>

-- 
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