Advanced Cluster Configuration Options

This section describes a small subset of the cluster configuration options that are more advanced to those described in Configuring a Simple tc Server Cluster, which describes how to set up a very simple cluster using mostly default values. Read this section if the default cluster values do not suit your needs.

In all cases the configuration requires you to add child elements or attributes to the basic <Cluster> element.

This section includes the following subsections:

tc Server clusters are highly configurable and this section describes only a few use cases. For additional and detailed information, see Clustering/Session Replication HOW-TO.

Changing the Default Multicast Address and Port

The default multicast address and port of a cluster are 228.0.0.4 and 45564, respectively. In certain cases, however, you might need to change these values; For example, you might want to configure two clusters on the same computer, one for testing and one for production. The easiest way to set this up is to specify different multicast/port combination for the two clusters.

To change the multicast address and port of a cluster, update the server.xml file for each tc Server instance that is a member of the cluster and add or update the <Membership> child element of the <Channel> element, which itself is a child member of the <Cluster> element. The details are shown in the following snippet:

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
   <Channel className="org.apache.catalina.tribes.group.GroupChannel">

      <Membership className="org.apache.catalina.tribes.membership.McastService"
                  address="228.1.0.4"
                  port="55564" /> 

   </Channel>

</Cluster>

Use the address and port attributes of the <Membership> element to set the multicast address and port; in the preceding example, the new values are 228.1.0.4 and 55564, respectively.

For additional information the <Membership> element, its default behavior, and the attributes you can set to further configure it, see The Cluster Membership Object.

Changing the Maximum Time After Which an Unresposive Cluster Member is Dropped

The default implementation of the cluster group notification is built on top of multicast heartbeats sent using UDP packets to a multicast IP address. As specified in the general cluster documentation, you group together cluster members by specifying the same multicast address/port combination (either using the default values or custom values). Each member then sends out a heartbeat within a given interval (frequency); this heartbeat is used for dynamic discovery. The cluster membership listener listens listens for these heartbeats; if the membership listener does not receive a heartbeat from a node within a certain timeframe (droptime), then the cluster considers the member suspect and notifies the chanel to take appropriate action.

The default frequency at which members send heartbeats (500 milliseconds) is typically adequate and you should never need to change it. On high-latency networks, however, you might want to increase the default value of the drop time (3000 milliseconds) to protect against false positives.

To change the drop time, update the server.xml file for each tc Server instance that is a member of the cluster and add or update the <Membership> child element of the <Channel> element, which itself is a child member of the <Cluster> element. The details are shown in the following snippet:

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
   <Channel className="org.apache.catalina.tribes.group.GroupChannel">
      <Membership className="org.apache.catalina.tribes.membership.McastService"
                  dropTime="6000" /> 
   </Channel>

</Cluster>

Use the dropTime attribute of the <Membership> element to set the drop time; in the preceding example, the new drop time value is 6000 milliseconds.

For additional information the <Membership> element, its default behavior, and the attributes you can set to further configure it, see The Cluster Membership Object.

Replicating a Session to a Single Backup Member

The default cluster configuration uses the DeltaManager object to enable all-to-all session replication, which means that the cluster replicates the session information (typically session deltas) to all the other nodes in the cluster, including nodes in which the application is not even deployed. (In this context, a node refers to a tc Server instance that is a member of the cluster.) All-to-all replication works well for smaller clusters that are made up of just a few nodes. However, the DeltaManager requires that all nodes in the cluster be homogeneous and that all nodes must deploy the same applications and be exact replicas.

Therefore, if you have configured a large cluster with many nodes, or you find the requirements of the DeltaManager too limiting, SpringSource recommends that you configure the cluster so that it replicates to just a single backup node by using the BackupManager object. The cluster ensures that the node to which it replicates also always have the application deployed. The location of the backup node is known to all nodes in the cluster. Finally, because the cluster is replicating to just one node, the cluster supports heterogenous deployment.

To configure use of a single backup node for session replication, add or update <Manager> child element of the <Cluster> element in the server.xml files for all tc Servers that are members of the cluster, as shown in the following snippet:

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
   <Manager className="org.apache.catalina.ha.session.BackupManager" /> 
</Cluster>

For additional information about the BackupManager, its default behavior, and the attributes you can set on the <Manager> element to further configure it, see The ClusterManager object.