Configuring the HTTP Load Balancer

Load balancer configuration is maintained in the domain.xml file. Configuring a load balancer is extremely flexible:

A load balancer services only one domain, though a domain can have multiple load balancers associated with it.
Each load balancer configuration can have multiple load balancers associated with it, though each load balancer has only one load balancer configuration.

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
Changing the HTTP Load Balancer Configuration
Disabling (Quiescing) a Server Instance or Cluster
Disabling (Quiescing) an Application
Configuring HTTP and HTTPS Failover
Using Redirects with the HTTP Load Balancer
Configuring Idempotent URLs

Configuring an HTTP Load Balancer on the DAS

You can create a load balancer configuration on the DAS using the asadmin create-http-lb subcommand . See Setting Up HTTP Load Balancing for instructions. Refer to create-http-lb(1) for complete information about the options for this subcommand.

Creating an HTTP Load Balancer Reference

When you create a reference in the load balancer to a standalone server or cluster, the server or cluster is added to the list of target servers and clusters the load balancer controls. If you created the load balancer configuration with a target, that target is already added as a reference.

You can create a reference using the asadmin create-http-lb-ref(1) subcommand. You must supply the load balancer configuration name and the target server instance or cluster.

To delete a reference, use the delete-http-lb-ref(1) subcommand. Before you can delete a reference, the referenced server or cluster must be disabled using disable-http-lb-server(1).

Enabling Server Instances for HTTP Load Balancing

After creating a reference to the server instance or cluster, enable the server instance or cluster using the asadmin enable-http-lb-server subcommand. If you specified a server instance or cluster as the target when you created the load balancer configuration, load balancing is enabled for that target by default. Refer to enable-http-lb-server(1) for complete information about the options for this subcommand.

Enabling Applications for HTTP Load Balancing

All servers managed by a load balancer must have homogenous configurations, including the same set of applications deployed to them. Once an application is deployed and enabled for access (this happens during or after the deployment step), load balancing is enabled for the application by default. If an application is not enabled for load balancing, requests to it are not load balanced and failed over, even if requests to the servers the application is deployed to are load balanced and failed over.

When enabling the application, specify the application name and target. If the load balancer manages multiple targets (for example, two clusters), enable the application on all targets.

Use the asadmin enable-http-lb-application subcommand to enable load balancing for one or more applications. Refer to enable-http-lb-application(1) complete information about the options for this subcommand.

Creating the HTTP Health Checker

The load balancer’s health checker periodically checks all the configured GlassFish Server instances that are marked as unhealthy. A health checker is not required, but if no health checker exists, or if the health checker is disabled, the periodic health check of unhealthy instances is not performed. The load balancer will not be able to determine when an unhealthy instance becomes healthy.

The load balancer’s health check mechanism communicates with the instance using HTTP. The health checker sends an HTTP request to the URL specified and waits for a response. A status code in the HTTP response header between 100 and 500 means the instance is healthy.

The following topics are addressed here:

Creating a Health Checker
Additional Health Check Properties for Healthy Instances

Creating a Health Checker

To specify the health checker properties use the asadmin create-http-health-checker subcommand. If an instance is marked as unhealthy, the health checker polls the unhealthy instances to determine if the instance has become healthy.

The health checker uses the specified URL to check all unhealthy instances to determine if they have returned to the healthy state. If the health checker finds that an unhealthy instance has become healthy, that instance is added to the list of healthy instances.

Use the delete-http-health-checker subcommand to delete health checkers.

Refer to create-http-health-checker(1) and delete-http-health-checker(1) for complete information about the options for these subcommands.

Additional Health Check Properties for Healthy Instances

The health checker created by create-http-health-checker only checks unhealthy instances. To periodically check healthy instances, set some additional properties in your exported loadbalancer.xml file.

To check healthy instances, set the following properties in loadbalancer.xml.

Table 8-1 Manual Health-Checker Properties in loadbalancer.xml

Property	Definition
`active-healthcheck-enabled`	True/false flag indicating whether to ping healthy server instances to determine whether they are healthy. To ping server instances, set the flag to true.
`number-healthcheck-retries`	Specifies how many times the load balancer’s health checker pings an unresponsive server instance before marking it unhealthy. Valid range is between 1 and 1000. A default value to set is 3.

