Updated: Configuring Load Balancing for Sun Java System Access Manager 2005Q1

   
By Xinfeng Liu and Marina Sum, December 14, 2005  

This is the updated version of the original article that was published on March 22, 2005.

Sun Java System Access Manager (henceforth, Access Manager) is a security foundation that helps businesses manage secure access to Web applications. Accordingly, availability and scalability of Access Manager are essential for establishing robust security. Load balancing ensures availability if one or more servers are down, and it divides among multiple servers the workload usually done by one server, thus enhancing productivity.

You can implement load balancing with hardware, software, or a combination of both. To preserve session information, a load balancer deployed with Access Manager must support sticky sessions. A sticky session specifies that, once a session is created by a server, subsequent user requests continue to be routed to that same server. Since Access Manager uses cookies to relay session information, the load balancer must redirect to the server that created the session. Without sticky sessions, you would have to trust all the servers and performance could be degraded.

Sun Java Application Server 2005Q1 (henceforth, Application Server) contains a load-balancer plug-in that can be installed in Sun Java System Web Server 2005Q1 (henceforth, Web Server). That load balancer adopts a sticky round-robin algorithm to balance incoming HTTP and HTTPS requests and sends all the requests for a given session to the same server instance.

Why use Web Server and the Application Server load-balancer plug-in? Three major reasons—

  •  

  • Hardware-based load balancers are generally expensive.
  •  

  • The required software is part of Sun Java Enterprise System, of which Access Manager is a component, so customers can benefit from the subscription pricing model without incurring additional costs.
  •  

  • Web Server is secure, reliable, and easy to use, ideal for medium and large business applications.

This article describes how to configure load balancing for Access Manager with Web Server and the load-balancer plug-in in Application Server. Familiarity with Access Manager and Web Server is assumed.

Note: To acquire the Access Manager Software Development Kit (SDK) for load balancing, install Patch 2 for Access Manager 2005Q1 or a later version on either the SPARC platform or the x86 platform.

Contents

 
Software Requirements

Sun Java Enterprise System 2005Q1 contains all the required software for load balancing:

  • Sun Java System Access Manager 2005Q1
  • Sun Java System Web Server 2005Q1
  • Sun Java System Application Server Enterprise Edition 2005Q1 (with a loadbalancer plug-in)

Note: You can also install the load-balancer plug-in in other Web servers, such as Apache Web Server and Microsoft Internet Information Services (IIS). For details, see the section "Configuring Web Servers for HTTP Load Balancing" in the Sun Java System Application Server Enterprise Edition 8.1 Administration Guide.

 
Installation and Configuration

This section details the installation and configuration Manager instances and load balancing.

Installing Access Manager Instances

Follow these steps to install and configure Access Manager:

  1. Install the first Access Manager instance by running Java Enterprise System Installer.

    In this example, Access Manager is deployed in Web Server. If you deploy Access Manager in Web Server's Web container, you must run Web Server as root.

  2. Install the second Access Manager instance.

    You can install a second instance on another machine, also by running Java Enterprise System Installer.

    Ensure that the password encryption key—the string that Access Manager uses to encrypt user passwords—is the same as that for the first instance. All Access Manager subcomponents must use the same password encryption key value as that used by the Identity Management and Policy Services Core.

    Likewise, to deploy multiple instances of Access Manager on different servers and to install the administration console or common domain services for federation management, you must use the same password encryption key for all instances.

    The value of password encryption key is stored in the am.encryption.pwd attribute in the AMConfig.properties file. Simply copy that value from the first Access Manager instance for future use. Figure 1 shows the first pane in the Java Enterprise System Installer. Note the password encryption key copied from the first Access Manager instance.

    Figure 1: Installing an Access Manager Instance with Java Enterprise System Installer
    Figure 1: Installing an Access Manager Instance with Java Enterprise System Installer

    Alternatively, you can use the amconfig utility to configure the second Access Manager instance on the same machine. Again, be sure to use the same password encryption key and set the AM_ENC_PWD variable to the value of that key.

    In addition, all Access Manager instances must point to the same directory server or the correspondent master replication server. Therefore, when installing or configuring the second Access Manager instance, you must specify the directory server's host name and port number rather than installing a new directory server. For example, make the second Access Manager instance point to the directory server on which the first Access Manager instance runs.
  3. Repeat step 2 to install as many Access Manager instances as you desire.

Installing and Configuring Load Balancing

