Radius Load-Balancing concept

[Santiago Balaguer García]

People, I have several radius severs who have configurated the same databases. As you said radius service has a fail-over when they connect to DB and the first one fails.
 
However, the main problem that I see in your configuration is the concurrency of database access. If you, at least, has two DB servers, both DB have to have the same data. So you have to solve the access concurrency firstly.> Date: Fri, 4 Jan 2008 10:20:44 +0100> Subject: Re: Radius Load-Balancing concept> From: sebastian at ganschow.name> To: freeradius-users at lists.freeradius.org> > Hi,> > load-balancing between the radius servers is not necessarily needed. I> think the servers we're going to by will be capable to manage all dialin> accounts.> > So the radius servers will be in fail over mode. If the first one is up,> all requests will be handled by it. If it fails, the second one will take> over.> > But will I get any trouble if both servers write their accounting data> into the same database?> > Do I need to setup radrelay? Is the second radius server able to take over> if radrelay isn't running?> > Regards> Sebastian> > On Thu, January 3, 2008 22:54, liran tal wrote:> > Hey Duane,> >> > On Jan 3, 2008 4:31 PM, Duane Cox <duanec at mail.illicom.net> wrote:> >> >> I'm doing this with no problem.> >>> >> I have 2 freeradius servers both writing/reading the same dbms> >>> >> > In a case where the entire transaction goes through one server it's ok,> > but if it gets split up through the two of them, then I'm not sure what> > will be the outcome.> >> > Regards,> > Liran.> > -> > List info/subscribe/unsubscribe? See> > http://www.freeradius.org/list/users.html> > > -> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
_________________________________________________________________
MSN Video. 
http://video.msn.com/?mkt=es-es
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20080104/9d82bd33/attachment.html>