This tutorial will cover AS 7 clustering capabilities that serve as an essential component to providing scalability and high availability to your applications. Actually, there is one more asset that can be achieved using clustering—you can spread the traffic load across several AS instances. Load balancing , however, is an orthogonal aspect of any Enterprise application that is generally achieved using a properly configured web server in front of the application server. So, we decided to move this information to the next tutorial, while in this tutorial we will discuss the following topics:
- We will describe all the available options to set up a cluster either using a standalone configuration or a domain of servers.
- We will show how to effectively configure the cluster-building blocks:
- The JGroups subsystem which is used for the underlying communication between nodes
- The Infinispan subsystem which handles the cluster consistency using its advanced data grid platform
- The Messaging subsystem which uses the HornetQ clusterable implementation
Setting up JBoss clustering
For the benefit of impatient readers, we will show straightaway how to get a cluster of AS 7 nodes up and running.
Earlier JBoss releases had their clustering libraries packed into the all server configuration which was de facto separated from the common default configuration.
We will repeat it once more: in AS 7 you don’t have any more server configurations bundled with libraries and configuration files. All you have to do to shape a new server profile is create a new XML configuration file.
Because the standalone server can just hold a single profile, AS 7 ships with a separated configuration file named standalone-ha.xml, which contains all the clustering subsystems.
On the other hand, a domain server is able to store multiple profiles into the core domain.xml configuration file, hence you can use this file both for clustered domains and for non-clustered domain servers.
Setting up a cluster of standalone servers
A cluster of standalone servers is a common option for a development/test environment. Nothing prevents you from using it also on your production system; however, you would need to arrange some tools for managing your cluster nodes, which are built-in domain of servers.
The possible cluster configurations for standalone servers can be broken in two main scenarios:
- Cluster of AS nodes running on different machines
- Cluster of AS nodes running on the same machine
Let’s see each cluster scenario:
Cluster of nodes running on different machines
If each server application is installed on a dedicated machine you are planning a horizontal-scaled cluster. In terms of configuration, this one requires the least effort— all you have to do is binding the server to its IP address in the single standalone servers and start the server using a clustered-compliant configuration. Let’s build an example
with a simple two-node cluster as illustrated in the picture:
Open the standalone-ha.xml file on each AS 7 distribution and reach to the interfaces section. Within the nested interface element insert the IP address of the standalone server. For the first machine (192.168.10.1), we will define:
On the second machine (192.168.10.2), we will bind to the other IP address:
That’s the only thing you needed to change in your configuration. To start the cluster, you have to indicate that your standalone servers will be using the standalone-ha.xml configuration file.
Starting from Release 7.0.2, the –b option has been resurrected to provide the server binding address. In addition, you can use the –bmanagement flag to specify the management-interface address. The previous configuration can, therefore, be rewritten for the first server as:
standalone.bat –server-config=standalone-ha.xml –b 192.168.10.1 – bmanagement 192.168.10.1
And for the second server as:
standalone.bat –server-config=standalone-ha.xml –b 192.168.10.2 – bmanagement 192.168.10.2
In a matter of seconds, your servers will be running, however we didn’t find any details about clustering nodes in the console, why? One of the most evident differences between JBoss AS 7 and earlier releases is that the clustering services are started on demand and stop once you don’t need them anymore. Hence, simply starting the
clustering, without any clustered-enabled application, will not initiate any service or channel.
So, in order to verify our installation, we will deploy a bare bones, cluster-enabled, web application named Example.war. To enable clustering of your web applications, you must mark them as distributable in the web.xml descriptor:
When deploying the application on both machines, you will find out that clustering services are now started and that each machine is able to find out the cluster members.
JBoss AS 7 does not use any more the concept of farm deployment. By farm deployment we mean a central repository where you can load (or unload) your applications across the cluster. If you are deploying an application to a domain of servers you can choose on which server groups the application is going to be deployed, hence a farm deployment folder is not needed at all.
If you are going to distribute your application to a set of standalone nodes, your best strategy is creating a CLI script that deploys your application to all your server nodes. For example, create a file named deploy.cli: connect 192.168.10.1 deploy Example.war connect 192.168.10.2 deploy Example.war Now you can execute this script using the jboss-admin.bat shell (Notice the flags—username and—password for connecting to a remote management interface): jboss-admin.bat –user=username –password=password –file=deploy.cli
Now you can execute this script using the jboss-admin.bat shell (Notice the flags— username and—password for connecting to a remote management interface): jboss-admin.bat –user=username –password=password –file=deploy.cli