JGroups Protocol RELAY2: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 26: Line 26:


An important design goal of RELAY is to be able to support completely autonomous clusters: a local cluster must not block waiting for credits from other local cluster, or a node in the a local cluster doesn't have to ask a node from other local cluster for retransmission of a missing message.
An important design goal of RELAY is to be able to support completely autonomous clusters: a local cluster must not block waiting for credits from other local cluster, or a node in the a local cluster doesn't have to ask a node from other local cluster for retransmission of a missing message.
=The <tt>site</tt> Property=
The RELAY2 <tt>site</tt> property must be set consistently on all members of a local cluster:
<pre>
<relay.RELAY2 site="blue" config=".../relay2.xml" relay_multicasts="false"/>
</pre>


=Configuration=
=Configuration=
Line 44: Line 36:


==Configuration Attributes==
==Configuration Attributes==
===<tt>site</tt>===
The RELAY2 <tt>site</tt> property must be set consistently on all members of a local cluster:
<pre>
<relay.RELAY2 site="blue" config=".../relay2.xml" relay_multicasts="false"/>
</pre>


===<tt> max_site_masters</tt>===
===<tt> max_site_masters</tt>===


The number of nodes from the local cluster that will join the bridge cluster. By default is 1 (the coordinator).
The number of nodes from the local cluster that will join the bridge cluster. By default is 1 (the coordinator).

Latest revision as of 14:21, 8 June 2016

External

Internal

Overview

RELAY2 protocol was introduced to allow relaying (bridging) messages between two or more clusters.

The relaying mechanism works by establishing a "bridging cluster" between the participating local clusters. Each local cluster is "represented" in the bridging cluster by its coordinator, which is the only node in the local cluster that forwards messages to the coordinators of other clusters participating in the relaying process. The only members of the bridging cluster are the local group coordinators. A message sent to the bridging cluster reaches all its member, hence all participating clusters.

For two local clusters ("blue" and "red"), relaying works in both directions: messages passing between the members of cluster "blue" will be forwarded to cluster "red", eventually reaching all its members, while messages passing between the members of the cluster "red" will be forwarded to the cluster "blue"

JGroups RELAY2 1.png

The relaying mechanism is implemented at JGroups level by adding a RELAY2 protocol at the top of the stack. The RELAY2 protocol instantiates and starts a new JGroups channel, which is used to join the bridging cluster. Thus, the coordinator instance will run two parallel JGroups stacks. The bridging clusters typically use the TCP transport.

JGroups RELAY2 2.png

In case a local coordinator dies, the next local member takes over as coordinator, joins the bridging cluster in the process, and continues relaying messages.

An important design goal of RELAY is to be able to support completely autonomous clusters: a local cluster must not block waiting for credits from other local cluster, or a node in the a local cluster doesn't have to ask a node from other local cluster for retransmission of a missing message.

Configuration

This is an example of how to configure two Infinispan clusters to relay to each other:

Bridge Two Infinsipan Clustered Caches with RELAY2

Configuration Attributes

site

The RELAY2 site property must be set consistently on all members of a local cluster:

<relay.RELAY2 site="blue" config=".../relay2.xml" relay_multicasts="false"/>

max_site_masters

The number of nodes from the local cluster that will join the bridge cluster. By default is 1 (the coordinator).