Configuring Load Balancing

This chapter describes how to setup load balancing of HTTP requests, configure, and administer the load balancer plug-in.

About Load Balancing

Sun™ Open Net Environment (ONE) Application Server 7, Enterprise Edition, provides load balancing and HTTP session persistence. The goal of load balancing is to evenly distribute the workload between multiple Sun ONE Application Server instances, thereby increasing the overall throughput of the system.

The load balancer plug-in is an enhanced version of the HTTP reverse proxy plug-in used in Sun ONE Application Server 7, Standard Edition. For more information on the reverse proxy plug-in, see Chapter 7, “Configuring the Web Server Plugin,” in Sun ONE Application Server 7, Standard Edition Administrator’s Guide.

Load Balancing Algorithm

Sun ONE Application Server load balancer uses sticky round robin algorithm to load balance incoming HTTP and HTTPS requests. This means that all requests for a given session are sent to the same application server instance. With a sticky load balancer, the session data can be cached on a single application server rather than having to be distributed to all instances in a cluster.

Therefore, the sticky round robin scheme provides significant performance benefits that normally override the benefits of a more evenly distributed load that can be obtained with pure round robin.

About Sticky Round Robin Load Balancing Algorithm

When a new HTTP request is sent to the load balancer plug-in, it’s forwarded to an application server instance based on a simple round robin scheme. Subsequently, this request is “stuck” to this particular application server instance, either by using cookies, or explicit URL rewriting.

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 application server instance. Therefore, all requests for a given session are sent to the same application server instance.

The load balancer plugin uses the following methods to determine session stickiness:

Cookie Based Method

In the cookie based method, the load balancer plug-in uses a separate cookie to record the route information.

Explicit URL Rewriting Method

In the explicit URL rewriting method, the sticky information is appended to the URL. This method works even if the browser does not support cookies.

Requirements for Load Balancing

You must meet the following requirements before you can use the load balancer plug-in:


Note	The browser must support cookies to use the cookie based method.

Configuring Load Balancer Plug-in

Configuration Changes to Web Server

The load balancer plug-in installation program makes a few modifications to the web server’s configuration files. This section details the changes to the following web server’s configuration files:

Modifications to Sun ONE Web Server Configuration

Modifications to Apache Web Server



Note	The load balancer plug-in can be installed either along with Sun ONE Application Server 7, Enterprise Edition, or separately, on a machine running the supported web server. For complete details on the installation procedure, see Sun ONE Application Server Installation Guide.

Modifications to Sun ONE Web Server Configuration

The installation program makes the following changes to the Sun ONE Web Server’s configuration files:

Adds the following load balancer plug-in specific entries to the web server instance’s magnus.conf file:

##EE lb-plugin
Init fn="load-modules" shlib="webserver_install_dir/webserver_instance/plugins/lbplugin/bin/libpassthrough.so" funcs="init-passthrough,service-passthrough,name-trans-passthrough" Thread="no"

Init fn="init-passthrough"

##end addition for EE lb-plugin

Adds the following entries specific to the load balancer plug-in to the web server instance’s obj.conf file:

NameTrans fn="name-trans-passthrough" name="lbplugin" config-file="webserver_install_dir/webserver_instance/config/loadbalancer.xml"

<Object name="lbplugin">
ObjectType fn="force-type" type="magnus-internal/lbplugin"
PathCheck fn="deny-existence" path="*/WEB-INF/*"
Service type="magnus-internal/lbplugin" fn="service-passthrough"
Error reason="Bad Gateway" fn="send-error" uri="$docroot/badgateway.html"
</object>

lbplugin is a name that uniquely identifies the Object, and webserver_install_dir/webserver_instance/config/loadbalancer.xml is the location of the XML configuration file for the virtual server on which the load balancer is configured to run.

You must now configure the load balancing plug-in, by editing the loadbalancer.xml configuration file. For more information on editing the loadbalancer.xml file, see "Creating the Load Balancer Configuration File".

