A cluster deployment service can be of various types. Today we are going to discuss on one of its type, HASingleton cluster deployment service.
An HASingleton is a service which is deployed on multiple nodes on a cluster, but provides its service only on one of the nodes. The node which is running the singleton service is called the Master Node. When the master fails or is terminates, another node is elected to be a Master Node from the remaining nodes in the cluster, and the service is restarted on the new master. The remaining nodes are generally called Stand by Nodes or Slave Nodes.
JBoss provides mainly 2 election policies:
The Simple election policy selects a master node based the relative age. The required age is configured in the position property, which is the index in the list of available nodes where,
position = 0 – refers to the oldest node (the default)
position = 1 – refers to the 2nd oldest etc.
Position can also be negative to indicate the youngness. Imagine the list of available nodes as a circular linked list.
position = -1 – refers to the youngest node
position = -2 – refers to the 2nd youngest node etc.
<bean> <property name="position">-1</property> </bean>
Sometimes you need a specific node to be the master node whenever available. The Preferred Master election policy does this job. This ppolicy extends HASingletonElectionPolicySimple, allowing the configuration of a preferred node. The preferredMaster property, specified as host:port or address:port, identifies a specific node that should become master, if available. If the preferred node is not available, the election policy will behave as described above.
<bean> <property name="preferredMaster">server1:12345</property> </bean>
We will dig more on PreferredMasterElectionPolicy configuration with JBoss 5.x. Configuration steps are as below,
Step-1: Open the file ‘deploy-hasingleton-jboss-beans.xml‘ available in $JBOSS_HOME/server/$Profile/deploy/cluster folder and add the following bean,
<bean class="org.jboss.ha.singleton.PreferredMasterElectionPolicy" name="HSPreferredMasterElectionPolicy"> <property name="preferredMaster">0.0.0.0:1299</property> </bean>
Where. 0.0.0.0 is the IP Address and 1299 is the JNP Port. Replace IP and Port respective to your environment.
And, add the following property to HASingletonDeployer bean,
<property name="electionPolicy"><inject bean="HSPreferredMasterElectionPolicy"/></property>
<bean name="HASingletonDeployer" class="org.jboss.ha.singleton.HASingletonController"> <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.ha:service=HASingletonDeployer", exposedInterface=org.jboss.ha.singleton.HASingletonControllerMBean.class, registerDirectly=true)</annotation> <depends>HAPartition</depends> <!-- Have the BarrierController that listens for our JMX notifications start first. --> <depends>HASingletonDeployerBarrierController</depends> <property name="HAPartition"><inject bean="HAPartition"/></property> <property name="target"><inject bean="HASingletonProfileManager"/></property> <property name="electionPolicy"><inject bean="HSPreferredMasterElectionPolicy"/></property> <property name="targetStartMethod">activateProfile</property> <property name="targetStopMethod">releaseProfile</property> <!-- whether to register thread context classloader for the RPC handler, default is false --> <!--<property name="registerThreadContextClassLoader">false</property>--> <!-- Whether the singleton should be restarted (i.e. invoke the TargetStopMethod and then the TargetStartMethod) if a cluster merge occurs while this node is the singleton master. A cluster merge means there may have been more than one singleton master during the period when communication between some or all of the nodes in the cluster was disrupted; hence the surviving master may not be aware of state changes made by another master. Restarting the singleton gives it a signal that it should refresh its internal state from any external store. By default this is set to true. --> <property name="restartOnMerge">true</property> </bean>
Step-2: Deploy an HA Singleton service in the deploy-hasingleton folder.
Step-3: Start two or more nodes in the cluster partition.
Now, you would see that the HASingleton service would be deployed on the preferredmaster node!