The HTTP Load Balancer enables high availability of services deployed on Java EE Application Servers. While doing so, it fails over a session request to another server instance if the original servicing instance is detected to be unavailable or unhealthy to service a request. For HTTP session information to persist, you must be using the cluster profile and have configured HTTP session persistence using in-memory replication or the HADB. For more information, see Chapter 9, Configuring High Availability Session Persistence and Failover.
The load balancer does not handle URI/URLs that are greater than 8k.
When a new HTTP request is sent to the load balancer plug-in, it is forwarded to an instance based on a simple round robin scheme. If the request is for a session-based application, then this also includes a request for a new session. Subsequent requests from the same client for the same session-based application are considered assigned or sticky requests and are routed by the load balancer to the same instance. Hence, the name sticky round robin. Requests to a non session-based application and the first request for a session-based application are called unassigned requests. Stickiness is achieved by using cookies, or explicit URL rewriting. The load balancer determines the method of stickiness automatically.
The load balancer plug-in uses the following methods to determine session stickiness:
Cookie Method: the load balancer plug-in uses a separate cookie to record the route information. The HTTP client (typically, the web browser) must support cookies to use the cookie based method. If the HTTP client is unable to accept cookies, the plug-in uses the following method.
Explicit URL Rewriting: the sticky information is appended to the URL. This method works even if the HTTP client does not support cookies.
From the sticky information, the load balancer plug-in first determines the instance to which the request was previously forwarded. If that instance is found to be healthy, the load balancer plug-in forwards the request to that specific instance. Therefore, all requests for a given session are sent to the same instance.
The load balancer provides increased flexibility and ease-of-use through the following features.
Enterprise Server allows changes to the load balancer configuration made from the Admin Console to be automatically sent over the wire to the Web Server configuration directory. With previous versions of Enterprise Server, the load balancer configuration had to be exported and then copied over to the web server configuration directory.
The load balancer enables improved distribution of HTTP requests. The administrator can use an attribute called 'weight' to specify how requests will be proportionately routed to an instance. For example, suppose a cluster has two instances, and the administrator has assigned a weight of 100 to instance x and a weight of 400 to instance y. Now, for every 100 requests, 20 will go to instance x and 80 will go to instance y.
Enterprise Server enables the administrator to define a custom policy for distributing HTTP requests. A custom policy defines the load balancing algorithm that the load balancer plug-in must use. In other words, the Administrator can define which instance will handle an HTTP request. To use this feature, the administrator needs to develop a shared library, which must implement an interface called loadbalancer.h. The shared library can, for example, be used to evaluate the headers of incoming requests provided to it and in accordance to some criteria, select the instance that can serve the request. This shared library would be loaded by the load balancer.
The interface loadbalancer.h is available under webserver_install_dir/plugins/lib/install. Enterprise Server also bundles a shared library called roundrobin.c, that the administrator can use as a template to build the shared library.