Previous |
Sun Java System Application Server Enterprise Edition 8.1 2005Q1

> ## Setting Up High Availability Failover

> With the configuration used in the previous chapter, if a server instance goes down, users lose session state. This section, the second of two advanced topics, provides the steps for installing the high-availability database (HADB), creating a highly available cluster, and testing HTTP session persistence.

> Application Server supports both HTTP session persistence and persistence for Stateful Session Beans. The procedures in this chapter cover HTTP session persistence.

> These steps assume you have already performed the steps in the previous sections of this Quick Start. The steps are presented in the order that you should complete them.

> Note | Completing this section may require additional hardware resources.

> ##

> About High Availability Clusters and HADB

> A highly availability cluster in Sun Java System Application Server Enterprise Edition integrates a state replication service with the clusters and load balancer created earlier, enabling failover of HTTP sessions.

> HttpSession objects and Stateful Session Bean state is stored in HADB, a high-availability database for storing session state. This horizontally scalable state management service can be managed independently of the application server tier. It was designed to support up to 99.999% service and data availability with load balancing, failover and state recovery capabilities.

> Keeping state management responsibilities separated from Application Server has significant benefits. Application Server instances spend their cycles performing as a scalable and high performance Java™ 2 Platform, Enterprise Edition (J2EE™ platform) containers delegating state replication to an external high availability state service. Due to this loosely coupled architecture, application server instances can be easily added to or deleted from a cluster. The HADB state replication service can be independently scaled for optimum availability and performance. When an application server instance also performs replication, the performance of J2EE applications can suffer and can be subject to longer garbage collection pauses.

> Because each HADB node requires 512 Mbytes of memory, you need 1 Gbyte of memory to run two HADB nodes on the same machine. If you have less memory, set up each node on a different machine. Running a two-node database on only one host is not recommended for deployment since it is not fault tolerant.

> ##

> HADB Preinstallation Steps

> This procedure covers the most common preinstallation tasks. For information on other preinstallation topics, including prerequisites for installing HADB, configuring network redundancy, and file system support, see the High Availability Administration Guide.

> 1. Get root access.
> 2. Define variables related to shared memory.

> On Solaris:

> 1. Add these lines to the /etc/system file (or if these lines are in the file as comments, uncomment them and make sure that the values match these):

> set shmsys:shminfo_shmmax=0x80000000

> set shmsys:shminfo_shmseg=20

> set semsys:seminfo_semmni=16

> set semsys:seminfo_semmns=128

> set semsys:seminfo_semmnu=1000

> Set shminfo_shmmax to the total memory in your system (in hexadecimal notation the value 0x80000000 shown is for 2 Gigabytes of memory).

> If the seminfo_* variables are already defined, increment them by the amounts shown.

> 2. Reboot, using this command:

> sync; sync; reboot

> On Linux:

> 3. Add these lines to the /etc/sysctl.conf file (or if they are in the file as comments, uncomment them). Set the value to the amount physical memory on the machine. Specify the value as a decimal number of bytes. For example, for a machine having 512 Mbytes of physical memory:

> kernel.shmmax=536870912

> kernel.shmall=536870912

> 4. Reboot, using this command:

> sync; sync; reboot

> 3. If you used existing JDK software when you installed a standalone Application Server, HADB requires Sun JDK 1.4.1_03 or higher (for the latest information on JDK versions, see the Release Notes). Check the version installed, and if it is not done already, set the JAVA_HOME environment variable to the directory where the JDK is installed.
> 4. If necessary after the reboot, restart the domain, Web Server, and node agent.

> To restart the domain, use the command asadmin start-domain domain1.

> To restart the Web Server, use the command web_server_install_dir/https-hostname/start.

> To restart the node agent, use the command asadmin start-node-agent hostname. Replace the variable hostname with the name of the host where the Application Server is running.

> ##

> Installing HADB

> This section provides the steps for installing the high-availability database (HADB).

> Note | If you plan to run the high-availability database on the Application Server machine, and if you installed HADB when you installed Application Server, skip to Starting HADB.

> You can install the HADB component on the same machine as your Application Server system if you have 2 Gbytes of memory and 1-2 CPUs. If not, use additional hardware. For example:

> - Two 1 CPU systems with 512 Mbytes to 1 Gbyte memory each
> - One 1-2 CPU system with 1 Gbytes to 2 Gbytes memory

> To install HADB:

> 1. Run the Application Server or Java Enterprise System installer.
> 2. In the Component Selection page, choose the option to install HADB.
> 3. Complete the installation on your hosts.

> ##

> Starting HADB