Set the properties by using the asadmin set command. For example:

asadmin> set domain.lb-configs.load-balancer-config.property.\ active-healthcheck-enabled=true

asadmin> set domain.lb-configs.load-balancer-config.property.\ number-healthcheck-retries=5

Changing the HTTP Load Balancer Configuration

If you change a load balancer configuration by creating or deleting references to servers, deploying new applications, enabling or disabling servers or applications, and so on, export the load balancer configuration file again and copy it to the web server’s config directory. For more information, see Exporting the HTTP Load Balancer Configuration File.

Alternatively, you can generate the load balancer configuration file and send the data over the wire to the web server in a single step. For more information, see To Export the Load Balancer Configuration Using the apply-http-lb-changes Subcommand.

The Loadbalancer Plug-In checks for an updated configuration periodically based on the reload interval specified in the load balancer configuration. After the specified amount of time, if the load balancer discovers a new configuration file, it starts using that configuration.

The following topics are addressed here:

Exporting the HTTP Load Balancer Configuration File
Enabling Dynamic Reconfiguration

Exporting the HTTP Load Balancer Configuration File

The Loadbalancer Plug-In that is available for Oracle GlassFish Server 3.1 uses a configuration file called loadbalancer.xml. After configuring the load balancer, you can export the configuration details from domain.xml to the loadbalancer.xml file. To do this, use the asadmin export-http-lb-config subcommand.

Alternatively, you can use the apply-http-lb-changes subcommand to generate the load balancer configuration file and send the data over the wire to the web server in a single step.

The following topics are addressed here:

To Export the Load Balancer Configuration Using the export-http-lb-config Subcommand
To Export the Load Balancer Configuration Using the apply-http-lb-changes Subcommand

To Export the Load Balancer Configuration Using the `export-http-lb-config` Subcommand

Export a loadbalancer.xml file using the asadmin export-http-lb-config subcommand.
Refer to export-http-lb-config(1) for complete information about the options for this subcommand.
Copy the exported load balancer configuration file to the web server’s configuration directory.
For example, for the Oracle iPlanet Web Server, that location usually is web-server-instance-dir/config .

Note - The load balancer configuration file in the web server’s configuration directory must be named loadbalancer.xml.

To Export the Load Balancer Configuration Using the `apply-http-lb-changes` Subcommand

This procedure explains how to generate the load balancer configuration file and send the data over the wire to the web server in a single step.

Configure the web server for SSL setup and import the DAS certificate.
See Chapter 7, Configuring Web Servers for HTTP Load Balancing for configuration instructions for your particular web server.
Use the apply-http-lb-changes subcommand to generate and push the load balancer configuration file to the web server.
See apply-http-lb-changes(1) for complete subcommand usage instructions.

Enabling Dynamic Reconfiguration

With dynamic reconfiguration, the Loadbalancer Plug-In periodically checks for an updated configuration.

To Enable Dynamic Reconfiguration

When creating a load balancer configuration, use the --reloadinterval option with the create-http-lb subcommand.
This option sets the amount of time between checks for changes to the load balancer loadbalancer.xml configuration file. By default, dynamic reconfiguration is enabled, with a reload interval of 60 seconds. Refer to create-http-lb(1) for complete information about this subcommand.
If you have previously disabled the --reloadinterval option, or to change the reload interval, use the asadmin set command.
After changing the reload interval, export the load balancer configuration file again and copy it to the web server’s config directory.
For example:
1. Determine the configuration name for your load balancer.
  In this case, the load balancer configuration name is mylb.
```
asadmin> get load-balancers.load-balancer.mylb.lb-config-name load-balancers.load-balancer.mylb.lb-config-name=mylb_LB_CONFIG
Command get executed successfully.
```
2. Next, change the reload interval.
  Enter the following command on a single line:
```
asadmin> set
 lb-configs.lb-config.mylb_LB_CONFIG.reload-poll-interval-in-seconds=30 lb-configs.lb-config.mylb_LB_CONFIG.reload-poll-interval-in-seconds=30
Command set executed successfully.
```
Note - If --reloadinterval is set to 0, then any updates to load-balancer.xml are not picked up. In this case, dynamic changes can only be pushed by using the apply-http-lb-changes subcommand. See To Export the Load Balancer Configuration Using the apply-http-lb-changes Subcommand.

