In the reference configuration's modular architecture, each module has a load balancer that routes traffic among the component instances in the module. For each module, the load balancer is configured with a virtual IP address for the service that the module provides. All of the requests for the service are delivered to the load balancer. The load balancer then routes this traffic among the component instances in the module.
For example, in Figure 3–1, the directory service module consists of two computers that are running instances of Directory Server ( ds1.pstest.com and ds2.pstest.com) and a load balancer (ds.pstest.com) that is placed in front of the two computers. Requests for directory services are addressed to the load balancer at ds.pstest.com, and the load balancer is configured to distribute these requests between the Directory Server instances running on ds1.pstest.com and ds2.pstest.com.
In configuring a load balancer, three categories of configurable parameters need to be specified, as described in the following sections:
The virtual IP addresses and real IP addresses that are used to configure each load balancer are shown in Figure 3–1. In configuring your load balancers, substitute the service names, host names, and IP addresses that you will be using on your network. Details of setting up each load balancer are provided in the implementation procedure for the respective module.
The following table specifies characteristics that are required for each load balancer in the reference configuration to properly route requests. For example, the bottom row of the table below describes how each load balancer needs to be configured to maintain session persistence (stickiness).
Table 3–4 Specification for Load Balancer Routing
Parameter |
Directory Service |
Access Manager Service |
Portal Service |
Gateway Service |
---|---|---|---|---|
Virtual Service Name |
ds.pstest.com |
am.pstest.com |
ps.pstest.com |
sra.pstest.com |
Protocol |
LDAP |
HTTP |
HTTP |
HTTPS or HTTP, depending on whether SSL is terminated or not |
Port |
389 |
80 |
80 |
443 |
Virtual Service Type |
Layer-4 (TCP) |
Layer-7 (HTTP) |
Layer-7 (HTTP) |
Layer-7 (HTTP) or SSL, depending on whether SSL is terminated |
Scheduling |
Least Connections or Round Robin |
Least Connections or Round Robin |
Least Connections or Round Robin |
Least Connections or Round Robin |
Session Persistence (Stickiness) |
Long Persistent TCP Connections |
Based on server-side cookie amlbcookie |
Load balancer-managed cookie |
SSL Session ID or Load balancer-managed cookie |
Load balancers use a health-check mechanism to establish if a service instance is properly working and if it can process requests from clients. If the health-checks succeed, the load balancer includes the service instance in the pool of available instances, and requests are routed to the instance based on the existing scheduling rules. However, if the health-checks fail, the instance is removed from the load balancer's scheduling list.
A health-check is considered failed if the response is different than the one expected, or if no response is received after a specified timeout value. The timeout mast be properly tuned because if it is too short, a sporadically overloaded service that is slow to respond can be considered down. If the timeout is too long, the load balancer will take too much time to detect failures, and users will notice the lack of response.
The simplest health-check is to try to open a TCP connection to the service instance. However, this health-check only proves that the application is listening on the assigned port. It does not show that the instance can process requests. To better establish that the instance is properly working, the health-check must actually exercise the service instance.
The load balancer performs health-checks at a specified interval. The interval needs to be as short as possible so that the load balancer will quickly detect failures. However, too many health-check requests can cause performance degradation. In the worst case, frequent health-checks can overload the service instances.
To determine if a server instance is down, the load balancer monitors the number of consecutive failed health-checks. If this number reaches a specified threshold, an instance is considered down. The time it takes to make this determination equals the number of consecutive failed health-checks, multiplied by the health-check interval. During this time, the load balancer considers a failed instance to be operating correctly, and users will notice a lack of response.
The health-check parameters need to be tuned separately for each service module. The following table specifies health-check parameter values that can be used as a starting point for the reference configuration.
Table 3–5 Specification for Load Balancer Health-Checks
Parameter |
Directory Service |
Access Manager Service |
Portal Service |
Gateway Service |
---|---|---|---|---|
Health-check Type |
LDAP (simple, anonymous bind) |
HTTP |
HTTP |
HTTP |
Query |
DN: <None> Base:dc=pstest,dc=com Scope: Base Query: (objectclass=*) |
GET/amserver/isAlive.jsp |
GET/portal |
GET |
Expected Result |
Any LDAP success code |
HTTP 200 |
HTTP 302 |
HTTP 302 |
Health-check Timeout |
20 seconds |
10 seconds |
5 seconds |
5 seconds |
Interval Between Checks |
60 seconds |
30 seconds |
30 seconds |
30 seconds |
Consecutive Failed Health-check Threshold |
3 |
3 |
3 |
3 |
In the reference configuration, Gateway SSL sessions are terminated at the load balancer, and the Gateway instances run plain HTTP. If the SSL sessions are terminated at the Gateway instances instead of at the Gateway load balancer, then the Health-check needs to be configured to use the SSL protocol.