Red Hat JBoss Enterprise Application Platform Administration I

Configuring Infinispan and JGroups to replicate HTTP sessions is only half of the Red Hat JBoss Enterprise Application Platform (JBoss EAP) web clustering equation. The other half is setting up a network load balancer to direct HTTP requests to JBoss EAP server instances that are cluster members, as depicted in the following diagram:

Figure 12.6: JBoss EAP cluster with Infinispan, JGroups, and a load balancer.

Other JBoss EAP clustered services, such as JMS clients and remote EJBs, do not require network load balancers. The JMS and EJB clients can handle load balancing and failover. Their client software also handles discovering existing cluster members and learning about other cluster topology changes.

The HTTP protocol does not provide the required load balancing and failover features. The solution to this problem is a standard HTTP protocol feature: the proxy support.

A web proxy is a web server that receives HTTP requests and forwards them to another web server. You can use a web proxy to provide security, caching, and other features. For most web clients the proxy hides the real web servers that provide application content.

Having a front-end web proxy between users and the Jakarta EE application server is a common pattern for the following reasons:

Session affinity, also known as sticky sessions, is a web proxy mechanism that sends all requests from the same user to the same back-end web server. If you do not have session affinity, then user requests can go to different back-end web servers.

Hardware network load balancers, which work on the OSI model layers 3 and 4, can be used for a Jakarta EE application server clusters. Some networking hardware embeds a web proxy and can be configured to work as a layer 7 load balancer.

Jakarta EE web engines use an HTTP cookie to store a unique session ID. Only load balancers that can handle HTTP cookies can balance requests and keep session affinity at the same time. This is true for most web application runtimes, not just Jakarta EE.

To understand the need and advantages of session affinity, consider the impact on stateful and stateless applications, and whether they are clustered or non-clustered:

Session affinity is an optional feature for many applications, but it has performance implications. Web applications usually perform faster and require less hardware resources with session affinity enabled because of data locality.

Even if an application works without session affinity, the application benefits from data locality because requests made by a user usually work with the same data. This data is cached by many layers, from the back-end web server to a possibly shared database instance. Having the same back-end web server performing the whole sequence maximizes the utilization of these caches.

Undertow is a full-featured web server, capable of replacing traditional web server software such as Apache Httpd and Microsoft IIS for most use cases. Undertow includes a web proxy component that can do load balancing.

Undertow is also a web server built specifically to support Jakarta EE specifications, and provides most features from Java web containers such as Apache Tomcat.

Undertow has two features related to JBoss EAP clustering:

Traditional web load balancer software requires static configuration to provide each back-end web server's connection details. The load balancer does not take back-end nodes failure into account, which increases response times and network overhead when routing traffic to nodes in a failed state. Also, adding more back-end servers requires reconfiguring and potentially restarting the load balancer. The following figure illustrates a traditional web proxy acting as a load balancer:

Figure 12.7: Traditional web proxy as a static load balancer.

The previous features make the Jakarta EE application server as a back-end web server.

The mod_cluster module dynamically builds the back-end web server list. It also detects new cluster members, new deployed applications, or failed cluster members without needing manual configuration.

The mod_cluster protocol requires a client component, that should be implemented by the load balancer, and a server part, that is implemented by the JBoss EAP modcluster subsystem. The following figure illustrates a mod_cluster enhanced web proxy acting as a load balancer:

Figure 12.8: Web proxy enhanced with mod_cluster as a dynamic load balancer.

In the previous figure, the web proxy + mod_cluster box can be either a JBoss EAP server instance with Undertow configured to enable mod_cluster, or a native web server with a mod_cluster plug-in. Each JBoss EAP server with modcluster box is a back-end web server.

A mod_cluster enhanced web proxy such as undertow, sends advertisement messages to all the back-end web servers that listen to the multicast address and port. Back-end web servers reply by sending their connection parameters and the list of application context paths to the load balancer.

The architecture is fault-tolerant, there can be multiple web proxies with mod_cluster clients acting as load balancers. Back-end web servers receive advertisement messages from web proxies and replies to them.

In networks where multicast traffic is not allowed, advertising is disabled on the mod_cluster client. Each back-end web server is then manually configured with a list of web proxies. All of the back-end servers send information about their status and applications to the servers in the web server list. Even without multicast a mod_cluster load balancer requires no static configuration.