Note - If the load balancer encounters a hard disk read error while attempting reconfiguration, it uses the configuration that is currently in memory. The load balancer also ensures that the modified configuration data is compliant with the DTD before over writing the existing configuration.
If a disk read error is encountered, a warning message is logged to the web server’s error log file. The error log for Oracle iPlanet Web Server is in web-server-install-dir/web-server-instance/logs/.

Disabling (Quiescing) a Server Instance or Cluster

Before stopping the server for any reason, the instance should complete serving requests. The process of gracefully disabling a server instance or cluster is called quiescing.

The load balancer uses the following policy for quiescing instances:

If an instance (either standalone or part of a cluster) is disabled, and the timeout has not expired, sticky requests continue to be delivered to that instance. New requests, however, are not sent to the disabled instance.
When the timeout expires, the instance is disabled. All open connections from the load balancer to the instance are closed. The load balancer does not send any requests to this instance, even if all sessions sticking to this instance were not invalidated. Instead, the load balancer fails over sticky requests to another healthy instance.

To Quiesce a Server Instance or Cluster

Run asadmin disable-http-lb-server, setting the timeout (in minutes).
Export the load balancer configuration file using the asadmin export-http-lb-config command.
Copy the exported configuration to the web server's config directory.
Alternatively, to export the load balancer configuration file and send the data over the wire to the web server in a single step, you can configure the web server for SSL setup and import the DAS certificate. The load balancer configuration file can then be pushed using the apply-http-lb-changes(1) subcommand. For information on configuring web servers for HTTP load balancing, see Chapter 7, Configuring Web Servers for HTTP Load Balancing.
Stop the server instance or instances.

Disabling (Quiescing) an Application

Before you undeploy a web application, the application should complete serving requests. The process of gracefully disabling an application is called quiescing. When you quiesce an application, you specify a timeout period. Based on the timeout period, the load balancer uses the following policy for quiescing applications:

If the timeout has not expired, the load balancer does not forward new requests to the application, but returns them from the web server itself. However, the load balancer continues to forward sticky requests until the timeout expires.
When the timeout expires, the load balancer does not accept any requests for the application, including sticky requests.

When you disable an application from every server instance or cluster the load balancer references, the users of the disabled application experience loss of service until the application is enabled again. If you disable the application from one server instance or cluster while keeping it enabled in another server instance or cluster, users can still access the application. For more information, see Chapter 9, Upgrading Applications Without Loss of Availability.

To Quiesce an Application

Use the asadmin disable-http-lb-application subcommand.
Specify the following options:
- Timeout (in minutes)
- Name of the application to disable
- Target cluster or instance on which to disable application
Export the load balancer configuration file using asadmin export-http-lb-config.
Copy the exported configuration to the web server config directory.
Alternatively, to export the load balancer configuration file and send the data over the wire to the web server in a single step, you can configure the web server for SSL setup and import the DAS certificate. The load balancer configuration file can then be pushed using the apply-http-lb-changes(1) subcommand. For information on configuring web servers for HTTP load balancing, see Chapter 7, Configuring Web Servers for HTTP Load Balancing.

Configuring HTTP and HTTPS Failover

The Loadbalancer Plug-In fails over HTTP/HTTPS sessions to another application server instance if the original instance to which the session was connected becomes unavailable. This section describes how to configure the Loadbalancer Plug-In to enable HTTP/HTTPS routing and session failover.

The following topics are addressed here:

HTTPS Routing
Configuring HTTPS Routing
Known Issues

HTTPS Routing

The Loadbalancer Plug-In routes all incoming HTTP or HTTPS requests to instances. However, if HTTPS routing is enabled, an HTTPS request will be forwarded by the Loadbalancer Plug-In to a server using an HTTPS port only. HTTPS routing is performed on both new and sticky requests.

If an HTTPS request is received and no session is in progress, then the Loadbalancer Plug-In selects an available instance with a configured HTTPS port, and forwards the request to that instance.

In an ongoing HTTP session, if a new HTTPS request for the same session is received, then the session and sticky information saved during the HTTP session is used to route the HTTPS request. The new HTTPS request is routed to the same server where the last HTTP request was served, but on the HTTPS port.

