Chapter 5 Implementation Module 2: Access Manager With Session Failover on Application Server
This chapter provides an overview of the Access Manager service module in Figure 2–2 and documents the tasks required to implement it. The chapter includes the following sections:
Overview of the Access Manager Service Module
The Access Manager service module of the reference configuration's deployment architecture illustrated in Figure 2–2. The module consists of two instances of Sun Java System Access Manager running on two different computers. The module makes use of a hardware load balancer that is configured to provide service failover capability between the two Access Manager instances. All requests for Access Manager services are addressed to the virtual service name and IP address of the load balancer. The load balancer directs each request to one of the two Access Manager instances.
This module implements Access Manager session failover. When a user logs in, the load balancer routes the login request to one of the Access Manager instances, which authenticates the user and creates a session object. Subsequent requests from the user are directed to the same Access Manager instance.
If an Access Manager instance fails, the system recovers as follows:
-
Service Failover. Subsequent requests are routed by the load balancer to the other Access Manager instance.
-
Access Manager Session Failover. The new Access Manager instance retrieves session information from an Access Manager session database, thus making the service failover transparent to the user. The session failover mechanism is designed to revert back to the original Access Manager instance, if that instance subsequently comes back on line.
Access Manager's session failover mechanism is designed to be web container independent. It uses Message Queue and a session database to provide session failover between the two Access Manager instances.
The architecture of the Access Manager service module is shown in the following illustration.
Figure 5–1 Access Manager Service Module
The Access Manager instances run in a web container that is provided by Sun Java System Application Server. Each Access Manager instance runs in the Domain Administration Server (DAS) instance of its respective computer. A Message Queue broker cluster, consisting of one Message Queue broker on each computer, is used by Access Manager to write session information to (and retrieve session information from) an Access Manager session database, which is replicated on each computer. The broker cluster and replicated session database are meant to avoid a single point of failure.
The Message Queue brokers and session database instances can reside on different computers from the Access Manager instances. However, it is simpler to set up the failover mechanism locally.
The general approach to implementing this module is to first set up Access Manager on each computer. In doing so, the Java ES installer is run in Configure Now mode to install and configure Application Server, Message Queue, and Access Manager. Following these procedures, load balancing is implemented to provide Access Manager service failover and then Access Manager session failover is set up.
This module can be scaled horizontally by adding an additional computer like am2 and its respective components, and following the instructions in this chapter that apply to am2. However, the procedures for implementing Access Manager session failover might require some adjustment.
Note –
The procedures in this chapter use the host names, domain name, and IP addresses shown in Figure 3–1 and Figure 5–1. However, you must map these host names, domain name, and IP addresses to equivalent names and addresses in your environment. For this reason, the procedures in this chapter show host names, domain name, and IP addresses as variables.
Setting Up Access Manager on am1
This task consists of the following procedures:
To Install Access Manager on am1
This procedure assumes that you are installing Access Manager on Solaris 10 8/07 OS or later version. Hence, no operating system patches need to be installed. The Java ES installer evaluates the state of the operating system and indicates if you need to install a patch. If you are using versions of the operating system older than Solaris 10 8/07 OS, it is better to install any required patches before you begin the actual Access Manager installation procedure.
The following procedure runs the Java ES installer without saving a state file. You can choose to run the installer and capture your input in a state file (-saveState state-filename). You could then use the state file to re-create the installation if, for example, you needed to reinstall Access Manager.
-
Download the Java ES software distribution to am1.
The procedure is documented in To Download the Software Distribution.
-
Log in as root or become superuser.
# su -
-
Start the Java ES installer.
# cd /portdist_71u2/Solaris_sparc
# ./installer
This procedure uses the GUI installer. The installer can also be run in text mode by using the - nodisplay option.
The Welcome panel opens.
-
In the Welcome panel, click Next.
The Software License Agreement panel opens.
-
In the Software License Agreement Panel, review the license terms and click Yes, Accept License.
The Choose Software Components panel opens.
-
In the Choose Software Components panel, select the following components:
-
Application Server Enterprise Edition 8.2
-
Domain Administration Server
-
Application Server Node Agent (Not needed for this module, but can be installed for possible future use)
-
Command-Line Administration Tool
-
Sample Application (Not needed for this module, but can be installed for possible future use)
-
-
High Availability Session Store 4.4 (Not needed for this module, but is a dependency of Application Server that is automatically selected and cannot be unselected)
-
Java DB 10.1 (Not needed for this module, but is a dependency of Application Server that is automatically selected and cannot be unselected)
-
Java DB Client
-
Java DB Server
-
-
Access Manager 7.1
-
Access Manager Core Services
-
Access Manager Administration Console
-
Common Domain Services for Federation (Not needed for this module, but can be installed for possible future use)
-
Access Manager SDK
-
Access Manager Session Failover Client
-
-
Message Queue 3.7 UR1
-
Install Multilingual Package(s) for all selected components (selected automatically, but optional if using English)
Also, unselect Directory Server Enterprise Edition 6.2 if it is automatically selected.
-
-
Click Next.
The Dependency Warning panel opens.
-
In the Dependency Warning panel, choose Use Directory Server Installed on a Remote Machine and click OK.
The installer evaluates the Java SE Software Development Kit on the computer and determines if an upgrade is required. On a fresh copy of Solaris 10 8/07 OS, an upgrade is needed, and the Java SE Software Development Kit Upgrade Required panel opens.
-
In the Java SE Software Development Kit Upgrade Required panel, select Automatic Upgrade to the Version Included with the Installer and click Next.
The installer evaluates the Java ES shared components on the computer and determines if any upgrades are required. On a fresh copy of the Solaris 10 8/07 OS, shared component upgrades are needed, and the Shared Components Upgrades Required panel opens.
-
In the Shared Components Upgrades Required panel, click Next.
The installer upgrades the shared components. The Specify Installation Directories panel opens.
-
In the Specify Installation Directories panel, type the following values and click Next.
Input Field
Value
Access Manager
/opt
Application Server
/opt/SUNWappserver
Application Server Data and Configuration
/var/opt/SUNWappserver
The installer checks the system, and the System Check panel opens.
-
In the System Check panel, evaluate the results of the system check.
If the system check is favorable, click Next.
The Choose a Configuration Type panel opens.
-
In the Choose a Configuration Type panel, select Configure Now and click Next.
The Custom Configuration Panel opens.
-
In the Custom Configuration Panel, note the following message and click Next.
The following component products cannot be configured during installation: Java DB Click Next to configure the other components.
The Specify Administrator Account Preferences panel opens.
-
In the Specify Administrator Account Preferences panel, type the following values and click Next.
If you are using different administrator accounts for different services (Java ES products), select the corresponding checkbox in the panel (see Administrator Account Specification).
Input Field
Value
Administrator User ID
admin
Administrator Password
app-server-admin-password
The Common Server Settings panel opens.
-
In the Common Server Settings panel, type the following values and click Next.
Input Field
Value
HostName
am1
DNS Domain Name
pstest.com
Host IP Address
10.0.2.1
System User
root
System Group
root
The Application Server: High Availability Session Store (HADB) panel opens.
-
In the Application Server: High Availability Session Store (HADB) panel, type the following values, uncheck the Automatically Start HADB checkbox, and click Next.
Input Field
Value
HADB Management Port
1862
HADB Resource Directory
/var/opt
HADB Administrator Group
root
The Application Server: Domain Administration Server panel opens.
-
In the Application Server: Domain Administration Server panel type the following values and click Next.
Input Field
Value
Admin Port
4849
JMX Port
8686
HTTP Port
80
HTTPS Port
8181
Master Password
app-server-master-password
The Access Manager: Specify Configuration Information panel opens.
-
In the Access Manager: Specify Configuration Information panel, type the following values and click Next.
Also, record the values that you specify in this panel. They will be needed when installing other components in the reference configuration.
Input Field
Value
Install Type
Legacy Mode
Administrator User ID
amadmin
(This administrator account is different from the admin account in step 15, Administrator Account Preferences panel.)
Administrator Password
access-manager-admin-password
LDAP User ID
amldapuser
LDAP Password
access-manager-LDAP-password
Password Encryption Key
password-enc-key (This password must be at least 12 characters. A value is proposed by the installer.)
The Access Manager: Choose Deployment Container panel opens.
-
In the Access Manager: Choose Deployment Container panel, type the following values and click Next.
Input Field
Value
Sun Java System Application Server
Yes
The Access Manager: Specify Sun Java System Application Server panel opens.
-
In the Access Manager: Specify Sun Java System Application Server panel type the following values and click Next.
Input Field
Value
Secure Server Instance Port
No
Secure Administration Server Port
Yes
The Access Manager: Specify Web Container for Running Access Manager Services panel opens.
-
In the Access Manager: Specify Web Container for Running Access Manager Services panel, type the following values and click Next.
Input Field
Value
Host Name
am1.pstest.com
Services Deployment URI
amserver
Common Domain Deployment URI
amcommon
Cookie Domain
pstest.com
Password Deployment URI
ampassword
Console Protocol
HTTP
The Access Manager: Choose Access Manager Console panel opens.
-
In the Access Manager: Choose Access Manager Console panel, type the following values and click Next.
Input Field
Value
Administration Console
Deploy New Console
Console Deployment URI
amconsole
Console Host Name
am1.pstest.com
Console Port
80
The Access Manager: Specify Directory Server Information panel opens.
-
In the Access Manager: Specify Directory Server Information panel, type the following values and click Next.
Input Field
Value
Directory Server Host
ds.pstest.com (The logical service name was created when the directory service module's load balancer was configured.)
Directory Server Port
389
Access Manager Directory Root Suffix
dc=pstest,dc=com (The suffix was defined when Directory Server was installed.)
Directory ManagerDN
cn=Directory Manager
Directory Manager Password
directory-manager-password (This password was defined when Directory Server was installed.)
The Access Manager: Specify Directory Server Data panel opens.
-
In the Access Manager: Specify Directory Server Data panel, type the following values and click Next.
Input Field
Value
Is Directory Server Provisioned With User Data?
No
The Ready to Install panel opens.
-
In the Ready to Install panel, indicate whether you want to open the software registration window during installation.
This panel enables you to register the components that you have selected for installation with Sun Connection. Sun Connection is a Sun-hosted service that helps you track, organize, and maintain Sun hardware and software. For example, Sun Connection can inform you of the latest available security fixes, recommended updates, and feature enhancements.
If you choose to register, information about the installation is sent to the Sun Connection database. You can also register at a later date, after installation has been completed.
-
Click Install.
The installer copies files to the computer, modifies configuration files based on the values provided, and deploys Access Manager to the Application Server's Domain Administration Server (DAS) instance.
-
When the installation is complete, review the installation in the Summary field.
-
Click Exit to exit the installer.
-
Check the installation log files for any installation errors.
# cd /var/sadm/install/logs
# egrep -i 'fail|error' Java*
To Start and Verify Access Manager on am1
The following procedure confirms that Access Manager has been installed by starting the Access Manager Console login page.
-
Check that Application Server is running.
# netstat -an | grep 80
-
If Application Server is not running, start it.
# /opt/SUNWappserver/appserver/bin/asadmin start-domain --user admin domain1
When prompted, type the app-server-admin-password.
-
Verify the operation of Access Manager on am1.
-
Start a browser.
-
Open the Access Manager Console login page:
http://am1.pstest.com/amconsole
The login page opens.
-
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 Access Manager is deployed and running in the web container.
-
Setting Up Access Manager on am2
This task consists of the following procedures:
To Install Access Manager on am2
-
Repeat the procedure that appears in To Install Access Manager on am1, using the same parameter values, except for the following:
-
Replace all occurrences of am1 with am2.
-
For the IP address, replace 10.0.2.1. with 10.0.2.2.
-
When you see the prompts in the following table, type the values in the table. These values were not requested in To Install Access Manager on am1 because no data was in the directory at that time.
Input Field
Value for am2 Installation
Is Directory Server Provisioned With User Data
Yes
Organization Marker Object Class
sunISManagedOrganization
Organization Naming Attribute
o
User Marker Object Class
inetorgperson
User Naming Attribute
uid
-
To Start and Verify Access Manager on am2
-
Repeat the procedure in To Start and Verify Access Manager on am1, except for the following:
When you are prompted for input values, type the values that apply to am2. For example, when you open the Access Manager Console, type the URL with am2 instead of am1.
Implementing Load Balancing for the Access Manager Service
This task consists of the following procedures:
To 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.
-
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.
-
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
-
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.
-
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.
-
Configure the load balancer to use Layer-7 (HTTP layer) load balancing.
-
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.
-
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.
-
Configure the health-check settings for the load balancer.
The recommended settings are specified in Table 3–5.
To 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.
-
Start a browser.
-
Go to the Access Manager Console login page.
http://am1.pstest.com/amconsole
The Access Manager Console login page opens.
-
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.
-
Modify the organization properties as follows:
-
In the Identity Management tab, select the Organizations view.
The Organizations section is displayed in the right pane.
-
In the Organizations section, locate the General Properties and the list of Organization Aliases.
-
In the list of Organization Aliases, add the following value:
am.pstest.com
-
Click Save.
The following message is displayed: "The organization properties have been saved."
-
-
In the Access Manager Console, navigate to the load balancer setup information.
-
Click the Service Configuration tab.
The Service Configuration tab displays a list of services that you can configure.
-
In the Service Configuration tab, locate the Service Name list in the left pane.
-
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.
-
In the list of configuration options, locate the section for Global options.
-
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.
-
Click Add.
The load balancer's name is added to the Site List.
-
Click Save.
The following message is displayed: "The service properties have been saved."
-
-
Under the Site List, locate the Server List, and in the server list locate the Instance Name.
Do the following:
To 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.
-
Modify the login URL property for the Access Manager instance on am1.
-
On am1, open the AMconfig.properties file in a text editor.
The file is located at:
/etc/opt/SUNWam/config/AMConfig.properties
-
Modify the login URL property:
com.sun.identity.loginurl=http://am.pstest.com:80/amserver/UI/Login
-
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.
-
-
Modify the login URL property for the Access Manager instance on am2.
Use the same procedure as in Step 1, except on am2.
To Verify Load Balancing for the Access Manager Service
This procedure verifies the following:
-
that you can interact with Access Manager instances through the load balancer
-
that the load balancer provides service failover when an Access Manager instance fails
-
Start the Access Manager instances on am1 and am2, if they are not already running.
-
Start a browser.
-
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.
-
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.
-
Determine which Access Manager instance handled the login request in Step 4.
-
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
-
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.
-
Note the instance that owns the amadmin session.
-
-
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
-
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.
-
Log in once again, as directed in Step 4.
-
Confirm the service failover.
-
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
-
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).
-
Check for an amadmin session on the remaining instance.
In this case, an amadmin session should be displayed.
-
-
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.
Setting Connection Timeouts for Access Manager
Access Manager connections to directory services can inadvertently time out with negative consequences if idle timeout values are not set correctly with respect to Directory Server (or the directory service load balancer).
This task consists of the following procedures:
To Configure the Connection Timeout of the Directory
Service
Access Manager uses a pool of open connections to access the directory service. If these connections remain idle for longer than the Directory Server's idle timeout period, the connections will be closed on the Directory Server end, and Access Manager will restart them.
However, if a load balancer (or firewall) is located between Access Manager and Directory Server, the idle timeout of the load balancer (or firewall) might close the connection before Directory Server does. Some load balancers (or firewalls) do not close the connection cleanly, and Access Manager is not notified of the closure. In this case, connections in the pool can be exhausted, requiring a restart of Access Manager. In addition, when a connection is not closed cleanly by a load balancer (or firewall), the Directory Server might not close the socket, causing the open sockets to accumulate.
To avoid this set of circumstances, the Directory Server's idle timeout for Access Manager connections must be less than the idle timeout interval of the directory service load balancer (or firewall).
-
Set the value of the Directory Server idle timeout to less than that of the directory service load balancer.
Run the following command on ds1:
# ldapmodify -h ds1.pstest.com -p 389 -D "cn=Directory Manager" <<EOF
dn: cn=amldapuser,ou=DSAME Users, dc=example,dc=com
changetype: modify
add: nsIdleTimeout
nsIdleTimeout: timeout-value
EOF
where timeout-value is a value in seconds less then the load balancer's idle timeout.
When prompted, type the directory-manager-password.
To Configure the Persistent Search Timeout for Access
Manager
Access Manager uses Directory Server persistent searches to obtain asynchronous notifications of changes on the Directory Server. The persistent search mechanism provides an active channel through which information about changes that occur can be communicated back to Access Manager.
Each active, persistent search requires that an open TCP connection be maintained between Access Manager and Directory Server. If the persistent search connections are made through a load balancer (or firewall), then these connections are subject to being closed by the load balancer (or firewall). For some load balancers (and firewalls), the connection is not closed cleanly. As a result, the persistent searches are not automatically restarted, and change notifications are interrupted until a persistent search connection is re-established.
This interruption in persistent searches can be prevented by configuring the Access Manager idle timeout for persistent search to be shorter than the TCP idle timeout of the directory service load balancer (or firewall). Hence, persistent searches are restarted before the load balancer (or firewall) can time out.
-
On am1, open the AMconfig.properties file in a text editor.
The file is located at:
/etc/opt/SUNWam/config/AMconfig.properties
-
Locate the persistent search timeout property:
com.sun.am.event.connection.idle.timeout
This property specifies the timeout value in minutes after which persistent searches will be restarted. A value of “0” (the default) indicates that the connection does not time out, so that searches will not be restarted.
-
Set the persistent search timeout value as follows and save the change:
com.sun.am.event.connection.idle.timeout=timeout-value
where timeout-value is a value in minutes less than the load balancer's idle timeout value.
-
Restart the Access Manager instance, am-inst-am1 on am1.
# /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.
-
Repeat Steps 1–4 on am2.
Replace all occurrences of am1 with am2 in these steps.
Implementing Session Failover for Access Manager
The implementation of session failover involves establishing a persistence layer that uses Message Queue to write session information to a replicated Access Manager session database (see Figure 5–1). If the Access Manager instance that owns a session fails, the session information is retrieved and passed to another Access Manager instance.
You implement session failover by first creating what is called a secondary configuration instance. The secondary configuration instance specifies values that are needed to store and recover persistent session information. You then use Access Manager utilities to set up the session persistence database.
Note –
Access Manager provides the amsfoconfig script, which performs some of the procedures that are needed to implement service failover and session failover. However, the amsfoconfig script is not used in this reference configuration because service failover and session failover are independent functions that are best implemented and verified separately.
To Create a Secondary Configuration Instance
-
Log in to the Access Manager Console.
-
Confirm that Application Server on am1 is running.
# /opt/SUNWappserver/appserver/bin/asadmin list-domains --user admin --terse=true
When prompted, type the app-server-admin-password.
If the Application Server is not running, then start it.
# /opt/SUNWappserver/appserver/bin/asadmin start-domain --user admin domain1
When prompted, type the app-server-admin-password.
-
Start a browser.
-
Go to the Access Manager login page:
http://am.pstest.com/amconsole
The Access Manager Console login page opens.
-
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.
-
-
In the Access Manager Console main page, click the Service Configuration tab.
-
In the Service Configuration tab, navigate to the New Secondary Configuration dialog box.
-
Locate the Service Name pane on the left side of the tab.
-
In the Service Name pane, scroll down and click the arrow to the right of Session.
The Session detail is displayed in the right pane.
-
In the Session detail pane, locate the Secondary Configuration Instances and click New.
The New Secondary Configuration dialog box opens.
-
-
In the New Secondary Configuration dialog box, type the following values and click Add.
Input Field
Value
Instance Name
http://am.pstest.com:80 (this is the URL for the load balancer)
Session Store User
am-svr-usr (the user name you establish in the following procedure for connecting to the Message Queue Server)
Session Store Password
am-svr-usr-password (the password you set in the following procedure)
Maximum Wait Time
5000
Database URL
am1.pstest.com:7777,am2.pstest.com:7777 ( the list of broker addresses in the Message Queue broker cluster)
The Secondary Configuration dialog box closes.
-
Click Save to save your changes.
To Configure Session Failover on am1
-
Shut down the Access Manager instance on am1.
You shut down the Access Manager instance by shutting down the Application Server instance in which it runs.
# /opt/SUNWappserver/appserver/bin/asadmin stop-domain
The response should resemble the following:
Domain domain1 stopped.
-
Add the required Java Archive (JAR) files to the web container classpath.
-
Start a browser.
-
Go to the following URL:
https://am1.pstest.com:4849
The Application Server login page opens.
-
Log in to the Application Server Admin Console by typing the following values and clicking Login.
Input Field
Value
User ID
admin
Password
app-server-admin-password
The Application Server Admin Console opens.
-
Click on the small triangle next to Configurations on the Common Tasks panel.
The configurations are expanded.
-
Click on the small triangle next to server-config.
The pscluster configuration is expanded.
-
Click on JVM Settings.
The frame on the right shows the configuration options.
-
In the right frame, select the Path Settings tab.
The JVM Classpath Settings panel opens.
-
Add /usr/share/lib/imq.jar and /usr/share/lib/jms.jarto the Classpath Suffix list.
-
Click Save.
-
-
Create a Message Queue user for Access Manager session failover.
This user will be used internally to send and retrieve session information. To use the imqusermgr utility in the following steps, you must first create a default user repository, which is done automatically the first time you start the Message Queue broker.
-
Start the Message Queue broker to be used for session failover.
# bash
This opens the bash shell, which supports background processes.
# /usr/bin/imqbrokerd -name aminstance -port 7777 &
Note –Before using port 7777, check that it is not being used by some other process.
The output should resemble the following:
[25/Oct/2007:16:17:00 MEST] ================================================================================ Sun Java(tm) System Message Queue 3.7 Sun Microsystems, Inc. Version: 3.7 UR2 (Build 3-b) Compile: Mon May 7 22:37:30 PDT 2008 Copyright (c) 2007 Sun Microsystems, Inc. All rights reserved. SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. This product includes code licensed from RSA Data Security. ================================================================================ Java Runtime: 1.5.0_12 Sun Microsystems Inc. /usr/jdk/instances/jdk1.5.0/jre [25/Oct/2007:16:17:00 MEST] IMQ_HOME=/ [25/Oct/2007:16:17:00 MEST] IMQ_VARHOME=/var/imq [25/Oct/2007:16:17:00 MEST] SunOS 5.10 sparc am1(24 cpu) root [25/Oct/2007:16:17:00 MEST] Max file descriptors: 65536 (65536) [25/Oct/2007:16:17:00 MEST] Java Heap Size: max=174784k, current=35328k [25/Oct/2007:16:17:00 MEST] Arguments: [25/Oct/2007:16:17:00 MEST] [B1060]: Loading persistent data... [25/Oct/2007:16:17:00 MEST] Using built-in file-based persistent store: /var/imq/instances/aminstance/ [25/Oct/2007:16:17:01 MEST] [B1039]: Broker "aminstance@am1:7777" ready.
-
Change the default Message Queue administrative user password.
# /usr/bin/imqusermgr update -i aminstance -u admin -p MQ-admin-psssword
The response should resemble the following:
User repository for broker instance: aminstance Are you sure you want to update user admin? (y/n) y User admin successfully updated.
-
Add a new Message Queue user to be used for Access Manager session failover..
# /usr/bin/imqusermgr add -i aminstance -u am-svr-usr -p am-svr-usr-password
The response should resemble the following:
User repository for broker instance: aminstance User amSvrUsr successfully added.
-
Delete the default guest user.
# /usr/bin/imqusermgr update -i aminstance -u guest -a false
The response should resemble the following:
User repository for broker instance: aminstance Are you sure you want to update user guest? (y/n) y User guest successfully updated.
-
Shut down the Message Queue broker.
# imqcmd shutdown bkr -b am1:7777 -u admin
When prompted, type the MQ-admin-password.
-
-
Check the installation directories in the amsessiondb file.
-
Generate an encrypted password file.
# /opt/SUNWam/bin/amsfopassword -f /opt/SUNWam/.password -e am-svr-usr-password
os.name=SunOS SUCCESSFUL
-
Edit the amsfo.conf file.
-
Open the amsfo.conf file in a text editor.
The file, which is used to configure Access Manager session failover, is located at:
/opt/SUNWam/lib/amsfo.conf
-
Type the following values:
Parameter
Value
AM_HOME_DIR
/opt/SUNWam
AM_SFO_RESTART
true
CLUSTER_LIST
am1.pstest.com:7777,am2.pstest.com:7777
DATABASE_DIR
/tmp/amsession/sessiondb
LOG_DIR
/tmp/amsession/logs
START_BROKER
true
BROKER_INSTANCE_NAME
aminstance
BROKER_PORT
7777
USER_NAME
am-svr-usr
lbServerPort
80
lbServerProtocol
http
lbServerHost
am.pstest.com:80
SiteID
10
JAVA_HOME
/usr/jdk/entsys-j2se
-
-
Run the amsfo script:
# /opt/SUNWam/bin/amsfo start
The script starts the Message Queue broker on am1, the Access Manager session database on am1, and initializes the Message Queue and Access Manager session database clients needed to implement session persistence.
-
Verify that the Message Queue connections are working.
Open the following log file:
/tmp/amsession/logs/amsessiondb.log
Check for errors in the file.
-
Restart the Access Manager instance on am1.
You start the Access Manager instance by starting the Application Server instance in which it runs.
# /opt/SUNWappserver/appserver/bin/asadmin start-domain --user admin domain1
When prompted, type the app-server-admin-password.
To Configure Session Failover on am2
-
Repeat the procedure that appears in To Configure Session Failover on am1, except for the following:
Replace all occurrences of am1 with am2.
To Verify Session Failover
In this procedure, a user logs in to the Access Manager Console, and you determine the Access Manager instance that is handling the Access Manager Console request. You then simulate a failure of that instance, have the user make another Access Manager Console request, and note which Access Manager instance is handling the second request. If session failover is working properly, the Access Manger service fails over to the failover Access Manager instance without the user having to log in a second time.
-
Log in to the Access Manager Console, if you are not already logged in.
-
Start a browser.
-
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.
-
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.
-
-
Determine which Access Manager instance handled the login request in Step 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
-
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.
-
Note the instance that owns the amadmin session.
-
-
Simulate a failure of the Access Manager instance that was noted in Step 2.
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 session 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 2.
# /opt/SUNWappserver/appserver/bin/asadmin stop-domain
-
Perform another Console request.
For example, click the Identity Management tab, then click the pstest link.
If session failover is working correctly, the Console session will fail over to the other Access Manager instance and display a list of Organization Aliases in the right pane. The fact that you did not have to log in again confirms that session failover is working.
-
Confirm that your Access Manager Console session is now owned by the other Access Manager instance.
You can do this step by repeating Step 2 or by checking the access logs on your web containers.
-
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 3.
# /opt/SUNWappserver/appserver/bin/asadmin start-domain --user admin domain1
When prompted, type the app-server-admin-password.
Tuning Access Manager Instances
Access Manager performs best when the web container in which it runs is tuned to optimize Access Manager performance. So, you should tune the Application Server instances that host Access Manager. In this module, Access Manager runs in the Application Server's DAS instance.
In the portal service reference configuration, no other component or application besides Access Manager runs in the Application Server's DAS instance. However, if you run other components or applications in the same Application Server instance, then be aware that optimizing the Application Server instance for Access Manager might negatively impact the performance of other components.
To Tune Application Server Instances for Access Manager
Tuning the Application Server instances that host Access Manager is performed by using the amtune utility. For additional information about amtune, see Part I, Basic Performance Tuning, in Sun Java System Access Manager 7.1 Performance Tuning and Troubleshooting Guide.
Perform the following procedure on both am1 and am2..
-
Change to the following directory:
# cd /opt/SUNWam/bin/amtune
-
Open the amtune-env file in a text editor.
-
Confirm, or if necessary, modify the following values and save the changes.
WEB_CONTAINER=AS8 ASADMIN_PORT=80 DOMAIN_NAME=pstest.com AMTUNE_PCT_MEMORY_TO_USE=100 AMTUNEAMTU_MIN_PERM_SIZE_AS8=128 AMTUNE_MODE=REVIEW
Note –In a Solaris zones deployment, also set AMTUNE_TUNE_OS=false.
-
Run the amtune utility.
# ./amtune directory-manager-password app-server-admin-password
The utility proposes changes to optimize Access Manager performance.
-
Review any suggested changes.
If no undesired changes are proposed, continue to the next step.
-
Modify the amtune-env file with the following value and save the change.
AMTUNE_MODE=CHANGE
-
Repeat Step 4.
The utility runs a second time, but makes all the changes proposed in Step 4.
-
Restart the computer.
Restarting the computer will affect changes to the operating system.
-
Start the Access Manager instance.
# /opt/SUNWappserver/appserver/bin/asadmin start-domain --user admin domain1
When prompted, type the app-server-admin-password.
Taking a Snapshot of the Module
When you have completed deploying the Access Manager module of the reference configuration, and before you move on to the next module, it is good practice to take a snapshot of the data in the Directory Server instance. By exporting ds-inst-ds1, you preserve the current state of your deployment in case you subsequently need to roll back directory information to this point in the reference configuration deployment process. The directory serves as the repository for service and user configuration information and therefore changes as each reference configuration module is deployed.
To take a snapshot of the directory on ds1
In this procedure you use the db2ldif command to export the directory to an ldif file. If you want to subsequently restore the directory, use an equivalent procedure with the ldif2db command.
-
On ds1 change directory as follows:
# cd /var/opt/SunWdsee/ds-inst-ds1
-
Stop the Directory Server instance.
# ./stop-slapd
-
Export the current state of the pstest directory to an ldif file.
# ./db2ldif -n pstest
The output should resemble the following:
ldiffile: /var/opt/SunWdsee/ds-inst-ds1/ldif/2008_05_20_140750.ldif [20/May/2008:14:07:56 +0100] - export pstest: Precessed 1000 entries (26%) ... [20/May/2008:14:08:02 +0100] - export pstest: Precessed 4165 entries (100%)
-
Rename the ldif file to something meaningful.
# mv /var/opt/SunWdsee/ds-inst-ds1/ldif/2008_05_20_140750.ldif /var/opt/SunWdsee/ds-inst-ds1/ldif/am_module_complete.ldif
-
Restart the Directory Server instance.
# ./start-slapd
- © 2010, Oracle Corporation and/or its affiliates