| Oracle® Access Manager Deployment Guide 10g (10.1.4.0.1) Part Number B25344-01 |
|
|
View PDF |
| Oracle® Access Manager Deployment Guide 10g (10.1.4.0.1) Part Number B25344-01 |
|
|
View PDF |
Failover and load-balancing are vital considerations when you performance-tune your Oracle Access Manager environment. This chapter contains 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
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:
WebPass requests to one or more Identity Servers
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:
Identity Server to one or more directory servers
Access Server to one or more directory servers
Oracle Access Manager supports multi-master LDAP environments. Failover and load balancing are supported for user and policy data, not configuration 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 3-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.
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.
See the Oracle Access Manager Identity and Common Administration Guide and Oracle Access Manager Access Administration Guide for more information about Web component configuration.
Enter the Maximum Connections you want opened for this WebPass or WebGate.
This 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.
Leave the Initial Connections to each associated Oracle Access Manager Server at the default, which is 1.
This applies to both primary and secondary Oracle Access Manager Servers.
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 3-2 provides an example. Assume you have two primary Identity Servers as shown in Figure 3-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. |
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 Admin, System Configuration, Configure WebPass.
From the Access System Console, select Access System Configuration, AccessGate Configuration.
Enter the Maximum Connections you want opened for a given WebPass.
Again, this 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.
Enter the Initial Connections to each associated Oracle Access Manager server to reflect that server's capacity.
Again, this 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.
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 server |
The 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 3–1.
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 screen 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 3-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 3-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 see |
To 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 earlier in see "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 3-4 for an example.
For example, assume there are 5 initial connections and 10 max 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
WebPass requests to secondary Identity Servers
WebGate requests to secondary Access 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.
A "heartbeat" polling mechanism facilitates immediate failover to a secondary directory server when the number of connections in the connection pool falls below the specified threshold level. Additionally, a failback mechanism facilitates switches from the secondary directory server back to the primary server as soon as the preferred connection has been recovered.
The heartbeat feature polls all the primary directory server connections periodically to verify the availability of the directory service (and by implication, the network). 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, rather than for the TCP timeout used previously.
A heartbeat_ldap_connection_timeout_in_millis parameter in globalparams.xml determines the timeout interval for establishing a connection. If the directory service is not available, the heartbeat mechanism immediately initiates failover to the secondary directory server. This enables failover without requiring an incoming directory service request and a subsequent TCP timeout.
The heartbeat_enabled parameter indicates whether the Identity and Access Servers should proactively identify when a directory server is down. Oracle recommends that you enable this function.
|
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 give an incorrect indication that directory is unreachable when it is up and working. |
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 connection timeout parameter
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.
Specifies the amount of time that Identity and Access Servers wait for a connection to be established with the directory server. If a connection with the directory server is not established within this time, the Identity and Access Servers assume that the directory is down or not reachable, and the servers start establishing connections with another directory server. The default value is 4000 (4 seconds). A value of -1 designates 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.
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 3-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 3-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 Admin, System Configuration, Configure WebPass, Name, Modify.
From the Access System Console, select Access System Configuration, AccessGate Configuration, All, Go, Name.
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.
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 3-2 Supported Failover Configurations for Directory Servers
| Component | Data Store | Operation |
|---|---|---|
|
Identity Server |
User |
READ/WRITE—Configured in the directory profile. |
|
Configuration |
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. |
|
|
Policy |
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. |
You use the Directory Profile screen 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 3–2 for details.
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
Locate the obencrypt tool in:
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".
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.
Sample Failover.xml
?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
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
AppDBfailover.xml
ConfigDBfailover.xml
WebResrcDBfailoverxml