> This section describes starting the HADB management agent by running the ma-initd script. For a production deployment, start the management agent as a service to ensure its availability. For more information, see the High Availability Administration Guide.

> If starting a database with HADB nodes on several hosts, start the management agent on each host.

> In a Java Enterprise System installation:

> 1. Change to the etc/init.d directory:

> cd /etc/init.d

> 2. Run the command to start the agent:

> ./ma-initd start

> In a standalone Application Server installation:

> 1. Change to the HADB bin directory in the Application Server installation:

> cd install_dir/hadb/4/bin

> 2. Run the command to start the agent:

> ./ma-initd start

> ##

> Configuring a Cluster and Application for High Availability

> 1. From the machine on which the Domain Administration Server is running, configure FirstCluster to use HADB using this command:

> asadmin configure-ha-cluster --hosts hadb_hostname,hadb_hostname --devicesize 256 FirstCluster

> Replace the hadb_hostname variable with the host name of the machine where HADB is to run. If you are using just one machine, you must name it twice.

> This simplified example runs two nodes of HADB on the same machine. In production settings, use more than one machine.

> Note | To reduce the memory footprint of HADB for demonstration purposes, execute the following hadbm command. You are prompted for the administration password. In Java Enterprise System installations: /opt/SUNWhadb/4/bin/hadbm set DataBufferPoolSize=64,LogBufferSize=25 FirstCluster In standalone Application Server installations: install_dir/hadb/4/bin/hadbm set DataBufferPoolSize=64,LogBufferSize=25 FirstCluster

> 2. Configure the clusterjsp application for HTTP session persistence by enabling high availability:
> 1. In the Admin Console, expand the Applications node
> 2. Expand Enterprise Applications.
> 3. Click clusterjsp.
> 4. In the right pane, on the General tab, click the Availability Enabled checkbox.
> 5. Click Save.

> Availability is enabled at the server instance and container level by default.

> ##

> Restarting the Cluster

> To restart the cluster:

> 1. In the Admin Console, expand the Clusters node.
> 2. Click FirstCluster.
> 3. In the right pane, click Stop Instances.
> 4. Once the instances are stopped, click Start Instances.

> ##

> Verifying HTTP Session Failover

> The steps for testing session data failover are similar for testing load balancing as described in the Verifying Load Balancing topic. This time Session Data is preserved after failure. Failover is transparent to the user because the sample application is configured for automatic retry after failure.

> 1. To display the first page of the clusterjsp application, type this URL in your browser:

> http://localhost:web_server_port/clusterjsp

> Replace the localhost variable with the name of the system that the Web Server is running on.

> Replace the web_server_port variable with the value of the port attribute of the LS element in web_server_install_dir/https-hostname/config/server.xml. For this example, port 38000 is used.

> A page similar to what you saw in the Verifying the Clustered Application section appears.

> 2. Examine the Session and Host information displayed. For example:
> - Executed From Server: localhost
> - Server Port Number: 38000
> - Executed Server IP Address: 192.18.145.133
> - Session ID: 41880f618e4593e14fb5d0ac434b1
> - Session Created: Wed Feb 23 15:23:18 PST 2005

> View the server access log files to determine which application server instance is serving the application. The log files are located here:

> - Solaris Java Enterprise System installation:
>   /var/opt/SUNWappserver/nodeagents/nodeagent_name/i1/logs/access/server_access_log
>   /var/opt/SUNWappserver/nodeagents/nodeagent_name/i2/logs/access/server_access_log
> - Linux Java Enterprise System installation:
>   /var/opt/sun/appserver/nodeagents/nodeagent_name/i1/logs/access/server_access_log
>   /var/opt/sun/appserver/nodeagents/nodeagent_name/i2/logs/access/server_access_log
> - Standalone Application Server installations:
>   install_dir/nodeagents/nodeagent_name/i1/logs/access/server_access_log
>   install_dir/nodeagents/nodeagent_name/i2/logs/access/server_access_log
> 3. Stop the Application Server instance that is serving the page.
> 1. In the Admin Console, in the left pane, expand Clusters.
> 2. Click FirstCluster.
> 3. In the right pane, click the Instances tab.
> 4. Click the checkbox next to the server instance that served the request and click the Stop button.
> 4. Reload the clusterjsp sample application page.

> The session ID and session attribute data is retained.

> 5. Check the access log of the other Application Server instance, and notice that it is now servicing the request.

> The state failover features work because the HTTP session is stored persistently in the HADB. In addition to the HTTP session state, the Application Server also can store the state of EJB™ enterprise beans in the HADB.

