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!
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@xxxxxxxxxxxxxxxxxxx> wrote:
I think the only thing that RHCS can't provide is an LVS director with
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!
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
-- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
