Load-balancing with mod_cluster
Mod_cluster is an HTTP-based load balancer, which, like mod_jk, can be used to forward a request to a set of application server instances. The advantage of using mod_cluster against mod_jk and mod_proxy can be summarized in these key points:
1. Dynamic clustering configuration.
2. Server-side pluggable load metrics.
3. Lifecycle notifications of application status.
Let’s see each point in more detail. As we have just learnt, when using a standard load balancer like mod_jk, you have to provide a static list of nodes that are used to spread load. This is a very limiting factor, especially if you have to deliver upgrades to your configuration by adding or removing nodes or you simply need to upgrade releases used
by single nodes. Besides this, using a flat cluster configuration can be tedious and prone to errors, especially if the number of cluster nodes is high.
When using mod_cluster, you are able to dynamically add or remove nodes to your cluster because cluster nodes are discovered through an advertising mechanism. In practice, the mod_cluster libraries on the httpd side send UDP messages on a multicast group, which is subscribed by AS7 nodes. This allows AS7 nodes the automatic discovery of httpd proxies where application lifecycle notifications are sent.
The next diagram illustrates the concept better:
mod_cluster is implemented as a core AS 7 module, which is a part of the distribution and, on the httpd side, as a set of libraries installed on the Apache web server.
On the JBoss AS 7 side, you can find already bundled the mod cluster’s 1.1.3 module as part of the clustered configuration file. You can find it either in the standalone-ha.xml file or in the domain.xml configuration file:
This is just a bare-bones declaration that references its socket-binding through the advertise-socket element:
<socket-binding name=”modcluster” port=”0″ multicastaddress=”
In the next section of this chapter, we will show how to customize the module configuration; for the time being, the great news is that you don’t have to install anything on the application server to get started.
On the Apache web server side, we have to install the core libraries, which are used to interact with mod_cluster. This is a very simple procedure: point the browser to the appropriate download page for your mod_cluster release. For mod cluster 1.1.3, the correct download page is located at http://www.jboss.org/mod_cluster/downloads/1-1-3.
From there, download the binaries for your platform, which contains a built-in httpd server and its modules. For example, if you are planning to run Apache web server on a Windows 32-bit machine, download the following binaries:
Once the binaries are downloaded extract the archive to a folder, for example, C:\modcluster. Then, navigate into the extracted folder. As you can see, mod cluster binaries consist essentially of a bundled Apache web server with all required libraries installed.
So, whether you choose to use your own Apache web server or the bundled one, you have to load the following libraries into your httpd.conf file. This is the list of modules that are needed for mod_cluster to get working:
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so
These libraries are located in the bundled Apache distribution (in our example, C:\mod_cluster\httpd-2.2\modules). You have to copy all the previous modules into your Apache distribution, as shown by the following screenshot:
Each of these modules covers an important aspect of the load balancing: mod_proxy and mod_proxy_ajp are the core modules, which forward requests to cluster nodes using either the HTTP/HTTPS protocol or the AJP protocol.
Next, mod_manager is a module that reads information from AS 7 and updates the shared memory information in conjunction with mod_slotmem . The mod_proxy_cluster is the module that contains the balancer for mod_proxy . Finally, the mod_advertise is an additional module that allows httpd to advertise via multicast packets—the IP and port—where the mod_cluster is listening.
The next part of the configuration that we need to add is the core load-balancing configuration:
Deny from all
Allow from 192.168.10.
Basically, you have to replace the 192.168.10.1 IP address with the one where your Apache web server listens for requests, and the port value of 8888 with the one you want to use for communicating with JBoss AS.
As it is, the Apache Virtual Host allows incoming requests from the sub-network 192.168.10.
The KeepAliveTimeout directive allows reusing the same connection within 60 seconds. The number of requests per connection is unlimited, since we are setting MaxKeepAliveRequests to 0. The ManagerBalancerName provides the balancer name for your cluster (defaults to mycluster).
Most important for us is the ServerAdvertise directive, which sets to On and uses the advertise mechanism to tell the JBoss AS to whom it should send the cluster information.
In-depth on the advertising mechanism
The default multicast IP address and port used for advertising are 22.214.171.124:23364. These values match the AS 7 bindings defined in the socket-binding name:
<socket-binding name=”modcluster” port=”0″ multicastaddress=” 126.96.36.199″ multicast-port=”23364″/>
Bear in mind that if you change these values, you have to match it on the httpd side with
the AdvertiseGroup directive:
You can also refine the time elapsed between multicasting advertising messages with the AdvertiseFrequency directive, which defaults to 10 seconds:
Now, restart Apache web server and the single application server nodes.
If you have correctly configured the mode cluster on the httpd side, you will see that each JBoss AS node will start receiving UDP multicast messages from mod_cluster: