JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide
search filter icon
search icon

Document Information


1.  High Availability in GlassFish Server

Overview of High Availability

HTTP Load Balancer Plug-in

High Availability Session Persistence

High Availability Java Message Service

RMI-IIOP Load Balancing and Failover

How GlassFish Server Provides High Availability

Storage for Session State Data

Highly Available Clusters

Clusters, Instances, Sessions, and Load Balancing

SSH for Centralized Cluster Administration

Recovering from Failures

Recovering the Domain Administration Server

Recovering GlassFish Server Instances

Recovering the HTTP Load Balancer and Web Server

Recovering Message Queue

Recovering From Power Failure and Failures Other Than Disk Storage

Recovering from Failure of Disk Storage

More Information

2.  Setting Up SSH for Centralized Administration

3.  Administering GlassFish Server Nodes

4.  Administering GlassFish Server Clusters

5.  Administering GlassFish Server Instances

6.  Administering Named Configurations

7.  Configuring Web Servers for HTTP Load Balancing

8.  Configuring HTTP Load Balancing

9.  Upgrading Applications Without Loss of Availability

10.  Configuring High Availability Session Persistence and Failover

11.  Configuring Java Message Service High Availability

12.  RMI-IIOP Load Balancing and Failover


How GlassFish Server Provides High Availability

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

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. GlassFish Server supports in-memory session replication on other servers in the cluster for maintaining HTTP session and stateful session bean data.

In-memory session replication is implemented in GlassFish Server 3.1 as an OSGi module. Internally, the replication module uses a consistent hash algorithm to pick a replica server instance within a cluster of instances. This allows the replication module to easily locate the replica or replicated data when a container needs to retrieve the data.

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 hosts, ensure that the following prerequisites are met:

Highly Available Clusters

A highly available cluster integrates a state replication service with clusters and load balancer.

Note - When implementing a highly available cluster, use a load balancer that includes session-based stickiness as part of its load-balancing algorithm. Otherwise, session data can be misdirected or lost. An example of a load balancer that includes session-based stickiness is the Loadbalancer Plug-In available in Oracle GlassFish Server.

Clusters, Instances, Sessions, and Load Balancing

Clusters, server instances, load balancers, and sessions are related as follows:

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

SSH for Centralized Cluster Administration

GlassFish Server uses secure shell (SSH) to ensure that clusters that span multiple hosts can be administered centrally. To perform administrative operations on GlassFish Server instances that are remote from the domain administration server (DAS), the DAS must be able to communicate with those instances. If an instance is running, the DAS connects to the running instance directly. For example, when you deploy an application to an instance, the DAS connects to the instance and deploys the application to the instance.

However, the DAS cannot connect to an instance to perform operations on an instance that is not running, such as creating or starting the instance. For these operations, the DAS uses SSH to contact a remote host and administer instances there. SSH provides confidentiality and security for data that is exchanged between the DAS and remote hosts.

Note - The use of SSH to enable centralized administration of remote instances is optional. If the use of SSH is not feasible in your environment, you can administer remote instances locally.

For more information, see Chapter 2, Setting Up SSH for Centralized Administration.