To Configure the Load Balancer for the Access Manger Service

This procedure describes how to configure the Access Manager service load balancer (am.pstest.com at IP address 10.0.3.10). The steps are relatively generic; the details depend on the load balancer you are using.

1. Populate the load balancer's Hosts Table.

   Add the IP address for am1.pstest.com and am2.pstest.com to the load balancer's hosts table.

2. Populate the load balancer's Real Service Table.

   Add the real services for am1.pstest.com and am2.pstest.com. A real service is identified by its IP address and port. Add 10.0.2.1:80 and 10.0.2.2:80

3. Populate the load balancer's Service Group Table.

   Add the service group for Access Manager services. The service groups are sets of the real services that you defined in Step 2. The real services in the group must be capable of fulfilling the same type of request. The load balancer will distribute requests among the real services in the service group. When you define the service group for am.pstest.com, you add the real services that specify the Access Manager instances, 10.0.2.1:80 and 10.0.2.2:80.

4. Populate the load balancer's Virtual IP Table.

   A virtual service definition includes the outward facing IP address and the port at which the load balancer accepts requests for a service, as well as the service group that you specified in Step 3, which actually handles the requests. The load balancer will accept requests at the virtual service address and distribute them among the service group. The virtual service definition for the Access Manager service should be am.pstest.com, with the virtual IP address of 10.0.3.10:80, and with the service group consisting of the computers am1.pstest.com and am2.pstest.com.

5. Configure the load balancer to use Layer-7 (HTTP layer) load balancing.

6. Configure the load balancer with a scheduling type of either least connections or round robin.

   Both scheduling types initially distribute the connections evenly between the Access Manager instances. Both scheduling types keep the connections evenly distributed if the connections are restarted.

7. Configure the load balancer for sticky routing based on a server-side cookie.

   In the case of Access Manager services, a session token (or cookie) is provided when a user is first authenticated. The load balancer must be configured to identify this session token (amlbcookie) in each request and to route all requests within the same user session to the same Access Manager instance.

   You typically accomplish the configuration of session persistence by establishing forwarding rules based on the HTTP Request and Response header predicate COOKIE, as in the following example:

   {COOKIE has amlbcookie eq 01}

   where 01 is the Access Manager instance ID.

   If the load balancer is not configured to stick sessions to the instance that creates them, but instead routes them randomly, the instances that receive subsequent requests will maintain shadow sessions. The instances in the module will communicate among themselves about session changes. Maintaining the shadow sessions requires more memory and decreases system performance. It also generates more network traffic among the Access Manager instances in order to keep the session caches synchronized.

8. Configure the health-check settings for the load balancer.

   The recommended settings are specified in Table 3–5.