To Configure the Load Balancer for the Portal Service

This procedure describes how to configure the portal service load balancer (ps.pstest.com at IP address 10.0.3.11). 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 ps1.pstest.com and ps2.pstest.com to the load balancer's hosts table.

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

   Add the real services for ps1.pstest.com and ps2.pstest.com. A real service is identified by its IP address and port. Add 10.0.2.3:80 and 10.0.2.4:80.

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

   Add the service group for portal 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 ps.pstest.com, you add the real services that specify the Portal Server instances, 10.0.2.3:80 and 10.0.2.4.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 Portal Server service should be ps.pstest.com, with the virtual IP address of 10.0.3.11:80, and with the service group consisting of the computers ps1.pstest.com and ps2.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 Portal Server instances. Both scheduling types keep the connections evenly distributed if the connections are restarted.

7. Configure the load balancer for sticky routing.

   The portal service load balancer must maintain session persistence; it must route all user requests subsequent to the first request, to the same Portal Server instance (except in the case of failure).

   There are two options for sticking the user's portal session to the same Portal Server instance:

   • Load balancer passive cookies (also known as managed cookies). If your load balancer has this feature, it is the preferred solution.

   • Portal Server provides a mechanism analogous to the Access Manager's amlbcookie. You can specify the name of a cookie (for example, pslbcookie) in the lb.cookie.name property of the following file on both ps1 and ps2: /var/opt/SUNWportal/portals/pstestPortal/config/desktopconfig.properties

     Each Portal Server instance assigns a value to this cookie at runtime. The value, which identifies the Portal Server instance, has the following syntax:

     <portalID>.<instanceID>

     For example, in the reference configuration, the value of the cookie for ps1.pstest.com will be pstestPortal.ps-inst-ps1 and for ps2.pstest.com the value will be pstestPortal.ps-inst-ps2.

     The load balancer is configured for session persistence using this cookie.

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

   The recommended settings are specified in Table 3–5.