I must be getting old, as I have installed/configured three different types of high availability setups for the Sun application server over the years. The first one was way back, when it was iPlanet app server 6.x, when you needed to do web tier HA setup, app server HA setup and FINALLY setup a directory server multimaster replication (yes you read that right) to complete the HA setup. Next was the Sun One app server 7.x HA setup with the HADB, SSH, RSH, RCP and what not. Now finally, we have the Sun Java system app server 8.x setup, which to tell you frankly, was a breeze when compared to all others. You kids have it very easy ;-)


This blog attempts to give a quick overview of how to setup load balancing and high availability using the Sun application server 8.1. You can use either the Sun JES 2005Q4 software bits or the file based installer of the Sun application server 8.1 Update x.


Architecture of our Sun Java System Application server

High availability/Load balancer setup




This architecture can be changed, to suit different criteria like machine availability, number of HADB nodes etc. For example, you can also do a quick setup with all the above components on a single server also.



Install DAS/Load balancer Plugin on server WS (where the Sun web server has been installed)



Run the Sun JES 2005Q4 installation program (or the file based Application server installer).


The following screen shot is from a stand alone Application server installer. If you use the Sun JES installer, select Application server and doubleclick the app server node and select ONLY the load balancer plugin,DAS and admin tool, If required ( Pointbase and sample apps) and please deselect any other JES components.






  • Select the web server instance directory like for example: /<JES base directory>/opt/SUNWwbsvr/https-<servername>

  • Click install and complete installation.

  • Start app server by invoking <as-homedirectory>/opt/SUNWappserver/bin/asadmin start-domain –user admin domain1

  • Verify, if you can access the app server admin console, by going to https://ws.india.sun.com:4849


Installation on AS1 and AS2 servers


On AS1 and AS2, make the following changes to /etc/system to BOTH servers and reboot the system. These changes are required for the High availability stuff to work.


For a server with 1 GB RAM, we can have the following settings:


set shmsys:shminfo_shmmax=0x40000000

set shmsys:shminfo_shmseg=20

set semsys:seminfo_semmni=16

set semsys:seminfo_semmns=128

set semsys:seminfo_semmnu=1000


Look at http://docs.sun.com/app/docs/doc/819-2561/6n4rfhrkf?a=view for more information on /etc/system settings for other kinds of servers.


Please follow these steps on both servers AS1 and AS2. Use the Sun app server 8.1 (or Sun JES 2005Q4 bits and start the install).







Enter the WS server name, port number, password etc (where we installed the DAS) in the next screen. This is how the node agent on AS1 will communicate with the DAS on WS server. Entering the correct DAS host name (WS), port number, admin/master passwords is very important.


Give some meaningful name for the Node agent name.


Complete the installation.


Start node agents on both AS1 and AS2


<App server base directory>/bin/asadmin start-node-agent --user admin


Note: The above commands assume that the DAS is running on default application server ports, if you have changed them please use the –port/--secure/--host options with all the asadmin commands. Please refer to the asadmin help. Please also note, that in the command line options above are two dashes --


Create a cluster on WS server


Open the app server admin console on WS server, https://WS:4849 and create a cluster and enter appropriate data for AS1 and AS2. A sample screen shot is given below, the instance names can be any meaningful names.








Note:


The above steps can also be created on the WS server, from command line, as follows:


asadmin create-cluster --user admin testcluster1


asadmin create-instance --user admin --nodeagent mde-iec1-cluster1 --cluster testcluster1 instance1


asadmin create-instance --user admin --nodeagent mdeiec-cluster2 --cluster testcluster1 instance2


asadmin start-cluster --user admin testcluster1


Note: The above commands assume that the DAS is running on default application server ports, if you have changed them please use the –port/--secure/--host options with all the asadmin commands. Please refer to the asadmin help. Please also note, that in the command line options above are two dashes --




Once, the cluster testcluster1 is created, start the application server instances using the “start instances” option in the same app server admin console screen on WS server.




Deploy a sample application to the cluster


The clusterjsp that ships with the Sun app server, is the best high availability application that can be used with the Sun application server.


asadmin deploy --user admin --target testcluster1 --availabilityenabled=true <appserverbase>/samples/ee-samples/highavailability/apps/clusterjsp/clusterjsp.ear


