Deploy JBoss Clusters

A cluster is a group of servers running simultaneously to process requests from the clients and a node is a server instance. With collaboration, these nodes can provide high availability, reliability, and scalability.

The JBoss Enterprise Application Server Platform supports clustering service, which allows an application to run on multiple, parallel servers. The features include load balance, fail over, http session replication, and so on.

In the following section, an example JBoss cluster environment is created that is composed of the four following nodes, as shown in: node1.server, node2.server, node3.server, and node4.server. These servers are a mixture of various Linux distributions on different hardware architectures as shown in Table 5..

Table 5 Cluster Nodes

Server Name	Linux Distribution and Version	Hardware Environment
`node1.server`	RHEL5	HP Proliant Bladesystem Server x86_64
`node2.serve`r	RHEL5	HP Proliant Bladesystem Server i386
`node3.server`	SLES10	HP Proliant Bladesystem Server x86_64
`node4.server`	RHEL5	HP Integrity Server

Load Balancing and Failing Over

The Apache Web Server with the mod_jk module as the load balancer is used to process all requests and dispatch them to the back-end cluster node, which are transparent to the client. The load balance policy can also be set through configuration of the mod_jk module.

Configure the mod_jk module by performing the following steps:

Verify mod_jk is installed by entering the following command:
# ls /etc/httpd/modules

Append the following contents to the end of the /etc/httpd/conf.httpd.conf file:

# Add this to the end of httpd.conf
 LoadModule jk_module modules/mod_jk.so

<IfModule mod_jk.c>
    Include conf/modjk.conf
</IfModule>

Create a file named /etc/httpd/conf/modjk.conf and add the following contents:

JkLogFile logs/modjk.log
JkLogLevel info
JkWorkersFile conf/jkworkers.properties
JkMountFile conf/jkmount.properties

# JK Balancer manager
<Location /status/>
    JkMount jkstatus
    Order deny,allow
    Allow from  all
</Location>

Create a file named /etc/httpd/conf/jkworkers.properties and add the following contents:

worker.list=jboss,jkstatus

# First Node
worker.node1.type=ajp13
worker.node1.host=node1.server
worker.node1.port=8009
worker.node1.lbfactor=1
worker.node1.disabled=false
worker.node1.socket_timeout=10
worker.node1.connect_timeout=20000

# Second Node
worker.node2.type=ajp13
worker.node2.host=node2.server
worker.node2.port=8009
worker.node2.lbfactor=1
worker.node2.disabled=false
worker.node2.socket_timeout=10
worker.node2.connect_timeout=20000

# Third Node
worker.node3.type=ajp13
worker.node3.host=node3.server
worker.node3.port=8009
worker.node3.lbfactor=1
worker.node3.disabled=false
worker.node3.socket_timeout=10
worker.node3.connect_timeout=20000

# Fourth Node
worker.node4.type=ajp13
worker.node4.host=node4.server
worker.node4.port=8009
worker.node4.lbfactor=1
worker.node4.disabled=false
worker.node4.socket_timeout=10
worker.node4.connect_timeout=20000
# Load balancer
worker.jboss.type=lb
worker.jboss.balance_workers=node1,node2,node3,node4
worker.jboss.sticky_session=true
worker.jboss.sticky_session_force=false
worker.jboss.method=R
worker.jboss.lock=P

worker.jkstatus.type=status




	NOTE: The value for `worker.nodeX.host` is represented in this step as `nodeX.servers`. This should be replaced for each JBoss Enterprise Application Servers hostname or IP address. For this example, node1.server is used for the host system.