> ##

> Cleaning Up

> To clean up, you can uninstall the Application Server installation by completing the steps in Option 1: Uninstalling Your Installation, or you can simply delete the sample cluster you have just created by completing the steps in Option2: Removing the Sample Cluster.

> ### Option 1: Uninstalling Your Installation

> To uninstall completely:

> 1. Stop the Application Server processes using these commands:

> asadmin stop-cluster FirstCluster

> asadmin remove-ha-cluster --hosts hadb_hostname,hadb_hostname FirstCluster

> Replace the hadb_hostname variable with the host name of the machine where HADB is to run. If you are using just one machine, you must name it twice.

> asadmin stop-node-agent hostname

> asadmin stop-domain domain1

> 2. Stop the HADB Management Agent by one of the following methods:

> In a Java Enterprise System installation:

> 1. Change to the /etc/init.d directory:

> cd /etc/init.d

> 2. Run the command to stop the agent:

> ./ma-initd stop

> In a standalone Application Server installation:

> 3. Change to the HADB bin directory in the Application Server installation:

> cd install_dir/hadb/4/bin

> 4. Run the command to stop the agent:

> ./ma-initd stop

> At this point all processes related to Sun Java System Application Server are stopped.

> 3. Uninstall the Application Server.

> In a Java Enterprise System installation, run var/sadm/prod/entsys/uninstall and follow the steps in the uninstallation wizard.

> In a standalone Application Server installation, run install_dir/uninstall and follow the steps in the uninstallation wizard.

> 4. If you created a new Web Server instance for this exercise, delete it:
> 1. Log on to the Web Server’s Administration Console.
> 2. Stop the instance.
> 3. Delete the instance.
> 5. To unsinstall the Web Server product, run the uninstall program from the web_server_install_dir.

> ### Option2: Removing the Sample Cluster

> To remove only the FirstCluster (the sample highly-available cluster) and the sample application used during this exercise:

> 1. Stop the Application Server processes and clean up configuration:

> asadmin stop-cluster FirstCluster

> asadmin remove-ha-cluster --hosts hadb_hostname,hadb_hostname FirstCluster

> Replace the hadb_hostname variable with the host name of the machine where HADB is to run. If you are using just one machine, you must name it twice.

> asadmin disable-http-lb-server FirstCluster

> asadmin delete-http-lb-ref --config MyLbConfig FirstCluster

> asadmin delete-http-lb-config MyLbConfig

> asadmin delete-instance i1

> asadmin delete-instance i2

> asadmin delete-cluster FirstCluster

> asadmin undeploy clusterjsp

> 2. Stop the web server instance acting as load balancer:

> web_server_install_dir/https-hostname/stop

> 3. Rename the loadbalancer.xml file in web_server_install_dir/https-hostname/config to loadbalancer.xml.sav
> 4. Stop the HADB Management Agent by one of the following methods:

> In a Java Enterprise System installation:

> 1. Change to the /etc/init.d directory:

> cd /etc/init.d

> 2. Run the command to stop the agent:

> ./ma-initd stop

> In a standalone Application Server installation:

> 3. Change to the HADB bin directory in the Application Server installation:

> cd install_dir/hadb/4/bin

> 4. Run the command to stop the agent:

> ./ma-initd stop

> In this section, you have installed, configured, and started HADB and configured a cluster and an application to use high availability. You have also cleaned up so that your system is ready for other work.

> Congratulations! You have now completed the Quick Start for Application Server.

> ##

> Where to Go Next

> Other resources for learning about and using Application Server are available. They include:

> - Product details at install_dir/docs-ee/about.html.

> See this document for the latest information on what is new, and pointers to tutorials and other educational services.

> - The Sun Java System Application Server Release Notes

> See this document for late-breaking information regarding this release.

> - The Sun Java System Application Server Administration Guide

> See this document for information on performing administrative functions using the Admin Console.

> - The Utility Reference (man pages)

> See this document for reference information on Application Server’s command-line utilities, such as asadmin.

> - The Sun Java System Application Server High Availability Administration Guide

> See this document for information on the Sun Java System Application Server’s high availability features.

> - The J2EE 1.4 Tutorial

> See this document for a tutorial that covers the process for building and deploying Java™ 2 Platform, Enterprise Edition (J2EE™ platform) applications.

> - Java™ BluePrints guidelines for the Enterprise

> See this document for a comprehensive set of examples that demonstrate operations of the Application Server software and that can be used as application templates.

> Previous

> Part No: 819-1003. Copyright 2004-2005 Sun Microsystems, Inc. All rights reserved.