| Oracle® Access Manager Deployment Guide 10g (10.1.4.2.0) Part Number E10353-01 |
|
|
View PDF |
| Oracle® Access Manager Deployment Guide 10g (10.1.4.2.0) Part Number E10353-01 |
|
|
View PDF |
Failover and load balancing are vital for Oracle Access Manager availability and performance. Load balancing distributes request processing across multiple servers. Failover redirects requests to alternate servers if the originally requested server is unavailable or too slow.
This chapter discusses the following topics:
Configuring Load Balancing among Oracle Access Manager and Directory Servers
About Failover Between Oracle Access Manager and Directory Servers
Configuring Directory Failover for Configuration and Policy Data
Configuring Failover Based on Directory Server Response Time
Oracle Access Manager uses load balancing to maximize performance by distributing server requests across multiple physical servers. You configure load balancing among the components listed below.
Load balancing between Oracle Access Manager Web components and servers includes:
WebGate requests to one or more Access Servers
You cannot use hardware load balancers to load balance requests from WebPass and/or WebGates to the Identity and/or Access Servers because the hardware load balancers do not understand the proprietary Oracle Access Manager protocols. Hardware load balancers can load balance only at the connection level, not the request level. The connections to the Oracle Access Manager Servers are persistent connections.
Load balancing among Oracle Access Manager Servers and directory servers includes:
Oracle Access Manager supports multi-master LDAP environments. Failover and load balancing are supported for user and policy data. However, failover and load balancing is not supported for configuration data. Configuration data includes system configuration, attribute definition, attribute access controls, workflow definition, and workflow instance data.
Before you configure load balancing for LDAP writes of user and group data, note that LDAP replication is likely to produce undesirable behavior. An update to one instance may take some time to be reflected on the another instance. This limitation is inherent to all LDAP directory services since LDAP replication does not guarantee transaction integrity.
For user and group data, clustering or segmenting may be useful for distributing the load for read and write operations. This is particularly the case if separate user populations exist in separate branches of the DIT, for example, if one server stores partner data under the ou=partners branch, and another server stores supplier data under the ou=suppliers branch. In cases like this, you can maintain each set of data on a different primary LDAP server for read and write operations. Also, for availability purposes, each server cluster can fail over to the other LDAP servers in a cross-over fashion. This load-balances read and write operations across LDAP multi-masters.
Some LDAP servers, for example Oracle Internet Directory, provide true load balancing capability for reads and writes. These servers guarantee immediate availability when an update occurs on any of the multi-mastered LDAP servers that are configured in this fashion. When using these types of servers, you can configure Oracle Access Manager to provide load-balancing for read and write operations for user and group data.
Oracle Access Manager does not support round robin write operations on either the user and group directories, nor the configuration branch containing Oracle Access Manager meta-data. Data corruption could result when WebGates and AccessGates are found in a round robin configuration with various Access Servers even if each Access Server points to a single, but different, instance of the configuration data hosted on separate, but multi-mastered directories. This is particularly important when Policy Management is turned on and the automatic cache flush is enabled on the Identity Server (or both). Every cache update triggers at least one write operation in the Policy Manager configuration data.
Oracle Access Manager supports both simple round-robin and weighted round-robin load balancing of requests from its Web components (WebPass and WebGate) to their associated servers (Identity and Access). You configure load balancing of Web component requests to Oracle Access Manager Servers from the perspective of the web component using two key fields:
Maximum Connections: The maximum connections you want opened for a given instance of the Web component. This is the total number of live connections you want established to one or more primary Oracle Access Manager Servers at any given time. If the Web component cannot establish a connection to one of its primary servers, it will try to establish a connection to a secondary server.
Initial Connections: The initial connections from the Web component to its associated Oracle Access Manager Servers. This applies to both primary and secondary Oracle Access Manager Servers.
There are several procedures in this section, to use depending upon your environment:
Configuring simple round-robin load balancing of Web component requests means that a Web component opens a single connection to each of its associated primary Oracle Access Manager Servers in the order they are listed, and distributes the requests evenly among them.
For example, assume that you have a single WebPass and two primary Identity Servers as shown in Figure 4-1. In this case, WebPass opens a connection to each Identity Server in the order they are listed. WebPass sends request1 to Identity Server P1, request2 to Identity Server P2, request 3 to Identity Server P1 and so on.
The following procedure guides as you configure a simple round-robin load balancing configuration. The maximum connections in this case is the total number of live connections you want established to one or more primary Identity or Access Servers at any given time. If the Web component cannot establish a connection to one of its primary servers, it tries to establish a connection to a secondary server. The initial connections apply to both primary and secondary Oracle Access Manager Servers.
To configure simple round-robin load balancing
Access the Web component configuration whose requests you want to load balance.
For example:
From the Identity System Console, select System Configuration, WebPass.
From the Access System Console, select Access System Configuration, AccessGate Configuration.
For more information about Web component configuration, see the Oracle Access Manager Identity and Common Administration Guide and Oracle Access Manager Access Administration Guide.
Enter the Maximum Connections you want opened for this WebPass or WebGate.
Leave the Initial Connections to each associated Oracle Access Manager Server at the default, which is 1.
You may want to configure weighted round-robin load balancing of Web component requests if your Oracle Access Manager Servers have varying performance capacities. The primary difference when configuring weighted load balancing is that you adjust the initial connections you want established to each server.
Figure 4-2 provides an example. Assume you have two primary Identity Servers as shown in Figure 4-2. However, Identity Server P1 can handle additional load. Then you may want to configure WebPass to open two connections to Identity Server P1, and one connection to Identity Server P2. The Maximum Connections for that WebPass would be 3: Identity Server P1, request2 to Identity Server P2, request 3 to Identity Server P1 and so on.
Note:
When you associate an AccessGate with an Access Server cluster, Oracle Access Manager automatically configures the number of connections between the AccessGate and all the Access Servers in the cluster based on the maximum number of connections that is specified for the cluster. Load balancing is dynamically configured and Oracle Access Manager ensures that the AccessGate routes requests to the most lightly loaded Access Servers in the cluster.Here as well, your maximum connections specification is the total number of live connections you want established to one or more primary Identity Servers at any given time. If WebPass cannot establish a connection to one of its primary servers, it tries to establish a connection to another primary server.
Again, initial connections applies to both primary and secondary servers. When you associate an AccessGate with an Access Server cluster, Oracle Access Manager automatically configures the number of connections between the AccessGate and all the Access Servers in the cluster based on the maximum number of connections specified for the cluster. Load balancing is dynamically configured and Oracle Access Manager ensures that the AccessGate routes requests to the most lightly loaded Access Servers in the cluster.
To configure weighted round-robin load balancing of Web component requests
Access the Web component where you will configure load balancing.
For example:
From the Identity System Console, select System Configuration, WebPass.
From the Access System Console, select Access System Configuration, AccessGate Configuration.
Enter the Maximum Connections you want opened for a given WebPass.
Enter the Initial Connections to each associated Oracle Access Manager server to reflect that server's capacity.
Simple round-robin load balancing of Oracle Access Manager server requests to two or more directory servers is supported.
Note:
Oracle Access Manager generally does not support load balancing for configuration data because many functions are dependent on data carried over from the previous request. In a load balanced environment, this data may not yet be available to the replicated serverThe instructions for configuring load balancing for directory servers vary depending on the type of component (Identity Server, Access Server, Policy Manager), and whether you are configuring load balancing for user data or configuration data. See Table 4–1 for a summary of data store types and operations.
Previous versions of Oracle Access Manager managed directory connection information solely through XML configuration files. Recently, Oracle Access Manager provided the ability to manage this information through the interface using the Directory Profile page in the Identity System Console and the Access System Console. However, some configuration and policy data is still managed through the XML files. Therefore, you will find yourself using combined methods for configuring load balancing.
Note:
The Identity Server depends on a profile configured for the policy tree to do referential integrity for the policy directory. During Policy Manager setup, this profile is created for the policy directory for the Identity Server component. Whenever a user makes DN changes from the Identity System, the Identity Server uses this profile to update any DN references in the policy directory.Table 4-1 Configuring Load Balancing for Directory Servers
| Component | Data Store | Operation |
|---|---|---|
|
Identity Server |
Users |
READ—Configured in the Directory Profile. See "Configuring Load Balancing for User Data". WRITE—Not supported |
|
Configuration |
READ—Not Supported WRITE—Not Supported |
|
|
Access Server |
User |
READ—Configured in the Directory Profile. WRITE—Not supported Note: Write operations apply to the Access Server only if password policy is enabled. |
|
Configuration |
READ—Configured via the ConfigureAAAServer command line tool. See "Configuring Load Balancing of Configuration & Policy Data". WRITE—n.a. |
|
|
Policy |
READ—Configured via the ConfigureAAAServer command line tool. WRITE—n.a. Note: If you turn on the Access Management Service for that Access Server, you cannot load balance requests from an Access Server to the data store containing policy information. |
|
|
Policy Manager |
User |
READ—Configured in the Directory Profile |
This section includes the following procedures:
By default, Oracle Access Manager creates a directory profile for each installed component. When configuring load balancing for Oracle Access Manager requests to directory servers containing user data, you use the Directory Profile page. For more information on directory profiles, see the Oracle Access Manager Identity and Common Administration Guide.
Maximum Active Servers: The total number of live primary directory servers you want up and running at all times. Requests are distributed evenly across these servers.
As shown in Figure 4-3 assume you have 2 primary directory servers and one secondary directory server. You want to load balance between the primary directory servers, so you should enter Max Active Servers = 2. The secondary directory server only comes into play during failover and does not impact this setting.
To configure load balancing for user data
Access the Directory Profile page.
For example:
From the Identity System Console, select System Configuration, Directory Profiles.
From the Access System Console, select System Configuration, View Server Settings, Directory Options.
Under Configure LDAP Directory Server Profiles, select the name of the profile for the component and data where you want load balancing.
Enter the Maximum Active Servers available for load balancing.
When you configure load balancing of Access Server requests to directory servers containing configuration and/or policy data, use the configureAAAserver tool. The following instructions assume that you have two or more primary directory servers set up.
Note:
Load balancing for configuration data is generally not supported for the Identity Server. These instructions address the Access Server only. The ConfigureAAAServer is an older tool that does not have the most current naming conventions. Maximum Connections as shown in the tool is equivalent to the Maximum Active Servers as explained earlier in seeTo configure load balancing of configuration and policy data for the Access Server
From the command prompt, access the configureAAAServer tool located in AccessServer_install_dir/access/oblix/tools/configureAAAServer
Run configureAAAServer utility using the reconfig install_dir option.
where install_dir is the name of the directory where your Access Server is installed.
For example:
configureAAAServer reconfig "c:\Program Files\COREid1014\access"
Enter the number that corresponds to the Access Server security mode. These are the Access Servers that will connect to the directory servers.
1) Open
2) Simple
3) Cert
You are then be asked if you want to specify failover information for Configuration or Policy.
Select Yes (Y).
Specify whether the data is stored in:
1) Oblix tree
2) Policy tree
Enter 1 to add a failover server at the following prompt.
1) Add a failover server
2) Modify a failover server
3) Delete a failover server
4) Modify common parameters
Enter the following information:
Directory server name
Directory server port
For LDAP in an Active Directory forest environment, use port 3268 for Open mode and port 3269 for SSL mode. These two are the global catalog ports.
Directory server login DN
Directory server password
Directory Server security mode
1) Open
2) SSL
Enter 1 as the priority since you are configuring load balancing
1) Primary
2) Secondary
Enter 4 to modify common parameters.
Enter 1 to specify the Maximum Active Servers.
Maximum Connections as shown in the tool is equivalent to the Maximum Active Servers as explained in "Configuring Load Balancing among Oracle Access Manager and Directory Servers".
Enter the total number of primary directory servers available for load balancing.
Enter 5 to Quit.
Enter 1 to commit changes.
In addition to specifying load balancing of requests evenly across directory server instances using the Max Active Servers parameter, you can also adjust connection pooling within a specific directory server instance by entering the Initial and Maximum Connections for that specific server instance. The request is sent on the connection with the least load.
Similar to configuring load balancing, you must adjust directory pool connections from the following places:
Directory Profile Page: You use this page to configure directory pool connections for user data.
See "To adjust directory connection pooling from the directory profile" for details.
ConfigureAAAServer Tool: You use this tool to configure directory pool connections for policy data.
See "To adjust directory connection pooling using the ConfigureAAAServer tool" for details.
To adjust directory connection pooling from the directory profile
From the Directory Profile page, select a specific DB (directory) instance.
Enter the Initial Connections you want opened to this directory server.
The default is 1.
Enter the Maximum Connections allowed to this directory server instance.
If any of the connections to the directory server are lost, then Oracle Access Manager can attempt to open connections up to the maximum entered.
When the first request is sent to a directory server, the initial number of connections is opened. When connections are lost, or when there are more service threads than connections, new connections are opened (up to the maximum). See Figure 4-4 for an example.
For example, assume there are 5 initial connections and 10 maximum connections to a directory server. When a service thread makes a request to the directory server, then 5 initial connections are created. Assume now, that there are 5 concurrent active service threads that require information from the directory server. They will use all of the existing 5 connections.
If the concurrent service threads increase beyond 5 more connections, Oracle Access Manager can create up to 10 max connections to that directory server. When the limit of 10 connections is reached, and there are 11 or more concurrent service threads, the 11th service thread will get one of the least loaded connections from the pool of 10 connections. The connection is then shared by more than one service thread.
Note:
There is no general optimal value for the initial and maximum connections, given variables such as directory configuration, hardware, and so on. However, you should not set the number of connections higher than the number of threads for a given Oracle Access Manager server.To adjust directory connection pooling using the ConfigureAAAServer tool
See "To configure load balancing of configuration and policy data for the Access Server".
Specify the Modify Common Parameters option when prompted.
Oracle Access Manager uses failover to provide uninterrupted service. Failover involves re-directing requests to another server when the original request destination fails.
Failover is accomplished by configuring primary and secondary servers and identifying specific parameters for the failover process. Failover can be configured between:
Oracle Access Manager Web components to Oracle Access Manager Servers
Oracle Access Manager Servers to directory servers
Identity Server to secondary directory servers
Access Server to secondary directory servers
Policy Manager to directory servers
Oracle Access Manager now provides the ability to perform failover from the Policy Manager to secondary directory servers.
Oracle Access Manager components first attempt to connect to a primary server.
If the primary server is unavailable, a connection attempt may be made to a secondary server. Oracle Access Manager continues to attempt to connect to the primary server, and when the connection is re-established, the connection to the secondary server is dropped. Any server can be configured as a primary or a secondary server. For example, you could designate less powerful or geographically distant servers as secondary.
Failover for Oracle Access Manager Servers occurs when the number of live primary directory servers drops below the number in the Failover Threshold field. The instructions for configuring failover from Oracle Access Manager components to directory servers vary depending on the type of component (Identity Server, Access Server, Policy Manager), and whether you are configuring failover for user data or configuration data.
Note:
The Identity Server depends on a profile configured for the policy tree to do referential integrity for the policy directory. During Policy Manager setup, this profile is created for the policy directory for the Identity Server component. Whenever a user makes DN changes from the Identity System, the Identity Server uses this profile to update any DN references in the policy directory.Table 4-2 Supported Failover Configurations for Directory Servers
| Component | Data Store | Operation |
|---|---|---|
|
Identity Server |
User |
READ/WRITE—Configured in the directory profile. |
|
READ/WRITE—Configured in the directory profile and XML configuration files. |
||
|
Access Server |
User |
Read/WRITE—Configured in the directory profile. Write is only applicable if a password policy is enabled. |
|
Configuration |
READ—Configured via the ConfigureAAAServer command line tool. |
|
|
READ—Configured via the ConfigureAAAServer command line tool. |
||
|
Policy Manager |
User |
READ—Configured in the directory profile. |
|
Configuration |
||
|
Policy |
READ—XML configuration files. |
Note:
The Identity Server depends on a profile configured for the policy tree to do referential integrity for the policy directory. During Policy Manager setup, this profile is created for the policy directory for the Identity Server component. Whenever a user makes DN changes from the Identity System, the Identity Server uses this profile to update any DN references in the policy directory.Configuring failover enables a WebPass or WebGate to check the health of its connections, and failover to secondary Oracle Access Manager Servers in case one or more primary servers go down. You configure failover from the perspective of the Web component. See Figure 4-5 for an example.
Failover Threshold: The key to configuring failover is the Failover Threshold field in the Web component configuration. This specifies the minimum number of live primary connections required. If the number of live connections drops below the failover threshold, then the Web component attempts to establish connections to its secondary servers in the order they are listed. The default is the maximum number of connections.
Sleep For Interval: The default interval is 60 seconds. After this interval, the WebPass or WebGate will check to see if the number of valid connections equals the maximum number of connections configured. If the number of valid connections does not equal the maximum number of connections (drops below the failover threshold), the Web component tries to establish connections to its secondary servers in the order they are configured. Then, at the interval specified, the Web component tries establishing a connection to the primary servers. When it establishes the connection, it drops the connections to the secondary servers after finishing the request it is servicing.
Timeout Threshold: Specifies how long (in seconds) the Web component waits for a non-responsive Oracle Access Manager server before it considers it unreachable and attempts to contact another. No value indicates there is no timeout, and the Web component will wait endlessly for a response from the Oracle Access Manager server. Leaving no timeout can potentially result in a hung session or default to a "TCP" timeout. For example:
For an existing WebPass, enter a value for the Identity Server Timeout Threshold.
For an existing AccessGate, enter a value for the Access Server Timeout Threshold.
In Figure 4-6 a WebGate communicates with two primary Access Servers (Access Server P1 and Access Server P2).
The Maximum Connections is 3. Assume that Access Server P2 can handle additional load, and therefore two initial connections are established to it.
The Failover Threshold is 3. If the number of valid connections drops below the failover threshold, WebGate tries to establish a connection to its secondary server, Access Server S1. Assume that Access Server P2 dropped its second connection.
The Access Server Timeout Threshold parameter is set for 30 seconds. If the WebGate does not receive a response from the Access Server P2 in 30 seconds, it considers the server unreachable and attempts to failover to Access Server S2.
The Sleep For parameter is set for 60 seconds. Every 60 seconds this WebGate checks whether the number of valid connections to primary servers equals the specified number of maximum connections. If not, WebGate continues its attempts to re-establish connections to failed primary Access Server P2.
To configure failover for Web component requests
Access the WebPass or WebGate Web component where you will configure failover.
For example:
From the Identity System Console, select System Configuration, then click the WebPass link in the left navigation pane, then select a WebPass, then click Modify.
From the Access System Console, select Access System Configuration, AccessGate Configuration, All, Go, then select a WebGate.
See the Oracle Access Manager Identity and Common Administration Guide and the Oracle Access Manager Access Administration Guide for more information.
In the Failover Threshold field, enter the required number of live connections from the Web component to its primary Oracle Access Manager server.
Enter the Sleep For interval in seconds.
Enter a Timeout Threshold to specify how long (in seconds) the Web component waits for a non-responsive Oracle Access Manager server before it considers it unreachable and attempts to contact another:
WebPass: Enter a value for the Identity Server Timeout Threshold.
AccessGate: Enter a value for the Access Server Timeout Threshold.
Save your changes.
You use the Directory Profile page when configuring failover of Oracle Access Manager requests to directory servers containing user data.
Failover Threshold: The required number of live primary directory servers. If the number of primary servers drops below the failover threshold, Oracle Access Manager fails over to a secondary directory server.
When the Oracle Access Manager server sends a request on one of its directory connections, and the LDAP SDK returns a connection or server-down error, the directory server is assumed not to be available. If the number of primary directory servers drops below the failover threshold, then Oracle Access Manager attempts to establish connections to its secondary servers in the order they are listed.
If there is a primary server available when failover occurs, the Oracle Access Manager server fails over to the primary server first.
Sleep For: The number of seconds before the watcher thread wakes up and attempts to re-establish connections and create new connections if the connection was down. The watcher thread maintains a pool of good connections at all times.
By default, Oracle Access Manager creates a directory profile for each installed component. You need to access this page to configure directory failover. For more information on directory profiles, see the Oracle Access Manager Identity and Common Administration Guide.
To configure directory failover for user data
Navigate to the System Console and access the Directory Profile page:
For example:
From the Identity System Console, select System Configuration, Directory Profiles.
From the Access System Console, select System Configuration, Server Settings.
Select the link to the directory profile that contains connection information for the component and data where you want failover.
Enter the Failover Threshold.
In the Sleep For field, enter the number of seconds before the watcher thread wakes up and attempts to re-establish connections and create new connections if the connection was down.
Add the Database Instances and indicate their status as secondary servers.
The instructions for configuring failover from Oracle Access Manager components to directory servers vary depending on the type of component (Identity Server, Access Server, Policy Manager), and whether you are configuring failover for user data or configuration data. See Table 4–2 on page 4-11 for details about supported failover configurations for directory servers.
Task overview: Configuring directory failover for configuration and policy data
See "Configuring Identity Server Failover for Configuration Data" for details..
See "Configuring Access Server Directory Failover for Configuration and Policy Data" for details.
For the Identity Server, most configuration data is still managed through the XML configuration files. However, multi-language and referential-integrity data is managed through the Directory Profile page.
When the primary configuration data directory server is down, there is no way for the Identity Server to read any configuration entries. Therefore, the Identity Server reads failover.xml to obtain bootstrap secondary directory server information. See "Sample Failover.xml" for an example.
Task overview: Configuring Identity Server failover for Configuration data
Configure failover for configuration data.
See "To configure Identity Server directory failover for configuration data" for details.
Create the encrypted password.
See "To create the encrypted password for the bind DN" for details.
Configure failover.xml.
See "To create failover.xml" for details.
To configure Identity Server directory failover for configuration data
From the Directory Profile page, enter failover specifications for the directory profile containing the configuration branch of the tree, as described in "Configuring Directory Failover for User Data".
Create a file called failover.xml and add it to IdentityServer_install_dir/identity/oblix/config/ldap directory.
To create the encrypted password for the bind DN
AccessServer_install_dir/access/oblix/tools/ldap_tools/
Run obencrypt password.
Copy and paste the encrypted password into your failover file, as described in "To create failover.xml".
Copy and paste the existing sample_failover.xml template into the directory:
IdentityServer_install_dir/identity/oblix/config/ldap
Open the copy with a text editor and add failover information for secondary servers using "Sample Failover.xml" as a guide.
Copy and paste the encrypted password into your failover file.
Rename the copy to failover.xml.
Repeat as necessary for each applicable Identity Server.
?xml version="1.0" encoding="ISO-8859-1"?> <CompoundList xmlns="http://www.oblix.com" ListName="failover.xml"> <!-- # Max number of connections allowed to all the active ldap servers -- note this is the same as Max Active Servers> <SimpleList> <NameValPair ParamName="maxConnections" Value="1"></NameValPair> </SimpleList> <!-- # Number of seconds after which we switch to a secondary or reconnect to a restarted primary ldap server --> <SimpleList> <NameValPair ParamName="sleepFor" Value="60"></NameValPair> </SimpleList> <!-- # Max amount of time after which a connection to the ldap server will expire --> <SimpleList> <NameValPair ParamName="maxSessionTime" Value="0"></NameValPair> </SimpleList> <!-- # Minimun number of active primary ldap servers after which failover to a secondary server will occur --> <SimpleList> NameValPair ParamName="failoverThreshold" Value="1"></NameValPair> </SimpleList> <!-- # Specify the list of all secondary ldap servers here --> <ValList xmlns="http://www.oblix.com" ListName="secondary_server_list"> <ValListMember Value="sec_ldap_server"></ValListMember> </ValList> <!-- # Specify the details of each secondary ldap server here --> <ValNameList xmlns="http://www.oblix.com" ListName="sec_ldap_server"> <NameValPair ParamName="ldapSecurityMode" Value="Open"></NameValPair> <NameValPair ParamName="ldapServerName" Value="instructor.oblix.com"></NameValPair> <NameValPair ParamName="ldapServerPort" Value="9002"></NameValPair> <NameValPair ParamName="ldapRootDN" Value="cn=Directory Manager"></NameValPair> <NameValPair ParamName="ldapRootPasswd" Value="000A0259585F5C564C"></NameValPair> <NameValPair ParamName="ldapSizeLimit" Value="0"></NameValPair> <NameValPair ParamName="ldapTimeLimit" Value="0"></NameValPair> </ValNameList> </CompoundList>
The following procedures describe configuring failover from the Access Server to one or more directory servers containing configuration and/or policy data.
To configure Access Server failover for configuration and policy data
To add a failover directory server using the ConfigureAAAServer tool
See also:
The section on configuring Access Server directory failover for Oracle and policy data, and the section on configuring policy manager failover in the Oracle Application Server Enterprise Deployment Guide.To configure Access Server failover for configuration and policy data
Using the Directory Profile page, enter the failover for the directory profile containing the oblix branch of the tree.
See "Configuring Directory Failover for User Data" for general instructions.
Repeat the above procedure for the directory server containing policy data, if applicable.
For the Access Server, most configuration data is still managed through the configuration files. However, multi-language and referential-integrity data is managed through the Directory Profile page.
Add failover information using the configureAAAServer tool, as described next.
To add a failover directory server using the ConfigureAAAServer tool
From the command line, navigate to the folder where configureAAAserver tool is located.
For example, the default location is:
AccessServer_install_dir\access\oblix\tools\configureAAAServer
where AccessServer_install_dir is the directory where the Access Server is located.
Run configureAAAServer tool using the following arguments:
configureAAAServer reconfig AccessServer_install_dir
For example:
configureAAAServer reconfig "c:\Program Files\COREid1014\access"
Enter the number that corresponds to the Access Server security mode for Access Servers that will connect to the directory servers.
1) Open
2) Simple
3) Cert
You are then be asked if you want to specify failover information for configuration or Policy.
Select Yes (Y).
Specify whether the data is stored in the:
1) Oblix tree
2) Policy tree
Enter 1 to add a failover server at the following prompt.
1) Add a failover server
2) Modify a failover server
3) Delete a failover server
4) Modify common parameters
5) Quit
Enter the following information:
Directory server name
Directory server port
For LDAP in an Active Directory forest environment, use port 3268 for Open mode and port 3269 for SSL mode. These two are the global catalog ports.
Directory server login DN
Directory server password
Directory Server security mode
1) Open
2) SSL
Priority Enter 2 as the priority
1) Primary
2) Secondary
Enter 5 to Quit.
You are prompted to commit the changes.
Select Y to commit your changes.
ConfigureAAAServer automatically creates the following XML files in AccessServer_install_dir/access/oblix/config/ldap
To configure Policy Manager failover
Copy the WebResrcDBfailover.xml file from the Access Server configuration directory to the Policy Manager installation directory.
Copy the AppDBfailover.xml file from the Access Server configuration directory to the Policy Manager install directory.
Copy the ConfigDBfailover.xml file from the Access Server configuration directory to the Policy Manager installation directory.
A "heartbeat" mechanism polls all primary directory server connections to verify the availability of the directory service. If the directory service is not available, the heartbeat mechanism immediately initiates failover to a secondary directory server if one is configured. A failback mechanism switches from the secondary directory server back to the primary server as soon as the preferred connection is recovered.
A heartbeat_ldap_connection_timeout_in_millis parameter in globalparams.xml determines the time limit for establishing a connection with the directory server. If the time limit is reached, the Identity and Access Servers start establishing connections with another directory server. This parameter enables the Identity and Access Servers to proactively identify when a directory server is down, and it enables failover without requiring a directory service request and TCP timeout. Oracle recommends that you enable this function.
You configure the polling interval by setting the Sleep For (Seconds) parameter for each directory profile. When the host cannot be reached, further attempts to connect to that host are blocked for the specified Sleep For interval.
Note:
If your network is slow and the heartbeat_ldap_ connection_ timeout_in_millis is set to a low value (for example, 10 milliseconds), the heartbeat mechanism can incorrectly indicate that directory is unreachable when it is up.To set the polling interval in the Identity System
From the Identity System Console, select System Configuration, Directory Profiles.
The Configure Profiles page appears.
In the Configure LDAP Directory Server Profiles section of the page, click the link for the profile that you want to modify.
The Modify Directory Server Profile page appears. This directory server profile is used by the Oracle Access Manager servers that are selected in the Used By lists on this page.
Enter the interval in the Sleep For (Seconds) field.
To set the polling interval in the Access System
From the Access System Console, select System Configuration, then click Server Settings.
In the Configure LDAP Directory Server Profiles section of the page, click the link for the profile that you want to modify.
The Modify Directory Server Profile page appears. This directory server profile is used by the Oracle Access Manager servers that are selected in the Used By lists on this page.
Enter the interval in the Sleep For (Seconds) field.
To set the time limit for establishing a connection with the directory
Open the following file:
Component_install_dir/identity/apps/common/bin/globalparams.xml
Where component_install_dir is the location where the Access or Identity Server was installed.
Edit the value for the heartbeat_ldap_connection_timeout_in_millis parameter.
Specify the amount of time that the Identity or Access Server is to wait for a connection to be established with the directory server. The default value is 4000 (4 seconds). A value of -1 specifies that the platform's connection timeout limit should be reached before attempting to establish a connection.
To turn the heartbeat mechanism on or off
Open the following file Component_install_dir/identity/apps/common/bin/globalparams.xml
Where component_install_dir is the location where the Access or Identity Server was installed.
Edit the value for the heartbeat_enabled parameter.
This parameter activates or deactivates the heartbeat mechanism. By default, it is set to true (on). A value of false deactivates the mechanism.
You can configure the Identity Server, Access Server, and Policy Manager to wait for a configurable amount of time (in milliseconds) for a response from a primary directory server. If no response is received within the configured time limit, the component fails over to a secondary directory server if one is configured.
The LDAPOperationTimeout setting in globalparams.xml controls the time that the Oracle Access Manager component waits for the directory server to respond.
When processing a user request, an Oracle Access Manager component can issue multiple LDAP queries. The LDAPOperationTimeout parameter applies to each query independently of other queries involved in processing the same request. For example, the LDAPOperationTimeout parameter sets a time limit for the directory server to process a single entry of a search result. If an entry in the search result set is not received within this time limit, the component fails over to a secondary server. To configure the time to wait for all search result entries, use the Oracle Access Manager administration console to configure the Time Limit parameter in the directory profile. See the Oracle Access Manager Identity and Common Administration Guide for details.
The default value for the LDAPOperationTimeout parameter of -1 causes the Oracle Access Manager component to wait indefinitely for the directory server to respond.
The rest of this section discusses the following topics:
Guidelines for Configuring Failover Based on Directory Server Response Time
Configuring the LDAPOperationTimeout and LDAPMaxNoOfRetries Parameters
WARNING:
If you keep the default value of -1 for LDAPOperationTimeout and the directory server hangs, Oracle Access Manager will hang, too. If you do not have issues with directory server hanging, you can use the default of -1.
Also, if you set the LDAPOperationTimeout parameter to too low a value, the primary directory server can fail over even if it is operational. If the value is also too low for the secondary server, an infinite loop can occur. See the following sections for details.
You determine the value for LDAPOperationTimeout based on your environment, for example, the amount of data in the directory server, network latency, the number of indexes defined for the directory server, whether the Oracle Access Manager component and the directory server communicate using SSL, and so on.
The following are guidelines for estimating the amount of time that an Oracle Access Manager component should wait before failing over to a secondary directory server:
Conduct tests to determine the value, for example, send time-consuming requests to the Oracle Access Manager component in a comparable environment to the one you are configuring.
Check for the message, "LDAPMaxNoOfRetries exceeded. Please verify configured value of LDAPOperationTimeout in globalparams.xml" in the following log file:
Component_install_dir\oblix\logs\oblog.log
This message appears in logs that are configured at the Warning level. The message indicates that a request timed out before an operational directory server could return the result. If you see this message, you should increase the value of the LDAPOperationTimeout parameter. A value that is too low can result in an infinite loop, where operational directory servers do not have adequate time to return a result.
As a safeguard for setting too low a value for the LDAPOperationTimeout parameter, The LDAPMaxNoOfRetries parameter limits the number of times that the Identity Server, Access Server, or Policy Manager can retry an LDAP operation or query in the configured directory servers. As with the parameter LDAPOperationTimeout, this parameter applies to each query independently of other queries involved in processing a request. Set the value to be greater than the number of directory servers that communicate with the Oracle Access Manager component. This ensures that at least one attempt is made to query each configured directory server.
The following procedure describes how to configure these parameters.
To configure the amount of time to wait for a response before failing over
Open the following file:
component_install_dir/apps/common/bin/globalparams.xml
Set the LDAPOperationTimeout parameter to one of the following values:
A positive number that indicates a time in milliseconds.
A value of -1 enables the directory server to determine the time to spend on the request.
Set the value of the LDAPMaxNoOfRetries parameter.
The default of 0 indicates that the number of retries is equal to the number of primary and secondary directory servers that are configured to communicate with the component. A value of -1 indicates an infinite number of retries. A whole number indicates a number of permitted retries.
Restart the component.
Some Oracle Access Manager functions require multiple LDAP operations. For some of the LDAP operations involved in a request, the LDAPOperationTimeout value may be adequate, and the operation will be successful. For other operations in the request, the LDAPOperationTimeout value may be too low, and the next LDAP operation in the request may fail, assuming that the directory server is unavailable. This can result in an inconsistent state.
If you set the LDAPOperationTimeout parameter to too low a value, the primary directory server can fail over even if it is operational. If the value is also too low for the secondary server, an infinite loop can occur.
Setting the LDAPOperationTimeout parameter to a higher value does not degrade Oracle Access Manager performance. As soon as the directory server returns the results, the Oracle Access Manager continues processing.
To test for an appropriate value for the LDAPOperationTimeout parameter, you can test particularly time-consuming operations in Oracle Access Manager.
Note:
In several steps of the following procedure, you investigate the processing of attributes that are configured using the DN Prefix semantic type. The DN Prefix semantic type is required for the person and group structural object classes and for all structural object classes in Organization Manager. The DN Prefix specifies the relative distinguished name (RDN) of an object. The RDN is the leftmost part of the distinguished name (DN). The DN Prefix is used when creating an object through a workflow.To test for the optimal LDAPOperationTimeout value
Configure the LDAPOperationTimeout value.
See "Configuring the LDAPOperationTimeout and LDAPMaxNoOfRetries Parameters" for details.
Find an attribute with the DN Prefix semantic type in the User Manager, as follows.
From the Identity System Console, click User Manager Configuration, then click Tabs, then click the link for the User Manager tab, then click Modify Attributes, and identify the attribute that is configured with the DN Prefix semantic type.
In the User Manager, click My Profile, then click Modify, and modify the attribute that was configured using the DN Prefix semantic type.
Go to the log file component_install_dir\oblix\logs\oblog.log, and be sure the following message does not appear in the file, "LDAPMaxNoOfRetries exceeded. Please verify configured value of LDAPOperationTimeout in globalparams.xml."
This message appears in logs that you configure at the Warning level. If the message appears, increase the value of LDAPOperationTimeout and conduct the test again.
Find an attribute with the DN Prefix semantic type in the Group Manager, as follows.
From the Identity System Console, click Group Manager Configuration, then click Tabs, then click the link for the Group Manager tab, then click Modify Attributes, and identify the attribute that was configured with the DN Prefix semantic type.
In the Group Manager, click My Groups, select a group, then click Modify, and modify the attribute that has the DN Prefix semantic type.
Look for the message described in step 4, and if it appears, increase the value of LDAPOperationTimeout and conduct the test again.
Find an attribute with the DN Prefix semantic type in the Org Manager, as follows.
From the Identity System Console, click Org Manager Configuration, then click Tabs, then click the link for an Org Manager tab, then click Modify Attributes, and modify the attribute that was configured with the DN Prefix semantic type.
Look for the message described in step 4, and if it appears, increase the value of LDAPOperationTimeout and conduct the test again.
Determine if the LDAPOperationTimeout value is adequate for deactivating or deleting a user who is a member of a static group as follows.
In the User Manager, view a user profile, delete the user, and check the oblog.log file as described in step 4.
Identify other time-consuming operations in your environment and perform them.
After conducting the operation, check the oblog.log file, as described in step 4.