Check if clusterjsp has been properly deployed, by accessing http://as1:port/clusterjsp and http://as2:port/clusterjsp. It is important to set the –availabilityenabled=true property to get this application to work with our high availability cluster.


Setting up Load balancing on WS server


In this step, we will configure load balancing on the web server WS, such that requests for applications to WS, will be load balanced across AS1 and AS2. We have installed the load balancer plugin on WS, in one of the previous steps.


Previously, we would modify the loadbalancer.xml directly on the web server instance directory, but now this process has been automated.


Issue the following commands on WS:


asadmin create-http-lb-config -u admin testcluster1_lb1


Create a load balancer reference to the Cluster, testcluster1, we have created before.


asadmin create-http-lb-ref -u admin --config testcluster1_lb1 testcluster1


asadmin enable-http-lb-server -u admin testcluster1


The next step, is to make the clusterjsp to be load balancer enabled.

asadmin enable-http-lb-application -u admin --name clusterjsp testcluster1


The next step, is to set the healthchecker properties for the load balancer (it uses the default health checker properties, change them if you like)

asadmin create-http-health-checker -u admin testcluster1


asadmin export-http-lb-config -u admin --config testcluster1_lb1 loadbalancer.xml


This complete the creation of the loadbalancer.xml file. The above steps could have been manually added to the loadbalancer.xml file, but there would have been scope for errors to creep in. If you open loadbalancer.xml , you will see that only requests to URI clusterjsp will be loadbalanced/forwarded to the app servers. If you want all requests to the web server to be forwarded, please change the context root to be /.


Copy the loadbalancer.xml file to the web server config directory:

cp loadbalancer.xml /<mybase>/opt/SUNWwbsvr/https-<myinstance>/config/


Login to the web server admin console on WS, manage the web server instance and click apply changes. This will apply the changes and restart the web server instance.


Restart the application server instances in the cluster testcluster1 from the app server admin console https://WS:4849


Note: The above commands assume that the DAS is running on default application server ports, if you have changed them please use the –port/--secure/--host options with all the asadmin commands. Please refer to the asadmin help. Please also note, that in the command line options above are two dashes --


Testing Load balancing


Open a browser and go to http://WS/clusterjsp , note down the executed server from and executed server IP address fields. Click Refresh, and the notice that the requests are being executed from the same same app server. This demonstrates “sticky load balancing”.


Close the browser and open a new browser window, and go to http://WS/clusterjsp , note down the executed server from and executed server IP address fields. The request will have been executed from the second app server instance. This demonstrates “load balancing”.



Setting up the High Availability database for session failover


Note: The system clocks/dates on servers AS1 and AS2 must be similar. Please use something like rdate or set the time/date manually, else HTTP session synchronization will go for a toss.


Start a new terminal window on both AS1 and AS2, and start the HA manageability agents on both AS1 and AS2:


cd <Appserver-base-in-AS1andAS2>/hadb/4/bin

#./ma-initd start

(Note: You may need to add the execute permission to ma-initd before it can be executed)


We should get a message like “Listening for client connections on port 1862”


The above procedure can also be automated, such that ma-initd will start automatically at boot time, by creating a symbolic link for ma-initd at /etc/init.d



On the machine where DAS is installed, WS in our case, please issue the following command:


./asadmin configure-ha-cluster --port 4849 --user admin --devicesize 256 --hosts AS1,AS2 testcluster1


The high availability database will be created, and a message “Command configure-ha-cluster executed successfully” should be seen.


Note: I got tripped a couple of times when running with a server with multiple interface cards. The docs says setting the ma.server.mainternal.interfaces property in ma.cfg to a IP address will work, but I was not successful. Please let me know, if this worked.


Testing high availability with the the clusterjsp sample application


Open the app server admin console, https://WS:4849.


Open a separate browser instance, and access the clusterjsp sample, http://WS/clusterjsp

Add a a few session variables and data. Please note down the server from where the clusterjsp app was fetched. If for example, it was fetched from AS2, then using the app server admin console, shut down AS1. Reload the page, the page should still get reloaded and the session data should remain INTACT. This demonstrates HTTP session failover.


Restart AS1, and repeat the above test by shutting down AS2.


Happy clustering !!!!


Comments:

Post a Comment:
Comments are closed for this entry.

This blog copyright 2009 by cmani