Modifications to Apache Web Server

The load balancer plug-in installation program extracts the necessary files to the modules folder under the web server’s root directory.It adds the following entries specific to the load balancer plug-in to the web server instance’s httpd.conf file:

LoadModule apachelbplugin_module libexec/mod_loadbalancer.so
#AddModule mod_apachelbplugin.cpp
<IfModule mod_apachelbplugin.cpp>
config-file webserver_instance/config/loadbalancer.xml
locale en
</IfModule>

<VirtualHost machine_ip_address>
DocumentRoot "webserver_instance/apache/htdocs"
ServerName server_name
</VirtualHost>



Note	Apache web server must be run in secure mode to ensure that it works well with the load balancer plug-in. We recommend that the URL pattern be set to / to ensure that all requests are forwarded to the load balancer plug-in first. If the request cannot match any of the installed applications, then it will be redirected to the web server. Create a directory called sec_db_files under apache_install_dir and copy <S1AS_installables_dir/sec_db_files/* to apache_install_dir/sec_db_files. When more than one Apache child processes are running, each process will have its own load balancing round robin sequence. For example, if there are two Apache child processes running, and the load balancing plug-in load balances on to two application server instances, the first request will be sent to instance #1 and the second request will also be sent to instance #1. The third request will be sent to instance #2 and the fourth request will be sent to instance #2 again. This trend will repeat (instance1, instance1, instance2, instance2, etc.) This behavior is different from what the user would usually expect, that is, instance1, instance2, instance1, instance2 .... This behavior is due to the fact that in Application Server 7 EE, the load balancing plug-in in Apache would instantiate a load balancer instance for each apache process, thereby creating an independent load balancing sequence. The use of load balancer plug-in is supported for development systems only and not for production systems.

This following section describes how to create a loadbalancer.xml file and specify the necessary configuration details.

Creating the Load Balancer Configuration File

The loadbalancer.xml file should be created based on the sun-loadbalancer_1_0.dtd and loadbalancer.xml.example files installed during load balancer installation. These files are available in the following location:

Sample loadbalancer.xml file

<!DOCTYPE loadbalancer PUBLIC "-//Sun Microsystems Inc.//DTD Sun ONE Web Server 6.0//EN" "file:///webserver_install_dir/webserver_instance/config/sun-loa dbalancer_1_0.dtd">



Note	The following requirements should be considered while configuring the load balancer plug-in: One load balancer instance cannot have two clusters with the same name. One cluster cannot have two instance elements with the same name. One cluster cannot have two web-module elements with the same context-root. The listeners are unique across servers/clusters. The listeners attribute is a space-separated list of URLs of the application server instance’s listeners. Therefore, no server instance either in a cluster, or across clusters, can have the same listener URL. The listeners attribute should be in the following format: http://hostname.domain:port For example: http://austen.sun.com:80 In this example, http://austen.sun.com, is the address of the application server instance followed by it’s port number, 80. instance name, such as, server1, are variables and you can provide any appropriate name. For HTTPS routing, we recommend that you create a dedicated HTTPS listener under each application server instance. For example, listeners="http://austen.sun.com:80 https://austen.sun.com:443" In this example, https://austen.sun.com, is the address of the application server instance followed by it’s port number, 443.

Save the changes made to the loadbalancer.xml file and restart your web server.



Note	For Apache Web Server, the DTD file will be in the conf directory. Therefore, the target location of the DTD file should be specified as given in the following example: "file:///webserver_install_dir/webserver_instance/conf/sun-loadbalancer_1_0.dtd"> For more information on creating and configuring application server instances, see Chapter 4, "Using Application Server Instances." The response-timeout-in-seconds property specifies the timeout interval within which a response must be obtained for a request that is load balanced, or an error page will be displayed. For information on clustering, see Chapter 17, "Managing Clusters."

Configuring Multiple Web Server Instances

The Sun ONE Application Server 7, Enterprise Edition, installer will not allow the installation of multiple load balancer plug-ins on a single machine. If you need to have multiple web servers (with the load balancer plug-in), on a single machine, in either a single cluster or multiple clusters, a few manual steps are required to configure the load balancer plug-in.

Follow the procedure listed in this section to configure the load balancer plug-in for multiple web server instances.

Configuring Multiple Sun ONE Web Server Instances

Make the following changes to the magnus.conf file of the web server instance on which you want to configure the load balancer plug-in:

Init fn="load-modules" shlib="webserver_install_dir/webserver_instance/plugins/lbplugin/bin/libpassthrough.so" funcs="init-passthrough,service-passthrough,name-trans-passthrough" Thread="no"

Init fn="init-passthrough"

Make the following changes to the obj.conf file of the web server instance on which you want to configure the load balancer plug-in:

NameTrans fn="name-trans-passthrough" name="lbplugin" config-file="webserver_install_dir/webserver_instance/config/loadbalancer.xml"

<Object name="lbplugin">
ObjectType fn="force-type" type="magnus-internal/lbplugin"
PathCheck fn="deny-existence" path="*/WEB-INF/*"
Service type="magnus-internal/lbplugin" fn="service-passthrough"
Error reason="Bad Gateway" fn="send-error" uri="$docroot/badgateway.html"
</object>

Copy the sun-loadbalancer_1_0.dtd and loadbalancer.xml file from the existing (which is configured with the load balancer plug-in) web server instance’ config directory to new, load balancer configured, instance’s config directory.

Edit the loadbalancer.xml file as described in "Creating the Load Balancer Configuration File".

Configuring Multiple Apache Web Server Instances

Add the following entries specific to the load balancer plug-in to the web server instance’s httpd.conf file:

##Addition for EE lb-plugin

LoadFile /usr/lib/libCstd.so.1

<VirtualHost machine_ip_address>
DocumentRoot "webserver_instance/apache/htdocs"
ServerName server_name
</VirtualHost>

##END EE LB Plugin Parameters

Copy the sun-loadbalancer_1_0.dtd and loadbalancer.xml file from the existing (which is configured with the load balancer plug-in) web server instance’ conf directory to new, load balancer configured, instance’s conf directory.

Edit the loadbalancer.xml file as described in "Creating the Load Balancer Configuration File".

Configuring Response Timeout

The load balancer configuration file, loadbalancer.xml, contains a response-timeout-in-seconds property that specifies the timeout interval within which a response must be obtained for a request that is load balanced, or an error page will be displayed. The default value is 60 seconds.

While configuring response-timeout-in-seconds, you must take into account the maximum time-outs for all the applications that are running. The value should be set to the maximum response time of all the applications.

Configuring HTTPS Routing

This section describes how to configure the load balancer plug-in to enable HTTP/HTTPS routing and session fail over between the web server and Sun ONE Application Server. The load balancer plug-in fails over HTTP /HTTPS sessions over to another application server instance if the original application server instance to which the session was connected, becomes unavailable.

About HTTPS Routing

All incoming requests, whether HTTP or HTTPS (secure HTTP), are routed by the load balancer plug-in to application server instances. However, if HTTPS routing is enabled, a HTTPS request will be forwarded by the load balancer plug-in to the application server using an HTTPS port only. Note that HTTPS routing is performed on both new and sticky requests.

If an HTTPS request is received and no session is in progress, then the load balancer plug-in selects an available application server 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 https-routing property controls whether HTTPS routing is turned on or off for all the application servers that are participating in load balancing. If this property is set to false, then all HTTP and HTTPS requests are forwarded as HTTP.

Configuring the Health-Checker


Note	For HTTPS routing to work, there should be one or more HTTPS listeners configured. If https-routing is set to true, and a new or a sticky request comes in, and there is no HTTPS listener healthy in the cluster, then the request is failed.

The load balancer periodically checks all the configured Sun ONE Application Server instances that are marked as unhealthy, based on the values specified in the health-checker element. Enabling the health checker is optional. If the health-checker is not enabled, periodic health check of unhealthy instances will not be performed.

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

To enable the health checker, edit the following properties in the loadbalancer.xml file:

url

Specifies the listener’s URL that the load balancer will check to determine its state of health.

interval-in-seconds

Specifies the interval at which health checks of instances occur. The default is 30 seconds.

timeout-in-seconds

Specifies the timeout interval within which a response must be obtained for a listener to be considered healthy. The default is 10 seconds.

If an application server 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 url attribute to check all unhealthy application server instances to check 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.

Configuring Quiescence

Quiescing is the process of gracefully disabling an application server instance or web application. You can set a duration, called the quiescing period, during which time the load balancer plug-in fails over sticky requests to another healthy instance in the cluster.

If you want to stop an application server instance for any reason (for example to add a JDBC resource), you would want this instance to complete serving these requests before you stop it. Similarly, if you want to undeploy a web application from a cluster, you would want to this application to complete serving the requests before undeploying it. You can achieve this by using the quiescing process.

You can choose to quiesce an application or an application server instance. These two options are described in the following sections:

Quiescing an Instance

The load balancer uses the following policy for quiescing application server instances:

If an instance is disabled, and the time out has not expired, then sticky requests will continue to be delivered to that instance. New requests, however, will not be sent to the disabled instance.

When the time-out expires, the instance is disabled. The load balancer does not send any requests to this instance, even if all sessions sticking to this instance were not invalidated. All open connections from the load balancer to the instance are closed. Instead, the load balancer will fail over sticky requests to another healthy instance in the same cluster.

In the loadbalancer.xml file, set the enabled sub-element under the instance element to false.

Set an appropriate value for the disable-timeout-in-minutes sub-element.

The disable-timeout-in-minutes sub-element represents the elapsed time after which the load balancer will disable the specified instance. The default is 31 minutes.

Quiescing an Application

If an application is disabled, and the time out has not expired, new requests to the disabled applications will not be forwarded by the load balancer. These requests will be returned to the web server. Sticky requests will continue to be forwarded till the time-out expires.

When the time out expires, the application is disabled. The load balancer will not accept any requests for this application, including sticky requests.



	When you quiesce an application, the users of the disabled application will experience loss of service until the application is re-enabled.

In the loadbalancer.xml file, set the enabled sub-element under the web-module element to false.

Set an appropriate value for the disable-timeout-in-minutes sub-element.

The disable-timeout-in-minutes sub-element represents the elapsed time after which the load balancer will disable the specified application. The default is 31 minutes.

About Dynamic Reconfiguration

The load balancer plug-in detects changes to its configuration by examining the time stamp of the loadbalancer.xml file. If a change has been made to the loadbalancer.xml file, then the load balancer automatically reconfigures itself.

The time interval after which the load balancer checks the time stamp of the loadbalancer.xml file can be specified in the reload-poll-interval-in-seconds property in the loadbalancer.xml file.By default, this value is set to 0 seconds, and therefore, dynamic reconfiguration is not enabled.



Note	If the changes to the loadbalancer.xml file are not in the correct format, as specified by the sun-loadbalancer_1_0.dtd, the reconfigure operation will fail. The failure notice will be printed in the web server’s error log files. The load balancer will continue to use the old configuration that’s already loaded in memory. If the load balancer encounters a hard disk read error while attempting to reconfigure itself, then it uses the configuration that is currently in memory. The load balancer also ensures that the modified configuration data is complaint with the DTD before over writing the existing configuration. If a disk read error is encountered, a warning message will be logged to the web server’s error log file. The Sun ONE Web Server’s error log file can be found at this location: webserver_install_dir/webserver_instance/logs/.

Monitoring the Load Balancer Plug-in

Configuring Log Messages

The load balancer plug-in uses the web server logging mechanism to write log messages. The load balancer plug-in uses the default logging level on Sun ONE Web Server (INFO), and Apache Web Server (WARN). The application server log levels - FINE, FINER, and FINEST map to the DEBUG level on the web server.

These log messages are written to the web server log files, and are in the form of raw data that can be parsed using scripts, or imported into spreadsheets to calculate the metrics you need.

Configuring Monitoring

From Sun ONE Web Server’s admin console, go to the Magnus Editor tab.

Set the Log Verbose option to On.

For Apache Web Server, set the log level to DEBUG.

Set the value of the require-monitor-data in loadbalancer.xml property to true.

For example: <property name="require-monitor-data" value="true" />

Request start/stop information is logged for every request.

Failed over request information is logged when the request fails over from an unhealthy instance to a healthy instance.

List of unhealthy instances is logged at the end of every health check cycle.



Note	When logging is enabled on the load balancer plug-in, and if the web server logging level is set to DEBUG or to print verbose messages, the load balancer writes HTTP session IDs in the web server log files. Therefore, if the web server hosting the load balancer plug-in is in the DMZ, we recommend that you do not use the DEBUG or similar log level in production environments. If you must use the DEBUG logging level, then you should turn off load balancer logging by setting require-monitor-data property to false in loadbalancer.xml.

Understanding Monitoring Messages

RequestStart Sticky(New) <req-id> <time-stamp> <URL>

The timestamp value is the number of milliseconds from January 1, 1970. For example:

RequestStart New 123456 602983 http://austen.sun.com/Webapps-simple/servlet/Example1

RequestExit Sticky(New) <req-id> <time-stamp> <URL> <listener-id> <response-time> Failure-<reason for error>(incase of a failure)

For example:

RequestExit New 123456 603001 http://austen.sun.com/Webapps-simple/servlet/Example1 http://austen:2222 18



Note	In the RequestExit message, <response-time> indicates the total request turn-around time in milliseconds, from the perspective of the load balancer plug-in.

UnhealthyInstances <cluster-id> <time-stamp> <listener-id>, <listener-id>...

For example:

UnhealthyInstances cluster1 701923 http://austen:2210, http://austen:3010

FailedoverRequest <req-id> <time-stamp> <URL> <session-id> <failed-over-listener-id> <unhealthy-listener-id>

For example:

FailedoverRequest 239496 705623 http://austen.sun.com/Apps/servlet/SessionTest 16dfdac3c7e80a40 http://austen:4044 http://austen:4045

Load Balancer Configuration File

The loadbalancer.xml file contains the configuration information for load balancing Sun™ Open Net Environment (ONE) Application Server instances. This file is part of the load balancer plugin for the front-end web server. Although located in the web server, it is described in this manual because of its importance and relevance to the Sun ONE Application Server.

The encoding of the loadbalancer.xml file is UTF-8 to maintain compatibility with regular UNIX text editors. A schema file, sun-loadbalancer_1_0.dtd, determines the format and content of the loadbalancer.xml file.

This chapterdescribes loadbalancer.xml and sun-loadbalancer_1_0.dtd files in these sections:

The sun-loadbalancer_1_0.dtd File

The sun-loadbalancer_1_0.dtd file defines the structure of the loadbalancer.xml file, including the elements it can contain and the subelements and attributes these elements can have.


Note	Do not edit the sun-loadbalancer_1_0.dtd file; its contents change only with new versions of Sun ONE Application Server Enterprise Edition.



Note	The sun-loadbalancer_1_0.dtd interface is unstable. An unstable interface may be experimental or transitional, and hence may change incompatibly, be removed, or be replaced by a more stable interface in the next release.

Each element defined in a DTD file (which may be present in the corresponding XML file) can contain the following:

Subelements

Elements can contain subelements. For example, the following file fragment defines the cluster element.

The ELEMENT tag specifies that a cluster element can contain instance, web-module, and health-checker elements in that order.

The following table shows how optional suffix characters of subelements determine the requirement rules, or number of allowed occurrences, for the subelements. The left column lists the subelement ending character, and the right column lists the corresponding requirement rule.

Table 16-1 requirement rules and subelement suffixes
Subelement Suffix	Requirement Rule
element*	Can contain zero or more of this subelement.
element?	Can contain zero or one of this subelement.
element+	Must contain one or more of this subelement.
element (no suffix)	Must contain only one of this subelement.

If an element cannot contain other elements, you see EMPTY or (#PCDATA) instead of a list of element names in parentheses.

Data

Some elements contain character data instead of subelements. These elements have definitions of the following format:

In the loadbalancer.xml file, white space is treated as part of the data in a data element. Therefore, there should be no extra white space before or after the data delimited by a data element. For example:

Attributes

Elements that have ATTLIST tags contain attributes (name-value pairs). For example:

<!ATTLIST instance   name           CDATA      #REQUIRED
                     enabled        %boolean;  "true"
                     disable-timeout-in-minutes  CDATA  "31"
                     listeners      CDATA      #REQUIRED>

An instance element can contain name, enabled, disable-timeout-in-minutes, and listeners attributes.

The #REQUIRED label means that a value must be supplied. The #IMPLIED label means that the attribute is optional, and that Sun ONE Application Server generates a default value. Wherever possible, explicit defaults for optional attributes (such as "true") are listed.

Attribute declarations specify the type of the attribute. For example, CDATA means character data, and %boolean is a predefined enumeration.

Elements in the loadbalancer.xml File

loadbalancer


Note	Subelements must be defined in the order in which they are listed under each Subelements heading unless otherwise noted.

Defines a load balancer. This is the root element; there can only be one loadbalancer element in a loadbalancer.xml file.

Subelements

The following table describes subelements for the loadbalancer element. The left column lists the subelement name, the middle column indicates the requirement rule, and the right column describes what the element does.

Table 16-2 loadbalancer subelements
Element	Required	Description
cluster	zero or more	Defines a cluster of server instances.
property	zero or more	Specifies a load balancer property.

Attributes

property

Subelements

The following table describes subelements for the property element. The left column lists the subelement name, the middle column indicates the requirement rule, and the right column describes what the element does.

Table 16-3 property subelements
Element	Required	Description
description	zero or one	Contains a text description of this element.

Attributes

The following table describes attributes for the property element. The left column lists the attribute name, the middle column indicates the default value, and the right column describes what the attribute does.

Table 16-4 property attributes
Attribute	Default	Description
name	none	Specifies the name of the property.
value	none	Specifies the value of the property.

Properties

The following table describes load balancer properties. The left column lists the property name, the middle column indicates the default value if the property is not present, and the right column describes what the property does.

Table 16-5 Load Balancer Properties
Property Name	Default Value	Description
response-timeout-in-seconds	60	Specifies the timeout interval within which a response must be obtained for a request that is load balanced, or an error page will be sent to the client.
reload-poll-interval-in-seconds	0	Specifies the interval at which the load balancer checks whether the loadbalancer.xml time stamp has changed. If it has changed, the load balancer reloads the file. If 0, polling is disabled.
https-routing	false	Specifies whether the load balancer routes incoming HTTPS requests to the instance as HTTPS requests.
require-monitor-data	false	Specifies whether load balancer monitoring is enabled.

description

Subelements

Attributes

cluster

Subelements

The following table describes subelements for the cluster element. The left column lists the subelement name, the middle column indicates the requirement rule, and the right column describes what the element does.

Table 16-6 cluster subelements
Element	Required	Description
instance	zero or more	Defines a server instance.
web-module	zero or more	Defines a web module.
health-checker	zero or one	Configures the cluster’s health checker.

Attributes

The following table describes attributes for the cluster element. The left column lists the attribute name, the middle column indicates the default value, and the right column describes what the attribute does.

Table 16-7 cluster attributes
Attribute	Default	Description
name	none	Specifies the name of the cluster. Within a load balancer, cluster names must be unique.

instance

Subelements

Attributes

The following table describes attributes for the instance element. The left column lists the attribute name, the middle column indicates the default value, and the right column describes what the attribute does.

Table 16-8 instance attributes
Attribute	Default	Description
name	none	Specifies the name of the server instance. Within a cluster, instance names must be unique.
enabled	true	(optional) Specifies whether instance is active (enabled) for requests to be load balanced to it.
disable-timeout-in-minutes	31	(optional) Specifies the quiescing timeout interval, at which the load balancer disables the instance and closes all its open connections.
listeners	none	Specifies a space-delimited list of the URLs of the instance’s listeners. Within a cluster, listener URLs must be unique.

web-module

Subelements

Attributes

The following table describes attributes for the web-module element. The left column lists the attribute name, the middle column indicates the default value, and the right column describes what the attribute does.

Table 16-9 web-module attributes
Attribute	Default	Description
context-root	none	Specifies the context root of the web module. Within a cluster, context roots must be unique. The default context root can be specified as “ “ or “/”. Context roots can also be specified with a leading slash (/). In a cluster, if an empty context root is used along with specific context roots, the load balancer plug-in will give precedence to the specific context roots.
enabled	true	(optional) Specifies whether web module is active (enabled) for requests to be load balanced to it.
disable-timeout-in-minutes	31	(optional) Specifies the quiescing timeout interval, at which the load balancer disables the web module and closes all its open connections.

health-checker

Subelements

Attributes

The following table describes attributes for the health-checker element. The left column lists the attribute name, the middle column indicates the default value, and the right column describes what the attribute does.

Table 16-10 Health checker properties
Attribute	Default	Description
url	/	(optional) Specifies the URL to ping to determine the health state of a listener.
interval-in-seconds	30	(optional) Specifies the interval at which health checks of instances occur.
timeout-in-seconds	10	(optional) Specifies the timeout interval within which a response must be obtained for a listener to be considered healthy.

Known Issues in Load Balancing Requests

The following list discusses the limitations in Load Balancer with respect to HTTP/HTTPS request processing.

If a session uses a combination of HTTP and HTTPS requests, then the first request has to be a HTTP Request. If the first request is an HTTPS request, it cannot be followed by an HTTP request. This is because the cookie associated with the HTTPS session is not returned by the browser. The browser interprets the two different protocols as two different servers, and initiates a new session.

Chapter 16 Configuring Load Balancing

About Load Balancing

Load Balancing Algorithm

About Sticky Round Robin Load Balancing Algorithm

Cookie Based Method

Explicit URL Rewriting Method

Requirements for Load Balancing

Configuring Load Balancer Plug-in

Configuration Changes to Web Server

Modifications to Sun ONE Web Server Configuration

Modifications to Apache Web Server

Creating the Load Balancer Configuration File

Sample loadbalancer.xml file

Configuring Multiple Web Server Instances

Configuring Multiple Sun ONE Web Server Instances

Configuring Multiple Apache Web Server Instances

Configuring Response Timeout

Configuring HTTPS Routing

About HTTPS Routing

Configuring HTTPS Routing

Configuring the Health-Checker

Configuring Quiescence

Quiescing an Instance

Quiescing an Application

About Dynamic Reconfiguration

Monitoring the Load Balancer Plug-in

Configuring Log Messages

Configuring Monitoring

Understanding Monitoring Messages

Load Balancer Configuration File

The sun-loadbalancer_1_0.dtd File

Subelements

Data

Attributes

Elements in the loadbalancer.xml File

loadbalancer

Subelements

Attributes

property

Subelements

Attributes

Properties

description

Subelements

Attributes

cluster

Subelements

Attributes

instance

Subelements

Attributes

web-module

Subelements

Attributes

health-checker

Subelements

Attributes

Known Issues in Load Balancing Requests

Chapter 16
Configuring Load Balancing