Create the file /etc/httpd/conf/jkmount.properties and add the following contents:
/jmx-console/*=jboss
/Counter/*=jboss
Restart the Apache Web Server by entering the following:
# /etc/init.d/httpd restart

Configuring JBoss Nodes

To configure the JBoss nodes, perform the following steps:

Verify the JDK installed. See “Verifying the Linux Installation” for detailed steps.
Verify JBoss is installed. See “Installing and Configuring JBoss ” for detailed steps.
Configure JBoss node1 on node1.server as follows:
1. Copy server/all to server/node1 by entering the following:
  # cp $JBOSS_HOME/server/all $JBOSS_HOME/server/node1
2. To differentiate between the JBoss Server instances, each cluster node must have an individual name. Add the jvmRoute attribute, with the syntax jvmRoute="nodeX”, in the file $JBOSS_HOME/deploy/jboss-web.deployer/server.xml by making the following change:
  Locate the line which contains the following:
  <Engine name=”jboss.web” defaultHost=”localhost”>,
  Change it to the following:
  <Engine name=”jboss.web” defaultHost=”localhost” jvmRoute=”node1”>
3. Turn on UseJK in the $JBOSS_HOME/server/node1/deploy/jboss-web.deployer/META-INF/jboss-service.xml file by making the following change:
  Locate the line which contains the following:
  <attribute name=”UseJK”>false</attribute>
  Change the attribute value to true as follows:
  <attribute name=”UseJK”>true</attribute>
Start the JBoss Services by entering the following:
# cd /usr/local/jboss/bin
# $JBOSS_HOME/bin/run.sh -c node1 -b 0.0.0.0
Repeat Steps 1 to 4 on the remaining three JBoss server node systems. Replace node1 with the appropriate node number (nodeN).

Deploying Web Applications

Create a Web application directory tree by entering the following:
# mkdir -p /tmp/Counter/WEB-INF
# mkdir -p /tmp/Counter/META-INF

Create the file /tmp/Counter/WEB-INF/web.xml and add the following lines:

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app>
  <description>JBoss Clustering Session Replication Test</description>
  <distributable/>
</web-app>

Create the file /tmp/Counter/WEB-INF/jboss-web.xml file and add the following contents:

<?xml version="1.0" encoding="ISO-8859-1"?>
<jboss-web>
  <replication-config>
     <replication-granularity>ATTRIBUTE</replication-granularity>
      <replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger>
  </replication-config>
</jboss-web>

Create the file /tmp/Counter/META-INF/context.xml file and add the following contents:

 <Context path="/Counter" docBase="Counter" debug="1" reloadable="true">
  </Context>

Create the file /tmp/Counter/index.jsp and add the following contents:

<%@ page import="java.io.*"%>
<%
  session = request.getSession(true);
  Integer ival = (Integer)session.getAttribute("simplesession.counter");
  if (ival == null) ival = new Integer(1);
  else ival = new Integer(ival.intValue() + 1);
  session.setAttribute("simplesession.counter", ival);
  System.out.println(session.getId()+", refresh count:" + ival);
%>

<html>
<head>
<title>Simple Session</title>
<body>
session ID: <%=session.getId()%><p>
 You have hit this page <%= ival %> times<p>
</body>
</html>

Build the WAR file by entering the following:
# cd /tmp/Counter/
# jar cf Counter.war *
Deploy the WAR file to node1 by entering the following:
# cp /tmp/Counter/Counter.war $JBOSS_HOME/server/node1/farm/
The other nodes are automatically deployed by the JBoss farm.

Testing Load Balance

Run the Apache Benchmark tool to verify the load balance is working.

Verify you have installed the Apache httpd RPM package before by entering the following:

# ab –n 1000 –c 10 http://node1.server/Counter/index.jsp




	TIP: The option `-n` specifies total request numbers and the option `–c` specifies concurrent requests.

From the console of each JBoss Server node, you should see messages similar to the following:

21:43:50,717 INFO  [STDOUT] z0FOv8evAScvu6jPLlcLXQ**.node3, refresh count:1
21:43:50,718 INFO  [STDOUT] Q1tDFMtcneh-cvf4GScuxw**.node3, refresh count:1
21:43:50,721 INFO  [STDOUT] M3RIwe4JOFCcPQnbYHBh7w**.node3, refresh count:1
21:43:50,728 INFO  [STDOUT] wBsMDBy-c0VwRxAaA3KZ+g**.node3, refresh count:1
21:43:50,731 INFO  [STDOUT] e0kpvsSgRKJ0FQhs5BXvhQ**.node3, refresh count:1
21:43:50,731 INFO  [STDOUT] Rd8cYEiL-065O7WPQcuSlA**.node3, refresh count:1
21:43:50,735 INFO  [STDOUT] 1gaI7wMnXUmmBTgbtiFKGw**.node3, refresh count:1
21:43:50,737 INFO  [STDOUT] 0C0zu41PErHtY9Vlwn6Ttg**.node3, refresh count:1
21:43:50,741 INFO  [STDOUT] khiU+5IOW-bWPLH89pRGqA**.node3, refresh count:1

The string between [STDOUT] and refresh count is the session id which also contains the node number as the suffix. If a similar log is displayed on all nodes, this indicates that all nodes are responding to the requests from the Apache Web Server front-end and the load balance is functional.

Testing Fail Over

Open a Web browser and navigate to the following URL:
http://node1.server/Counter/
Figure 26 is displayed:
Figure 26 Failover Test-1
To determine which node is currently serving, look at the end of the first line.

From the console for that node, stop the JBoss Enterprise Application Server by pressing Ctrl+C.

The remaining nodes receive the membership change event which is sent to the console. The log information displayed to the console should be similar to the following:

22:11:13,249 INFO  [DefaultPartition] New cluster view for partition DefaultPartition: 
13 ([10.100.0.97:1099, 
10.101.1.86:1099, 10.101.1.80:1099] delta: -1)
22:11:13,249 INFO  [DefaultPartition] I am (10.101.1.80:1099) received membershipChanged event:
22:11:13,249 INFO  [DefaultPartition] Dead members: 1 ([10.101.1.78:1099])
22:11:13,249 INFO  [DefaultPartition] New Members : 0 ([])
22:11:13,249 INFO  [DefaultPartition] All Members : 
3 ([10.100.0.97:1099, 10.101.1.86:1099, 10.101.1.80:1099])

Refresh the Web page. Similar log information is displayed as in Figure 27, however, the end of the first line is no longer node1 and now appears as node2. This demonstrates that the failover succeeded because node2 took over the response from the dead node1.
Figure 27 Failover Test-2

Replicating an HTTP Session

HTTP session replication is used to copy the Web client state from one node to other nodes in a cluster environment. When one node fails, another node in the cluster is able to continue processing client requests without interruption. The following steps assume that you have already created a clustering environment as detailed previously in this section.

Open a browser and navigate to the following URL:
http://node1.server/Counter/
As displayed in Figure 28, the session ID is displayed at the end of the first line (for this example it is node2) the node number is included in the URL, and the visitor counter appears.
Figure 28 Simple Session-Replication Node1
Navigate to the node console and locate node1. Stop the JBoss Enterprise Application Server by pressing Ctrl+C.
The cluster membership change event is submitted to the network and received by the other nodes.
Do not close the browser. Refresh the Web page and the same session ID should appear but with a different node number as displayed in Figure 29.
The visitor counter should have increased by one. This indicates your session was successfully replicated to other nodes. Even if one of the JBoss nodes is down, the session is not lost.
Figure 29 Simple Session-Replication Node2

Replicating Buddy Nodes

Buddy replication is different from the default replication in a cluster because it only replicates data to a certain number of nodes, not all nodes in a cluster. This reduces the impact on network traffic during replication because a smaller number of nodes are involved in replication.

The following steps assume that you have already created a clustering environment as detailed previously in this section.

For all four nodes, edit the file $JBOSS_HOME/server/nodeX/deploy/jboss-web-cluster.sar/META-INF/jboss-service.xml by making the following change:
Locate the line which contains the following:
"<buddyReplicationEnabled>false</buddyReplicationEnabled>"
Change the attribute value to true as follows:
"<buddyReplicationEnabled>true</buddyReplicationEnabled>"
For node1 and node2, edit the file $JBOSS_HOME/server/nodeX/deploy/jboss-web-cluster.sar/META-INF/jboss-service.xml by making the following change:
Locate the line which contains the following:
"<buddyPoolName>default</buddyPoolName>"
Change the attribute value to mygroup1 as follows:
"<buddyPoolName>mygroup1</buddyPoolName>"
This designates node1 and node2 as buddies, with node2 acting as the backup for node1.
For node3 and node4, edit the file $JBOSS_HOME/server/nodeX/deploy/jboss-web-cluster.sar/META-INF/jboss-service.xml by making the following change:
Locate the line which contains the following:
"<buddyPoolName>default</buddyPoolName>"
Change the attribute value to mygroup2 as follows:
"<buddyPoolName>mygroup2</buddyPoolName>"
This designates node3 and node4 as buddies, with node4 acting as the backup for node3. If node1 and node2 both fail, either node3 or node4 are chosen as the backup node.
To configure the JMX console for testing, edit the $JBOSS_HOME/server/nodeX/conf/props/jmx-console-users.properties file and uncomment the following line:
#admin=admin
Restart all JBoss Application Services on all four nodes by entering the following:
# cd /usr/local/jboss/bin
# $JBOSS_HOME/server/nodeX/conf/props
Open the counter application by launching a browser and navigating to the following URL:
http://node1.server/Counter/
The JMX console security dialog box is displayed.
To login, enter admin as the value for both the username and password.
As shown in Figure 30, the JMX Agent View is displayed with the session ID.
Figure 30 Simple Session-Buddy Replication Node1
Open the JMX console for node2 (the buddy to node1) by launching a browser and navigating to the following URL:
http://node2.server:8080/jmx-console/
The simple session buddy replication appears, as displayed Figure 31.
Locate the service=TomcatClusteringCache link and click on the link.
Figure 31 Simple Session-Buddy Replication Node2
Click on Invoke to run the method printDetails()(), as displayed in Figure 32.
Figure 32 MBean Inspector
As displayed in Figure 33, the session should be replicated from node1 while the session ID number should remain the same as in Step 6.
Figure 33 JMX MBean Operation Results-Buddy Node2
Open a browser and navigate to a non-buddy node, such as node3. Access the node3 JMX console by navigating to the following URL:
http://node3.server:8080/jmx-console/
Locate the service=TomcatClusteringCache link and invoke the printDetails()() method. As displayed in Figure 34, the results show that no session was copied.
Figure 34 JMX MBean Operation Results-Non-Buddy Node3