How the HTTP Load Balancer Works

This section discusses using the GlassFish Loadbalancer Plug-In.

The load balancer attempts to evenly distribute the workload among multiple instances (either standalone or clustered), thereby increasing the overall throughput of the system.

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 more information, see Chapter 10, Configuring High Availability Session Persistence and Failover.

The following topics are addressed here:

• Installing the Loadbalancer Plug-In

• HTTP Load Balancing Algorithm

• Features of the GlassFish Loadbalancer Plug-In

Installing the Loadbalancer Plug-In

The GlassFish Loadbalancer Plug-In is available for separate download for customers who are using Oracle GlassFish Server 3.1. Note that the Loadbalancer Plug-In is not available for GlassFish Server Open Source Edition 3.1.

The Plug-In is installed by means of a graphical GlassFish Loadbalancer Configurator. The Configurator automatically configures most of settings that are required to use the Loadbalancer Plug-In with your web server. However, depending on your particular web server, there may be some manual configuration procedures that you need to perform before or after you run the Configurator.

For complete instructions on installing the Loadbalancer Plug-In, see Chapter 7, Configuring Web Servers for HTTP Load Balancing.

HTTP Load Balancing Algorithm

The HTTP load balancer, by default, uses a sticky round robin algorithm to load balance incoming HTTP and HTTPS requests.

When a new HTTP request is sent to the Loadbalancer Plug-In, it is forwarded to an instance based on a simple round robin scheme. If the request is for a session-based application, and a new session is created, then subsequent requests that are part of the same session are considered to be 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 Loadbalancer Plug-In uses the following methods to determine session stickiness:

• Cookie Method

  The Loadbalancer 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. To implement explicit URL rewriting, the application developer must use HttpResponse.encodeURL() and encodeRedirectURL() calls to ensure that any URLs in the application have the session information appended to them.

From the sticky information, the Loadbalancer Plug-In first determines the instance to which the request was previously forwarded. If that instance is found to be healthy, the Loadbalancer Plug-In forwards the request to that specific instance. If the instance is unavailable, a new instance is chosen and the subsequence requests are routed to the new instance.

Features of the GlassFish Loadbalancer Plug-In

The load balancer provides increased flexibility and ease-of-use through the following features:

• Auto Apply

• Weighted Round Robin

• User-Defined Load Balancing

Auto Apply

GlassFish Server enables changes made to a configuration through the Administration Console or from the command line with the apply-http-lb-changes(1) subcommand to be automatically sent over the wire to the web server configuration directory.

Weighted Round Robin

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.

User–Defined Load Balancing

GlassFish Server enables administrators to define custom policies for distributing HTTP requests. A custom policy defines the load balancing algorithm that the Loadbalancer Plug-In must use. In other words, an 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 loadbalancer.h interface is available in webserver-install-dir/glassfish-lbplugin/lib/install/templates. A sample implementation, named roundrobin.c, is provided in this same directory. Administrators can use roundrobin.c as a template to build custom shared libraries.