Miles to go …

TOTD #67 shows how to configure GlassFish High Availability using Apache httpd + mod_jk on Mac OS X. Even though that’s a standard and supported configuration, there are several advantages for replacing Apache httpd with Sun Web Server and mod_jk with Load Balancer plugin that comes with GlassFish.

This Tip Of The Day (TOTD) shows how to configure Clustering and Load Balancing using GlassFish v2.1, Sun Web Server, Load Balancer plugin on Windows Vista. This blog is using JDK 6 U7, GlassFish v2.1 (cluster profile), Sun Web Server 7 U4, and Load Balancer plug-in with Sun GlassFish Enterprise Server 2.1 Enterprise Profile (with HADB link).

Lets get started!

1. Install the required software
   1. Download JDK (if not already installed).
   2. Download and Install GlassFish v2.1. Make sure to configure using “ant -f setup-cluster.xml”. This will ensure that the created domain is capable of creating clusters and can perform in-memory session replication for applications deployed on the cluster.
   3. Download and Install Sun Web Server. The process is very simple by unzipping the downloaded bundle, clicking on “setup.exe” and taking all the defaults.
   4. Download GlassFish Enterprise Profile for Load Balancer plugin bits. Start the install by clicking on the downloaded file and select the options as shown below:
   5. Copy the following “loadbalancer.xml” in “https-<host>” (replace <host> with the host name of your machine) directory of Sun Web Server installation directory:
      

      <?xml version=”1.0″ encoding=”UTF-8″?> <!DOCTYPE loadbalancer PUBLIC “-//Sun Microsystems Inc.//DTD Sun Java System Application Server 9.1//EN” “file:///C:/Sun/WebServer7/https-LH-KRKZDW6CJE1V/config/sun-loadbalancer_1_2.dtd “> <loadbalancer> <cluster name=”cluster1″ policy=”round-robin” policy-module=”"> <instance name=”instance1″ enabled=”true” disable-timeout-in-minutes=”60″ listeners=”http://localhost:38080” weight=”100″/> <instance name=”instance2″ enabled=”true” disable-timeout-in-minutes=”60″ listeners=”http://localhost:38081” weight=”100″/> <web-module context-root=”/clusterjsp” disable-timeout-in-minutes=”30″ enabled=”true” error-url=”"/> <health-checker interval-in-seconds=”7″ timeout-in-seconds=”5″ url=”/”/> </cluster> <property name=”response-timeout-in-seconds” value=”120″/> <property name=”reload-poll-interval-in-seconds” value=”7″/> <property name=”https-routing” value=”false”/> <property name=”require-monitor-data” value=”false”/> <property name=”active-healthcheck-enabled” value=”false”/> <property name=”number-healthcheck-retries” value=”3″/> <property name=”rewrite-location” value=”true”/> </loadbalancer>

      The parameters to be changed are highlighted in bold and explained below:

      1. Sun Web Server installation directory
      2. HTTP port of instances created in the cluster. The ports specified are the default ones and can be found by clicking on the instance as shown below:
      3. Context root of the application that will be deployed in the cluster. The Domain Administration Server (DAS) can be configured to populate this file whenever any application is deployed to the cluster.
2. Create the cluster as explained in TOTD #67. The admin console shows the following screenshot after the cluster is created and all instances are created/started:

   and the following for 2 instances:

   

3. Deploy “clusterjsp” as explained in TOTD #67. The admin console shows the following screenshot after “clusterjsp” is deployed:
4. Start Sun Web Server using “startserv.bat” in “https-<host>” directory.

This concludes the installation and configuration steps, now show time!

Accessing “http://localhost/clusterjsp” shows:

The Sun Web Server is running on port 80 and uses “loadbalancer.xml” to serve the request from the configured instances in <loadbalancer> fragment. This particular page is served by “instance1″ as indicated in the image. Lets add session data with property name “aaa” and value “111″. The value is shown as:

The instance serving the data, “instance1″ in this case, and the session data are highlighted.

Now lets stop “instance1″ using the admin console and it looks like:

Click on “RELOAD PAGE” and it looks like:

Exactly same session data is served, this time by “instance2″.

The sequence above proves that the session data created by the user is preserved even if the instance serving the data goes down. This is possible because of GlassFish High Availability. The session data is served by the ”replica partner” where its already copied using in-memory session replication.

The following articles are also useful:

• Load balancing for Glassfish V2 deployments using BIG-IP System
• Configure the Cluster/Load Balancer with GlassFish v2

Please leave suggestions on other TOTD (Tip Of The Day) that you’d like to see. A complete archive of all tips is available here.

Technorati: totd glassfish highavailability clustering loadbalancing lbplugin sunwebserver windows vista

Related posts:

1. Screencast #34: GlassFish 3.1 Clustering, High Availability and Centralized Administration
2. LOTD #14: New Whitepaper: GlassFish High Availability Reference Configurations for a Virtualized Environment
3. TOTD #81: How to use nginx to load balance a cluster of GlassFish Gem ?
4. TOTD #138: GlassFish 3.1 Milestone 1 – Clustering and Application Versioning Demos
5. TOTD #92: Session Failover for Rails applications running on GlassFish