Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

17.2. Introduction

17.2.1. About High-Availability and Load Balancing Clusters

Clustering refers to using multiple resources, such as servers, as though they were a single entity. The two main types of clustering are Load balancing (LB) and High-availability (HA). In a LB cluster, all resources run at the same time, and a management layer spreads the work load across them.
In HA clustering, one resource runs, and another is available to step in if the first one becomes unavailable. The purpose of HA clustering is to reduce the consequences of hardware, software, or network outages.
JBoss EAP 6 supports clustering at several different levels. Some of the components of the runtime and your applications that can be made highly available are:
  • Instances of the Application Server
  • Web applications, when used in conjunction with the internal JBoss Web Server, Apache HTTP Server, Microsoft IIS, or Oracle iPlanet Web Server.
  • Stateful, stateless, and entity Enterprise JavaBeans (EJBs)
  • Single Sign On (SSO) Mechanisms
  • Distributed cache
  • HTTP sessions
  • JMS services and Message-driven beans (MDBs)
Clustering is made available to JBoss EAP 6 by two subsystems: jgroups and modcluster. The ha and full-ha profiles have these systems enabled. In JBoss EAP 6 these services start up and shut down on demand, but they will only start up if an application configured as distributable is deployed on the servers.
Infinispan is provided as the cache provider in JBoss EAP 6. Infinispan manages clustering and replication caches for JBoss EAP 6.

17.2.2. Components Which Can Benefit from High Availability

High Availability (HA) falls into a few broad categories in JBoss EAP 6.
The Container

Several instances of JBoss EAP 6 (running as a standalone server) or a server group's members (running as part of a managed domain) can be configured to be highly available. This means that if one instance or member is stopped or disappears from the cluster, its work load is moved to a peer. The work load can be managed in such a way to provide load-balancing functionality as well, so that servers or server groups with more or better resources can take on a larger portion of the work load, or additional capacity can be added during times of high load.

The Web Server

The web server itself can be clustered for HA, using one of several compatible load balancing mechanisms. The most flexible is mod_cluster connector, which is tightly integrated with the JBoss EAP 6 container. Other choices include Apache mod_jk or mod_proxy connectors, or the ISAPI connector and NSAPI connector.

The Application

Deployed applications can be made highly-available because of the Java Enterprise Edition 6 (Java EE 6) specification. Stateless or stateful session EJBs can be clustered so that if the node which is involved in the work disappears, another node can take over, and in the case of stateful session beans, preserve the state.

17.2.3. Overview of HTTP Connectors

JBoss EAP 6 has the ability to use load-balancing and high-availability mechanisms built into external web servers, such as Apache Web Server, Microsoft IIS, and Oracle iPlanet. JBoss EAP 6 communicates with the external web server using a connector. These connectors are configured within the web subsystem of JBoss EAP 6.
The web servers include software modules which control the way that HTTP requests are routed to JBoss EAP 6 nodes. Each of these modules varies in how it works and how it is configured. The modules are configured to balance work loads across multiple JBoss EAP 6 nodes, to move work loads to alternate servers in case of a failure event, or both. These abilities are called Load Balancing and High Availability (HA).
JBoss EAP 6 supports several different connectors. The one you choose depends on the web server in use and the functionality you need.
The table below lists the differences between the different HTTP connectors which are compatible with JBoss EAP 6. For the most current information about supported configurations for HTTP connectors, see https://access.redhat.com/articles/111663.

Table 17.3. HTTP connector features and constraints

Connector Web server Supported operating systems Supported protocols Adapts to deployment status Supports sticky session
mod_cluster httpd in JBoss Enterprise Web Server, httpd provided by operating system (Red Hat Enterprise Linux, Hewlett-Packard HP-UX) Red Hat Enterprise Linux, Microsoft Windows Server, Oracle Solaris, Hewlett-Packard HP-UX HTTP, HTTPS, AJP Yes. Detects deployment and undeployment of applications and dynamically decides whether to direct client requests to a server based on whether the application is deployed on that server. Yes
mod_jk httpd in JBoss Enterprise Web Server, httpd provided by operating system (Red Hat Enterprise Linux, Hewlett-Packard HP-UX) Red Hat Enterprise Linux, Microsoft Windows Server, Oracle Solaris, Hewlett-Packard HP-UX AJP No. Directs client requests to the container as long as the container is available, regardless of application status. Yes
mod_proxy httpd in JBoss Enterprise Web Server Red Hat Enterprise Linux, Microsoft Windows Server, Oracle Solaris HTTP, HTTPS, AJP No. Directs client requests to the container as long as the container is available, regardless of application status. Yes
ISAPI connector Microsoft IIS Microsoft Windows Server AJP No. Directs client requests to the container as long as the container is available, regardless of application status. Yes
NSAPI connector Oracle iPlanet Web Server Oracle Solaris AJP No. Directs client requests to the container as long as the container is available, regardless of application status. Yes
JBoss EAP 6 supported configurations are available here: https://access.redhat.com/articles/111663.

17.2.4. Node types

HTTP connector node

A worker node, sometimes referred to as a node, is a JBoss EAP 6 server instance which accepts requests from one or more client-facing HTTP servers that act as a proxy. JBoss EAP 6 can accept HTTP, HTTPS and AJP requests from Apache HTTP Server, Microsoft IIS or Oracle iPlanet Web Server (formerly Netscape Web Server).

For an overview of HTTP connectors supported by JBoss EAP 6 and how to configure them, see Section 17.2.3, “Overview of HTTP Connectors”.
Cluster node

Cluster node is a specialization of the worker node. Such a cluster may be load-balancing, high-availability or both. In a load-balancing cluster, a central manager distributes work loads amongst its nodes equally, by some situation-specific measurement of equality. In a high-availability cluster, some nodes are actively doing work, and others are waiting to step in if one of the active nodes leaves the cluster.

Example 17.1. Apache HTTP Server with mod_cluster configured

For instance, you might have a setup where Apache HTTP Server with mod_cluster configured acts as a load-balancing proxy to client's requests. These requests are forwarded to particular cluster nodes according to their current load. In case the sticky sessions are disabled, all incoming requests are distributed according to the current load. In case sticky sessions are enabled (default), subsequent requests within an already created session are routed to the worker node with which the session was created. If one of these cluster nodes dies or becomes overloaded, Apache HTTP Server with mod_cluster acting as a load-balancing proxy will forward client's request to another cluster node. Due to the session replication within the cluster, client's data will not be lost.
Similarly, you might have a simpler setup with worker nodes that are not clustered. If a worker node dies, its neighbor does not have the former session data, yet client will not get any non-HTTP 200 error code.
In the case of sticky session configuration, it does not matter to the load-balancing proxy whether or not its worker nodes are clustered.