12 Configuring High Availability for Oracle Directory Services Components
This chapter describes configuring Oracle Directory Services products for high availability in an active-active configuration.
- About the 12c Oracle Directory Services Products
The following table summarizes Oracle Identity Management products that you can install using the suite-level installation program for 12c. - Configuring Oracle Directory Integration Platform on ODIPHOST1 (OID)
- Prerequisites for Oracle Directory Services High Availability Configuration
This section describes the prerequisite steps that you must complete before setting up an Oracle Directory Services high availability configuration. - Oracle Internet Directory High Availability
This section provides an introduction to Oracle Internet Directory and describes how to design and deploy a high availability environment for Oracle Internet Directory. - Oracle Directory Integration Platform High Availability
This section describes how to design and deploy a high availability environment for Oracle Directory Integration Platform (ODIP). - About Starting and Stopping Oracle Directory Services Components
- About Configuring Oracle Internet Directory for Maximum High Availability
This section provides high-level instructions for setting up a maximum high availability deployment for Oracle Internet Directory. This deployment includes two sites in different geographic locations. This is an active-active deployment where both sites are active at the same time when the deployment is functioning normally. If one site fails, the surviving site continues to function.
Parent topic: Component Procedures
About the 12c Oracle Directory Services Products
The following table summarizes Oracle Identity Management products that you can install using the suite-level installation program for 12c.
Table 12-1 The 12c Identity Management Components and Product Suites
Product | Description | Product Suite |
---|---|---|
Oracle Internet Directory | LDAP Version 3-enabled service that enables fast retrieval and centralized management of information about dispersed users, network configuration, and other resources. | Oracle Identity Management Platform and Directory Services Suite |
Oracle Directory Integration Platform | Oracle Directory Integration Platform is a J2EE application that enables you to synchronize data between various directories and the back-end directory. Oracle Directory Integration Platform includes services and interfaces that enable you to deploy synchronization solutions with other enterprise repositories. | Oracle Identity Management Platform and Directory Services Suite |
Oracle Directory Services Manager | GUI for Oracle Internet Directory. Oracle Directory Services Manager that simplifies administration and configuration of Oracle Virtual Directory and Oracle Internet Directory by enabling you to use web-based forms and templates. Oracle Directory Services Manager is available from either the Oracle Enterprise Manager Fusion Middleware Control or from its own URL. | Oracle Identity Management Platform and Directory Services Suite |
For more information on Oracle Internet Directory installation, See Preparing to Install in Oracle Fusion Middleware Installing and Configuring Oracle Internet Directory
Configuring Oracle Directory Integration Platform on ODIPHOST1 (OID)
ODIPHOST1
:
Prerequisites for Oracle Directory Services High Availability Configuration
This section describes the prerequisite steps that you must complete before setting up an Oracle Directory Services high availability configuration.
- Oracle Home Requirement
The Oracle home for the Identity Management components must be the same across all nodes. - Database Prerequisites
Several Oracle Identity Management components require the presence of a supported database and schemas. - About Installing and Configuring the Database Repository
Oracle recommends a highly available database to store the metadata repository. - Configuring the Database for Oracle Fusion Middleware 12c Metadata
You need to have the network prerequisites for deploying an Oracle Identity Management high availability environment.
Oracle Home Requirement
The Oracle home for the Identity Management components must be the same across all nodes.
/u01/app/oracle/product/fmw/idmas the Oracle home on Node1, then you must choose
/u01/app/oracle/product/fmw/idmas the Oracle home on all subsequent nodes.
Database Prerequisites
Several Oracle Identity Management components require the presence of a supported database and schemas.
To check if your database is certified or to see all certified databases, see the "Certified Databases" section in the Certification Document: http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html.
SQL>select version from sys.product_component_version where product like 'Oracle%'
About Installing and Configuring the Database Repository
Oracle recommends a highly available database to store the metadata repository.
For maximum availability, Oracle recommends using an Oracle Real Application Clusters (Oracle RAC) database. Oracle recommends that the database use Oracle Automatic Storage Management for data storage. If you use Oracle ASM, the best practice is to also use Oracle Managed Files.
-
One for the Database files.
-
One for the Flash Recovery Area.
Oracle Clusterware
See Oracle Real Application Clusters Installation Guide for Linux and UNIX.
Automatic Storage Management
See Oracle Real Application Clusters Installation Guide for Linux and UNIX.
When you run the installer, select Configure Automatic Storage Management in the Select Configuration page to create a separate Automatic Storage Management home.
Oracle Real Application Clusters
See Oracle Real Application Clusters Installation Guide for Linux and UNIX.
Many Oracle Fusion Middleware components require that schemas are in a database prior to installation. Use the Repository Creation Utility (RCU) to create the component schemas in an existing database. For high availability environments, you must create the schemas and load them into an Oracle RAC database.
Configuring the Database for Oracle Fusion Middleware 12c Metadata
You need to have the network prerequisites for deploying an Oracle Identity Management high availability environment.
Create the Oracle Real Application Clusters database to store Oracle Fusion Middleware 12c metadata with the following characteristics:
-
It should be in archive log mode to facilitate backup and recovery.
-
Optionally, flashback should be enabled.
-
It should be created with the ALT32UTF8 character set.
The value of the static PROCESSES initialization parameter must be 500 or greater for Oracle Internet Directory. This value is checked by the Repository Creation Utility.
To check the value, you can use the SHOW PARAMETER command in SQL*Plus:
prompt> sqlplus "sys/password as sysdba" SQL> SHOW PARAMETER processes
One common way to change the parameter value is to use a command similar to the following and then stop and restart the database to make the parameter take effect:
prompt> sqlplus "sys/password as sysdba" SQL> ALTER SYSTEM SET PROCESSES=500 SCOPE=SPFILE;
The method that you use to change a parameter's value depends on whether the parameter is static or dynamic, and on whether your database uses a parameter file or a server parameter file.
See:
- Database Examples in this Chapter
See the databases used in Oracle Directory Services Configuration examples in this chapter. - Configuring Database Services
Oracle recommends using the Oracle Enterprise Manager Cluster Managed Services Page to create database services that client applications use to connect to the database. - Verifying Transparent Application Failover
After the Oracle Internet Directory process starts, you can query the FAILOVER_TYPE, FAILOVER_METHOD, and FAILED_OVER columns in the V$SESSION_VIEW to obtain information about connected clients and their TAF status. - Configuring Virtual Server Names and Ports for the Load Balancer
There are network prerequisites for Load Balancer and Virtual Server Names for deploying an Oracle Identity Management high availability environment.
Database Examples in this Chapter
See the databases used in Oracle Directory Services Configuration examples in this chapter.
Table 12-5 Databases Used in Identity Management Configuration Examples
Component | Database Service Name | Database Instance Name |
---|---|---|
Oracle Internet Directory |
oid.example.com |
oiddb1, oiddb2 |
Oracle Directory Integration Platform |
oid.example.com |
oiddb1, oiddb2 |
Oracle Directory Services Manager |
N/A |
N/A |
Configuring Database Services
Oracle recommends using the Oracle Enterprise Manager Cluster Managed Services Page to create database services that client applications use to connect to the database.
If you already have a service in the database, ensure that it is enabled for high availability notifications and configured with the proper server-side Transparent Application Failover (TAF) settings. Use the DBMS_SERVICE package to modify the service to enable high availability notification to go through Advanced Queuing (AQ) by setting the AQ_HA_NOTIFICATIONS attribute to TRUE and configure server-side TAF settings, as shown below:
prompt> sqlplus "sys/password as sysdba" SQL> EXECUTE DBMS_SERVICE.MODIFY_SERVICE (SERVICE_NAME => 'idm.example.com', AQ_HA_NOTIFICATIONS => TRUE, FAILOVER_METHOD => DBMS_SERVICE.FAILOVER_METHOD_BASIC, FAILOVER_TYPE => DBMS_SERVICE.FAILOVER_TYPE_SELECT, FAILOVER_RETRIES => 5, FAILOVER_DELAY => 5);
You must enter the EXECUTE DBMS_SERVICE command on a single line.
See Also:
-
Administering Services with Oracle Enterprise Manager, PL/SQL, and SRVCTL in Oracle Real Application Clusters Administration and Deployment Guide
-
DBMS_SERVICE in Oracle Database PL/SQL Packages and Types Reference
Verifying Transparent Application Failover
After the Oracle Internet Directory process starts, you can query the FAILOVER_TYPE, FAILOVER_METHOD, and FAILED_OVER columns in the V$SESSION_VIEW to obtain information about connected clients and their TAF status.
SELECT MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER, COUNT(*) FROM V$SESSION GROUP BY MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER;
The output before failover is similar to this:
MACHINE FAILOVER_TYPE FAILOVER_M FAI COUNT(*) -------------------- ------------- ---------- ---- ---------- oidhost1 SELECT BASIC NO 11 oidhost1 SELECT BASIC NO 1
The output after failover is similar to this:
MACHINE FAILOVER_TYPE FAILOVER_M FAI COUNT(*) -------------------- ------------- ---------- ---- ---------- oidhost2 SELECT BASIC NO 11 oidhost2 SELECT BASIC NO 1
Configuring Virtual Server Names and Ports for the Load Balancer
There are network prerequisites for Load Balancer and Virtual Server Names for deploying an Oracle Identity Management high availability environment.
- Load Balancers
All components in the Oracle Identity Management software stack require a hardware load balancer when deployed in a high availability configuration. - Virtual Server Names
You should setup virtual server names for the high availability deployments. Ensure that the virtual server names are associated with IP addresses and are part of your Domain Name System (DNS). The computers on which Oracle Fusion Middleware is running must be able to resolve these virtual server names.
Load Balancers
All components in the Oracle Identity Management software stack require a hardware load balancer when deployed in a high availability configuration.
The hardware load balancer should have the following features:
-
Ability to load-balance traffic to a pool of real servers through a virtual hostname: Clients access services using the virtual hostname (instead of using actual host names). The load balancer can then load balance requests to the servers in the pool.
-
Port translation configuration: The load balancer should have the ability to perform port translation, where it enables incoming requests received on one port to be routed to a server process running on a different port. For example, a request received on port 80 can be routed to port 7777.
-
Protocol translation: The load balancer should support protocol translation between systems running different protocols. It enables users on one network to access hosts on another network, despite differences in the native protocol stacks associated with the originating device and the targeted host. For example, incoming requests can be HTTPS, and outgoing requests can be HTTP.
This feature is recommended but not required.
-
SSL acceleration: SSL acceleration is a method of offloading the processor-intensive public key encryption algorithms involved in SSL transactions to a hardware accelerator.
This feature is recommended but not required.
-
Monitoring of ports (HTTP, HTTPS, LDAP, LDAPS)
-
Virtual servers and port configuration. Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:
The load balancer should enable configuration of multiple virtual servers. For each virtual server, the load balancer should enable configuration of traffic management on more than one port. For example, for Oracle Internet Directory clusters, the load balancer needs to be configured with a virtual server and ports for LDAP and LDAPS traffic.
The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the load balancer through the virtual server names.
-
Ability to detect node failures and immediately stop routing traffic to the failed node.
-
Resource monitoring / port monitoring / process failure detection.
The load balancer must be able to detect service and node failures (through notification or some other means) and to stop directing non-Oracle Net traffic to the failed node. If your load balancer has the ability to automatically detect failures, you should use it.
-
Fault-tolerant mode
It is highly recommended that you configure the load balancer to be in fault-tolerant mode.
-
Other
Oracle recommends that you configure the load balancer virtual server to return immediately to the calling client when the back-end services that it forwards traffic to are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client machine.
-
Sticky routing capability
Ability to maintain sticky connections to components based on cookies or URL.
The following table shows the virtual server names to use for the external load balancer in the Oracle Identity Management high availability environment.
Table 12-6 Virtual Server Names for the External Load Balancer
Component | Virtual Server Name |
---|---|
Oracle Internet Directory | oid.example.com |
Oracle Directory Services Manager Console | admin.example.com |
Virtual Server Names
You should setup virtual server names for the high availability deployments. Ensure that the virtual server names are associated with IP addresses and are part of your Domain Name System (DNS). The computers on which Oracle Fusion Middleware is running must be able to resolve these virtual server names.
oid.example.com
This virtual server acts as the access point for all LDAP traffic to the Oracle Internet Directory servers in the directory tier. Traffic to both the SSL and non-SSL ports is configured. The clients access this service using the address oid.example.com:636 for SSL and oid.example.com:389 for non-SSL.
Monitor the heartbeat of the Oracle Internet Directory processes on OIDHOST1 and OIDHOST2. If an Oracle Internet Directory process stops on OIDHOST1 or OIDHOST2, or if either host is down, the load balancer must continue to route the LDAP traffic to the surviving computer.
Oracle Internet Directory High Availability
This section provides an introduction to Oracle Internet Directory and describes how to design and deploy a high availability environment for Oracle Internet Directory.
- About Oracle Internet Directory Component Architecture
Oracle Internet Directory is an LDAP store that can be used by Oracle components such as Directory Integration Platform, Oracle Directory Services Manager, JPS, and also by non-Oracle components. These components connect to Oracle Internet Directory using the LDAP or LDAPS protocols. - Understanding Oracle Internet Directory High Availability Concepts
This section provides conceptual information about using Oracle Internet Directory in a high availability two-node Cluster Configuration. - Oracle Internet Directory High Availability Configuration Steps
You can deploy Oracle Internet Directory in a High Availability configuration as part of a WebLogic Server domain. - Validating Oracle Internet Directory High Availability
Use theldapbind
command-line tool to ensure that you can connect to each OID instance and the LDAP Virtual Server. Theldapbind
tool enables you to determine whether you can authenticate a client to a server. - Oracle Internet Directory Failover and Expected Behavior
This section describes how to perform a failover of Oracle Internet Directory and Oracle RAC. - Troubleshooting Oracle Internet Directory High Availability
This section provides information that can help you troubleshoot OID high availability issues: - Additional Oracle Internet Directory High Availability Issues
This section describes issues for Oracle Internet Directory in a high availability environment.
About Oracle Internet Directory Component Architecture
Oracle Internet Directory is an LDAP store that can be used by Oracle components such as Directory Integration Platform, Oracle Directory Services Manager, JPS, and also by non-Oracle components. These components connect to Oracle Internet Directory using the LDAP or LDAPS protocols.
The Oracle directory replication server uses LDAP to communicate with an Oracle directory (LDAP) server instance. To communicate with the database, all components use OCI/Oracle Net Services. Oracle Directory Services Manager and the command-line tools communicate with the Oracle directory servers over LDAP.
An Oracle Internet Directory node consists of one or more directory server instances connected to the same directory store. The directory store—that is, the repository of the directory data—is an Oracle database.
An Oracle Internet Directory node includes the following major elements:
Table 12-7 An Oracle internet Directory Node
Element | Description |
---|---|
Oracle directory server instance |
Also called either an LDAP server instance or a directory server instance, it services directory requests through a single Oracle Internet Directory dispatcher process listening at specific TCP/IP ports. There can be more than one directory server instance on a node, listening on different ports. |
Oracle directory replication server |
Also called a replication server, it tracks and sends changes to replication servers in another Oracle Internet Directory system. There can be only one replication server on a node. You can choose whether to configure the replication server. If there are multiple instances of Oracle Internet Directory that use the same database, only one of them can be running replication. This is true even if the Oracle Internet Directory instances are on different nodes. The replication sever process is a process within Oracle Internet Directory. It only runs when replication is configured. For more information on Oracle Internet Directory replication, see Configuring Identity Management for Maximum High Availability.. |
Oracle Database Server |
Stores the directory data. Oracle strongly recommends that you dedicate a database for use by the directory. The database can reside on the same node as the directory server instances. |
OID Monitor (OIDMON) |
Initiates, monitors, and terminates the LDAP server and replication server processes. When you invoke process management commands, such as oidctl or Node Manager, or when you use Fusion Middleware Control to start or stop server instances, your commands are interpreted by this process. OIDMON also monitors servers and restarts them if they have stopped running for abnormal reasons. OIDMON starts a default instance of OIDLDAPD. If the default instance of OIDLDAPD is stopped using the OIDCTL command, then OIDMON stops the instance. When OIDMON is restarted by Node Manager (using All OID Monitor activity is logged in the file |
OID Control Utility (OIDCTL) |
Communicates with OID Monitor by placing message data in Oracle Internet Directory server tables. This message data includes configuration parameters required to run each Oracle directory server instance. Normally used from the command line only to stop and start the replication server. |
- Oracle Internet Directory Component Characteristics
Oracle Internet Directory, which is Oracle's LDAP store, is a C-based component that uses a database as its persistence store. It is a stateless process and stores all of the data and the majority of its configuration information in the back-end database. It uses Oracle Net Services to connect to the database.
Parent topic: Oracle Internet Directory High Availability
Oracle Internet Directory Component Characteristics
Oracle Internet Directory, which is Oracle's LDAP store, is a C-based component that uses a database as its persistence store. It is a stateless process and stores all of the data and the majority of its configuration information in the back-end database. It uses Oracle Net Services to connect to the database.
- Runtime Processes
Oracle Internet Directory has the following runtime processes: - Process Lifecycle
Node Manager is responsible for the direct start, stop, restart and monitoring of the daemon process, OIDMON (ORACLE_HOME/bin/oidmon). OIDMON is responsible for the process control of an Oracle Internet Directory instance. - Request Flow
Once the Oracle Internet Directory (OID) process starts up, clients access OID using the LDAP or LDAPS protocol. There is no affect on other running instances when an OID instance starts up - About Configuration Artifacts
The storage location requires a DB connect string.TNSNAMES.ORA
is stored in DOMAIN_HOME/config. The wallet is stored inDOMAIN_HOME/config/fmwconfig/components/OID/admin
(The DB ODS user password is stored in the wallet). - External Dependencies
Oracle Internet Directory uses an Oracle database to store configuration information as well as data. It uses the ODS schema to store this information. - Oracle Internet Directory Log File
Log files for Oracle Internet Directory are under the following directory:
Parent topic: About Oracle Internet Directory Component Architecture
Runtime Processes
Oracle Internet Directory has the following runtime processes:
-
OIDLDAPD: This is the main process for Oracle Internet Directory. OIDLDAPD consists of a dispatcher process and a server process. The dispatcher process spawns the OIDLDAPD server processes during startup. Each OIDLDAPD dispatcher process has its own SSL and non-SSL ports for receiving requests. Every OID instance has one dispatcher and one server process by default. The number of server processes spawned for an instance is controlled by the
orclserverprocs
attribute. -
OIDMON: OIDMON is responsible for the process control of an Oracle Internet Directory instance. This process starts, stops, and monitors Oracle Internet Directory. During startup OIDMON spawns the OIDLDAPD dispatcher process and the replication server process, if replication is configured for the instance.
-
Replication server process: This is a process within Oracle Internet Directory that runs only when replication is configured. The replication server process is spawned by OIDMON during startup.
-
Node Manager: Node Manager is a daemon process that monitors Oracle Fusion Middleware components, including Oracle Internet Directory.
Node Manager is responsible for the direct start, stop, restart and monitoring of OIDMON. It does not start or stop the server process directly.
Parent topic: Oracle Internet Directory Component Characteristics
Process Lifecycle
Node Manager is responsible for the direct start, stop, restart and monitoring of the daemon process, OIDMON (ORACLE_HOME/bin/oidmon). OIDMON is responsible for the process control of an Oracle Internet Directory instance.
Process Status Table
Oracle Internet Directory process information is maintained in the ODS_PROCESS_STATUS table in the ODS database user schema. OIDMON reads the contents of the table at a specified interval and acts upon the intent conveyed by the contents of that table. The interval is controlled by the value of the sleep command line argument used at OIDMON startup, and the default value is 10 seconds.
Starting and Stopping Oracle Internet Directory
An Oracle Internet Directory instance can be started and stopped using system component management scripts — startComponent.sh
and stopComponent.sh
.
Start Process
The start process for Oracle Internet Directory is:
-
Upon receiving the start command, Node Manager issues an oidmon start command with appropriate arguments.
-
OIDMON then starts all Oracle Internet Directory Server instances whose information in the ODS_PROCESS_STATUS table has state value 1 or 4 and COMPONENT_NAME, INSTANCE_NAME values matching the environment parameters set by Node Manager.
Stop Process
The stop process for Oracle Internet Directory is:
-
Upon receiving the stop command, Node Manager issues an oidmon stop command.
-
For each row in the ODS_PROCESS_STATUS table that matches the environment parameters COMPONENT_NAME, and INSTANCE_NAME, the oidmon stop command kills OIDMON, OIDLDAPD, and OIDREPLD processes and updates the state to 4.
Monitoring
Node Manager does not monitor server processes directly. Node Manager monitors OIDMON and OIDMON monitors the server processes. The events are:
-
When you start OIDMON through Node Manager, Node Manager starts OIDMON and ensures that OIDMON is up and running.
-
If OIDMON goes down for some reason, Node Manager brings it back up.
-
OIDMON monitors the status of the Oracle Internet Directory dispatcher process, LDAP server processes, and replication server process and makes this status available to Node Manager.
Parent topic: Oracle Internet Directory Component Characteristics
Request Flow
Once the Oracle Internet Directory (OID) process starts up, clients access OID using the LDAP or LDAPS protocol. There is no affect on other running instances when an OID instance starts up
Oracle Internet Directory listener/dispatcher starts a configured number of server processes at startup time. The number of server processes is controlled by the orclserverprocs attribute in the instance-specific configuration entry. The default value for orclserverprocs is 1. Multiple server processes enable OID to take advantage of multiple processor systems.
The OID dispatcher process sends the LDAP connections to the OID server process in a round robin fashion. The maximum number of LDAP connections accepted by each server is 1024 by default. This number can be increased by changing the attribute orclmaxldapconns in the instance-specific configuration entry, which has a DN of the form:
cn=componentname,cn=osdldapd,cn=subconfigsubentry
Database connections from each server process are spawned at server startup time, depending on the value set for the instance configuration parameters ORCLMAXCC and ORCLPLUGINWORKERS. The number of database connections spawned by each server equals ORCLMAXCC + ORCLPLUGINWORKERS + 2. The OID server processes communicate with the Oracle database server through Oracle Net Services. An Oracle Net Services listener/dispatcher relays the request to the Oracle database. For more information, see Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.
Parent topic: Oracle Internet Directory Component Characteristics
About Configuration Artifacts
The storage location requires a DB connect string. TNSNAMES.ORA
is stored in DOMAIN_HOME/config. The wallet is stored in DOMAIN_HOME/config/fmwconfig/components/OID/admin
(The DB ODS user password is stored in the wallet).
Parent topic: Oracle Internet Directory Component Characteristics
External Dependencies
Oracle Internet Directory uses an Oracle database to store configuration information as well as data. It uses the ODS schema to store this information.
The Oracle directory replication server uses LDAP to communicate with an Oracle directory (LDAP) server instance. To communicate with the database, all components use OCI/Oracle Net Services. Oracle Directory Services Manager and the command-line tools communicate with the Oracle directory servers over LDAP.
Parent topic: Oracle Internet Directory Component Characteristics
Oracle Internet Directory Log File
Log files for Oracle Internet Directory are under the following directory:
DOMAIN_HOME/servers/OID/logs/InstanceName/
Table shows Oracle Internet Directory processes and the log file name and location for the process.
Table 12-8 Locations of Oracle Internet Directory Process Log Files
Process | Log File Location |
---|---|
Directory server (oidldapd) |
00 is the instance number (00 by default) s stands for server PID is the server process identifier XXXX is a number from 0000 to orclmaxlogfilesconfigured. Once the orclmaxlogfilesconfigured value is reached, it starts over again from 0000. When it starts over, it truncates the file to 0 bytes.
|
LDAP dispatcher (oiddispd) |
00 is the instance number (00 by default) XXXX is a number from 0000 to orclmaxlogfilesconfigured |
OID Monitor (OIDMON) |
XXXX is a number from 0000 to orclmaxlogfilesconfigured |
Directory replication server (oidrepld) |
XXXX is a number from 0000 to orclmaxlogfilesconfigured |
For more information on using log files to troubleshoot Oracle Internet Directory, see Troubleshooting Oracle Internet Directory High Availability.
Parent topic: Oracle Internet Directory Component Characteristics
Understanding Oracle Internet Directory High Availability Concepts
This section provides conceptual information about using Oracle Internet Directory in a high availability two-node Cluster Configuration.
See Oracle Internet Directory Prerequisites for prerequisites and Oracle Internet Directory High Availability Configuration Steps to set up the two-node Cluster Configuration.
- Oracle Internet Directory High Availability Architecture
Learn about the Oracle Internet Directory Cluster Configuration high availability architecture in an active-active configuration. - Protection from Failures and Expected Behavior
This section discusses protection from different types of failure in an OID Cluster Configuration. - Oracle Internet Directory Prerequisites
This section describes prerequisites for setting up the OID high availability architecture.
Parent topic: Oracle Internet Directory High Availability
Oracle Internet Directory High Availability Architecture
Learn about the Oracle Internet Directory Cluster Configuration high availability architecture in an active-active configuration.
The Figure 12-1 shows the Oracle Internet Directory Cluster Configuration high availability architecture in an active-active configuration.
Figure 12-1 Oracle Internet Directory Cluster Configuration High Availability Architecture
![Description of Figure 12-1 follows Description of Figure 12-1 follows](img/ashia_dt_007.gif)
Description of "Figure 12-1 Oracle Internet Directory Cluster Configuration High Availability Architecture"
The Figure 12-1 shows Oracle Internet Directory (OID) in the directory tier in a Cluster Configuration high availability architecture. Clustering is set up at installation time. The load balancing router routes LDAP client requests to the two OID instances that are clustered on OIDHOST1
and OIDHOST2
.
Transparent Application Failover (TAF) is used to connect the OID instances with the Oracle RAC database that serves as the security metadata repository. The Oracle RAC database is configured in TNSNAMES.ORA
. High availability event notification is used for notification when an Oracle RAC instance becomes unavailable.
- Starting and Stopping the Cluster
In the Cluster Configuration, Node Manager (startComponent.sh
andstopComponent.sh
commands) start each OID instance. There is no affect on OID at startup. A new database connection spawns when OID starts. - Cluster-Wide Configuration Changes (OID)
Starting and Stopping the Cluster
In the Cluster Configuration, Node Manager (startComponent.sh
and stopComponent.sh
commands) start each OID instance. There is no affect on OID at startup. A new database connection spawns when OID starts.
When the cluster is stopped using Node Manager (stopComponent.sh
command), OID disconnects from the database and the OID server stops.
Parent topic: Oracle Internet Directory High Availability Architecture
Cluster-Wide Configuration Changes (OID)
When you deploy Oracle Internet Directory in a high availability configuration, all Oracle Internet Directory instances in the cluster share the same database. Any changes made to Oracle Directory Integration Platform on one Oracle Internet Directory node automatically propagate to all the Oracle Internet Directory instances in the cluster.
Directory Synchronization Profiles
Changes that you make to directory integration profiles on one Oracle Internet Directory node do not replicate automatically to other Oracle Internet Directory nodes in a default multimaster Oracle Internet Directory replication environment. You must copy changes from the primary node to the secondary nodes manually and do so on a periodic basis. By doing this, a directory synchronization profile can run on a secondary node if a problem occurs on the primary node.
Oracle Directory Integration Platform uses the parameter orcllastappliedchangenumber
. The value assigned to the lastchangenumber
attribute in a directory synchronization profile depends on the directory server on which Oracle Directory Integration Platform is running. In an active-active Oracle Directory Integration Platform configuration, you must manually update the lastchangenumber
attribute in all instances.
To synchronize directory provisioning profiles between the primary Oracle Internet Directory node and secondary nodes:
-
On the primary node, use the
ldifwrite
command to create an LDIF dump of the entries from this container:cn=subscriber profiles,cn=changelog subscriber,cn=oracle internet directory
-
Copy the LDIF dump to the secondary node.
-
Use the
ldapadd
command to add the profiles on the secondary node.
After you copy an export profile to a target node, you must update the lastchangenumber
attribute with the target node value. To update the value:
-
Disable the synchronization profile.
-
Get the value of the
lastchangenumber
attribute on the target node using theldapsearch
command. -
Use
ldapsearch
to get the LDIF dump of the profile entry. -
Use
ldapadd
to add the profile to the other Managed Server instance. -
Go to the Oracle Directory Integration Platform Admin console and select the profile. Select Edit. Select the Advanced tab then select Edit and Persist. Enter the value of the
lastchangenumber
attribute. Save the profile. -
Enable the synchronization profile.
Directory Provisioning Profiles
In a default multimaster Oracle Internet Directory replication environment, Oracle Directory Integration Platform is installed in the same location as the primary Oracle Internet Directory. The information and steps in this topic applies only when multimaster replication is set up.
If the primary node fails, event propagation stops for all profiles located on the node. Although the events are queued and not lost while the primary node is stopped, the events do not propagate to any applications that expect them. To ensure that events continue to propagate even when the primary node is down for the Version 1.0 and 2.0 profiles, the directory provisioning profiles must be copied to other secondary nodes.
However, copy directory provisioning profiles from the primary node to any secondary nodes immediately after an application is installed and before any user changes are made in Oracle Internet Directory.
To synchronize directory provisioning profiles between a primary node and any secondary nodes:
-
On the primary node, use the ldifwrite command to create an LDIF dump of the entries from this container:
cn=provisioning profiles,cn=changelog subscriber,cn=oracle internet directory
-
Copy the LDIF dump to the secondary node.
-
Use the
ldapadd
command to add the profiles on the secondary node.
Parent topic: Oracle Internet Directory High Availability Architecture
Protection from Failures and Expected Behavior
This section discusses protection from different types of failure in an OID Cluster Configuration.
- Oracle Internet Directory Process Failure
OIDMON monitors OID processes. If the OID process goes down, OIDMON tries to restart it. - Expected Client Application Behavior When Failure Occurs
Oracle Internet Directory server failure is usually transparent to OID clients as they continue to get routed through the load balancer. External load balancers are typically configured to perform a health check of OID processes. If a request is received before the load balancer detects process unavailability, clients application could receive a error. If the client application performs a retry, the load balancer should route it to a healthy OID instance and the request should be successful. - External Dependency Failure
This section describes the protection available for OID from database failure.
Oracle Internet Directory Process Failure
OIDMON monitors OID processes. If the OID process goes down, OIDMON tries to restart it.
Node Manager monitors OIDMON. If OIDMON goes down, Node Manager restarts OIDMON.
If you cannot start an OID process, the front-ending load balancing router detects failure of OID instances in the Cluster Configuration and routes LDAP traffic to surviving instances. In case of failure, the LDAP client retries the transaction. If the instance fails in the middle of a transaction, the transaction is not committed to the database. When the failed instance comes up again, the load balancing router detects this and routes requests to all the instances.
If an OID instance in the Cluster Configuration gets hung, the load balancing router detects this and routes requests to surviving instances.
If one OID instance in the two-node Cluster Configuration fails (or if one of the computers hosting an instance fails), the load balancing router routes clients to the surviving OID instance.
Parent topic: Protection from Failures and Expected Behavior
Expected Client Application Behavior When Failure Occurs
Oracle Internet Directory server failure is usually transparent to OID clients as they continue to get routed through the load balancer. External load balancers are typically configured to perform a health check of OID processes. If a request is received before the load balancer detects process unavailability, clients application could receive a error. If the client application performs a retry, the load balancer should route it to a healthy OID instance and the request should be successful.
In OID active-active configurations, if you are doing ldapadd operations through the LDIF file at the time of failover, your operation would fail even if you are doing this operation through a load balancer host and port. This is because OID is down for a fraction of a second. For most applications, this will not be an issue because most applications have the ability to retry the connection a fixed number of times.
Parent topic: Protection from Failures and Expected Behavior
External Dependency Failure
This section describes the protection available for OID from database failure.
By default, the tnsnames.ora
file configured in OID's ORACLE_INSTANCE ensures that OID's connections to the database are load balanced between the Oracle RAC database instances. For example, if an OID instance establishes four database connections, two connections are made to each database instance.
Oracle Internet Directory uses database high availability event notification to detect database node failure and to fail over to a surviving node.
If Transparent Application Failover (TAF) is configured, then upon a database instance failure, OID will fail over its database connections to the surviving database instance, which enables the LDAP search operations that were in progress during the failover to be continued.
If both TAF and high availability event notification are configured, TAF is used for failover and high availability event notifications are used only for logging the events. The high availability event notifications are logged in OIDLDAPD log file.
Oracle Internet Directory also has a mechanism to detect stale database connections, which enables OID to reconnect to the database.
If none of the database instances are available for a prolonged period, then the OID LDAP and REPL processes will automatically be shut down. However, OIDMON and Node Manager will continue to ping for the database instance availability and when the database becomes available, the OID processes (LDAP and REPL) are automatically restarted by OIDMON.
While all database instances are down, OIDMON continues to be up and an oid_instanceStatus(instanceName = 'instance-name')
command shows that OIDLDAPD instances are down. When a database instance becomes available, OIDMON restarts all configured OID instances.
All database failover induced activity for OID is recorded in the OIDMON log file.
Parent topic: Protection from Failures and Expected Behavior
Oracle Internet Directory Prerequisites
This section describes prerequisites for setting up the OID high availability architecture.
- Synchronizing the Time on Oracle Internet Directory Nodes
Before setting up OID in a high availability environment, you must ensure that the time on the individual OID nodes is synchronized. - Load Balancer Virtual Server Names for Oracle Internet Directory
When you deploy OID in a high availability configuration, Oracle recommends using an external load balancer to front-end OID instances and load balance requests between the OID instances.
Synchronizing the Time on Oracle Internet Directory Nodes
Before setting up OID in a high availability environment, you must ensure that the time on the individual OID nodes is synchronized.
Synchronize the time on all nodes using Greenwich Mean Time so that there is a discrepancy of no more than 250 seconds between them.
If OID Monitor detects a time discrepancy of more than 250 seconds between the two nodes, the OID Monitor on the node that is behind stops all servers on its node. To correct this problem, synchronize the time on the node that is behind in time. The OID Monitor automatically detects the change in the system time and starts the OID servers on its node.
If there are more than two nodes, the same behavior is followed. For example, assume that there are three nodes, where the first node is 150 seconds ahead of the second node, and the second node is 150 seconds ahead of the third node. In this case, the third node is 300 seconds behind the first node, so the OID Monitor will not start the servers on the third node until the time is synchronized.
Parent topic: Oracle Internet Directory Prerequisites
Load Balancer Virtual Server Names for Oracle Internet Directory
When you deploy OID in a high availability configuration, Oracle recommends using an external load balancer to front-end OID instances and load balance requests between the OID instances.
See Configuring Virtual Server Names and Ports for the Load Balancer.
Parent topic: Oracle Internet Directory Prerequisites
Oracle Internet Directory High Availability Configuration Steps
You can deploy Oracle Internet Directory in a High Availability configuration as part of a WebLogic Server domain.
Oracle recommends that you set up OID in a clustered deployment in which clustered OID instances access the same Oracle RAC database repository.
- Installing Oracle Fusion Middleware Components
This section describes how to install the required binaries for the Oracle WebLogic Server (WL_HOME) and Oracle Home for (ORACLE_HOME) for Oracle Identity Management. - Creating Oracle Internet Directory Schemas in the Repository Using RCU
This section describes the procedure to create schemas in the repository using Repository Creation Utility (RCU). - Configuring Oracle Internet Directory With a WebLogic Domain
In this configuration, OID and a WebLogic Server domain is configured on the first host and the second host. The OID instance on the second host joins the domain created on the first host.
Parent topic: Oracle Internet Directory High Availability
Installing Oracle Fusion Middleware Components
This section describes how to install the required binaries for the Oracle WebLogic Server (WL_HOME) and Oracle Home for (ORACLE_HOME) for Oracle Identity Management.
Oracle strongly recommends that you read the release notes for any additional installation and deployment considerations prior to starting the setup process.
- Installing Oracle WebLogic Server
This section describes the procedure to install Oracle WebLogic server. - Installing Oracle Internet Directory
This section describes the procedure to install Oracle Internet Directory.
Installing Oracle WebLogic Server
This section describes the procedure to install Oracle WebLogic server.
Parent topic: Installing Oracle Fusion Middleware Components
Installing Oracle Internet Directory
This section describes the procedure to install Oracle Internet Directory.
Ensure that the system, patch, kernel and other requirements are met. These are listed in the Preparing to Install in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
Note:
Ensure that the ORACLE_HOME that are using for installing OID is same as ORACLE_HOME used for installing weblogic server.On Linux platforms, if the /etc/oraInst.loc
file exists, verify that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for it. If the/etc/oraInst.loc
file does not exist, skip this step.
Start the installer for Oracle Fusion Middleware components.
Before starting the install, ensure that the following environment variables are not set:
-
LD_ASSUME_KERNEL
On the Specify Inventory Directory screen, do the following:
-
Enter
HOME/oraInventory
, where HOME is the home directory of the user performing the installation (this is the recommended location). -
Enter the OS group for the user performing the installation. Click Next.
For a UNIX install, follow the instructions on screen to run createCentralInventory.sh
as root.
Click OK.
Proceed as follows:
-
Start Oracle Internet Directory 12c Installer.
-
On the Welcome screen, click Next.
-
On the Auto Updates screen, select Skip Auto Updates and click Next.
-
On the Installation Location screen, browse and select the folder where you want to install Oracle Internet Directory. Click Next
Note:
Ensure that the ORACLE_HOME used for installing OID is same as ORACLE_HOME used for installing Weblogic server. -
On the Installation Type screen, Based on your requirement, Select either of the option — Standalone Oracle Internet Directory Server (Managed Independently of WebLogic server) or Collocated Oracle Internet Directory Server (Managed through Weblogic server) . ClickNext.
-
On the JDK Selection screen, browse and select jdk8 folder and click Next.
-
On the Prerequisite Checks ensure that all the prerequisites are met, without any warnings. Click Next.
-
On the Installation Summary screen, click Install.
-
Click Finish.
Parent topic: Installing Oracle Fusion Middleware Components
Creating Oracle Internet Directory Schemas in the Repository Using RCU
This section describes the procedure to create schemas in the repository using Repository Creation Utility (RCU).
Configuring Oracle Internet Directory With a WebLogic Domain
In this configuration, OID and a WebLogic Server domain is configured on the first host and the second host. The OID instance on the second host joins the domain created on the first host.
- Oracle Internet Directory Component Names Assigned by Oracle Identity Management Installer
When you configure OID using the Config Wizard, the default instance that the installer assigns to the OID instance isoid1
. You cannot change this name. - Configuring Oracle Internet Directory on OIDHOST1
Ensure that the schema database is running and that RCU has been used to seed the ODS database schema, then follow these steps to configure the OID instance on OIDHOST1: - Configuring Oracle Internet Directory on OIDHOST2
Ensure that the OID repository is running and then follow these steps to configure the OID instance on OIDHOST2:
Oracle Internet Directory Component Names Assigned by Oracle Identity Management Installer
When you configure OID using the Config Wizard, the default instance that the installer assigns to the OID instance is oid1
. You cannot change this name.
The instance-specific configuration entry for this OID instance is cn=oid1, cn=osdldapd, cn=subconfigsubentry
.
If you perform a second OID installation on another computer and that OID instance uses the same database as the first instance, the installer detects the previously installed OID instance on the other computer using the same Oracle database, so it gives the second OID instance a component name of oid2
.
The instance-specific configuration entry for the second OID instance is cn=oid2, cn=osdldapd, cn=subconfigsubentry
. Any change of properties in the entry cn=oid2, cn=osdldapd, cn=subconfigsubentry
will not affect the first instance (oid1)
.
If a third OID installation is performed on another computer and that instance uses the same database as the first two instances, the installer gives the third OID instance a component name of oid3, and so on for additional instances on different hosts that use the same database.
Note that the shared configuration for all OID instances is cn=dsaconfig, cn=configsets,cn=oracle internet directory
. Any change in this entry will affect all the instances of OID.
Configuring Oracle Internet Directory on OIDHOST1
Ensure that the schema database is running and that RCU has been used to seed the ODS database schema, then follow these steps to configure the OID instance on OIDHOST1:
Validating Oracle Internet Directory High Availability
Use the ldapbind
command-line tool to ensure that you can connect to each OID instance and the LDAP Virtual Server. The ldapbind
tool enables you to determine whether you can authenticate a client to a server.
Note:
See the Configuring Your Environment section of Oracle Fusion Middleware Reference for Oracle Identity Management for a list of the environment variables you must set before using theldapbind
command.
For non-SSL:
ldapbind -h oidhost1.example.com -p 3060 -D "cn=orcladmin" -q ldapbind -h oidhost2.example.com -p 3060 -D "cn=orcladmin" -q ldapbind -h oid.example.com -p 3060 -D "cn=orcladmin" -q
Note:
The -q option prompts the user for a password. LDAP tools are modified to disable the options -w password and -P password when the environment variable LDAP_PASSWORD_PROMPTONLY is set to TRUE or 1. Use this feature whenever possible.For SSL:
ldapbind -h oidhost1.example.com -p 3131 -D "cn=orcladmin" -q -U 1 ldapbind -h oidhost2.example.com -p 3131 -D "cn=orcladmin" -q -U 1 ldapbind -h oid.example.com -p 3131 -D "cn=orcladmin" -q -U 1
where -U is an optional argument used to specify the SSL authentication mode. These are the valid values for the SSL authentication mode:
-
1 = No authentication required
-
2 = One way authentication required. With this option, you must also supply a wallet location (-W "file:/home/my_dir/my_wallet") and wallet password (-P wallet_password).
-
3 = Two way authentication required. With this option, you must also supply a wallet location (-W "file:/home/my_dir/my_wallet") and wallet password (-P wallet_password).
For more information about the ldapbind
command, see the ldapbind section in Oracle Fusion Middleware Reference for Oracle Identity Management.
For information about setting up SSL for OID, see Configuring Secure Sockets Layer (SSL) in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory manual.
WebLogic Server Administration Console:
http://oidhost1.example.com:7001/console
Oracle Enterprise Manager Fusion Middleware Console:
http://oidhost1.example.com:7001/em
Parent topic: Oracle Internet Directory High Availability
Oracle Internet Directory Failover and Expected Behavior
This section describes how to perform a failover of Oracle Internet Directory and Oracle RAC.
This section includes the following topics:
- Performing Oracle Internet Directory Failover
This procedure describes the steps to be followed to perform Oracle Internet Directory failover. - Performing an Oracle RAC Failover
Theorclfailoverenabled
attribute is a configuration entry("cn=configset,cn=oidmon,cn=subconfigsubentry")
that configures failover for Oracle Internet Directory processes. This attribute specifies the failover time in minutes before the OID Monitor will start failed processes on a surviving node. The default failover time is 5 minutes. A value of zero (0) specifies that Oracle Internet Directory processes will not fail over to another node.
Parent topic: Oracle Internet Directory High Availability
Performing Oracle Internet Directory Failover
This procedure describes the steps to be followed to perform Oracle Internet Directory failover.
Performing an Oracle RAC Failover
The orclfailoverenabled
attribute is a configuration entry ("cn=configset,cn=oidmon,cn=subconfigsubentry")
that configures failover for Oracle Internet Directory processes. This attribute specifies the failover time in minutes before the OID Monitor will start failed processes on a surviving node. The default failover time is 5 minutes. A value of zero (0) specifies that Oracle Internet Directory processes will not fail over to another node.
Parent topic: Oracle Internet Directory Failover and Expected Behavior
Troubleshooting Oracle Internet Directory High Availability
This section provides information that can help you troubleshoot OID high availability issues:
- Log files for OID are in directory:
DOMAIN_HOME/servers/OID/logs/InstanceName
-
The order in which log files should be examined when troubleshooting is:
-
oidmon-xxx.log
-
oiddispd01-xxxx.log
-
oidldapd01s-xxxx.log
-
-
This section shows some of the error messages that may be related to high availability, and their meaning:
Error: ORA-3112, ORA-3113 errors in the log file
Cause: one of the database node is down, OID connects again to surviving node.
Action: See why database node went down or Oracle process got killed
Error: Failing Over...Please stand by in the log file
Cause: OID server received a notification from the Oracle process that one of the database node is down. OID will connect to the surviving node.
-
If the failover is successful you would see this message:
Failover ended...resuming services.
-
If the failover was not successful, you would see these errors:
- Tried 10 times, now quitting from failover function...
-
Bad Failover Event:
-
Forcing Failover abort as setting of DB parameters for the session failed
-
-
If high availability event notification is enabled, you would see a message similar to the following:
HA Callback Event Thread Id: 8 Event type: 0 HA Source: OCI_HA_INSTANCE Host name: dbhost1 Database name: orcl Instance name: orcl1 Timestamp: 14-MAY-09 03.25.24 PM -07:00 Service name: orcl.example.com HA status: DOWN - TAF Capable
-
If TAF is disabled, HA status will be shown as
DOWN.
Action: See why database node went down.
Error: Time Difference of at least 250 sec found between node1 and node2.
Cause: There is time difference between the two nodes
Action: Synchronize the system time.
Error: Node=% did not respond for configured %d times, Failing over...
Cause: One of the OID nodes (oidmon) is not responding.
Action: See if the node is alive or OIDMON process is running.
Related Topics
Parent topic: Oracle Internet Directory High Availability
Additional Oracle Internet Directory High Availability Issues
This section describes issues for Oracle Internet Directory in a high availability environment.
This section describes issues for Oracle Internet Directory in a high availability environment.
See Changing the Password of the ODS Schema Used by Oracle Internet Directory
- Changing the Password of the ODS Schema Used by Oracle Internet Directory
You can change the OID database schema password (that is, the password of the ODS user in the database) using the Oracle Internet Directory Database Password Utility (oidpasswd) from OIDHOST1 (Where AdminServer is installed). However, since the ODS schema password is stored in a password wallet under the DOMAIN_HOME on each host. This is propagated from OIDHOST1 to all other hosts automatically by Weblogic Domain Framework.
Parent topic: Oracle Internet Directory High Availability
Changing the Password of the ODS Schema Used by Oracle Internet Directory
You can change the OID database schema password (that is, the password of the ODS user in the database) using the Oracle Internet Directory Database Password Utility (oidpasswd) from OIDHOST1 (Where AdminServer is installed). However, since the ODS schema password is stored in a password wallet under the DOMAIN_HOME on each host. This is propagated from OIDHOST1 to all other hosts automatically by Weblogic Domain Framework.
oidpasswd connect=database-connection-string change_oiddb_pwd=true
Oracle Directory Integration Platform High Availability
This section describes how to design and deploy a high availability environment for Oracle Directory Integration Platform (ODIP).
- Understanding Oracle Directory Integration Platform Component Architecture
Oracle Directory Integration Platform is a J2EE application that enables you to integrate your applications and directories, including third-party LDAP directories, with an Oracle back-end directory: Oracle Internet Directory, Oracle Unified Directory, and Oracle Directory Server Enterprise Edition. - Understanding Oracle Directory Integration Platform High Availability Concepts
This section describes the Oracle Directory Integration Platform high availability concepts. - Configuring Oracle Directory Integration Platform for High Availability
You can use Oracle Internet Directory or Oracle Unified Directory as the as the back-end directory to configure Oracle Directory Integration Platform high availability. - About Retrieving Changes from Connected Directories
- Understanding Oracle Directory Integration Platform Failover and Expected Behavior
In a high availability environment, you deploy the Oracle Directory Integration Platform application on a WebLogic Server cluster that comprises at least two WebLogic instances. - Troubleshooting Oracle Directory Integration Platform High Availability
This section describes how to manage issues involving Oracle Directory Integration Platform high availability.
Understanding Oracle Directory Integration Platform Component Architecture
Oracle Directory Integration Platform is a J2EE application that enables you to integrate your applications and directories, including third-party LDAP directories, with an Oracle back-end directory: Oracle Internet Directory, Oracle Unified Directory, and Oracle Directory Server Enterprise Edition.
Note:
Oracle Directory Integration Platform does not support Oracle Directory Server Enterprise Edition in high availability mode in this release.See Introduction to Oracle Directory Integration Platform in Oracle Fusion Middleware Administering Oracle Directory for more on Oracle Directory Integration Platform architecture.
Parent topic: Oracle Directory Integration Platform High Availability
Understanding Oracle Directory Integration Platform High Availability Concepts
This section describes the Oracle Directory Integration Platform high availability concepts.
- About Oracle Directory Integration Platform High Availability Architecture (OID Back-End)
Learn about the Oracle Directory Integration Platform high availability architecture with Oracle Internet Directory as the back-end directory. - About Oracle Directory Integration Platform High Availability Architecture (OUD Back-End)
This section describes the Oracle Directory Integration Platform high availability architecture with Oracle Unified Directory (OUD ) as the back-end directory. - Protection from Failures and Expected Behavior
This section describes protection from different types of failure in an Oracle Directory Integration Platform active-active cluster
Parent topic: Oracle Directory Integration Platform High Availability
About Oracle Directory Integration Platform High Availability Architecture (OID Back-End)
Learn about the Oracle Directory Integration Platform high availability architecture with Oracle Internet Directory as the back-end directory.
Figure 12-2 Oracle Directory Integration Platform with Oracle Internet Directory (Back-End Directory) in a High Availability Architecture
![This figure describes Oracle Directory Integration Platform with Oracle Internet Directory (Back-End Directory) in a High Availability Architecture. This figure describes Oracle Directory Integration Platform with Oracle Internet Directory (Back-End Directory) in a High Availability Architecture.](img/ha_oid.png)
In Figure 12-2 , Connected Directory 1 and Connected Directory 2 replicate information with each other. A load balancing router routes requests to the Connected Directories.
The Application Tier includes the ODIPHOST1
and ODIPHOST2
computers.
ODIP1
and ODIP2
go through the load balancer when they must communicate with the Connected Directories.
On ODIPHOST1
, the following installations are performed:
-
An Oracle Directory Integration Platform instance is installed (
ODIP1
) on the Managed Server. -
A Quartz Scheduler is installed on
ODIP1
by default. It connects to the Oracle RAC database using a WebLogic multi data source. The Quartz Scheduler invokes EJBs that do the actual work; if the EJB fails, the Quartz Scheduler marks the job as failed and reschedules it to run at later time by another EJB. -
An Administration Server is installed. Under normal operations, this is the active Administration Server.
On ODIPHOST2
, the following installations are performed:
-
An Oracle Directory Integration Platform instance is installed (
ODIP2
) on the Managed Server. -
A Quartz Scheduler is installed on
ODIP2
by default. Quartz Scheduler connects to the Oracle RAC database using a WebLogic multi data source. -
An Administration Server is installed. Under normal operations, this is the passive Administration Server instance. You make this Administration Server active if the Administration Server on
ODIPHOST1
becomes unavailable.
The Oracle Directory Integration Platform instances on the ODIPHOST1
and ODIPHOST2
Managed Servers are configured as a cluster.
A load balancer is set up for the back-end directories OIDHOST1
and OIDHOST2
. The load balancer routes requests to either OIDHOST1 or OIDHOST2.
Note:
When you use a RAC database, multi data source is used with Oracle Directory Integration Platform to protect the instances from RAC failure.About Starting and Stopping the Cluster
By default, the WebLogic Server starts, stops, and monitors the applications and Oracle Directory Integration Platform leverages the high availability features of the underlying clusters. If there is a hardware or other failure, session state is available to other cluster nodes that can resume the work of the failed node.
Node Manager monitors the WebLogic servers. If failure occurs, Node Manager restarts the WebLogic Server.
See General Node Manager Configuration in Oracle Fusion Middleware Administering Node Manager for Oracle WebLogic Server.
Cluster-Wide Configuration Changes (OID)
When you deploy Oracle Internet Directory in a high availability configuration, all Oracle Internet Directory instances in the cluster share the same database. Any changes made to Oracle Directory Integration Platform on one Oracle Internet Directory node automatically propagate to all the Oracle Internet Directory instances in the cluster.
Directory Synchronization Profiles
Changes that you make to directory integration profiles on one Oracle Internet Directory node do not replicate automatically to other Oracle Internet Directory nodes in a default multimaster Oracle Internet Directory replication environment. You must copy changes from the primary node to the secondary nodes manually and do so on a periodic basis. By doing this, a directory synchronization profile can run on a secondary node if a problem occurs on the primary node.
Oracle Directory Integration Platform uses the parameter orcllastappliedchangenumber
. The value assigned to the lastchangenumber
attribute in a directory synchronization profile depends on the directory server on which Oracle Directory Integration Platform is running. In an active-active Oracle Directory Integration Platform configuration, you must manually update the lastchangenumber
attribute in all instances.
To synchronize directory provisioning profiles between the primary Oracle Internet Directory node and secondary nodes:
-
On the primary node, use the
ldifwrite
command to create an LDIF dump of the entries from this container:cn=subscriber profiles,cn=changelog subscriber,cn=oracle internet directory
-
Copy the LDIF dump to the secondary node.
-
Use the
ldapadd
command to add the profiles on the secondary node.
After you copy an export profile to a target node, you must update the lastchangenumber
attribute with the target node value. To update the value:
-
Disable the synchronization profile.
-
Get the value of the
lastchangenumber
attribute on the target node using theldapsearch
command. -
Use
ldapsearch
to get the LDIF dump of the profile entry. -
Use
ldapadd
to add the profile to the other Managed Server instance. -
Go to the Oracle Directory Integration Platform Admin console and select the profile. Select Edit. Select the Advanced tab then select Edit and Persist. Enter the value of the
lastchangenumber
attribute. Save the profile. -
Enable the synchronization profile.
Directory Provisioning Profiles
In a default multimaster Oracle Internet Directory replication environment, Oracle Directory Integration Platform is installed in the same location as the primary Oracle Internet Directory. The information and steps in this topic applies only when multimaster replication is set up.
If the primary node fails, event propagation stops for all profiles located on the node. Although the events are queued and not lost while the primary node is stopped, the events do not propagate to any applications that expect them. To ensure that events continue to propagate even when the primary node is down for the Version 1.0 and 2.0 profiles, the directory provisioning profiles must be copied to other secondary nodes.
However, copy directory provisioning profiles from the primary node to any secondary nodes immediately after an application is installed and before any user changes are made in Oracle Internet Directory.
To synchronize directory provisioning profiles between a primary node and any secondary nodes:
-
On the primary node, use the ldifwrite command to create an LDIF dump of the entries from this container:
cn=provisioning profiles,cn=changelog subscriber,cn=oracle internet directory
-
Copy the LDIF dump to the secondary node.
-
Use the
ldapadd
command to add the profiles on the secondary node.
About Oracle Directory Integration Platform High Availability Architecture (OUD Back-End)
This section describes the Oracle Directory Integration Platform high availability architecture with Oracle Unified Directory (OUD ) as the back-end directory.
Figure 12-3 Oracle Directory Integration Platform with Oracle Unified Directory (Back-End Directory) in a High Availability Architecture
![This figure describes the Oracle Directory Integration Platform with Oracle Unified Directory (Back-End Directory) in a High Availability Architecture. This figure describes the Oracle Directory Integration Platform with Oracle Unified Directory (Back-End Directory) in a High Availability Architecture.](img/ha_oud.png)
Figure 12-3, Connected Directory 1 and Connected Directory 2 replicate information with each other. A load balancing router routes requests to the Connected Directories.
The Application Tier includes the ODIPHOST1
and ODIPHOST2
computers.
On ODIPHOST1
, the following installations are performed:
-
An Oracle Directory Integration Platform instance is installed (
ODIP1
) on the Managed Server.ODIP1
goes through the load balancer for connected directories when it must connect to them. -
The Quartz Scheduler is installed. It goes through the load balancer for the back-end directories.
-
An Administration Server is installed. Under normal operations, this is the active Administration Server.
On ODIPHOST2
, the following installations are performed:
-
An ODIP instance is installed (
ODIP2
) on the Managed Server.ODIP2
goes through the load balancer for connected directories when it must connect to them. -
The Quartz Scheduler is installed. It goes through the load balancer for backend directories.
-
An Administration Server is installed. Under normal operations, this is the passive Administration Server instance. You make this Administration Server active if the Administration Server on
ODIPHOST1
becomes unavailable.
The Oracle Directory Integration Platform instances on the ODIPHOST1
and ODIPHOST2
Managed Servers are configured as a cluster.
A load balancer is set up for the back-end directories OUDHOST1
and OUDHOST2
. The load balancer routes requests to either OUDHOST1
or OUDHOST2
.
Cluster-Wide Configuration Changes (OUD)
Oracle Unified Directory supports cluster-wide configuration changes. All Oracle Unified Directory instances that are part of the same replication topology share the same content. Any changes made to Oracle Directory Integration Platform on one Oracle Unified Directory node automatically propagate to all Oracle Unified Directory instances in the replication topology.
Protection from Failures and Expected Behavior
This section describes protection from different types of failure in an Oracle Directory Integration Platform active-active cluster
About Process Failure
In a high availability environment, you deploy the Oracle Directory Integration Platform application to a cluster that comprises at least two Oracle WebLogic instances.
By default, the Oracle Directory Integration Platform application leverages high availability features of the underlying WebLogic clusters. When you deploy Oracle Directory Integration Platform, the Quartz scheduler starts with a clustering option. Depending on the load on the node, the scheduler then runs the job on any available nodes in the cluster. If hardware or other failures occur on one or more nodes, the Quartz scheduler runs the jobs on available nodes.
Also, Node Manager monitors WebLogic servers. In case of failure, Node Manager restarts the WebLogic server.
Within the Oracle Directory Integration Platform application, the Quartz Scheduler invokes the Provisioning or Synchronization EJBs that do the actual work. As soon as the Quartz scheduler invokes an EJB, it tags that EJB as running the job. If the EJB fails, the Quartz scheduler marks the job as failed and reschedules it to run later by another EJB.
Parent topic: Protection from Failures and Expected Behavior
About Updating the Oracle Directory Integration Platform Server Configuration
If the back-end server is not accessed or cannot be accessed through a load balancer, Oracle Directory Integration Platform failover is not transparent.
This scenario requires manual intervention because the information to connect to the back-end directory is local to each Oracle Directory Integration Platform instance.
You must run the manageDIPServerConfig
utility to update the Oracle back-end directory (Oracle Internet Directory and Oracle Unified Directory) host
and port
parameters for all of the Oracle Directory Integration Platform instances.
See manageDIPServerConfig Utility in Oracle Fusion Middleware Administering Oracle Directory Integration Platform.
Parent topic: Protection from Failures and Expected Behavior
About External Dependency Failure
Oracle Directory Integration Platform requires the back-end repository, Oracle Internet Directory, Oracle Unified Directory, Credential Store Framework, and the WebLogic Managed Server to be available during startup.
It fails to start if any one of these elements are unavailable.
Parent topic: Protection from Failures and Expected Behavior
Configuring Oracle Directory Integration Platform for High Availability
You can use Oracle Internet Directory or Oracle Unified Directory as the as the back-end directory to configure Oracle Directory Integration Platform high availability.
- Configuring High Availability for an Oracle Internet Directory Back-End Server
Use the steps in the following order to configure Oracle Internet Directory (back-end directory) for Oracle Directory Integration Platform high availablity. - Configuring High Availability for an Oracle Unified Directory Back-End Server
Use the steps in the following order to configure Oracle Unified Directory (back-end directory) for Oracle Directory Integration Platform high availability.
Parent topic: Oracle Directory Integration Platform High Availability
Configuring High Availability for an Oracle Internet Directory Back-End Server
Use the steps in the following order to configure Oracle Internet Directory (back-end directory) for Oracle Directory Integration Platform high availablity.
-
Before You Configure Oracle Directory Integration High Availability (OID)
-
Configuring Oracle Directory Integration Platform on ODIPHOST1 (OID)
-
Configuring Oracle Directory Integration Platform for Oracle Internet Directory (OIDHOST1)
-
Configuring Oracle Directory Integration Platform on ODIPHOST2 (OID)
- Before You Configure Oracle Directory Integration High Availability (OID)
- Configuring Oracle Directory Integration Platform on ODIPHOST1 (OID)
- Configuring Oracle Directory Integration Platform for Oracle Internet Directory (OIDHOST1)
You must configure Oracle Directory Integration Platform for Oracle Internet Directory onOIDHOST1
instance. - Configuring Oracle Directory Integration Platform on ODIPHOST2 (OID)
Before You Configure Oracle Directory Integration High Availability (OID)
Complete the following before you configure Oracle Directory Integration Platform high availability with Oracle Internet Directory as the back-end directory:
-
Ensure that Oracle Internet Directory is configured for high availability, as described in Oracle Internet Directory High Availability Configuration Steps.
-
Oracle WebLogic Server and Oracle Directory Integration Platform is installed across all nodes (
ODIPHOST1
andODIPHOST2
).
Configuring Oracle Directory Integration Platform on ODIPHOST1 (OID)
ODIPHOST1
:
Configuring Oracle Directory Integration Platform for Oracle Internet Directory (OIDHOST1)
You must configure Oracle Directory Integration Platform for Oracle Internet Directory on OIDHOST1
instance.
Configuring High Availability for an Oracle Unified Directory Back-End Server
Use the steps in the following order to configure Oracle Unified Directory (back-end directory) for Oracle Directory Integration Platform high availability.
- Before You Configure Oracle Directory Integration High Availability (OUD)
- Configuring Oracle Directory Integration Platform on ODIPHOST1 (OUD)
- Configuring Oracle Directory Integration Platform for Oracle Unified Directory (OUDHOST1)
You must configure Oracle Directory Integration Platform for Oracle Unified Directory onOIDHOST1
instance. - Configuring Oracle Directory Integration Platform on ODIPHOST2 (OUD)
Before You Configure Oracle Directory Integration High Availability (OUD)
Complete the following before you configure Oracle Directory Integration Platform high availability with Oracle Unified Directory as the back-end directory:
-
Ensure that you install Oracle Unified Directory, see Installing the Oracle Unified Directory Software in Oracle Fusion Middleware Installing Oracle Unified Directory.
When you set up an Oracle Unified Directory server instance using either the graphical user interface (GUI) or the command-line interface (CLI), ensure that you select the Enable for DIP option to enable the server instance for Oracle Directory Integration Platform.
-
Ensure that Oracle Unified Directory is configured for high availability. See Understanding Oracle Unified Directory High Availability Deployments in Oracle Fusion Middleware Administering Oracle Unified Directory.
-
Ensure that you have created the Oracle Unified Directory Suffixes for Oracle Directory Integration Platform. See Creating Oracle Unified Directory Suffixes in Oracle Fusion Middleware Administering Oracle Directory Integration Platform.
-
Ensure that the change log is enabled. See Enabling External Change Login Oracle Fusion Middleware Administering Oracle Directory Integration Platform.
-
Oracle WebLogic Server and Oracle Directory Integration Platform is installed across all nodes (
ODIPHOST1
andODIPHOST2
).
Configuring Oracle Directory Integration Platform on ODIPHOST1 (OUD)
ODIPHOST1
for Oracle Unified Directory as the back-end directory:
Configuring Oracle Directory Integration Platform for Oracle Unified Directory (OUDHOST1)
You must configure Oracle Directory Integration Platform for Oracle Unified Directory on OIDHOST1
instance.
About Retrieving Changes from Connected Directories
Oracle Directory Integration Platform uses readers to retrieve changes from connected directories. However, there are some connectors that you cannot use for load-balanced directories. This section describes how Oracle Directory Integration Platform supports the use of several instances of a connected directory for import profiles.
Failing Over Oracle Directory Server Enterprise Edition Manually
Oracle Directory Integration Platform does not support transparent failover from one Oracle Directory Server Enterprise Edition (ODSEE) Managed Server (WLS_ODSEE1) to another ODSEE server (WLS_ODSEE2). Even if you replicate ODSEE Managed Server instances, the change numbers may not be identical on both ODSEE Managed Servers for the same update. If Oracle Directory Integration Platform fails over transparently from WLS_ODSEE1 to WLS_ODSEE2, ODIP may replay changes or miss changes each time it switches.
Oracle Unified Directory
When you use Oracle Unified Directory with Iplanet Reader and Iplanet Writer, Oracle Unified Directory does not support transparent failover from one Oracle Unified Directory instance to another because, as with ODSEE Server, change numbers may not be synchronized. However, you can configure your profile to use an Oracle Unified Directory connector that does support it.
To configure your profile, you must set the reader to oracle.ldap.odip.gsi.OudCookieReader
. You must configure this attribute at creation time; you cannot configure it for existing profiles.
-
Go to the directory
ORACLE_HOME/ldap/odi/conf
and edit the fileiplanetimp.cfg.master
-
Replace the line
Reader: oracle.ldap.odip.gsi.IPlanetReader
with the lineoracle.ldap.odip.gsi.OudCookieReader
To failover transparently from one Oracle Unified Directory instance to another, the reader uses the External Change Log cookie that Oracle Unified Directory provides. The last applied change number contains a cookie but no longer contains a change number.
See Using the External Change Log in Oracle Fusion Middleware Administering Oracle Unified Directory for more information on Oracle Unified Directory external change log cookies.
Novell eDirectory
Because the Oracle Directory Integration Platform reader for Novell eDirectory is based on timestamps, clocks on all instances must be synchronized.
OpenLDAP
Because Oracle Directory Integration Platform reader for OpenLDAP is based on timestamps, clocks on all instances must be synchronized.
IBM Tivoli Directory Server
Oracle does not support IBM Tivoli by means of the load balancer.
Oracle Internet Directory
If you configure Oracle Internet Directory replication so that change numbers are identical on all Oracle Internet Directory instances that you target, the Oracle Internet Directory instances can failover transparently. If you do not set up this configuration, transparent failover is not supported.
Parent topic: Oracle Directory Integration Platform High Availability
Understanding Oracle Directory Integration Platform Failover and Expected Behavior
In a high availability environment, you deploy the Oracle Directory Integration Platform application on a WebLogic Server cluster that comprises at least two WebLogic instances.
By default, the Oracle Directory Integration Platform application leverages high availability features of the underlying WebLogic clusters. In case of hardware or other failures, session state is available to other cluster nodes that can resume the work of the failed node.
In addition, in a high availability environment, Node Manager is configured to monitor the WebLogic servers. In case of failure, Node Manager restarts the WebLogic Server.
If an instance of Oracle Internet Directory fails, the load balancer redirects to the surviving instance of Oracle Internet Directory and the Oracle RAC database. If Oracle Unified Directory fails, the load balancer redirects to the surviving instance of Oracle Unified Directory.
In case of a database instance failure, the surviving Oracle RAC node takes over any remaining processes. There may be innocuous errors in the Managed Servers logs during an Oracle RAC failover; see Troubleshooting Oracle Directory Integration Platform High Availability.
Parent topic: Oracle Directory Integration Platform High Availability
Troubleshooting Oracle Directory Integration Platform High Availability
This section describes how to manage issues involving Oracle Directory Integration Platform high availability.
- Managed Server Log File Exception May Occur During an Oracle RAC Failover
- Node Manager Fails to Start
- Error Messages May Appear After Starting Node Manager
- Configuration Changes Do Not Automatically Propagate to All Oracle Directory Integration Platform Instances in a Highly Available Topology
- An Operation Cannot Be Completed for Unknown Errors Message Appears
Parent topic: Oracle Directory Integration Platform High Availability
Managed Server Log File Exception May Occur During an Oracle RAC Failover
During an Oracle RAC failover, exceptions similar to the ones below are seen in the Managed Server log files running the Oracle Directory Integration Platform application. These errors are thrown when the multi data sources configured on the WebLogic Server platform try to verify the health of the Oracle RAC database instances during failover. These are innocuous errors that you can ignore. The Oracle Directory Integration Platform application recovers and begins to operate normally after a lag of one or two minutes. During an Oracle RAC failover, there will be no Oracle Directory Integration Platform down time if one Oracle RAC instance is running at all times.
RuntimeException: [2008-11-21T00:11:10.915-08:00] [wls_ods] [ERROR] [] [org.quartz.impl.jdbcjobstore.JobStoreTX] [tid: 25] [userId: <anonymous>] [ecid: 0000Hqy69UiFW7V6u3FCEH199aj0000009,0] [APP: DIP] ClusterManager: Error managing cluster: Failed to obtain DB connection from data source 'schedulerDS': java.sql.SQLException: Could not retrieve datasource via JNDI url 'jdbc/schedulerDS' java.sql.SQLException: Cannot obtain connection: driverURL = jdbc:weblogic:pool:schedulerDS, props = {EmulateTwoPhaseCommit=false, connectionPoolID=schedulerDS, jdbcTxDataSource=true, LoggingLastResource=false, dataSourceName=schedulerDS}.[[ Nested Exception: java.lang.RuntimeException: Failed to setAutoCommit to true for pool connection AuthenticationException while connecting to OID: [2008-11-21T00:12:08.812-08:00] [wls_ods] [ERROR] [DIP-10581] [oracle.dip] [tid: 11] [userId: <anonymous>] [ecid: 0000Hqy6m54FW7V6u3FCEH199apO000000,0] [APP: DIP] DIP was not able to get the context with the given details {0}[[ javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]
Most exceptions are related to the scheduler or LDAP, for example:
-
Could not retrieve datasource via JNDI url 'jdbc/schedulerDS' java.sql.SQLException
-
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]
Node Manager Fails to Start
If the Node Manager fails to start, ensure that you have copied the nodemanager.domains
file from ODIPHOST1
to ODIPHOST2
:
WL_HOME/common/nodemanager/nodemanager.domains
Error Messages May Appear After Starting Node Manager
If you see the following error message after starting Node Manager, follow the procedure described after the error message:
<Dec 15, 2008 8:40:05 PM> <Warning> <Uncaught exception in server handler: javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was received from stbee21.example.com - 152.68.64.2155. Check the peer to determine why it rejected the certificate chain (trusted CA configuration, hostname verification). SSL debug tracing may be required to determine the exact reason the certificate was rejected.> javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was received from stbee21.example.com - 152.68.64.215. Check the peer to determine why it rejected the certificate chain (trusted CA configuration, hostname verification). SSL debug tracing may be required to determine the exact reason the certificate was rejected.
-
If you have not already done so, click Lock & Edit in the Change Center of the Administration Console.
-
In the left pane of the Console, expand Servers and AdminServer (admin).
-
Select the Configuration > SSL > Advanced Link.
-
Select None for Hostname Verification.
-
Click Save to save the setting.
-
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
-
Restart all servers.
(Optional) Enter an example to illustrate your reference here.
-
If you have not already done so, click Lock & Edit in the Change Center of the Administration Console.
-
In the left pane of the Console, expand Servers and the name of the server that is running in ADMIN mode.
-
Select the Control > Start/Stop tab.
-
Select the name of the server.
-
Click Resume.
-
Select Yes to resume servers.
Configuration Changes Do Not Automatically Propagate to All Oracle Directory Integration Platform Instances in a Highly Available Topology
When you change the configuration of one Oracle Directory Integration Platform instance in a high availability topology, the configuration change does not propagate automatically to all Oracle Directory Integration Platform instances in the topology.
Use the manageDIPServerConfig
tool to make configuration change to all Oracle Directory Integration Platform instances in the topology, ensuring the same configuration across all Oracle Directory Integration Platform instances.
See manageDIPServerConfig Utility in Oracle Fusion Middleware Administering Oracle Directory Integration Platform.
An Operation Cannot Be Completed for Unknown Errors Message Appears
The following error message may appear intermittently when you use the manageSyncProfiles
command:
OPERATION CANNOT BE COMPLETED FOR UNKNOWN ERRORS
If you see this error message, start and stop the Managed Server (wls_ods1
or wls_ods2)
. If the problem persists, repeat the copy method on the second node.
About Starting and Stopping Oracle Directory Services Components
To start and stop Oracle Directory Services Components components, see Starting and Stopping Components in Oracle Fusion Middleware Administering Oracle Fusion Middleware.
About Configuring Oracle Internet Directory for Maximum High Availability
This section provides high-level instructions for setting up a maximum high availability deployment for Oracle Internet Directory. This deployment includes two sites in different geographic locations. This is an active-active deployment where both sites are active at the same time when the deployment is functioning normally. If one site fails, the surviving site continues to function.
Each site includes a two-node Oracle Internet Directory cluster configuration, which provides high availability for Oracle Internet Directory. The Oracle Internet Directory cluster configuration at each site uses an Oracle Real Applications Cluster (Oracle RAC) database as the security store, which provides high availability for the database.
Oracle Internet Directory High Availability Architecture provides an introduction to the high availability Oracle Internet Directory cluster configurations.
Multimaster replication replicates data from the master site to the replica site.
Topics
-
xref link to first topic
-
xref link to second topic
- Overview of Maximum High Availability Oracle Internet Directory Deployment
- Overview of Replication
This section describes the supported replication types for Oracle Internet Directory.
Overview of Maximum High Availability Oracle Internet Directory Deployment
The following figure, shows the maximum high availability deployment for Oracle Internet Directory.
The master site is located in New York and the replica site is located in Los Angeles.
Each site includes a highly available two-node Oracle Internet Directory cluster configuration that uses an Oracle RAC database as a highly available security store. Each two-node cluster has a load balancer. See Section 8.3.3, "Oracle Internet Directory High Availability Configuration Steps" for information on setting up a two-node Oracle Internet Directory cluster.
The master site in New York consists of:
-
OIDHOST1 and OIDHOST2
These are the two clustered hosts on which Oracle Internet Directory is installed.
-
RAC_DB1
The Oracle RAC database which serves as the security store for the Oracle Internet Directory instances on OIDHOST1 and OIDHOST2. Multimaster replication replicates data between RAC_DB1 in New York and RAC_DB2 in Los Angeles.
The replica site in Los Angeles consists of:
-
OIDHOST3 and OIDHOST4
These are the two clustered hosts on which Oracle Internet Directory is installed.
-
RAC_DB2
This is the Oracle RAC database which serves as the security store for the Oracle Internet Directory instances on OIDHOST3 and OIDHOST4. Multimaster replication replicates data between RAC_DB1 in New York and RAC_DB2 in Los Angeles.
Overview of Replication
This section describes the supported replication types for Oracle Internet Directory.
The following types of replication are available for Oracle Internet Directory:
-
LDAP multimaster replication
Uses the industry-standard Lightweight Directory Access Protocol Version 3 as the replication transport mechanism. Oracle recommends this protocol for replication.
-
Oracle Advanced Database multimaster replication
Uses the replication feature of Oracle Database, also called Advanced Replication.
-
Two-way fan-out replication
-
One-way fan-out replication
With this replication method, the replicated data is read-only at the replica site. Fan-out uses LDAP as its transport mechanism.
For more information about the replication types for Oracle Internet Directory, see Understanding Oracle Internet Directory Replication in Administering Oracle Internet Directory.
For the maximum availability deployment shown in Figure 10-1, either LDAP or Oracle Advanced Database multimaster replication can be set up.