Next, install Web Server as the load balancer and then install and configure the loadbalancer plug-in:

  1. Run Java Enterprise System Installer to install Web Server or, if it is already installed, configure a new instance from the Web Server administration console.

    The host on which the load balancer runs is usually a different host from the Access Manager instances.

  2. Install and configure the load-balancer plug-in against Web Server by running Java Enterprise System Installer on the host on which the Web Server instance runs. See Figure 2.

    Figure 2: Installing the Load-Balancer Plug-In
    Figure 2: Installing the Load-Balancer Plug-In

    When prompted to select the Web Server instance, select the one that will serve as the load balancer. In this example, it is /opt/SUNWwbsvr/https-loadbalancer.

  3. Go to your Web Server's installation configuration directory, for example, /opt/SUNWwbsvr/https-loadbalancer/config, and copy loadbalancer.xml.example to loadbalancer.xml. Specify all the instances of the Access Managers in loadbalancer.xml, for example:

    <instance name="instance1" enabled="true" disable-timeout-in-minutes="60"
    listeners="http://jes-zone.prc.sun.com:80"/>
    <instance name="instance2" enabled="true" disable-timeout-in-minutes="60"
    listeners="http://jes-zone2.prc.sun.com:80"/>
    
    
  4. Change the line web-module context-root="abc" to web-module context-root="/".
  5. Save the changes and restart Web Server.


Configuring Access Manager Instances for Load Balancing

Do the following to set up Access Manager instances for load balancing:

  1. From the administration console, log in to one of Access Manager instances as amadmin.
  2. Choose Organization under View and then, under Organization Aliases on the right pane, add the host name of the load balancer. See Figure 3.

    Figure 3: Adding the Host Name of the Load Balancer
    Figure 3: Adding the Host Name of the Load Balancer
  3. On the Access Manager servers, add the following line for fqdnMap to the AMConfig.properties file, for example:

    com.sun.identity.server.fqdnMap[loadbalancer.prc.sun.com] = loadbalancer.prc.sun.com

    Note: The load-balancer FQDN (fully-qualified domain name) must appear in two positions on this line, as shown above, to override the default behavior, whereby Access Manager replaces that FQDN with its own.
  4. Restart all the server instances.
 
Testing of Load Balancing

Now test the load balancing capability:

  1. From the browser, go to http:// loadbalancer . domainname : portnumber / amconsole , for example, http://loadbalancer.prc.sun.com:80/amconsole .

    View the logs of the Web container in which Access Manager runs. If you see that the load balancer has redirected your request to the first Access manager instance configured in loadbalancer.xml, that means load balancing is working.

  2. From another browser window, access the same URL.

    View the logs of the Web container in which Access Manager runs. If you see that the load balancer has redirected to the second Access manager instance configured in loadbalancer.xml, that means load balancing is working.

  3. Manually shut down one of Access Manager instances and then access the same URL.

    View the logs again. The load balancer should have redirected your request to one of the live Access Manager instances.
 
Troubleshooting Tips

If a test fails, note the following troubleshooting tips:

  • Mozilla and Netscape browser windows share one session. If you use either one of these browsers, open another instance of the browser from another machine to make the load balancer redirect the new request to the second Access Manager instance.
  • If you see no Access Manager login page or authentication error messages, the configuration of the load balancer is probably in error. Look for clues in the error logs of the load balancer in the Web Server installation, for example, /opt/SUNWwbsvr/https-loadbalancer/logs/errors.
  • If you fail to log in from the Access Manager login page, the configuration of Access Manager is probably in error. Look for clues in the debug or error messages in the directories /var/opt/SUNWam/debug and /var/opt/SUNWam/logs. In addition, you can change the debug level by setting com.iplanet.services.debug.level=message in the AMConfig.properties file. Afterwards, restart Access Manager.
  • If you cannot connect to Access Manager through the load balancer, the configuration still enables you to connect to each of the Access Manager instances. That way, you can pinpoint where the problem lies: in the configuration of Access Manager or that of the load balancer.
 
Enhancements

Because Access Manager depends on Sun Java System Directory Server (Directory Server for short), you may wish to configure Directory Server's replications or Sun Java System Directory Proxy Server for high availability and scalability. For details, see the Access Manager 6 2005Q1 Deployment Planning Guide .

Also, session failover is a requirement for high availability for Access Manager. With session failover, a user's authentication session persists and, even if one or multiple Access Manager instance fails, the user need not reauthenticate. Access Manager provides an independent session failover implementation for the Web container with Sun Java System Message Queue (Message Queue) as the communications broker and the Berkeley DB by Sleepycat Software, Inc. as the session store database. Again, for more information, see the Access Manager 6 2005Q1 Deployment Planning Guide .

 
References
 
Acknowledgment

Thanks to Tim Rault-Smith at Sun for his review and comments on this article.

Rate and Review
Tell us what you think of the content of this page.
Excellent   Good   Fair   Poor  
Comments:
Your email address (no reply is possible without an address):
Sun Privacy Policy

Note: We are not able to respond to all submitted comments.
Left Curve
Java SDKs and Tools
Right Curve
Left Curve
Java Resources
Right Curve
JavaOne Banner Java 8 banner (182)