Skip Navigation Links | |
Exit Print View | |
Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide |
1. High Availability in GlassFish Server
2. Setting Up SSH for Centralized Administration
3. Administering GlassFish Server Nodes
4. Administering GlassFish Server Clusters
5. Administering GlassFish Server Instances
6. Administering Named Configurations
7. Configuring Web Servers for HTTP Load Balancing
8. Configuring HTTP Load Balancing
How the HTTP Load Balancer Works
Installing the Loadbalancer Plug-In
Features of the GlassFish Loadbalancer Plug-In
Setting Up HTTP Load Balancing
Prerequisites for Setting Up HTTP Load Balancing
Procedure for Setting Up HTTP Load Balancing
To Set Up Load Balancing Using the asadmin Tool
HTTP Load Balancer Deployments
Configuring the HTTP Load Balancer
Configuring an HTTP Load Balancer on the DAS
Creating an HTTP Load Balancer Reference
Enabling Server Instances for HTTP Load Balancing
Enabling Applications for HTTP Load Balancing
Creating the HTTP Health Checker
Additional Health Check Properties for Healthy Instances
Changing the HTTP Load Balancer Configuration
Exporting the HTTP Load Balancer Configuration File
Enabling Dynamic Reconfiguration
Disabling (Quiescing) a Server Instance or Cluster
To Quiesce a Server Instance or Cluster
Disabling (Quiescing) an Application
Configuring HTTP and HTTPS Failover
Using Redirects with the HTTP Load Balancer
The auth-pass-through-enabled Attribute
Monitoring the GlassFish Loadbalancer Plug-In
Load Balancer Configurator Log Messages
Request Dispatch and Runtime Log Messages
Enabling HTTP Load Balancer Logging
To Turn on HTTP Load Balancer Logging
Understanding Monitoring Messages
9. Upgrading Applications Without Loss of Availability
10. Configuring High Availability Session Persistence and Failover
11. Configuring Java Message Service High Availability
This section describes how to set up load balancing for GlassFish Server.
The following topics are addressed here:
Before configuring your load balancer, you must:
Install a supported web server and configure it. For more information on configuring a supported web server, see Chapter 7, Configuring Web Servers for HTTP Load Balancing.
Install the Loadbalancer Plug-In.
For complete instructions on installing the Loadbalancer Plug-In, see Chapter 7, Configuring Web Servers for HTTP Load Balancing.
Create GlassFish Server clusters or server instances to participate in load balancing.
Deploy applications to these clusters or instances.
There are several asadmin subcommands that enable you to set up and use HTTP load balancing in your GlassFish Server and web server environment.
Most of the required load balancing configuration settings can be performed in a single step with the asadmin create-http-lb subcommand, as described in this procedure. After performing this procedure, or if you choose to not perform all configuration steps with one subcommand, you can set individual load balancing options using several other subcommands. Information about configuring individual load balancing options is provided after this procedure, in Configuring the HTTP Load Balancer.
Use the asadmin create-http-lb subcommand.
For the purposes of this procedure, the create-http-lb subcommand can be used to perform the following load balancing tasks. Other options are available but are not included in this example. For more information, see create-http-lb(1).
Specify a target cluster or standalone server instance for the load balancer to manage (--target). This task can also be performed at a later time with the create-http-lb-ref(1) subcommand.
Enable (activate) load balancing on the specified target (--lbenableallinstances). This task can also be performed at a later time with the enable-http-lb-server(1) subcommand. Note that load balancing is enabled by default for all instances.
Enable load balancing for the applications that run on the specified target. The applications must already be deployed and enabled for use on the clusters or standalone instances that the load balancer references (--lbenableallapplications). This task can also be performed at a later time with the enable-http-lb-application(1) subcommand. Note that load balancing is enabled by default for all applications.
Create a health checker for the load balancer. A health checker monitors unhealthy server instances so that when they become healthy again, the load balancer can send new requests to them (--healthcheckerurl). This task can also be performed at a later time with the create-http-health-checker(1) subcommand.
Generate a load balancer configuration file. This file can be used with the Loadbalancer Plug-In and exported to other targets. (load_balancer_name). This task can also be performed at a later time with the export-http-lb-config(1) subcommand.
Note - To generate the load balancer configuration file and send the data over the wire to the web server in a single step, you need to 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.
Example 8-1 Creating a Load Balancer
The following example creates a load balancer on a host named host1 using port 5555. A cluster named c1 is the target. A healthchecker is enabled for the load balancer, and a load balancer configuration file named mylb is generated. The following command should be entered on a single line.
asadmin> create-http-lb --devicehost host1 --deviceport 55555 --target c1 --healthcheckerinterval 10 mylb
You can configure your load balancer in different ways, depending on your goals and environment, as described in the following sections:
The most common way to deploy the load balancer is with a cluster or clusters of server instances. By default all the instances in a cluster have the same configuration and the same applications deployed to them. The load balancer distributes the workload between the server instances and requests fail over from an unhealthy instance to a healthy one. If you’ve configured HTTP session persistence, session information persists when the request is failed over.
If you have multiple clusters, requests can be load balanced across clusters but are only failed over between the instances in a single cluster. Use multiple clusters in a load balancer to easily enable rolling upgrades of applications. For more information, see Chapter 9, Upgrading Applications Without Loss of Availability.
Note - Requests cannot be load balanced across clusters and standalone instances.
It is also possible to configure your load balancer to use multiple standalone instances, and load balance and failover requests between them. However, in this configuration, you must manually ensure that the standalone instances have homogenous environments and the same applications deployed to them. Because clusters automatically maintain a homogenous environment, for most situations it is better and easier to use clusters.
Tip - Load balancing across multiple standalone instances only provides failover for requests, and any associated HTTP session data will not be failed over. This is another reason why using a cluster, which can provide session failover, is a more desirable load balancing configuration.