Skip Navigation Links | |
Exit Print View | |
Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide |
1. High Availability in GlassFish Server
2. Setting Up SSH for Centralized Administration
3. Administering GlassFish Server Nodes
4. Administering GlassFish Server Clusters
5. Administering GlassFish Server Instances
6. Administering Named Configurations
7. Configuring Web Servers for HTTP Load Balancing
8. Configuring HTTP Load Balancing
How the HTTP Load Balancer Works
Installing the Loadbalancer Plug-In
Setting Up HTTP Load Balancing
Prerequisites for Setting Up HTTP Load Balancing
Procedure for Setting Up HTTP Load Balancing
To Set Up Load Balancing Using the asadmin Tool
HTTP Load Balancer Deployments
Using Clustered Server Instances
Using Multiple Standalone Instances
Configuring the HTTP Load Balancer
Configuring an HTTP Load Balancer on the DAS
Creating an HTTP Load Balancer Reference
Enabling Server Instances for HTTP Load Balancing
Enabling Applications for HTTP Load Balancing
Creating the HTTP Health Checker
Additional Health Check Properties for Healthy Instances
Changing the HTTP Load Balancer Configuration
Exporting the HTTP Load Balancer Configuration File
Enabling Dynamic Reconfiguration
Disabling (Quiescing) a Server Instance or Cluster
To Quiesce a Server Instance or Cluster
Disabling (Quiescing) an Application
Configuring HTTP and HTTPS Failover
Using Redirects with the HTTP Load Balancer
The auth-pass-through-enabled Attribute
Monitoring the GlassFish Loadbalancer Plug-In
Load Balancer Configurator Log Messages
Request Dispatch and Runtime Log Messages
Enabling HTTP Load Balancer Logging
To Turn on HTTP Load Balancer Logging
Understanding Monitoring Messages
9. Upgrading Applications Without Loss of Availability
10. Configuring High Availability Session Persistence and Failover
11. Configuring Java Message Service High Availability
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:
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.
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:
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.
The load balancer provides increased flexibility and ease-of-use through the following features:
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.
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.
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.