To Configure the Load Balancer for the Gateway Service

This procedure describes how to configure the Gateway service load balancer (sra.pstest.com at IP address 10.0.5.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 sra1.pstest.com and sra2.pstest.com to the load balancer's hosts table.

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

   Add the real services for sra1.pstest.com and sra2.pstest.com. A real service is identified by its IP address and port. Add 10.0.4.1:443 and 10.0.4.2:443.

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

   Add the service group for Gateway 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 the sra.pstest.com, you add the real services that specify the Gateway instances, 10.0.4.1:443 and 10.0.4.2.443.

4. Set the load balancer to perform certificate authentication.

   1. Generate an SSL key and certificate request.

      Use the certificate and key manager (CKM) on the load balancer.

   2. Obtain a valid X.509 certificate.

      Submit the certificate signing request (CSR) to an authorized certificate authority (CA). Alternatively, the load balancer might have a utility for generating a test certificate.

   3. Install the X.509 certificate.

      The method for installing the certificate depends on the load balancer.

5. 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 Gateway service should be sra.pstest.com, with the virtual IP address of 10.0.5.10:443, and with the service group consisting of the computers sra1.pstest.com and sra2.pstest.com.

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

7. 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 Portal Server instances. Both scheduling types keep the connections evenly distributed if the connections are restarted.

8. Configure the load balancer for sticky routing.

   Although not mandatory, it is good practice to maintain a binding between the user's session and the Gateway instance that processed the user's initial request. Gateway instances keep, in cache, the Access Manager sessions that are associated with user requests. If there is no session persistence on the Gateway instances, user requests are routed randomly to the Gateway instances, and every instance caches every user session. This duplication creates additional network traffic whenever a Gateway instance needs to refresh a session. It also leads to unnecessary memory use by the Gateway instances.

   Configuring the Gateway service load balancer to maintain session persistence with the Gateway instances will prevent these problems.

   In the reference configuration, Internet users access the portal service over HTTPS connections to the Gateway service. When users connect over HTTPS, the requests, including any session persistence cookies that help a load balancer route the traffic to the correct instance, are encrypted. The information in the cookies is not available to the load balancer for routing purposes. The following are two ways of handling this situation in the Gateway service load balancer:

   • SSL termination

     If the load balancer supports SSL termination, then the load balancer can perform all the encryption and decryption work that is needed to terminate SSL at the load balancer. Terminating SSL at the load balancer reduces the load on the Gateway instances and improves performance. When the load balancer decrypts an HTTPS request, the session cookie is available to the load balancer. If the load balancer supports passive cookies, it can be configured to maintain session persistence. This approach is the preferred way to configure a load balancer for sticky routing.

     If the load balancer does not support passive cookies, session persistence can be maintained by using the client IP address. However, if multiple users are using a web proxy to reach the Gateway service load balancer, the IP address that the load balancer will see is the IP address of the web proxy. In this case, all users who are using the same web proxy will be routed to the same Gateway instance, possibly resulting in an uneven load on the Gateway instances.

   • SSL session ID

     If the load balancer does not support SSL termination, then it cannot read the session cookie. In this case, you can configure the load balancer to read the SSL session ID and make routing decisions based on the value of the session ID.

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

   The recommended settings are specified in Table 3–5.