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 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 > [email protected] > https://www.redhat.com/mailman/listinfo/linux-cluster >
-- Linux-cluster mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-cluster
