JGroups Protocol RELAY2: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(5 intermediate revisions by the same user not shown)
Line 27: Line 27:
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=
=Configuration=
 
This is an example of how to configure two Infinispan clusters to relay to each other:
 
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Bridge Two Infinsipan Clustered Caches with RELAY2]]
</blockquote>
 
==Configuration Attributes==
 
===<tt>site</tt>===


The RELAY2 <tt>site</tt> property must be set consistently on all members of a local cluster:
The RELAY2 <tt>site</tt> property must be set consistently on all members of a local cluster:
Line 35: Line 45:
</pre>
</pre>


=Configuration=
===<tt> max_site_masters</tt>===
 
This is an example of how to configure two Infinispan clusters to relay to each other:


<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
The number of nodes from the local cluster that will join the bridge cluster. By default is 1 (the coordinator).
:[[Bridge Two Infinsipan Clustered Caches with RELAY2]]
</blockquote>

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).