[Linux-cluster] Geographical Load-Balancing/High-Availability ?!

Brain Stormer minoritystorm at gmail.com
Fri Nov 21 12:30:53 UTC 2008


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
<nlam87346 at library.usyd.edu.au>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 with
> layer 3 routing capabilities. You need this in order to migrate the IP
> addresses the services are published on between your two geographical
> locations. Once you can do this, your directors can encapsulate packets
> from the client back to your real servers using the ip-ip kernel module.
> My institution runs directors with keepalived and quagga OSPF routers on
> them.
>
> The rest can be done with standard RHCS, the only other non-standard
> thing you'll have to think about involves the multicasting of cluster
> communications. The main gotcha with this is that you have to set up an
> iptables rule to mangle the routing TTL of the multicast cluster
> communications packets to a large enough number of hops (the default is
> 1, which means it won't get outside your LAN) to get from one site to
> the other via the longest reasonable route.
>
> e.g.
>
>  iptables -A OUTPUT -d <destination_multicast_addr> -j TTL --ttl-set 30
>
> Think about the security of multicast routing these communications as
> well.
>
> The new CLVM RAID 1 coming in RHEL5.3 probably means that you can do all
> this without expensive proprietary back-end storage mirroring too.
>
> A couple of other points:
> * it really helps if you have good control of all the infrastructure
> between the two sites
> * the risk of split-brain is certainly higher than having all cluster
> nodes in the one datacentre.
>
> Regards,
>
> Nik
>
>
>
>
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20081121/30ae3b61/attachment.htm>


More information about the Linux-cluster mailing list