This chapter describes the high availability features in the Sun Java SystemApplication Server Enterprise Edition, with the following topics:
High availability applications and services provide their functionality continuously, regardless of hardware and software failures. Application Server provides high availability for HTTP requests and session data (both HTTP session data and stateful session bean data).
Application Server provides high availability through the following sub-components and features:
The load balancer plug-in accepts HTTP and HTTPS requests and forwards them to application server instances in a cluster. If an instance fails, becomes unavailable (due to network faults), or becomes unresponsive, the load balancer redirects requests to existing, available machines. The load balancer can also recognize when a failed instance has recovered and redistribute the load accordingly. The Application Server Enterprise Edition includes the load balancer plug-in for the Sun Java System Web Server and the Apache Web Server, and Microsoft Internet Information Server.
By distributing workload among multiple physical machines, the load balancer increases overall system throughput. It also provides higher availability through failover of HTTP requests. For HTTP session information to persist, you must configure HTTP session persistence.
For simple, stateless applications a load-balanced cluster may be sufficient. However, for mission-critical applications with session state, use load balanced clusters with HADB.
Server instances and clusters participating in load balancing have a homogenous environment. Usually that means that the server instances reference the same server configuration, can access the same physical resources, and have the same applications deployed to them. Homogeneity assures that before and after failures, the load balancer always distributes load evenly across the active instances in the cluster.
For information on configuring load balancing and failover for see Chapter 4, Configuring Load Balancing and Failover
Application Server Enterprise Edition provides the High Availability Database (HADB) for high availability storage of HTTP session and stateful session bean data. HADB is designed to support up to 99.999% service and data availability with load balancing, failover, and state recovery. Generally, you must configure and manage HADB independently of Application Server.
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 very 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.
For information on planning and setting up your application server installation for high availability with HADB, including determining hardware configuration, sizing, and topology, see Planning for Availability in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Deployment Planning Guide and Chapter 3, Selecting a Topology, in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Deployment Planning Guide.
A cluster is a collection of Application Server instances that work together as one logical entity. A cluster provides a runtime environment for one or more J2EE applications. A highly available cluster integrates a state replication service with clusters and load balancer.
Using clusters provides the following advantages:
High availability, by allowing for failover protection for the server instances in a cluster. If one server instance goes down, other server instances take over the requests that the unavailable server instance was serving.
Scalability, by allowing for the addition of server instances to a cluster, thus increasing the capacity of the system. The load balancer plug-in distributes requests to the available server instances within the cluster. No disruption in service is required as an administrator adds more server instances to a cluster.
All instances in a cluster:
Reference the same configuration.
Have the same set of deployed applications (for example, a J2EE application EAR file, a web module WAR file, or an EJB JAR file).
Have the same set of resources, resulting in the same JNDI namespace.
Every cluster in the domain has a unique name; furthermore, this name must be unique across all node agent names, server instance names, cluster names, and configuration names. The name must not be domain. You perform the same operations on a cluster (for example, deploying applications and creating resources) that you perform on an unclustered server instance.
A cluster's settings are derived from a named configuration, which can potentially be shared with other clusters. A cluster whose configuration is not shared by other server instances or clusters is said to have a stand-alone configuration . By default, the name of this configuration is cluster_name -config, where cluster_name is the name of the cluster.
A cluster that shares its configuration with other clusters or instances is said to have a shared configuration.
Clusters, server instances, load balancers, and sessions are related as follows:
A server instance is not required to be part of a cluster. However, an instance that is not part of a cluster cannot take advantage of high availability through transfer of session state from one instance to other instances.
The server instances within a cluster can be hosted on one or multiple machines. You can group server instances across different machines into a cluster.
A particular load balancer can forward requests to server instances on multiple clusters. You can use this ability of the load balancer to perform an online upgrade without loss of service. For more information, see “Using Multiple Clusters for Online Upgrades Without Loss of Service” in the chapter “Configuring Clusters”
A single cluster can receive requests from multiple load balancers. If a cluster is served by more than one load balancer, you must configure the cluster in exactly the same way on each load balancer.
Each session is tied to a particular cluster. Therefore, although you can deploy an application on multiple clusters, session failover will occur only within a single cluster.
The cluster thus acts as a safe boundary for session failover for the server instances within the cluster. You can use the load balancer and upgrade components within the Application Server without loss of service.
For information about planning a high-availability deployment, including assessing hardware requirements, planning network configuration, and selecting a topology, see Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Deployment Planning Guide. This manual also provides a high-level introduction to concepts such as:
Application server components such as node agents, domains, and clusters
IIOP load balancing in a cluster
HADB architecture
Message queue failover
For more information about developing and deploying applications that take advantage of high availability features, see Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide.
For information on how to configure and tune applications and Application Server for best performance with high availability, see Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Performance Tuning Guide, which discusses topics such as:
Tuning persistence frequency and persistence scope
Checkpointing stateful session beans
Configuring the JDBC connection pool
Session size
Tuning HADB disk use, memory allocation, performance, and operating system configuration
Configuring load balancer for best performance
J2EE applications typically have significant amounts of session state data. A web shopping cart is the classic example of a session state. Also, an application can cache frequently-needed data in the session object. In fact, almost all applications with significant user interactions need to maintain session state. Both HTTP sessions and stateful session beans (SFSBs) have session state data.
Preserving session state across server failures can be important to end users. For high availability, the Application Server provides the capability to persist session state in the HADB. If the application server instance hosting the user session experiences a failure, the session state can be recovered, and the session can continue without loss of information.
For a detailed description of how to set up high availability session persistence, see Chapter 8, Configuring High Availability Session Persistence and Failover