(RADIATOR) Re: Redundancy for RADIUS

Matthew Trout MatthewTrout at businessserve.co.uk
Wed Apr 16 04:00:59 CDT 2003


If you're looking at two separate locations, I don't think I'd like to risk
having a single DB server - too many things to go wrong.

Configuring both radiator installs to allocate by NAS should work - our
configs use

PoolHint %{Client:Indentifier}

in the AuthBy DYNADDRESS clause quite extensively to achieve similar things.

As for the databases, I'd suggest that investigating MySQL's replication is
the way to go - setting each db server up to slave off the other one should
do the trick; you shouldn't get any conflicts while both are still up since
they'll be working off different pools, but if one goes down the other
should be able to pick up its load as well pretty much where it left off.
You may find you need to do a little hand-tweaking to get the replication
running again once both machines are back up, but assuming you aren't
planning to lose one server often (!) it's not that much of a pain.

If you want more robust, albeit not necessarily quite as fast/lightweight
(this may be a concern depending on the speed of the links between sites)
replication, I know of people using PostgreSQL in production with much
success, but can't advise on how well it would work in this case.

If you want redundancy against radiator boxes going down while still
presenting a single IP to the NASen, then you might want to take a look at
http://www.linuxvirtualserver.org/ or http://linux-ha.org/

-----Original Message-----
From: Hugh Irvine [mailto:hugh at open.com.au] 
Sent: 16 April 2003 09:17
To: Surajh Surjoo [ MTN - Innovation Centre ]
Cc: Radiator Mailing List (E-mail); Radiator-Support (E-mail)
Subject: (RADIATOR) Re: Redundancy for RADIUS



Hello Surajh -

This is a difficult problem with no single good answer.

How do people on the list provide redundancy?

My personal view is that a single "high-availability" database server 
is best, but then you are back in the situation of having a single 
point of failure.

regards

Hugh


On Wednesday, Apr 16, 2003, at 17:59 Australia/Melbourne, Surajh Surjoo 
[ MTN - Innovation Centre ] wrote:

> Hi all
>
> We are using Radiator with two Ericsson CGSNs for GPRS.
> We allocate IPs from two different ranges using RADIUS and the two 
> CGSN are geograhically separated.
> The MySQL DB is configured on the same server as the Radiator radius 
> server.
> Problem we have is if one server goes down then no access to GPRS is 
> available to that CGSN.
> How can we improve this situation so that when one server goes down 
> then the CGSN will use the other server?
> Bear in mind that the IP pools would be different and the routing 
> through FW will not allow them through that server.
> What about having one DB supporting both radius servers with all the 
> IP pools and using the NAS identifier to then allocate IP?
> Would this work? What about the DB redundancy then?
>
> Has anyone implemented such a scenario? We have some ideas, but would 
> like your views. They might be better and easier ;-)
>
> regards
> Surajh Surjoo
> Systems Engineer - Data
> Mobile: 0832129829
> Mobile Fax: 083 8 2129829
> Office Fax: 011 3018811
> Office Tel: 011 3016000
> surajh.surjoo at mtn.co.za
>
> "Imagination is more important than Knowledge" - Albert Einstein
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20030416/7ab4cb3c/attachment.html>


More information about the radiator mailing list