How Enterprise ServerProvides High Availability

Enterprise Server provides high availability through the following subcomponents and features:

• Storage for Session State Data

• In-Memory Replication on Other Servers in the Cluster

• Highly Available Clusters

Storage for Session State Data

Storing session state data enables the session state to be recovered after the failover of a server instance in a cluster. Recovering the session state enables the session to continue without loss of information. Enterprise Server provides the following types of high availability storage for HTTP session and stateful session bean data:

• In-memory replication on other servers in the cluster

• High availability database

In-Memory Replication on Other Servers in the Cluster

In-memory replication on other servers provides lightweight storage of session state data without the need to obtain a separate database, such as HADB. This type of replication uses memory on other servers for high availability storage of HTTP session and stateful session bean data. Clustered server instances replicate session state in a ring topology. Each backup instance stores the replicated data in memory. Replication of session state data in memory on other servers enables sessions to be distributed.

The use of in-memory replication requires the Group Management Service (GMS) to be enabled. For more information about GMS, see Group Management Service.

If server instances in a cluster are located on different machines, ensure that the following prerequisites are met:

• To ensure that GMS and in-memory replication function correctly, the machines must be on the same subnet.

• To ensure that in-memory replication functions correctly, the system clocks on all machines in the cluster must be synchronized as closely as possible.

High Availability Database

The HADB software is supplied with the Enterprise Server standalone distribution of Sun GlassFish Enterprise Server. For information about available distributions of Sun GlassFish Enterprise Server, see Distribution Types and Their Components in Sun GlassFish Enterprise Server v2.1.1 Installation Guide. HADB features are available only in the enterprise profile. For information about profiles, see Usage Profiles in Sun GlassFish Enterprise Server v2.1.1 Administration Guide.

GlassFish Communications Server 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 Enterprise Server.

Keeping state management responsibilities separated from GlassFish Communications Server has significant benefits. GlassFish Communications Server instances spend their cycles performing as a scalable and high performance application containers delegating state replication to an external high availability state service. Due to this loosely coupled architecture, GlassFish Communications 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 GlassFish Communications Server instance also performs replication, the performance of Java EE applications can suffer and can be subject to longer garbage collection pauses.

For information on planning and setting up your installation for high availability with HADB, including determining hardware configuration, sizing, and topology, see the Sun GlassFish Enterprise Server 2.1 Deployment Planning Guide.

Highly Available Clusters

A cluster is a collection of instances that work together as one logical entity. A cluster provides a runtime environment for one or more Java EE 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 Java EE 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.

Clusters and Configurations

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, Instances, Sessions, and Load Balancing

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 Enterprise Server without loss of service.