Clustering Web Applications with GlassFish V2

Here is a short tutorial on how to make your web apps highly available with GlassFish V2 and it's new in memory replication features.

Step 1: Setup a GlassFish V2 domain:
  • Download GlassFish V2 beta2 (eg build 41c) from here
  • Execute java -jar glassfish-installer-v2-<buildnumber>.jar
  • As we will have to use the cluster profile edit setup-cluster.xml as needed. If the default ports and passwords are ok for you there is no need to change anything. (I assume default settings for the next steps)
  • Execute ant -f setup-cluster.xml and a GlassFish domain with its domain administration server is created for you.
  • Start your domain admin server by executing asadmin start-domain --user admin and verify that its up and running by accessing the admin gui at http:<servername>:4848
  • Next you have to create a node-agent. Node agents are responsible for communication between you domain admin server and server instances or clusters. You create a node agent be executing asadmin create-node-agent <nodeagentname>. If you don't specify a node agent name the hostname if your system will be used. If you create your node agent on a different server you also have to specify host/port information for your domain admin server by giving --host <hostname> --port <portnumber> to asadmin
  • Fire up your node agent by asadmin start-node-agent <nodeagentname>
  • Next look at your admin console. Your node agent should show up as running.

Step 2: Setup a GlassFish V2 cluster

Setting up a cluster means that we are going to define a cluster configuration that is shared among multiple instances. To create a cluster proceed this way in the admin gui:
  • Select Clusters in the navigation tree
  • Click on new to create a cluster, give your cluster a name, select default config and add cluster nodes (at least 2 for now). For each cluster node select your node agents representing the machines where your cluster instances shall run. The following picture shows my test setup.

  • Click on OK and your cluster and its instances will be created (will take some time depending on your machine).
  • On the next page that will show up in the admin gui you can select the checkbox left to the clustername and click on the Start Cluster button to start up your cluster.
  • Now your cluster should be up and running and ready for application deployment!
If you prefer cluster creation using command line tools you can do it with asadmin this way:
  • <glassfish-install-dir>/bin/asadmin create-cluster --user admin <clustername>
  • <glassfish-install-dir>/bin/asadmin create-instance --user admin --nodeagent <nodeagentname> --cluster <clustername> <instancename1>
  • <glassfish-install-dir>/bin/asadmin create-instance --user admin --nodeagent <nodeagentname> --cluster <clustername> <instancename2>
  • <glassfish-install-dir>/bin/asadmin start-cluster <clustername>

Step 3: Deploy an application to your cluster

Now we can finally deploy an application to our new cluster environment. In order for a web application to make use of session failover in a cluster some preconditions must be met:
  • The group membership service in your cluster must be running as it provides some hearbeat information about the health of your instances. Normally this service is enabled by default. You can doublecheck by selecting your cluster and look at the general tab - the checkbox Heartbeat should show enabled.
  • The deployment descriptor of your web app - web-inf/web.xml must contain the <distributable/> element:
      <web-app version="2.5" ....... >  
    <display-name>myclusterable webapp</display-name>
  • And also your application must provide a web-inf/sun-web.xml that contains properties for the session manager:
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0
    Servlet 2.5//EN" "">

    <session-manager persistence-type="replicated">
    <property name="persistenceFrequency" value="web-method"/>
    <property name="persistenceScope" value="session"/>
  • In aboves extract of a sun-web.xml the session manager has to specify persistence-type="replicated" to use the in memory replication of your cluster. The persistenceFrequency property with value web-method means that after each request the session gets replicated. A different setting would be time-based replication. The persistenceScope property with a value of session means that on each request the whole HTTPSession gets replicated. Other potential settings are modified-session and modified-attribute.
  • If you have changed your apps web.xml and sun-web.xml you are ready to deploy to your cluster. In the admin gui you can simply select your cluster as target. Usually only "server" is shown as selected Target which means that its deployed to the domain admin server. Just select your cluster and add it to the targets list.
  • Before you click on the OK button for deployment make sure to select the Availability Enabled checkbox for your application!
  • If things went fine the server.log of your instances should have an entry like this:
    _ThreadID=24;_ThreadName=RMI TCP connection(19)-<ip-address>/clusterjsp;replicated;
    web-method;session;|WEB0130: Enabling ha-based persistence for web module [/clusterjsp]'s
    sessions: persistence-type = [replicated] / persistenceFrequency = [web-method] /
    persistenceScope = [session]|#]
Now you can access your application on both of your cluster instances by directly pointing your browser to each server instances. (eg <host1>:<httpport> and <host2>:<httpport>). If your application changes attributes in the HTTPSession you should see those changes getting replicated to the other server in your cluster.

Thats all for now about clustering with session failover for GlassFish V2. Of course you also want to use load balancing in front of your cluster. Do do this you can use either the Sun Web Server with GlassFish or use Apache+mod_jk with GlassFish V2.

Update: Shreedhar (check his excellent blog about Shoal) pointed out that 2 things should be considered when using in memory replication:
  • The cluster instances should be located on the same subnet
  • Clock times on all machines in the cluster should be time syncd to be as close as possible

Powered by ScribeFire.


Senden Sie einen Kommentar:
Kommentare sind ausgeschaltet.

Daniel Adelhardt


« April 2014