You can configure undertow to act as either a static, without mod_cluster, or dynamic, with mod_cluster load balancer. In either case it is usually configured as a dedicated JBoss EAP server instance, where no applications are deployed. This dedicated server instance is not a cluster member. You can use a server group consisting only of multiple dedicated load balancer JBoss EAP instances to prevent having a single point of failure.

Configuring undertow as a dynamic load balancer involves the following high-level steps:

/profile=ha/subsystem=undertow/configuration=filter/mod_cluster=lb:add(\
management-socket-binding=http, advertise-socket-binding=modcluster)

/profile=ha/subsystem=undertow/server=default-server/host=default-host/filter-ref=lb:add

/profile=ha/subsystem=modcluster/mod_cluster-config=configuration:\
write-attribute(name=advertise-security-key,value=secret)

/profile=ha/subsystem=undertow/configuration=filter/mod_cluster=lb:\
write-attribute(name=security-key,value=secret)

/profile=ha/subsystem=undertow/configuration=filter/mod_cluster=lb:\
write-attribute(name=advertise-frequency,value=0)

/profile=ha/subsystem=undertow/configuration=filter/mod_cluster=lb:\
write-attribute(name=advertise-socket-binding,value=null)

/profile=ha/subsystem=modcluster/mod_cluster-config=configuration:\
write-attribute(name=advertise,value=false)

/socket-binding-group=ha-sockets/remote-destination-outbound-socket-binding=lb:\
add(host=10.1.2.3, port=8080)

/profile=ha/subsystem=modcluster/mod_cluster-config=configuration:\
write-attribute(name=proxies,value=[lb])

Configuring undertow as a static load balancer involves the following high-level steps:

You must configure each cluster member IP address and AJP port as an outbound socket binding. For example, assuming there are two cluster members:

/socket-binding-group=ha-sockets/remote-destination-outbound-socket-binding=\
cluster-member1/:add(host=10.1.2.3, port=8009)

/socket-binding-group=ha-sockets/remote-destination-outbound-socket-binding=\
cluster-member2/:add(host=10.1.2.13, port=8009)

The reverse-proxy handler is created in the undertow subsystem:

/profile=ha/subsystem=undertow/configuration=handler/reverse-proxy=lb:add

Each cluster member is added as a route to the reverse-proxy handler by using a host child:

/profile=ha/subsystem=undertow/configuration=handler/reverse-proxy=lb/host=member1:\
add(outbound-socket-binding=cluster-member1,scheme=ajp,instance-id=hosta:server1,\
path=/app)

/profile=ha/subsystem=undertow/configuration=handler/reverse-proxy=lb/host=member2:\
add(outbound-socket-binding=cluster-member2,scheme=ajp,instance-id=hostb:server2,\
path=/app)

In the previous commands, each route instance-id attribute has to match the jboss.server.node system property for the referred node. This system property usually takes the form host_name:server_name. The path attribute value has to match the clustered application context path.

Enable the reverse-proxy handler on the desired undertow virtual hosts:

/profile=ha/subsystem=undertow/server=default-server/host=default-host/\
location=\/app:add(handler=lb)

In the previous example command, it was necessary to escape the / forward slash in /app by using a \ back slash, because the forward slash is part of the CLI syntax.

Notice that this example only configures the load balancer for a single clustered application with the /app context path. To add more applications to the load balancer, you can add each one as a new host child with a different path attribute.

Jakarta EE web containers usually employ the JSESSIONID HTTP cookie to store a unique session identifier (ID), as mandated by the Servlet API specification. This cookie value is an index to retrieve user session data stored in memory.

Undertow uses the session ID cookie to provide an efficient session affinity implementation. Undertow appends the jboss.server.node system property to the session ID. The load balancer intercepts the next requests from that browser, and send them to the same backend server.

The dynamic load balancer also uses an instance-id attribute in the same way a static load balancer does. Mod_cluster creates load balancing configurations at runtime. The cluster member modcluster subsystem provides all necessary information, including the jboss.server.node system property value. Then, the mod_cluster filter creates a hidden reverse_proxy handler and configures its routes.

Earlier JBoss EAP releases had no undertow subsystem, and the embedded web server provided no proxy capabilities.

Red Hat supported a number of native web server plug-ins as load balancers, for many operating systems and web servers.

Some of them are still supported by Red Hat through the Red Hat JBoss Core Services product, which is included as part of the JBoss EAP subscription.

JBoss Core Services provides the following load balancers modules, based on Apache Httpd native modules for Linux, Windows and Solaris operating systems:

Configuration details for the load balancers follow the same concepts already presented for Undertow. For more information, see the references section.