Need help with JGroup traffic in case of network failure

[j.hedin]

Hi all

We have a cluster of two Linux machines with two Suse Enterprice Linux 9 machines running JBoss 4.0.4.GA in a cluster. The cluster interconnect is two separate ethernet lines. Linux heartbeat and MySQL traffic works over both lines in case of a network failure. However, I am only capable of sending the JGroup traffic over a single line. How do we protect the cluster from a split brain senario? I saw that in JGroups 2.2.9, there was an option to always send mcast over all interfaces. Will this work with JBoss cluster and cache?

TIA

Johan Hedin

[belaban]

Yes, although this is not load balancing the traffic over the 2 network, this is sending the *same* traffic over both lines, so this is costly.

[j.hedin]

Thanks for the rapid answer

Extra load is workable. My main consert was if there was any problem with that a cluster node gets multiple copies of the messages. My second consert is if there is problem with multiple joining of groups. The third consert was the external interface, which will block the cluster traffic through IP tables.

Is there an alternative solution?

[belaban]

"J.Hedin" wrote:
Thanks for the rapid answer

Extra load is workable. My main consert was if there was any problem with that a cluster node gets multiple copies of the messages.

Yes, each node gets 2 copies of a message, but since we tag each message with a sequence number, the 2nd duplicate message will simply be discarded.

My second consert is if there is problem with multiple joining of groups.

You're not joining multiple groups, it is just the transport protocol in JGroups wich sends the *same* traffic out via 2 interfaces rather than 1.

[j.hedin]

Perfect. Sounds like a working solution for a fault tolerant cluster interconnect. Will do some tests on the development servers.

Thanks

Johan Hedin

[belaban]

Yes. In the future, we could think about writing additional transports, whcih for example multiple the entire traffic across multiple networks, this might even result in better performance. But that's for the future... :-)