Loadbalancer.jar will fail a session over to a second Orion, if it can't open a
successful session within several seconds to the first (sticky) Orion. Works
great, but you have that single point of failure.
I'm experimenting with the MS Network Load Balancer (it comes in Win2K AS) and
the main issue I have seen is that it will peg a session to a single Orion/web
server. The only way it will fail over is if that server (hardware) or the MS
NLB software goes down. It does not monitor the servers/services that it pushes
to. The MS solution is to run a third party monitoring program to monitor that
back end program and then manually, or thru a script, drop the node from the
NLB cluster.
I'm thinking that Load Director does some type of monitoring. I know some of
the other hardware type devices do. The LinuxHA setups all have monitoring
(look at linuxDirector) as an integrated part of the load balancer.
I'm more of a unix/linux guy, but those are not options where I am, right now.
The MS NLB does not cost us anything and it clusters up to 32 nodes. It has
worked great so far, other than the monitoring gotchas. In our case, we have
had to hit Apache as a proxy and then onto Orion so that we can segregate the
multicast traffic - NT routing still is not quite unix/linux routing.
If the Cisco does some type of monitoring to notice a failed Orion node, you
should be able to cluster 2+ nodes behind the Load Director.
Good luck,
Bob
From: "Curt Smith" <[EMAIL PROTECTED]>@orionserver.com on 11/16/2001 11:01
PM EST
Please respond to "Orion-Interest" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
To: "Orion-Interest" <[EMAIL PROTECTED]>
cc:
Subject: Re: loadbalancer.jar: what does it do, really?
the loadbalancer.jar does sticky ip by default itself and we have had to turn
it off when because of the above issues.
How did you solve your problem?
Looking for thoughts on my problem; 2 boxes available for clustering.
I have a Cisco Director (SP?). But I don't have a 3rd box in production to
run the loadbalancer.jar on.
It would be a single point of failure anyway so???? How would a resilient
architecture be assembled
from what I have available?
One option that I see is to NOT cluster, and deploy several instances of Orion
across 2 boxes. Use
my Cisco Director HW loadbalancer to direct requests across the Orion
instances. If an instance failes
or locks up, Director is smart enough to stop routing requests to that Orion
instance.
This config just drops the customer's requests on that box or instance, and
delivers scalability across
two boxes. To me, this is preferable to a single box where if it fails
customers won't get service until
support comes in the next morning... :\
thanks, curt
