test

Sun Java System Reference Configuration Series: Portal Service on Application Server Cluster

Implementing Load Balancing for the Portal Service

This task consists of the following procedures:

ProcedureTo 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.

ProcedureTo Verify Load Balancing for the Portal Service

This procedure verifies that you can interact with Portal Server instances through the load balancer and that the load balancer provides service failover when a Portal Server instance fails.

  1. Configure the Portal Server instances on ps1 and ps2 to support session cookies.

    Portal Server provides a mechanism that is analogous to the Access Manager's amlbcookie in which you can specify the name of a session cookie, as follows:

    1. In a text editor, open the following configuration file:

      /var/opt/SUNWportal/portals/pstestPortal/config/desktopconfig.properties

    2. Specify the name of a session cookie, as follows:

      lb.cookie.name=pslbcookie

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

      <portal ID>.<instance ID>

  2. Restart the Portal Server instances on ps1 and ps2 by restarting the Application Server instances in which they are deployed.

    See To Start and Verify Portal Server on ps1 and To Start and Verify Portal Server on ps2.

  3. Log in to the DeveloperSample desktop.

    1. Open the portal service in a browser.

      Use the load balancer URL:

      http://ps.pstest.com/portal

      The portal Welcome page opens.

    2. On the Samples box, click on the DeveloperSample.

      The anonymous desktop for the DeveloperSample should be displayed.

    3. Log in by typing the following values and clicking Login.

      Input Field 

      Value 

      User ID 

      developer 

      Password 

      developer 

      The DeveloperSample desktop is displayed.

  4. Determine which Portal Server instance handled the login request in Step 3.

    You can determine the instance by opening the pslbcookie cookie in your browser and checking it's instance ID value. For example in the Firefox browser, do the following:

    1. Choose Edit->Preferences->Privacy->Show Cookies.

    2. Select the pstest.com portal.

    3. Select the pslbcookie cookie.

    4. Note the instance ID in the Content field.

      For example, 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.

  5. Simulate a failure of the Portal Server instance that was noted in Step 4.

    Failure of an Portal Server instance can result from a computer failure, a software failure, or a network failure. The method employed for simulating a failure in this service failover verification procedure is to shut down the Portal Server instance (by shutting down the Application Server instance in which it runs). Additionally, you could also simulate failure by unplugging the network cable or disabling the interface.

    Run the following command on the computer (ps1 or ps2) hosting the instance identified in Step 2.

    # /opt/SUNWappserver/sbin/asadmin stop-instance --user admin as-cluster-inst-ps1|ps2

    When prompted, type the app-server-admin-password.

  6. Repeat Step 3, above (log in to the DeveloperSample desktop).

    If service failover is working correctly, the portal Welcome page opens, confirming that the load balancer has routed the login request to the remaining online Portal Server instance.

  7. Recover the simulated failure of your original Portal Server instance.

    Restart the Application Server instance that was shut down in Step 5.

    # /opt/SUNWappserver/sbin/asadmin ststt-instance --user admin as-cluster-inst-ps1|ps2

    When prompted, type the app-server-admin-password.