|
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
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.
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:
- 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.
- 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 |
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.
- 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:
- 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.
- 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 |
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.
- 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"/>
|
- Change the line
web-module context-root="abc" to
web-module context-root="/".
- Save the changes and restart Web Server.
Web Server is now ready for load balancing requests. However, you must further
configure Access Manager to make load balancing work correctly.
Configuring Access Manager Instances for Load Balancing
Do the following to set up Access Manager instances for load balancing:
- From the administration console, log in to one of Access Manager instances as
amadmin.
- 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 |
- 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.
- Restart all the server instances.
Now test the load balancing capability:
- 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.
- 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.
- 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.
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.
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.
Thanks to Tim Rault-Smith at Sun for his review and comments on this article.
|
 Xinfeng Liu, currently a member of technical staff at Sun's Market Development Engineering group, provides consultation service to Sun's software partners and vendors in China. He has 11 years of experience in software development and technical consulting.
|
 Marina Sum is a staff writer for Sun Developer Network. She has been writing for Sun since 1989, mostly in the technical arena. Marina blogs on Sun products, technologies, events, and publications.
|
|
Print-friendly Version
