The JBoss Application Server is a widely used and very popular J2EE certified platform for deploying enterprise Java applications. The Application server supports all J2EE 1.4 features and includes support for clustering, caching and persistence.

This article will give you an overview of how ZXTM from Zeus Technology can be used to load balance a JBoss application server cluster.

Contents

• Prerequisites
• Example Topology
• Basic configuration
• Passing the client IP address
• Session persistence
• Load balancing algorithms
• SSL offload

Prerequisites

• ZXTM version 4.0 or later is required.
• JBOSS Application Server

This document will assume that the reader has already configured their JBoss cluster and installed ZXTM on one or more machines in front of this cluster. For help with the initial set up of ZXTM you may refer to the getting started guide.

Topology

In our test environment we will run a cluster of two JBoss servers and will deploy a test application across it. We will have a cluster of ZXTM appliances in front of the JBoss cluster to load balance incoming connections.

Basic Configuration

To set up a simple service to load balance traffic to the JBoss cluster we will need to perform the following actions.

1. Create a Traffic IP Group
2. Create a new service for the JBoss cluster using that Traffic IP Group.

Create a Traffic IP Group

Go to services -> Traffic IP Group, and create a new traffic IP group, containing the external IP address(es) to which the host names of your websites resolve. The example group is named “JBoss Cluster”

Create a new service

We will use the “Manage a new service” wizard to manage a new virtual server and pool.

We want to manage a new service using protocol HTTP and port 80. We can call this service “JBoss Cluster”

On the next screen we need to add all the JBoss cluster members as nodes.

Click “Next” to review the configuration and finish the set up. You will then need to go to Services -> Virtual Servers -> JBoss Cluster and bind the service to the Traffic IP Group created earlier. Your JBoss Cluster service should now be running. You can return to the home page of ZXTM and the green play button should be highlighted next to your new service.

Passing the Client IP to JBoss

Other J2EE application servers we have tested provide a http server component and it is usually this component that handles the magic that informs the J2EE containers of the remote IP and security details of the connection. JBoss does not provide a http server and we have been unable to find a way to send the client IP to JBoss directly. This leaves you with two options. You can either run a web server in front of JBoss running one of our ZXTM web server modules to preserve the clients IP. Or if you are running ZXTM software on GNU/Linux or have a ZXTM appliance you can use the IP Transparency module.

Using a web server

Currently we provide web server modules for the following third party web servers, Apache, SunONE, iPlanet and Sun Java Server. You can download the appropriate modules from the ZXTM Knowledgehub article "Achieving IP transparency with ZXTM"

If you are running Zeus Web Server (ZWS) you do not need to add a module as it already has support for the X-Cluster-Client-IP header set by ZXTM. To enable this support you need to set the following flag in your global.cfg: balancer!enabled yes

Using IP Transparency

If you are using a Zeus appliance the module will be included and must be enabled on the pools you wish to use transparency with. If you are using the software version of ZXTM on a supported Linux kernel, you will need to download the source and follow the instructions listed on the KnowledgeHub article "IP Transparency with the ZXTM software".

For more information regarding the IP Transparency module you should read Section 2.4: 'IP Transparency' in the ZXTM User manual.

Enabling Session Persistence

The JBoss server can manage session replication internally and ensure that all cluster members have the session data. If your application does not make use of this JBoss feature, or you choose not to use it, you can use ZXTM persistence classes to ensure clients always hit the correct server. The best methods to achieve this are:

1. Monitor Application Cookie
2. URL rewriting

The combination of monitor application cookie and URL rewriting are the suggested methods to use with JBoss as these will catch clients with and without cookies enabled.

Note: This only works for browsers without cookies if you use the J2EE encodeURL() method from HTTPServletResponse to generate your URLs. When you create a session the application server will set a JSESSIONID cookie which can be used by ZXTM to ensure that all requests with this session are sent back to the same node. If the client does not accept the cookie encodeURL() will add the jsessionid as a parameter to the request. eg http://some.web.server/some/path;jsessionid=xxxxxxxxx

Monitoring Application Cookies

Go to Services -> Pools -> [your JBoss cluster] and click on the "Session Persistence" link. Click the "Create New Session Persistence Class" link, and create a class named "jsessionid_cookie". Set this class to "Monitor Application Cookies" and set the cookie name to "JSESSIONID".