Configuring HTTPS Routing

The --httpsrouting option for the create-http-lb subcommand controls whether HTTPS routing is turned on or off for all the application servers that are participating in load balancing. If this option is set to false, all HTTP and HTTPS requests are forwarded as HTTP. If set to true, HTTPS are forwarded as HTTPS requests. Set HTTPS routing when creating a new load balancer configuration, or change it later using the asadmin set command.

Note - Note the following limitations:

For HTTPS routing to work, one or more HTTPS listeners must be configured.
If --httpsrouting is set to true, and a new or a sticky request comes in where there are no healthy HTTPS listeners in the cluster, then that request generates an error.

Known Issues

The Load Balancer has the following limitations with HTTP/HTTPS request processing.

In cases where a web browser does not share cookies between HTTP and HTTPS requests, if a session uses a combination of HTTP and HTTPS requests, then the first request must be an HTTP request. If the first request is an HTTPS request, it cannot be followed by an HTTP request. This is because the cookies associated with the HTTPS session are not returned by the browser. The browser interprets the two different protocols as two different servers, and initiates a new session. This limitation only exists if --httpsrouting is set to true and the client web browser does not share cookies between HTTP and HTTPS requests.
If a session has a combination of HTTP and HTTPS requests, then the instance must be configured with both HTTP and HTTPS listeners. This limitation is valid only if --httpsrouting is set to true.
If a session has a combination of HTTP and HTTPS requests, then the instance must be configured with HTTP and HTTPS listeners that use standard port numbers, that is, 80 for HTTP, and 443 for HTTPS. This limitation applies regardless of the value set for --httpsrouting. This limitation is due to redirection, and nonstandard ports cannot be handled correctly.

Using Redirects with the HTTP Load Balancer

Use redirects to redirect a request from one URL to another URL. For example, use redirects to send users to a different web site (for example, redirecting from an old version of an application to a newer version) or from HTTP to HTTPS or from HTTPS to HTTP. Redirects can be enabled in a number of ways in the application (for example, servlet-based redirects, web.xml redirects). However, sending a redirect URL through the load balancer may require some additional configuration of the GlassFish Server or the load balancer. Note that redirects are different from requests that are forwarded using HTTPS Routing. When using redirects, set httpsrouting to false. If configuring HTTPS requests to be forwarded to HTTP, use HTTPS Routing.

The following settings affect redirects: the auth-pass-through-enabled attribute of an HTTP type protocol, the proxyHandler property of the HTTP service, and the rewrite-location property in the loadbalancer.xml file.

The `auth-pass-through-enabled` Attribute

When the GlassFish Server auth-pass-through-enabled attribute is set to true, information about the original client request (such as client IP address, SSL keysize, and authenticated client certificate chain) is sent to the HTTP type network listeners using custom request headers. The auth-pass-through-enabled attribute allows you to take advantage of a hardware accelerator for faster SSL authentication if you have one installed. It is easier to configure a hardware accelerator on the load balancer than on each clustered GlassFish Server instance.

Caution - Set auth-pass-through-enabled to true only if the GlassFish Server is behind a firewall.

Use the asadmin set command to set the auth-pass-through-enabled attribute on an HTTP type protocol, which is referenced by an HTTP type network listener. Be sure to enter this command on a single line.

asadmin> set cluster-name-config.network-config.protocols.protocol-name.http.auth-pass-through-enabled=true

The `proxyHandler` Property

The proxy handler for the GlassFish Server is responsible for retrieving information about the original client request that was intercepted by a proxy server (in this case, a load balancer) and forwarded to the server, and for making this information available to the deployed web application that is the target of the client request. If the intercepting proxy server is SSL-terminating, the proxy handler retrieves and makes available additional information about the original request, such as whether the original request was an HTTPS request, and whether SSL client authentication is enabled. Use the proxyHandler property only if auth-pass-through-enabled is set to true.

The proxy handler inspects incoming requests for the custom request headers through which the proxy server conveys the information about the original client request, and makes this information available to the web application using standard ServletRequest APIs.

The proxy handler implementation is configurable globally at the HTTP service level with the proxyHandler property, whose value specifies the fully-qualified class name of an implementation of the com.sun.appserv.ProxyHandler abstract class. Configurable proxy handler implementations allow the server to work with any proxy server, as long as the proxy handler implementation knows about the HTTP request header names, and understands the format of their values, through which the proxy server conveys information about the original client request.

