Jay West wrote:
>
> Hugh wrote...
> > I would be inclined to put a UDP redirector in front of your Radiator
> hosts to
> > transparently handle any number of hosts at a single IP address.
>
> No problem, basically the cisco can do this - on later releases of IOS you
> can specify load balancing between multiple radius hosts.
If you're dealing with a single (or small number) of privately owned NAS
boxes, doing the load balancing work in the NAS boxes works. When you
get to the point of using dialup wholesalers, the stand-alone load
balancers which can spread UDP traffic to multiple hosts becomes an
interesting solution.
>
> >Then I would
> > put my SQL database on a dual-port RAID box and have both servers access
> the
> > same database. I would also have a single session database for multiple
> logon
> > restriction.
>
> This is a major no-no for high availability. It's a glaring single point of
> failure. We're hard over on not having any single points of failure,
> especially with our authentication services. It's true that having a single
> sql box with two separate dual channel controller cards going to drives that
> mirror from one controller to the other is a good thing. But there are more
> frequent problems that can be encountered than disk/controller failures.
> Someone pulls an ethernet cable. The video card or motherboard dies causing
> the system to die, the OS crashes, etc. There just has to be a better way of
> handling the back end.
You've got a few choices here.
1. Buy a fault tolerant box, such as Stratus Computer. No single points
of failure.
2. Build based on clustered technology: multiple servers, multiported
RAID arrays. Expensive, but workable.
2. Replicate your databases. Keep one server as a master, and clone out
your database to other servers.
>
> > And no, there are no problems with multiple radiator machines querying a
> single
> > database.
>
> What I meant by that last question was slightly different. Here's what I was
> thinking. Set the cisco to do round-robbin between the two different radius
> servers - thus load balancing. Each subsequent aaa request would go to the
> other radius server. Both radius servers would be configured to try one sql
> database (on sql machine1) and then another sql database (on sql machine2).
> This would be accomplished I believe in the radius config file. I seem to
> recall seeing that the radius config file can contain multiple authbySQL's
> (or in my case multiple authbyRADMIN's) for a single realm and thus radius
> would try one and then the next. If it didn't get a response from one, it
> would start using the other one until it didn't get a response from that one
> and then would move back to the first. At least, I seem to remember it being
> documented that way - I haven't tried it. This would seem to solve all my
> problems except I have two concerns. First, would it not be possible that
> one of the sql machines might go down, and one of the radius servers sees it
> so it switches to the other sql machine. Then say the failed sql machine was
> only down a split second and came back up before the next radius server
> tried to authenticate. Then you would have each radius machine talking to
> two different sql servers. This isn't that bad except for two items - I
> suspect your "users online" database would be messed up, and if you were
> trying to do simultaneous login checking it would be REALLY messed up. There
> are other scenarios I can think of that would cause the two radius machines
> to each be looking at a different sql server.
>
> I can't seem to get my head around this problem - but there just has to be a
> way.... :) Any advice is most appreciated!
>
> Jay West
>
> ===
> Archive at http://www.starport.net/~radiator/
> Announcements on [EMAIL PROTECTED]
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
--
-----------------------------------------------------------------
Daniel Senie [EMAIL PROTECTED]
Amaranth Networks Inc. http://www.amaranth.com
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
