Clustering allows us to run an applications on several parallel servers (a.k.a cluster nodes). The load is distributed across different servers, and even if any of the servers fails, the application is still accessible via other cluster nodes. Clustering is crucial for scalable enterprise applications, as you can improve performance by simply adding more nodes to the cluster.

The JBoss Application Server (AS) comes with clustering support out of the box.

The simplest way to start a JBoss server cluster is to start several JBoss instances on the same local network, using the run -c all command for each instance. Those server instances, all started in the all configuration, detect each other and automatically form a cluster.

For Web applications, a hardware- or software-based HTTP load-balancer usually sits in front of the application servers within a cluster. These load-balancers can be used to decrypt HTTPS requests quickly, distribute the load between nodes in the cluster, and detect server failures. The usual setup is to have a user session live entirely on one server that is picked by the load-balancer. This is called a "sticky" session.

Configuring JBoss to run in a cluster

So let's see how to configure 2 instances of JBoss in a cluster. We'll define two nodes nodeA and nodeB

Now for every installation of JBoss go under the folder "JBOSS_HOME\server\all\deploy\jboss-web.deployer" and pick up the file server.xml

fine the line:

<Engine name="jboss.web" defaultHost="localhost">

and for the machine 192.168.0.1 modify:

<Engine name="jboss.web" defaultHost="localhost" jvmRoute="nodeA">

and for the machine 192.168.0.2

<Engine name="jboss.web" defaultHost="localhost" jvmRoute="nodeB">
 

Now create an HelloWorld web application and add a Servlet which simply dumps some session information

public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {

 response.setContentType("text/html");
 String dummy = (String)request.getSession().getAttribute("dummy");

 PrintWriter out = response.getWriter();
 out.println("");
 out.println("");

 System.out.print("Hello from Node "+ InetAddress.getLocalHost().toString());

 if (dummy == null) {
  out.println("
Dummy value not found. Inserting it....");
  request.getSession().setAttribute("dummy", "dummyOk");
 }
 else {
  out.println("
Dummy is " +dummy);
 }

 out.println(" ");
 out.println("");
 out.flush();
 out.close();
}

before packing the application add at the very beginning of the web.xml file

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

<distributable/>

Ok so now you're ready to deploy the web application: where can I deploy it ?

The easiest way to deploy an application into the cluster is to use the farming service. That is to hot-deploy the application archive file (e.g., the EAR, WAR or SAR file) in the all/farm/ directory of any of the cluster member and the application is automatically duplicated across all nodes in the same cluster

You can only put archive files, not exploded directories, in the farm directory. This way, the application on a remote node is only deployed when the entire archive file is copied over. Otherwise, the application might be deployed (and failed) when the directory is only partially copied.

Ok, so now Jboss is ready to accept Cluster Web Applications, now we need at first something something sitting in front of our JBoss Cluster. We'll use for our purpose Apache Web Server.

for a detailed explanation of all steps necessary to configure Apache-JBoss via modJK we suggest you reading the Wiki http://wiki.jboss.org/wiki/UsingMod_jk1.2WithJBoss. Now we'll focus in particular on the part of the configuration relative to the cluster.

The first thing we need to have is redirecting calls to the mod_JK load balancer: this is done in file mod_jk.properties:

# Where to find workers.properties
JkWorkersFile conf/workers.properties

# Where to put jk logs
JkLogFile logs/mod_jk.log

JkMount /HelloWorld/* loadbalancer

Here HelloWorld is the Web Context of our sample application. Now let's move to workers.properties file.

worker.list=loadbalancer,status

worker.nodeA.port=8009
worker.nodeA.host=192.168.0.1
worker.nodeA.type=ajp13
worker.nodeA.lbfactor=1

worker.nodeB.port=8009
worker.nodeB.host=192.168.0.2
worker.nodeB.type=ajp13
worker.nodeB.lbfactor=1

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=nodeA,nodeB

# Status worker for managing load balancer
worker.status.type=status

As you can see we have the two nodes (nodeA and nodeB) with relative port and IP address.

Now launch the two instances of JBoss using the command run -c all. The first instance started will display this information when the second instance kicks in:

16:09:20,562 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-192.168.0.1-8009
16:09:20,578 INFO [Server] JBoss (MX MicroKernel) [4.2.0.GA (build: SVNTag=JBoss_4_2_0_GA date=200705111440)] Started in 1m:20s:438ms
16:10:28,343 INFO [TreeCache] viewAccepted(): [192.168.0.1:2300|1] [192.168.0.1:2
300, 192.168.0.2:2321]
16:10:28,421 INFO [TreeCache] locking the subtree at / to transfer state
16:10:28,593 INFO [StateTransferGenerator_140] returning the state for tree roo
ted in /(1024 bytes)
16:10:40,921 INFO [DefaultPartition] New cluster view for partition DefaultPart
ition (id: 1, delta: 1) : [192.168.0.1:1099, 192.168.0.2:1099]
16:10:40,984 INFO [DefaultPartition] I am (192.168.0.1:1099) received membership
Changed event:
16:10:40,984 INFO [DefaultPartition] Dead members: 0 ([])
16:10:40,984 INFO [DefaultPartition] New Members : 1 ([192.168.0.2:1099])
16:10:40,984 INFO [DefaultPartition] All Members : 2 ([192.168.0.1:1099, 192.168.0.2:1099])
16:10:45,187 INFO [TreeCache] viewAccepted(): [192.168.0.1:2309|1] [192.168.0.1:2 309, 192.168.0.2:2336]
16:10:47,453 INFO [TreeCache] viewAccepted(): [192.168.0.1:2313|1] [192.168.0.1:2 313, 192.168.0.2:2341]

Ok. In order to invoke our Servlet simply point to our Apache Web Server domain address

http://apache.web.server/HelloWorld/helloWorld

You'll see that the balancer load balances calls and, once it has created the session, it will replicate the session to the secondary server. You can do experiments to test your cluster, switching off one instance of the cluster and verifying that the session stays alive on the other server. 

Simply verify that the dummy values stays in the Session when you switch off the current instance of JBoss.

Dummy is dummyOk
 

Conclusion

JBoss clustering is designed to be simple to configure and simple to extend. It is one of the final pieces of the puzzle that makes JBoss a viable open source competitor to other enterprise J2EE offerings.

In the next article we'll see how to cluster EJB using simple annotations.

JBoss.org Search

Custom Search