Note - If the proxyHandler property is not set and the auth-pass-through-enabled attribute is set to true, then the default implementation that works with the Loadbalancer Plug-In is enabled.

The proxy handler for the GlassFish Server reads and parses the SSL certificate chain from the request header. This allows a back-end instance to retrieve information about the original client request that was intercepted by an SSL-terminating proxy server (in this case, a load balancer). You can use the default proxy handler settings, or configure your own using the proxyHandler property of the HTTP service or HTTP/HTTPS listener. The proxyHandler property specifies the fully-qualified class name of a custom implementation of the com.sun.appserv.ProxyHandler abstract class used by the listener or all listeners.

An implementation of this abstract class inspects a given request for the custom request headers through which the proxy server communicates the information about the original client request to the instance, and returns that information to its caller. The default implementation reads the client IP address from an HTTP request header named Proxy-ip, the SSL keysize from an HTTP request header named Proxy-keysize, and the SSL client certificate chain from an HTTP request header named Proxy-auth-cert. The Proxy-auth-cert value must contain the BASE-64 encoded client certificate chain without the BEGIN CERTIFICATE and END CERTIFICATE boundaries and with \n replaced with % d% a.

You can only use this property if auth-pass-through-enabled is set to true. If you set the proxyHandler property on an individual HTTP or HTTPS listener, it overrides the default setting for all listeners.

Use the asadmin set command to set the proxyHandler property on the HTTP service.

asadmin> set cluster-name-config.http-service.property.proxyHandler=classname

The `rewrite-location` Property

If set to true, the rewrite-location property rewrites the original request information and includes the protocol (HTTP or HTTPS), host, and port information By default, the rewrite-location property is set to true to maintain backward compatibility with previous GlassFish Server releases.

The rewrite-location property is not available through the asadmin create-http-lb-config subcommand. To use the property, use the asadmin set command as follows:

asadmin set lb-configs.load-balancer-config-config.property.rewrite-location=false

Set the rewrite-location property with the following points in mind:

If httpsrouting is false and auth-pass-through-enabled is not enabled on the GlassFish Server, set the rewrite-location property to true. When auth-pass-through-enabled is not enabled, the GlassFish Server will not be aware of the protocol (HTTP or HTTPS) of the original request. By setting rewrite-location to true the load balancer modifies the protocol part of the rewrite location suitably. That is, if the client is sending HTTPS requests, then the load balancer redirects the client to a HTTPS-enabled listener port on the load balancer. The process is the same for HTTP requests.
If httpsrouting is false, and auth-pass-through-enabled is enabled on the GlassFish Server, then rewrite-location can be set to true or false because the GlassFish Server is aware of whether the client request is HTTP or HTTPS. When auth-pass-through-enabled is enabled, the GlassFish Server modifies the protocol part of rewrite location suitably. If rewrite-location is set to false, the load balancer does not rewrite the location of the redirected URL. If set to true, it rewrites the location of the redirected URL. But this rewrite is not needed as the GlassFish Server was aware of HTTPS connections from the client. Also, if the application needs to redirect HTTP to HTTPS or HTTPS to HTTP, you must set the rewrite-location property to false.

Configuring Idempotent URLs

An idempotent request is one that does not cause any change or inconsistency in an application when retried. In HTTP, some methods (such as GET) are idempotent, while other methods (such as POST) are not. Retrying an idempotent URL must not cause values to change on the server or in the database. The only difference is a change in the response received by the user.

Examples of idempotent requests include search engine queries and database queries. The underlying principle is that the request must not cause an update or modification of data.

To enhance the availability of deployed applications, configure the environment to retry failed idempotent HTTP requests on all the instances serviced by a load balancer. This option is used for read-only requests, for example, to retry a search request.

Configure idempotent URLs in the sun-web.xml file. When you export the load balancer configuration, idempotent URL information is automatically added to the loadbalancer.xml file.

For more information on configuring idempotent URLs, see Configuring Idempotent URL Requests in Oracle GlassFish Server 3.1 Application Development Guide.

Skip Navigation Links
Exit Print View
	Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide