Load Balancer Configuration Specification

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:

• IP Address Configuration

• Configuration of Routing Characteristics

• Health-check Configuration

IP Address Configuration

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.

Configuration of Routing Characteristics

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

Health-check Configuration

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

---

Note –

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.

---