Personally, I'm not too keen on DNS solutions. I use UltraMonkey, which
includes LDirectord, and it has provisions for some geographical load balancing
between real servers by using tunnels, but to me something isn't geographical
load balancing until you are dealing with separate sites handing off to one or
the other via internet with no direct connection. For me, I prefer using BGP
to provide this bit of geographic redundancy, but it doesn't really truly load
balance. As Nik noted, the chances of split-brain are increased like this...
so I always thought it would be interesting to set up a three-site geographic
load balancing setup and use a consensus to determine when the disconnected
node should accept that it is offline.
Just my thoughts, way too early in the morning.
Stephen
Date: Fri, 21 Nov 2008 14:30:53 +0200From: [EMAIL PROTECTED]: [EMAIL
PROTECTED]: Re: [Linux-cluster] Geographical Load-Balancing/High-Availability ?!
Well,From what I understand is that there will be a 3rd party handling the
communication of the Layer 3 routing (if I got you well), however the only
thing available right now is the physical nodes, I am also aware that such
setup would increase thee probability of a split-brain situation, I also did
not understand the part (need this in order to migrate the IP addresses the
services are published on between your two geographical locations), you mean if
a box is dead it will still have the capability to migrate the services to the
other one ?I am also thinking about about DNS based load-balancing, may be
creating DNS records at different DNS service providers and have each one a
different A record but I'vnt thought about how sessions/cookies/ssl/ftp would
be handled through this way ?Thanks so much!
On Fri, Nov 21, 2008 at 6:01 AM, Nikolas Lam <[EMAIL PROTECTED]> wrote:
On Fri, 2008-11-21 at 03:54 +0200, Brain Stormer wrote:> Hello,>> Could any
component from the `Red Hat Cluster Suite` be utilized to> achieve a
geographical load-balancing and high-availability system ?>> I know how to do
load-balancing/high-availability when both nodes are> allocated in the same
network however it happens that I have 2 nodes> allocated in different places
with different IP pool so I think> calling it geographical is the proper
word.>> Also if the `Red Hat Cluster Suite` does not have anything related to>
that, its might be helpful to know other techniques to achieve such> goal.>>
Any input is appreciated!I think the only thing that RHCS can't provide is an
LVS director withlayer 3 routing capabilities. You need this in order to
migrate the IPaddresses the services are published on between your two
geographicallocations. Once you can do this, your directors can encapsulate
packetsfrom the client back to your real servers using the ip-ip kernel
module.My institution runs directors with keepalived and quagga OSPF routers
onthem.The rest can be done with standard RHCS, the only other
non-standardthing you'll have to think about involves the multicasting of
clustercommunications. The main gotcha with this is that you have to set up
aniptables rule to mangle the routing TTL of the multicast
clustercommunications packets to a large enough number of hops (the default
is1, which means it won't get outside your LAN) to get from one site tothe
other via the longest reasonable route.e.g. iptables -A OUTPUT -d
<destination_multicast_addr> -j TTL --ttl-set 30Think about the security of
multicast routing these communications aswell.The new CLVM RAID 1 coming in
RHEL5.3 probably means that you can do allthis without expensive proprietary
back-end storage mirroring too.A couple of other points:* it really helps if
you have good control of all the infrastructurebetween the two sites* the risk
of split-brain is certainly higher than having all clusternodes in the one
datacentre.Regards,Nik--Linux-cluster mailing [EMAIL
PROTECTED]://www.redhat.com/mailman/listinfo/linux-cluster
_________________________________________________________________
Proud to be a PC? Show the world. Download the “I’m a PC” Messenger themepack
now.
hthttp://clk.atdmt.com/MRT/go/119642558/direct/01/
--
Linux-cluster mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-cluster