Leave the failure mode set to "choose a new node to use". This will cause ZXTM to send the request to a different node if the persistent node isn't available.

URL Rewriting Persistence

Configuring URL Rewriting Persistence is a two stage process. First, a persistence class using "Universal Session Persistence" must be created, and then two TrafficScript™ rules written that detect a rewritten URL, extract the JSESSIONID from it and persist on this ID. To create the session persistence class, go to Catalogs -> Persistence and create a new class called "url_rewriting". Set this class to use the "Universal Session Persistence" method and failure mode of "choose a new node to use", and click "Update" to finish. (Note that you should not associate the url_rewriting class with any particular pool - the TrafficScript rule below will associate it with a request as and when it is required.)

Now, go to Services -> Virtual Servers -> [your JBoss Cluster] -> Rules and click the "Manage Rules in Catalog" link in the "Add New Request Rule" section. Create a new TrafficScript rule called "url_rewriting_persistence", and cut and paste the following into the rule's text box, and click "Update". Note that the argument to connection.setPersistence must match the name of the persistence class you created above.

# Don't need to do this if we can persist on a cookie $cookie = http.getCookie( "JSESSIONID" ); if( $cookie ) break; # No cookie, so check the URL $url = http.getpath(); if (string.regexmatch($url, ".*;JSESSIONID=([\\w+-.*]*).*", "i")) {    $sessionid = $1;    connection.setPersistence( "url_rewriting" );    connection.setPersistenceKey( $sessionid ); }

Finally, create a new response rule. Go to Services -> Virtual Servers -> [your JBoss Cluster] -> Rules and click the "Manage Rules in Catalog" link in the "Add New Response Rule" section. Create a new TrafficScript rule called "url_rewriting_response", cut and paste the following into the rule's text box, and click "Update".

# We're only interested in intercepting html responses $contenttype = http.getResponseHeader( "Content-Type" ); if( ! string.startsWith( $contenttype, "text/html" ) ) break; # Don't need to do this if we can persist on a cookie $cookie = http.getCookie( "JSESSIONID" ); if( $cookie ) break; # Oracle and webLogic try to set the cookie on every request, so # even if the client rejects it they keep trying. $cookie = http.getResponseCookie( "JSESSIONID" ); if ( $cookie ) {    connection.setPersistence( "url_rewriting" );    connection.setPersistenceKey( $cookie ); } else {    # No cookie? JBoss doesn't set-cookie after it detects they're    # turned off so we will need to process the html entire document!    $body = http.getResponseBody();    if (string.regexmatch($body, ".*;JSESSIONID=([\\w+-.*]*).*", "i")) {       $sessionid = $1;       connection.setPersistence( "url_rewriting" );       connection.setPersistenceKey( $sessionid );    } } As mentioned above, you can safely use (and we recommend that you use) the Monitor Application Cookies and URL Rewriting methods together to ensure that session persistence works regardless of whether or not clients have cookies enabled.

Load Balancing Algorithms

By default, a newly created pool will use a simple round robin algorithm. This takes no account of the load on the back-end servers, and so it is recommended that one of the more sophisticated algorithms is used. The optimal choice will depend on the application being run. See section 5.2.1 of the ZXTM User Manual for details of each algorithm. The “Least Connections” algorithm is a sensible default for a typical JBoss deployment; set it on the Services -> Pool -> [Your JBoss Cluster Pool] -> Load Balancing page.

SSL Offloading

You may use ZXTM to terminate (off-load) any incoming SSL connections. This reduces the load on your application server by making use of the highly optimized SSL engine of ZXTM. A potential issue with this solution arises when you want your application to know when the connection is secured.

The only direct way to do this with JBoss is to pass the SSL headers and have your application check for these. Unfortunately this means you can not use the J2EE isSecure() or getScheme() methods to check the security of the connection.

The alternative solution is to run JBoss behind a web server and use AJP connectors. With this method you can configure different worker threads for secure and insecure connections and then use ZXTM to route secured traffic via the appropriate thread. More information on this technique is available in the following article: ssl_offloading_for_jboss_and_tomcat_serv.

Mark Boddington [Zeus Systems Engineering] 19 December 2006