13.3. Separating Clusters

As discussed in Section 4.2, “Standard Server Configurations”, the production configuration is based on the all configuration and supports clustering as a result. Server instances that run on the same network, which are started using the default configuration settings, will belong to the same cluster. As such, it is important to understand how to separate clusters during server startup. This will be required, for instance, to separate test clusters from production clusters.
The attributes and settings discussed below will be covered in detail in the sections that follow. They are introduced here to emphasize the importance of separating clusters during server startup. The relevant MBeans and their associated properties (PartitionName and mcast_addr) both require modification to successfully separate clusters.
The HAPartition MBean

Starting JBoss servers with their default clustering settings on a local network results in a default cluster named DefaultPartition that includes all server instances as its nodes. This setting is defined in the HAPartition MBean definition packaged with the standard JBoss AS distribution as in the following code sample: 

<mbean code="org.jboss.ha.framework.server.ClusterPartition"
  name="jboss:service=DefaultPartition">
			
  <! -- Name of the partition being built -->
  <attribute name="PartitionName">
    ${jboss.partition.name:DefaultPartition}
  </attribute>
  
  ...
  ...
   
</mbean>
PartitionName is an optional attribute to specify the name of the cluster. Its default value is DefaultPartition as indicated in the code sample above. It is necessary to use the -g (a.k.a. --partition) command line switch to set this value at JBoss startup and create unique cluster (group) names. 
/run.sh -g QAPartition -b 192.168.1.100 -c all
As will be discussed in Section 13.4, “HAPartition” to follow, the nodes that form a cluster must have exactly the same PartitionName and ParitionConfig elements. ParitionConfig elements are defined in the Cluster Partition MBean which will be discussed briefly here.
The Cluster Partition MBean

Section Section 20.1, “JGroups Configuration” discusses how the JGroups framework provides services to enable peer-to-peer communications between nodes in a cluster.

JGroups configurations often appear as a nested attribute in cluster related MBean services, such as the PartitionConfig attribute in the ClusterPartition MBean or the ClusterConfig attribute in the TreeCache MBean. The behavior and properties of each protocol in JGroups can be configured via the MBean attributes. Below is an extract of a JGroups configuration in the ClusterPartition MBean showing the UDP protocol configuration: 
<mbean code="org.jboss.ha.framework.server.ClusterPartition"
  name="jboss:service=${jboss.partition.name:DefaultPartition}">
	 
  ... ...
	 
  <attribute name="PartitionConfig">
    <Config>
	  <UDP mcast_addr="${jboss.partition.udpGroup:228.1.2.3}" 
		   mcast_port="${jboss.hapartition.mcast_port:45566}"
		   tos="8"
		   ucast_recv_buf_size="20000000"
		   ucast_send_buf_size="640000"
		   mcast_recv_buf_size="25000000"
		   mcast_send_buf_size="640000"
		   loopback="false"
           discard_incompatible_packets="true"
           enable_bundling="false"
           max_bundle_size="64000"
           max_bundle_timeout="30"
           use_incoming_packet_handler="true"
           use_outgoing_packet_handler="false"
           ip_ttl="${jgroups.udp.ip_ttl:2}"
           down_thread="false" up_thread="false"/>
           ...
           ...
    </Config>
  </attribute>
</mbean>
The mcast_addr above specifies the multicast address (class D) for joining a group (i.e., the cluster). If omitted, the default is 228.8.8.8. The -u (a.k.a. --udp) command line switch may be used to control the multicast address used by the JGroups channels opened by all standard AS services. 
/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c all
This switch sets the jboss.partition.udpGroup system property as indicated in the above ClusterPartition MBean code sample.

Important

The production server configuration is based on the all configuration and supports clustering as a result. Any server instance started using the default production configuration, that is located on the same network, will form part of single default cluster. Test clusters may inadvertently from a part of a production cluster unless the -u and -g flags are set during server startup as described above.