High availability applications and services provide their functionality continuously, regardless of hardware and software failures. Such applications are sometimes referred to as providing five nines of reliability, because they are intended to be available 99.999% of the time.
Enterprise Server provides the following high availability features:
The HTTP load balancer plug-in accepts HTTP/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. GlassFish Communications Server provides 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 replicated persistence.
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 the HTTP load balancer plug-in, see Chapter 5, Configuring HTTP Load Balancing.
The Java Message Service (JMS) API is a messaging standard that allows Java EE applications and components to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous. The Sun Java System Message Queue (MQ), which implements JMS, is tightly integrated with Enterprise Server, enabling you to create components that rely on JMS, such as message-driven beans (MDBs).
JMS is made highly available through connection pooling and failover and MQ clustering. For more information, see Chapter 10, Java Message Service Load Balancing and Failover.
Enterprise Server supports JMS connection pooling and failover. The Enterprise Server pools JMS connections automatically. By default, Enterprise Server selects its primary MQ broker randomly from the specified host list. When failover occurs, MQ transparently transfers the load to another broker and maintains JMS semantics.
For more information about JMS connection pooling and failover, see Connection Pooling and Failover.
MQ Enterprise Edition supports multiple interconnected broker instances known as a broker cluster. With broker clusters, client connections are distributed across all the brokers in the cluster. Clustering provides horizontal scalability and improves availability.
For more information about MQ clustering, see Using MQ Clusters with Enterprise Server.
With RMI-IIOP load balancing, IIOP client requests are distributed to different server instances or name servers, which spreads the load evenly across the cluster, providing scalability. IIOP load balancing combined with EJB clustering and availability also provides EJB failover.
When a client performs a JNDI lookup for an object, the Naming Service essentially binds the request to a particular server instance. From then on, all lookup requests made from that client are sent to the same server instance, and thus all EJBHome objects will be hosted on the same target server. Any bean references obtained henceforth are also created on the same target host. This effectively provides load balancing, since all clients randomize the list of target servers when performing JNDI lookups. If the target server instance goes down, the lookup or EJB method invocation will failover to another server instance.
IIOP Load balancing and failover happens transparently. No special steps are needed during application deployment. If the Enterprise Server instance on which the application client is deployed participates in a cluster, the Enterprise Server finds all currently active IIOP endpoints in the cluster automatically. However, a client should have at least two endpoints specified for bootstrapping purposes, in case one of the endpoints has failed.
For more information on RMI-IIOP load balancing and failover, see Chapter 11, RMI-IIOP Load Balancing and Failover.
For information about planning a high-availability deployment, including assessing hardware requirements, planning network configuration, and selecting a topology, see the Sun GlassFish Enterprise Server 2.1 Deployment Planning Guide. This manual also provides a high-level introduction to concepts such as:
Enterprise Server components such as node agents, domains, and clusters
IIOP load balancing in a cluster
Message queue failover
For more information about developing applications that take advantage of high availability features, see Sun GlassFish Enterprise Server 2.1 Developer’s Guide.
For information on how to configure and tune applications and Enterprise Server for best performance with high availability, see the Performance Tuning Guide on docs.sun.com, which discusses topics such as:
Tuning persistence frequency and persistence scope
Checkpointing stateful session beans
Configuring the JDBC connection pool
Tuning HADB disk use, memory allocation, performance, and operating system configuration
Configuring load balancer for best performance