Sun Java System Application Server Enterprise Edition 8.1 Administration Guide 2005Q1 |
Chapter 3
Configuring Load Balancing and FailoverThis chapter describes how to set up load balancing of HTTP requests in the Sun Java System Application Server. It also explains how to configure failover between server instances controlled by the load balancer. In addition, it discusses RMI-IIOP load balancing and Failover.
It contains the following sections:
About HTTP Load Balancing and FailoverHTTP Load Balancing and Failover
The goal of load balancing is to evenly distribute the workload between multiple Sun Java System Application Server instances, stand-alone or clustered, thereby increasing the overall throughput of the system.
Using a load balancer also enables requests to fail over from one server instance to another. For HTTP session information to persist, configure HTTP session persistence. For more information, see Chapter 1, “Configuring Availability and Session Persistence.”
Use the asadmin tool, not the Admin Console, to configure HTTP load balancing.
Requirements for HTTP Load Balancing
You must meet the following requirements before using the load balancer plug-in for HTTP requests:
For more information, see "Configuring Web Servers for HTTP Load Balancing".
- A load balancer plug-in is installed.
- The Application Server is configured.
- Application Server instances or clusters participating in load balancing are created.
- Applications are deployed to all Application Server instances or clusters participating in load balancing.
- Server instances and clusters participating in load balancing must have a homogenous environment. Usually that means that the server instances reference the same server configuration and have the same applications deployed to them.
Understanding Assigned Requests and Unassigned Requests
When a request first comes in from an HTTP client to the load balancer, it is a request for a new session. A request for a new session is called an unassigned request. The load balancer routes this request to an application server instance in the cluster according to a round-robin algorithm. For more information, see "HTTP Load Balancing Algorithm".
Once a session is created on an application server instance, the load balancer routes all subsequent requests for this session only to that particular instance. A request for an existing session is called an assigned or a sticky request.
HTTP Load Balancing Algorithm
The Sun Java System Application Server load balancer uses a sticky round robin algorithm to load balance incoming HTTP and HTTPS requests. All requests for a given session are sent to the same application server instance. With a sticky load balancer, the session data is cached on a single application server rather than being 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 obtained with pure round robin.
About the 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 plug-in 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 HTTP client does not support cookies.
Load Balancing and Failover Sample Applications
The following directories contain sample applications that demonstrate load balancing and failover:
install_dir/samples/ee-samples/highavailability
install_dir/samples/ee-samples/failoverThe
ee-samples
directory also contains information for setting up your environment to run the samples.Overview of HTTP Load Balancing Set-up
Use the
asadmin
tool to configure load balancing in your environment. Follow these steps:
- Complete the "Requirements for HTTP Load Balancing", including installing and configuring a web server and Application Server instances and or clusters.
- Create a load balancer configuration using the
asadmin
commandcreate-http-lb-config
.- Add references to clusters and stand-alone server instances for the load balancer to manage using
asadmin
create-http-lb-ref
.If you created the load balancer configuration with a target, and that target is the only cluster or stand-alone server instance the load balancer references, skip this step.
- Enable the clusters or stand-alone server instances reference by the load balancer using
asadmin enable-http-lb-server
.- Enable applications for load balancing using
asadmin enable-http-lb-application
.These applications must already be deployed and enabled for use on the clusters or stand-alone instances that the load balancer references. Enabling for load balancing is a separate step from enabling them for use.
- Create a health checker using
asadmin
create-health-checker
.The health checker monitors unhealthy server instances so that when they become healthy again, the load balancer can send new requests to them.
- Generate the load balancer configuration file using
asadmin
export-http-lb-config
.This command generates a configuration file to use with the load balancer plug-in shipped with the Sun Java System Application Server.
- Copy the load balancer configuration file to your web server
config
directory where the load balancer plug-in configuration files are stored.
Configuring Web Servers for HTTP Load BalancingAbout Web Server Configuration
The load balancer plug-in installation program makes a few modifications to the web server’s configuration files. The changes made depend upon the web server.
Modifications to Sun Java System Web Server
The installation program makes the following changes to the Sun Java System 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
web_server_install_dir
Init fn="load-modules" shlib="/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:<Object name=default>
NameTrans fn="name-trans-passthrough" name="lbplugin" config-file="web_server_install_dir/web_server_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 theObject
, and web_server_install_dir/
web_server_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.After installing, configure the load balancer as described in "Overview of HTTP Load Balancing Set-up".
Modifications to Apache Web Server
Before installing the load balancer plug-in on Apache, see information on compiling and configuring Apache in Appendix A, "Compiling and Configuring Apache Web Server."
Modifications Made by the Installer
The load balancer plug-in installation program extracts the necessary files to the
libexec
(Apache 1.3) orm
odules
(Apache 2.0) 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’shttpd.conf
file:
<VirtualHost
machine_name:443>
##Addition for EE lb-plugin
LoadFile /usr/lib/libCstd.so.1
LoadModule apachelbplugin_module libexec/mod_loadbalancer.so
webserver_instance
#AddModule mod_apachelbplugin.cpp
<IfModule mod_apachelbplugin.cpp>
config-file/conf/loadbalancer.xml
locale en
</IfModule>
<VirtualHost
machine_ip_address>
webserver_instance
DocumentRoot "/htdocs"
ServerName server_name
</VirtualHost>
##END EE LB Plugin ParametersVersion 7
Modifications After Installation
Additional Modifications on Microsoft Windows
If you are running Apache on Microsoft Windows, after installing the plug-in, some environment variable changes are required:
Add a new path to the Path environment variable by clicking Start->Settings->Control Panel->System->Advanced->Environment Variables->System Variables. Edit the Path variable to include the following:
application_server_install_dir
/bin
In addition, set the environment variable NSPR_NATIVE_THREADS_ONLY to 1 before starting Apache web server.
On the Environment Variables window, under System Variables, click New.Enter the following name and value pair:
Variable name: NSPR_NATIVE_THREADS_ONLY
Variable value: 1
Restart the machine.
Modifications to Microsoft IIS
To configure Microsoft Internet Information Services (IIS) to use the load balancer plug-in, modify certain properties in Windows Internet Services Manager. The Internet Services Manager is located in the Administrative Tools folder in the Control Panel folder.
Make these modifications after installing the Sun Java System Application Server.
- Open the Internet Services Manager.
- Select the web site for which you want to enable the plug-in. This web site is typically named the Default Web Site.
- Right click on the web site and select Properties to open the Properties notebook.
- To add a new ISAPI filter, open the ISAPI Filters tab, click Add, and follow the steps given below:
- Create and configure a new virtual directory:
- Right click on the default web site, select New, and then Virtual Directory.
The Virtual Directory Creation Wizard opens.
- In the Alias field, type
sun-passthrough
.- In the Directory field, type
C:\Inetpub\wwwroot\
sun-passthrough- Check the Execute Permission checkbox. Leave all other permission-related check boxes are left unchecked.
- Click Finish.
- Add the path of
sun-passthrough.dll
file and application_server_install_dir/bin
to the system’sPATH
environment variable. Restart the machine.- Stop and start the web server for the new settings to take effect.
To stop the web server, right click on the web site and select
Stop
. To start the web server, right click on the web site and selectStart
.Next, type the following in a web browser to access the web application context root:
http://
webserver_name/
web_application
where webserver_name is the hostname or IP address of the web server and
/
web_application is the context root that you listed in theC:\Inetpub\wwwroot\sun-passthrough\sun-passthrough.properties
file. Verify that the web server, load balancer plug-in, and Application Server are operating correctly.The installer automatically configures the following properties in
sun-passthrough.properties
. You can change the default values.
Configuring Multiple Web Server Instances
The Sun Java System Application Server installer does not allow the installation of multiple load balancer plug-ins on a single machine. 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.
- Configure the new web server instance to use the load balancer plug-in, as described in "Modifications to Sun Java System Web Server", "Modifications to Apache Web Server", or "Modifications to Microsoft IIS".
- Copy the
sun-loadbalancer_1_1.dtd
file from the existing web server instance’sconfig
directory to the new instance’sconfig
directory.- To use the same load balancer configuration, copy the
loadbalancer.xml
file from the existing web server instance’sconfig
directory to the new instance’sconfig
directory.- To use a different load balancer configuration:
- Create a new load balancer configuration using
asadmin create-http-lb-config
.- Export the new configuration to a
loadbalancer.xml
file usingasadmin export http-lb-config
.- Copy that
loadbalancer.xml
file to the new web server’sconfig
directory.For information on creating a load balancer configuration and exporting it to a
loadbalancer.xml
file, see "HTTP Load Balancer Configuration Tasks."
HTTP Load Balancer Configuration TasksCreating an HTTP Load Balancer Configuration
A load balancer configuration is a named configuration in the
domain.xml
file that defines a load balancer.Load balancing configuration is extremely flexible:
Create the configuration using the
asadmin
commandcreate-http-lb-config
. Specify the following parameters:
Specifies whether HTTPS requests to the load balancer result in HTTPS or HTTP requests to the server instance.
For more information, see "Configuring HTTP and HTTPS Session Failover".
The interval between checks for changes to the load balancer configuration file
loadbalancer.xml
. When the check detects changes, the configuration file is reloaded. A value of 0 disables reloading.For more information, see "Enabling Dynamic Reconfiguration".
Specifies whether monitoring is enabled for the load balancer.
For more information, see "Monitoring the HTTP Load Balancer Plug-in".
For more information see the documentation for c
reate-http-lb-config
,delete-http-lb-config
, andlist-http-lb-configs
.Creating an HTTP Load Balancer Reference
When you create a reference in the load balancer to a stand-alone server or cluster, the server or cluster is added to the list of target servers and clusters the load balancer controls. The referenced server or cluster still needs to be enabled (using
enable-http-lb-server
) before requests to it are load balanced. If you created the load balancer configuration with a target, that target is already added as a reference.Create a reference using
create-http-lb-ref
. You must supply the load balancer configuration name and the target server instance or cluster.To delete a reference, use
delete-http-lb-ref
. Before you can delete a reference, the referenced server or cluster must be disabled usingdisable-http-lb-server
.For more information, see the documentation for
create-http-lb-ref
anddelete-http-lb-ref
.Enabling Server Instances for Load Balancing
After creating a reference to the server instance or cluster, enable the server instance or cluster using
enable-http-lb-server
. If you used a server instance or cluster as the target when you created the load balancer configuration, you must enable it.For more information, see the documentation for
enable-http-lb-server
.Enabling Applications for 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) you must enable it for load balancing. 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.
For more information, see the online help for
enable-http-lb-application
.If you deploy a new application, you must also enable it for load balancing and export the load balancer configuration again.
Creating the HTTP Health Checker
The load balancer’s health checker periodically checks all the configured Application 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’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. A status code in the HTTP response header between 100 and 500 means the instance is healthy.
Creating a Health Checker
To create the health checker, use the
asadmin
create-http-health-checke
r command. Specify the following parameters:
- url
Specifies the listener’s URL that the load balancer checks to determine its state of health. The default is
“/”
.interval
Specifies the interval in seconds at which health checks of instances occur. The default is 30 seconds. Specifying 0 disables the health checker.
- timeout
Specifies the timeout interval in seconds 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 specified URL to check all unhealthy application server 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.
For more information see the documentation for c
reate-http-health-checker
anddelete-http-health-checker
.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 exportedloadbalancer.xml
file.
Note
These properties can only be set by manually editing
loadbalancer.xml
after you’ve exported it. There is no equivalent asadmin command to use.
To check healthy instances, set the following properties:
Set the properties by editing the
loadbalancer.xml
file. For example:<property name="active-healthcheck-enabled" value="true"/>
<property name="number-healthcheck-retries" value="3"/>
If you add these properties, then subsequently edit and export the
loadbalancer.xml
file again, you must add these properties to the file again, since the newly exported configuration won’t contain them.Exporting the Load Balancer Configuration File
The load balancing plug-in shipped with Sun Java System Application Server uses a configuration file called
loadbalancer.xml
. Use theasadmin
tool to create a load balancer configuration in thedomain.xml
file. After configuring the load balancing environment, export it to a file:
- Export a
loadbalancer.xml
file using theasadmin
commandexport-http-lb-config
.Export the
loadbalancer.xml
file for a particular load balancer configuration. You can specify a path and a different file name. If you don’t specify a file name, the file is namedloadbalancer.xml.
load_balancer_config_name. If you don’t specify a path, the file is created in the application_server_install_dir/domains/
domain_name/generated
directory.To specify a path on Windows, use quotes around the path. For example,
“c:\sun\AppServer\loadbalancer.xml”
.- Copy the exported load balancer configuration file to the web server’s configuration directory.
For example, for the Sun Java System Web Server, that location might be web_server_root
/config
.The load balancer configuration file in the web server’s configuration directory must be named
loadbalancer.xml
. If your file has a different name, such asloadbalancer.xml.
load_balancer_config_name, you must rename it.Changing the HTTP Load Balancer Configuration
If you change an HTTP 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 Load Balancer Configuration File".The load balancer 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.
Enabling Dynamic Reconfiguration
When dynamic reconfiguration is enabled, the load balancer plug-in periodically checks for an updated configuration. To enable dynamic reconfiguration:
After changing these settings, export the load balancer configuration file again and copy it to the web server’s
config
directory.If you enable dynamic reconfiguration after it has previously been disabled, you also must restart the web server.
Disabling (Quiescing) a Server Instance or Cluster
Before stopping an application server for any reason, you want the instance to 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 application server instances:
- If an instance (either stand-alone 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 disable a server instance or cluster:
Disabling (Quiescing) an Application
Before you undeploy a web application, you want to the application to complete serving requests. The process of gracefully disabling an application is called quiescing.
The load balancer uses the following policy for quiescing applications:
- If an application is disabled, and the timeout has not expired, new requests to the disabled applications are not forwarded by the load balancer. These requests are returned to the web server. Sticky requests continue to be forwarded until the timeout expires.
- When the timeout expires, the application is disabled. The load balancer does not accept any requests for this 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.
To disable an application:
Run asadmin disable-http-lb-application
, specifying the timeout (in minutes) the name of the application to disable, and the target cluster or instance on which to disable it.- Export the load balancer configuration file using
asadmin export-http-lb-config
.- Copy the exported configuration to the web server
config
directory.Configuring HTTP and HTTPS Session Failover
The load balancer plug-in fails over HTTP/HTTPS sessions to another application server instance if the original application server instance to which the session was connected becomes unavailable. This section describes how to configure the load balancer plug-in to enable HTTP/HTTPS routing and session failover.
For information about configuring HTTP session persistence, see Chapter 1, “Configuring Availability and Session Persistence.”
The following topics are discussed in this section:
About HTTPS Routing
All incoming requests, whether HTTP or HTTPS, 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
httpsrouting
option of thecreate-http-lb-config
command 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. Set it to true when creating a new load balancer configuration, or change it later using theasadmin set
command.
Known Issues in Load Balancing HTTP/HTTPS 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 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 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.
Configuring Idempotent URLs
To enhance the availability of deployed applications, configure the environment to retry failed idempotent HTTP requests on all the application server instances serviced by a load balancer. This option is used for read-only requests, for example, to retry a search request.
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 retry does not cause an update or modification of data.
Configure idempotent URLs in the
sun-web.xml
file. When you export the load balancer configuration, idempotent URL information is automatically added to theloadbalancer.xml
file.For more information on configuring idempotent URLs, see the Developer’s Guide.
Configuring HTML Error Pages
You can specify your own error page or a URL to an error page to be displayed to the end user. Specifying an error page overrides all other mechanisms configured for error reporting.
Configure HTML error pages in the
sun-web.xml
file. When you export the load balancer configuration, HTML error page information is automatically added to theloadbalancer.xml
file from thesun-web.xml
file.For more information on configuring HTML error pages, see the Developer’s Guide.
Monitoring the HTTP Load Balancer Plug-inConfiguring Log Messages
The load balancer plug-in uses the web server’s logging mechanism to write log messages. The default log level on the Application Server is set to the default logging level on Sun Java System Web Server (
INFO
), Apache Web Server (WARN
) and Microsoft IIS(INFO)
.The application server log levels -
FINE
,FINER
, andFINEST
map to theDEBUG
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 required metrics.
Types of Log Messages
The load balancer plug-in generates the following three different sets of log messages:
Load Balancer Configurator Log Messages
These messages will be logged when you are using idempotent URLs and error page settings.
An output for idempotent URL pattern configuration contains the following information:
An output for error page URL configuration contains the following information (log level set to WARN):
CONFxxxx: Invalid error-url for web-module <web-module>
Request Dispatch and Runtime Log Messages
These log messages are generated while a request is being load balanced and dispatched.
Configurator Error Messages
These errors appear if there are configuration problems, for example, if the custom error page referenced is missing.
Configuring Monitoring
Perform the following steps to turn on load balancer plug-in log messages:
- Set the logging options in the web server.
- Set the load balancer configuration’s
monitor
option to true.Use the
asadmin create-http-lb-config
command to set monitoring to true when you initially create the load balancer configuration, or use theasadmin set
command to set it to true later. Monitoring is disabled by default.The load balancer plug-in logs the following information:
- Request start/stop information for every request.
- Failed-over request information when the request fails over from an unhealthy instance to a healthy instance.
- List of unhealthy instances at the end of every health check cycle.
Understanding Monitoring Messages
The format of the load balancer plug-in log messages is as follows.
Upgrading an ApplicationAbout Rolling Upgrades
To upgrade an application without loss of service to a user, upgrade the application on one server or cluster at a time. The cluster transparently maintains a mixed-version environment, and users are unaware that the upgrade is taking place. This type of upgrade is called a rolling upgrade.
Rolling upgrades are only possible if old and new versions of the application are compatible and can both run at once. Session information must be compatible. Perform a mixed-mode rolling upgrade in a single stand-alone cluster, or in multiple clusters.
Rolling upgrade in a mixed-mode environment is not possible if the application has major changes, for example, changes to the database schema. In that case, bring down the application while you upgrade. Undeploy the application, then redeploy the upgraded application with the same name.
Upgrading In a Single Stand-alone Cluster
To upgrade an application in a single, stand-alone cluster (that is, a cluster which does not share a configuration with any other cluster):
- Save an old version of the application or back up the domain.
To back up the domain use the
asadmin backup-domain
command.- Turn off dynamic reconfiguration for the cluster if it is enabled.
Through the Admin Console:
- Expand the Configurations node.
- Click the name of the cluster’s configuration.
- On the Configuration System Properties page, uncheck the Dynamic Reconfiguration Enabled box.
- Click Save
The
asadmin
equivalent command isasadmin set
. The syntax is:
asadmin set --user
user--passwordfile
password_file cluster_name-config.dynamic-reconfiguration-enabled=false
- Redeploy the upgraded application to the target
domain
. If you redeploy using the Admin Console, the domain is automatically the target. Because dynamic reconfiguration is disabled, the old application continues to run on the cluster.- Enable the redeployed application for the instances using
asadmin enable-http-lb-application
.- Disable one server instance using
asadmin disable-http-lb-server.
- Export the load balancer configuration file using
asadmin export-http-lb-config
.- Copy the exported configuration file to the web server instance’s configuration directory. For example, for Sun Java System Web Server, the location is web_server_install_dir/
https-
host-name/config/loadbalancer.xml
- Wait until the timeout has expired. Monitor the load balancer’s log file to make sure the instance is offline.
- Restart the disabled server instance while the other instances in the cluster are still running. The restart causes the server to synchronize with the domain and update the application.
- Test the application on the restarted server to make sure it runs correctly.
- Enable the server instance using
asadmin enable-http-lb-server.
- Export the load balancer configuration file using
asadmin export-http-lb-config
.- Copy the configuration file to the web server’s configuration directory.
- When all server instances have the new application and are running, enable dynamic reconfiguration for the cluster again.
Upgrading in Two Clusters
- Save an old version of the application or back up the domain.
To back up the domain use the
asadmin backup-domain
command.- Turn off dynamic reconfiguration for both clusters if it is enabled.
Through the Admin Console:
- Expand the Configurations node.
- Click the name of one cluster’s configuration.
- On the Configuration System Properties page, uncheck the Dynamic Reconfiguration Enabled box.
- Click Save
- Repeat for the second cluster.
The
asadmin
equivalent command isasadmin set
. The syntax is:
asadmin set --user
user--passwordfile
password_file cluster_name-config.dynamic-reconfiguration-enabled=false
- Redeploy the upgraded application to the target
domain
. If you redeploy using the Admin Console, the domain is automatically the target. Because dynamic reconfiguration is disabled, the old application continues to run on the clusters.- Enable the redeployed application for the clusters using
asadmin enable-http-lb-application
.- Disable one cluster from the load balancer using
asadmin disable-http-lb-server
.- Export the load balancer configuration file using
asadmin export-http-lb-config
.- Copy the exported configuration file to the web server instance’s configuration directory. For example, for Sun Java System Web Server, the location is web_server_install_dir/
https-
host-name/config/loadbalancer.xml
- Wait until the timeout has expired. Monitor the load balancer’s log file to make sure the cluster is offline.
- Restart the disabled cluster while the other cluster is still running. The restart causes the cluster to synchronize with the domain and update the application.
- Test the application on the restarted cluster to make sure it runs correctly.
- Enable the cluster using
asadmin enable-http-lb-server.
- Export the load balancer configuration file using
asadmin export-http-lb-config
.- Copy the configuration file to the web server’s configuration directory.
- When all server instances have the new application and are running, enable dynamic reconfiguration for both clusters again.
About RMI-IIOP Load Balancing and FailoverRequirements for RMI-IIOP Load Balancing and Failover
Sun Java System Application Server provides high availability of remote EJB references and name service objects over RMI-IIOP. Before using these features, your environment must meet the following requirements:
Load balancing is supported for the following RMI-IIOP clients:
The configuration settings required to enable RMI-IIOP-based applications depend on the type of client. For more information on configuring RMI-IIOP client applications for load balancing, see the Sun Java System Application Server Developer’s Guide.
For additional information on RMI-IIOP failover and load balancing, see the Sun Java System Application Server High Availability Administration Guide.
RMI-IIOP Load Balancing and Failover Algorithm
Sun Java System Application Server employs a randomization and round-robin algorithm for load balancing of remote EJB references and name service objects on the RMI-IIOP path.
When an RMI-IIOP client first creates a new
InitialContext
object, the list of available Application Server IIOP endpoints is randomized for that client. For thatInitialContext
object, the load balancer directs lookup requests and otherInitialContext
operations to the first endpoint on the list. If the first endpoint is not available then the second endpoint in the list is used, and so on.Each time the client subsequently creates a new
InitialContext
object, the endpoint list is rotated so that a different IIOP endpoint is used forInitialContext
operations.When you obtain or create beans from references obtained by an
InitialContext
object, those beans are created on the Application Server instance serving the IIOP endpoint assigned to theInitialContext
object. The references to those beans contain the IIOP endpoint addresses of all Application Server instances in the cluster.The primary endpoint is the bean endpoint corresponding to the
InitialContext
endpoint used to look up or create the bean. The other IIOP endpoints in the cluster are designated as alternate endpoints. If the bean's primary endpoint becomes unavailable, further requests on that bean fail over to one of the alternate endpoints.RMI-IIOP Sample Application
The following directory contains a sample application that demonstrates using RMI-IIOP failover with and without ACC:
install_dir/samples/ee-samples/sfsbfailover
See the
index.html
file accompanying this sample for instructions on running the application with and without ACC. Theee-samples
directory also contains information for setting up your environment to run the samples.