test

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

Implementing Load Balancing for the Access Manager Service

This task consists of the following procedures:

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

ProcedureTo Configure Access Manager as a Load-Balanced Server Site

To implement Access Manager session persistence, you define what is called a load-balanced Access Manager site. Once a site is defined and configured, Access Manager automatically sets the value of a cookie, with the default name of amlbcookie, to be equal to the instance ID of the Access Manager instance that first authenticates an Access Manager client request.

The instance ID is defined at the moment the instance is created. For example, the Access Manager instance created on am1.pstest.comwill have an instance ID equal to 01 because this is the first instance created.

  1. Start a browser.

  2. Go to the Access Manager Console login page.

    http://am1.pstest.com/amconsole

    The Access Manager Console login page opens.

  3. Log in to the Access Manager Console by typing the following values and clicking Login.

    Field 

    Input Value 

    User ID 

    amadmin

    Password 

    access-manager-admin-password

    The Access Manager Console opens.

  4. Modify the organization properties as follows:

    1. In the Identity Management tab, select the Organizations view.

      The Organizations section is displayed in the right pane.

    2. In the Organizations section, locate the General Properties and the list of Organization Aliases.

    3. In the list of Organization Aliases, add the following value:

      am.pstest.com

    4. Click Save.

      The following message is displayed: "The organization properties have been saved."

  5. In the Access Manager Console, navigate to the load balancer setup information.

    1. Click the Service Configuration tab.

      The Service Configuration tab displays a list of services that you can configure.

    2. In the Service Configuration tab, locate the Service Name list in the left pane.

    3. In the Service Name list, locate Platform. Click the arrow to the right of Platform.

      The configuration options for the Platform service are displayed in the right pane.

    4. In the list of configuration options, locate the section for Global options.

    5. Locate the entry field for the Site List and type the following value:

      http://am.pstest.com:80|10

      where 10 is an arbitrary site number.

    6. Click Add.

      The load balancer's name is added to the Site List.

    7. Click Save.

      The following message is displayed: "The service properties have been saved."

  6. Under the Site List, locate the Server List, and in the server list locate the Instance Name.

    Do the following:

    1. Add am2.pstest.com:80|02|10

    2. Add am1.pstest.com:80|01|10

    3. Remove am1.pstest.com:80|01

    4. Remove am2.pstest.com:80|02

    5. Click Save.

      Your changes are saved.

ProcedureTo Configure Access Manager Instances for Load Balancing

The AMconfig.properties file for each Access Manager instance must be configured to recognize the load balancer as the virtual Access Manager service login host.

  1. Modify the login URL property for the Access Manager instance on am1.

    1. On am1, open the AMconfig.properties file in a text editor.

      The file is located at:

      /etc/opt/SUNWam/config/AMConfig.properties

    2. Modify the login URL property:

      com.sun.identity.loginurl=http://am.pstest.com:80/amserver/UI/Login

    3. Restart the Access Manager instance.

      # /opt/SUNWappserver/appserver/bin/asadmin stop-domain

      # /opt/SUNWappserver/appserver/bin/asadmin start-domain --user admin domain1

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

  2. Modify the login URL property for the Access Manager instance on am2.

    Use the same procedure as in Step 1, except on am2.

ProcedureTo Verify Load Balancing for the Access Manager Service

This procedure verifies the following:

  1. Start the Access Manager instances on am1 and am2, if they are not already running.

  2. Start a browser.

  3. Go to the Access Manager Console login page by using the load balancer URL

    http://am.pstest.com/amconsole

    The Access Manager Console login page opens.

  4. Log in to the Access Manager Console by typing the following values and clicking Login.

    Input Field 

    Value 

    User ID 

    amadmin

    Password 

    access-manager-admin-password

    The Access Manager Console opens, which confirms that the load balancer has routed the login request to one of the Access Manager instances.

  5. Determine which Access Manager instance handled the login request in Step 4.

    1. Click on the Current Sessions tab.

      The left panel shows both Access Manager instances: http://am1.pstest.com:80 and http://am2.pstest.com:80

    2. Check for an amadmin session on each instance.

      You can display the sessions existing on each instance by clicking on the small triangle adjacent to each.

    3. Note the instance that owns the amadmin session.

  6. Simulate a failure of the Access Manager instance that was noted in Step 5.

    Failure of an Access Manager 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 Access Manager 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 (am1 or am2) hosting the instance identified in Step 5.

    # /opt/SUNWappserver/appserver/bin/asadmin stop-domain

  7. In the Access Manager Console, click on the Identity Management tab.

    If service failover has succeeded, the login page should once again be displayed, indicating that content is now being served from the remaining Access Manager instance.

  8. Log in once again, as directed in Step 4.

  9. Confirm the service failover.

    1. Click on the Current Sessions tab.

      The left panel shows both Access Manager instances: http://am1.pstest.com:80 and http://am2.pstest.com:80

    2. Check for an amadmin session on the failed instance.

      You can display the existing sessions by clicking on the small triangle adjacent to the instance. In this case, an “Failed to get the valid sessions...” error message should be displayed (the instance is shut down).

    3. Check for an amadmin session on the remaining instance.

      In this case, an amadmin session should be displayed.

  10. Recover the simulated failure of your original Access Manager instance.

    Run the following command on the computer (am1 or am2) on which the Application Server instance was shut down in Step 6.

    # /opt/SUNWappserver/appserver/bin/asadmin start-domain --user admin domain1

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