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.

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)

To configure Oracle Directory Integration Platform on ODIPHOST1:

1. Start the Configuration Wizard by running the ORACLE_HOME/oracle_common/common/bin/config.sh script (on UNIX) or ORACLE_HOME\oracle_common\common\bin\config.cmd (on Windows).

   The Configuration Type screen is displayed.

2. Select Update an existing domain, and click Next.

   The Templates screen is displayed.

3. On the Templates screen, select Update Domain Using Product Templates and then select Oracle Directory Integration Platform - 12.2.1.3.0[dip] domain configuration option.

   Note:

   When you select the Oracle Directory Integration Platform - 12.2.1.3.0 [dip] option, Oracle Enterprise Manager 12.2.1.3.0 [em] is automatically selected.

   Click Next.

   The JDBC Data Sources screen is displayed.

4. Make changes if required and then click Next

   The JDBC Data Sources Test screen is displayed.

5. Select the data sources to test, and click Test Selected Connections.

   Click Next.

   The Database Configuration Type screen is displayed.

6. Make changes if required and then click Get RCU Configuration to retrieve the schema information. After successfully retrieving the schema information, click Next to continue.

   The JDBC Component Schema screen is displayed.

7. Verify that the values populated are correct for all schemas, and Click Next.

   Note:

   To convert one or more of the schemas to Oracle RAC multi-data source schemas, select the check boxes next to the name of those schemas, and select the Convert to RAC multi data source option. Click Next when done. When you click Next, the Oracle RAC Multi Data Source Component Schema screen appears.

   See Oracle RAC Multi Data Source Component Schema in Oracle Fusion Middleware Creating WebLogic Domains Using the Configuration Wizard.

   The JDBC Component Schema Test screen is displayed.
8. You can select the component schema to test, and click Test Selected Connections. Wait for one or more connection tests to complete. If you do not want to test connections, deselect all data sources.

   Note:

   In order to test connections, the database to which you are trying to connect must be running.

   Click Next.

   The Advanced Configuration screen is displayed.

9. Select Managed Servers, Clusters, and Coherence option. Click Next.

   The Managed Servers screen is displayed.

10. Click Add, and create one Managed Servers each for ODIPHOST1 and ODIPHOST2.

    Table 12-2 Managed Server on ODIPHOST1

    Name	Listen Address	Listen Port
    wls_ods1	odipHost1.example.com	7005

    Table 12-3 Managed Server on ODIPHOST2

    Name	Listen Address	Listen Port
    wls_ods2	odipHost2.example.com	7005

    Click Next.

    The Clusters screen is displayed.

11. Click Add and enter odip_cluster in the Cluster Name field to configure cluster for the Managed Servers on ODIPHOST1 and ODIPHOST2.

    Click Next.

    The Server Templates screen is displayed.

12. Click Next and Dynamic Servers screen is displayed.

    Click Next.

    The Assign Servers to Clusters screen is displayed.

13. Use the Assign Servers to Clusters screen to assign the wls_ods1 and wls_ods2 Managed Servers to the odip_cluster cluster. Only Managed Servers appear in the Server list box. The Administration Server is not listed because it cannot be assigned to a cluster.

    Select the name of the Managed Server in the Servers list box and click the right arrow. The name of the Managed Server is removed from the Servers list box and added below the name of the target cluster in the Clusters list box.

    The name of the Managed Server is removed from the Servers list box and added below the name of the target cluster in the Clusters list box.

    Click Next and continue clicking Next till the Machines screen is displayed.

14. Click the Machine (for Windows) or Unix Machine tab (for UNIX) and then click Add to add the following machines:

    Table 12-4 Machines

    Name	Node Manager Listen Address	Node Manager Listen Port
    odip_1	odipHost1.example.com	5556
    odip_2	odipHost2.example.com	5556

    Click Next.

    The Assign Servers to Machines screen is displayed.

15. Use the Assign Servers to Machines to assign the WebLogic Server instances to each of the machines.
    1. In the Machine list box, select the odip_1 machine.
    2. Select the wls_ods1 instance in the Server list box and click the right arrow.
       The name of the wls_ods1 instance is removed from the Server list box and added, below the name of the target machine, in the Machine list box.
    3. Repeat above steps to assign odip_2 machine to the wls_ods2 Managed Server.

    Select the name of the Managed Server in the Servers list box and click the right arrow. The name of the Managed Server is removed from the Servers list box and added below the name of the target cluster in the Clusters list box.

    The name of the Managed Server is removed from the Servers list box and added below the name of the target cluster in the Clusters list box.

    Click Next and continue clicking Next till the Configuration Summary screen is displayed.

16. Review each item on the Configuration Summary screen and verify that the information is correct.
    To make any changes, go back to a screen by clicking the Back button or selecting the screen in the navigation pane. Domain creation does not start until you click Create.
    A new WebLogic domain (for example: base_domain) is created to support Oracle Directory Integration Platform and Fusion Middleware Control in the <ORACLE_HOME>\user_projects\domains directory (on Windows). On UNIX, the domain is created in the <ORACLE_HOME>/user_projects/domains directory.

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.

For example: If you choose

/u01/app/oracle/product/fmw/idm

as the Oracle home on Node1, then you must choose

/u01/app/oracle/product/fmw/idm

as 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.

To determine the database version, run this query:

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.

If you use Oracle ASM, install it in its own Oracle Home and have two disk groups:

• 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.

You can also use SQL*Plus to configure your Oracle RAC database to automate failover for Oracle Internet Directory using the following instructions. Note that each of the following commands has to be run on only one node in the cluster:

1. Use the CREATE_SERVICE subprogram to both create the database service and enable high availability notification and configure server-side Transparent Application Failover (TAF) settings.

   prompt> sqlplus "sys/password as sysdba"
   
   SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE
   (SERVICE_NAME => 'idm.example.com',
   NETWORK_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.

2. Add the service to the database and assign it to the instances using srvctl.

   prompt> srvctl add service -d idmdb -s idm -r idmdb1,idmdb2

3. Start the service using srvctl.

   prompt> srvctl start service -d idmdb -s  idm

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.

For example, use the following SQL statement to verify that TAF is correctly configured:

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 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.
• 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 startComponent.sh), OIDMON restarts the default instance. All OID Monitor activity is logged in the file DOMAIN_HOME/servers/OID/logs/oid1/oidmon-xxxx.log. This file is on the Oracle Internet Directory server file system.
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.

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 in DOMAIN_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:

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.

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:

1. Upon receiving the start command, Node Manager issues an oidmon start command with appropriate arguments.

2. 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:

1. Upon receiving the stop command, Node Manager issues an oidmon stop command.

2. 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.

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.

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).

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.

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)	DOMAIN_HOME/servers/OID/logs/InstanceName/oidldapd00sPID-XXXX.log where: 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. DOMAIN_HOME/servers/OID/logs/InstanceName/oidstackInstNumberPID.log
LDAP dispatcher (oiddispd)	DOMAIN_HOME/servers/OID/logs/InstanceName/oiddispd00-XXXX.log where: 00 is the instance number (00 by default) XXXX is a number from 0000 to orclmaxlogfilesconfigured
OID Monitor (OIDMON)	DOMAIN_HOME/servers/OID/logs/InstanceName/oidmon-XXXX.log where: XXXX is a number from 0000 to orclmaxlogfilesconfigured
Directory replication server (oidrepld)	DOMAIN_HOME/servers/OID/logs/InstanceName/oidrepld-XXXX.log where: 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.

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.

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 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 OIDHOST1and 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 and stopComponent.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.

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:

1. 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

2. Copy the LDIF dump to the secondary node.

3. 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:

1. Disable the synchronization profile.

2. Get the value of the lastchangenumber attribute on the target node using the ldapsearch command.

3. Use ldapsearch to get the LDIF dump of the profile entry.

4. Use ldapadd to add the profile to the other Managed Server instance.

5. 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.

6. 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:

1. 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

2. Copy the LDIF dump to the secondary node.

3. Use the ldapadd command to add the profiles on the secondary node.

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.

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.

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.

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.

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.

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.

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.

See Understanding Your Installation Starting Point in Oracle Fusion Middleware Installation Planning Guide for the Oracle WebLogic Server version to use with the latest Oracle Fusion Middleware version.

Ensure that system, patch, kernel and other requirements are met as described in Installation Prerequisites in Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

Start the Oracle WebLogic Server installer then follow these steps:

1. On the Welcome screen, click Next.
2. On the Choose Installation Location screen, browse and navigate to the folder where you want to install the WebLogic Servre.
   Click Next
3. On the Installation Type screen, Select Fusion Middleware Insfrastructure
4. On the Prerequisite Checks screen, Click Next.
5. On the Installation Summary screen, the window contains a list of the components you selected for installation, along with the approximate amount of disk space to be used by the selected components once installation is complete.
   Click Install.
6. On the Installation Progress, Click Next.
7. On the Installation Complete screen, click Finish.

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:

1. Start Oracle Internet Directory 12c Installer.

2. On the Welcome screen, click Next.

3. On the Auto Updates screen, select Skip Auto Updates and click Next.

4. 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.

5. 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.

6. On the JDK Selection screen, browse and select jdk8 folder and click Next.

7. On the Prerequisite Checks ensure that all the prerequisites are met, without any warnings. Click Next.

8. On the Installation Summary screen, click Install.

9. Click Finish.

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).

To run RCU and create Identity Management schemas in a RAC database repository:

1. Run this command:
   ORACLE_HOME/oracle_common/bin/rcu &
2. On the Welcome screen, click Next.
3. On the Create Repository screen, select the Create Repository and System Load and Product Load to load component schemas into an existing database.

   Click Next.

4. On the Database Connection Details screen, enter connection information for the existing database as follows:
   • Database Type: Oracle Database
   • Connection String Format: select either —

     • Connection Parameters: This option provides an interface that accepts all connection parameters (namely - host, port and service name) separately in different UI elements.

     • Connection String: This option accepts all parameters in a single string. This string can be of one of the following formats:

       <host>:<port>/service or <host>:<port>:<SID> or (DESCRIPTION=(ADDRESS=(host=host_name)(protocol=protocol_name)(port=port_number))(CONNECT_DATA=(SERVICE_NAME=service_name)))

   • Host Name:Name of the computer on which the database is running. For an Oracle RAC database, specify the VIP name or one node name. Example: INFRADBHOST1-VIP or INFRADBHOST2-VIP
   • Port:The port number for the database. Example: 1521
   • Service Name:The service name of the database. Example: oid.example.com
   • Username:SYS
   • Password: The SYS user password
   • Role:SYSDBA
5. Click Next.
6. On the Select Components screen, create a new prefix and select the components to be associated with this deployment:

   Create a New Prefix:idm (Entering a prefix is optional if you select only Identity Management(Oracle Internet Directory - ODS) in the Components field)

   Components: Select Identity Management(Oracle Internet Directory - ODS). On selecting Identity Management component, some of the default components that are dependent on Oracle Internet Directory are automatically selected.

   Click Next.

7. On the Schema Passwords screen, enter the passwords to create password for the main and auxiliary schema users.

   Click Next.

8. On the Map Tablespaces screen, select the tablespaces for the components. The default tablespaces for the selected components are displayed. Click Next
9. On the Summary screen, click Create.
10. On the Completion Summary screen, click Close.

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 is oid1. 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:

1. Ensure that the system, patch, kernel and other requirements are met. These are listed in Preparing to Install in Oracle Fusion Middleware Installation Guide for Oracle Identity Managementguide.
2. Ensure that Oracle Identity Management software is installed and upgraded on OIDHOST1 Installing Oracle Fusion Middleware Components describes.
3. Ensure that ports 3060 and 3131 are not in use by any service on the computer by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.
   On UNIX:

   netstat -an | grep LISTEN | grep ":3060" 
   netstat -an | grep LISTEN | grep ":3131" 

   On Windows:

   netstat -an | findstr "LISTEN" | findstr ":3060"
   netstat -an | findstr "LISTEN" | findstr ":3131"

4. If the port is in use (if the command returns output identifying the port), you must free the port.
   1. On Unix:
      Remove any entries for ports 3060 and 3131 in the /etc/services file and restart the services, or restart the computer. You can also check for any existing processes that is using these ports, using netstat -anp command.
   2. On Windows:
      Stop the component that is using these ports.
5. Start the Configuration Wizard from ORACLE_HOME/oracle_common/common/bin/config.sh directory:

   On UNIX, issue this command: ./config.sh

   On Windows, double-click config.exe

6. On Create Domain screen, select Create a New Domain and provide the domain location. Click Next.
7. On Templates screen, select Oracle Internet Directory ( Collocated ) - 12.2.1.3.0 [oid] template. Retain all the selected dependent templates. Click Next.
8. On Administrator Account screen, provide weblogic user password and click Next.
9. On Domain Mode and JDK screen, select Production in Domain Mode field and select JDK8 Based Install . Click Next.
10. On Database Configuration Type screen, specify the database connection parameters. Change the schema owner field value from DEV_STB to relevant prefix — <PREFIX_STB> — as needed, click Get RCU Configuration and click Next.
11. On Component Datasources screen, click Next.
12. On JDBC Test screen, after successful connection test, click Next.
13. On Advanced Configuration screen, select Administration Server, Node Manager and Topology. Click Next.
14. On Administration Server screen, update Listen Address to a desired hostname and Listen Port as needed. Click Next.
15. On Node Manager Type screen, provide Node Manager credentials and Click Next.
16. On Manager Server, Skip the screen and click Next.
17. On Cluster screen, Skip and click Next.
18. On Server Templates screen, Skip and click Next.
19. On Coherence Clusters screen, Skip and click Next.
20. On Machines screen, Do Not change the name of the default machine name as oidhost1. Update the Listen Address to appropriate host name. The Node Manager Listen Port can be changed, if required. This port number should be the same value as the one in nodemanager.properties file. Add a new machine with name - oidhost2 and update the Listen Address to appropriate host name that points to OIDHOST2. If required, change the Listen Port to a desired port value.
21. On Assign Servers to Machines screen, select oidhost1 and assign AdminServer to oidhost1. Click Next.
22. On Virtual Targets screen, click Next.
23. On Partitions screen, click Next.
24. On Configuration Summary, click Create.
25. Start Administration Server.
26. Start Node Manager.
27. From ORACLE_HOME/oracle_common/common/bin/wlst.sh directory, Run wlst.sh and execute the following commands:

    connect('weblogic','<password>', 't3://<admin-host>:<admin-port>')
    oid_setup(orcladminPassword='<desired-password>', odsPassword='ODS-schema-password")
    oid_createInstance(instanceName='oid2', machine='oidhost2',port='oid-non-ssl-port',sslPort='oid-ssl-port', host='hostname-of-OIDHOST2')
    exit()

28. From ORACLE_HOME/oracle_common/common/bin/pack.sh directory, execute pack.sh command, as shown below:

    pack.sh -domain=<DOMAIN_HOME_LOCATION> -template=./base_domain.jar -template_name=base_domain -managed=true 
    

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:

1. Ensure that the system, patch, kernel and other requirements are met. These are listed in Preparing to Install in Oracle Fusion Middleware Installation Guide for Oracle Identity Managementguide.
2. Ensure that Oracle Identity Management software has been installed and upgraded on OIDHOST2 as described in Installing Oracle Fusion Middleware Components
3. On OIDHOST1, ports 3060 and 3131 were used for OID. The same ports should be used for the OID instance on OIDHOST2. Therefore, ensure that ports 3060 and 3131 are not in use by any service on OIDHOST2 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.
   On Unix:

   netstat -an | grep LISTEN | grep ":3060" 
   
   netstat -an | grep LISTEN | grep ":3131" 

   On Windows:

   netstat -an | findstr "LISTEN" | findstr ":3060"
   
   netstat -an | findstr "LISTEN" | findstr ":3131"

4. If the port is in use (if the command returns output identifying the port), you must free the port.
   On Unix:

   Remove any entries for ports 3060 and 3131 in the /etc/services file and restart the services, or restart the computer. You can also check for any existing processes that is using these ports, using netstat -anp command.

   On Windows:

   Stop the component that is using these ports.

5. From ORACLE_HOME/oracle_common/common directory, create the domain using unpack.sh command. Use the packed domain jar file created in OIDHOST1:

   unpack.sh -template=./base_domain.jar -domain=<ORACLE_HOME>/user_projects/domains/base_domain

6. From theDOMAIN_HOME/bin directory, start Node Manager.

   ./startNodeManager.sh 
   

7. From DOMAIN_HOME/bin directory, Start oid2 instance by executing startComponent.sh script. Execute the script from OIDHOST1 machine, where AdminServer is setup and not from OIDHOST2.
   • ./startComponent.sh oid2
   • oid2 can also be started either from OIDHOST1 or OIDHOST2 using WLST command — nmStart()

     nmStart(erverName='oid2', serverType='OID')
     

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

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
  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.

Performing Oracle Internet Directory Failover

This procedure describes the steps to be followed to perform Oracle Internet Directory failover.

The following example describes how to perform a failover to OIDHOST2 and check the status of OID service:

1. On OIDHOST1, use the following WLST command to stop the OID instance:
   shutdown(name='instance-name')
2. On OIDHOST2, check the status of OID using the load balancing router.

   Note:

   See the "Configuring Your Environment" section of Oracle Fusion Middleware Reference for Oracle Identity Management for a list of environment variables you must set before using the ldapbind command.

   ldapbind -h oid.example.com -p 3060 -D "cn=orcladmin" -q

   Note:

   The -q option above prompts you 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.

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.

To perform an Oracle RAC failover, perform the following steps:

1. Use the srvctl command to stop a database instance:
   srvctl stop instance -d db_unique_name -i inst_name_list
2. Use the srvctl command to check the status of the database:
   srvctl status database -d db_unique_name -v
3. Check the status of Oracle Internet Directory:

   Note:

   See "Configuring Your Environment" in Oracle Fusion Middleware Reference for Oracle Identity Management for a list of environment variables you must set before using the ldapbind command.

   ldapbind -h oid_host1 -p 3060 -D "cn=orcladmin" -q
   ldapbind -h oid_host2 -p 3060 -D "cn=orcladmin" -q
   ldapbind -h oid.example.com -p 3060 -D "cn=orcladmin" -q

   Note:

   The -q option above 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.

To know more about RAC failover, See Oracle Internet Directory Replication-Server Control and Failover

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:

  1. oidmon-xxx.log

  2. oiddispd01-xxxx.log

  3. 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.

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.

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.

To change the ODS database user password, invoke the following command on one of the OID nodes:

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.

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

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

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
  
• Cluster-Wide Configuration Changes (OID)
  

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:

1. 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

2. Copy the LDIF dump to the secondary node.

3. 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:

1. Disable the synchronization profile.

2. Get the value of the lastchangenumber attribute on the target node using the ldapsearch command.

3. Use ldapsearch to get the LDIF dump of the profile entry.

4. Use ldapadd to add the profile to the other Managed Server instance.

5. 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.

6. 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:

1. 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

2. Copy the LDIF dump to the secondary node.

3. 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

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)
  

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
  
• About Updating the Oracle Directory Integration Platform Server Configuration
  
• About External Dependency Failure
  

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.

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.

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.

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.

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 on OIDHOST1 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 and ODIPHOST2).

Configuring Oracle Directory Integration Platform on ODIPHOST1 (OID)

To configure Oracle Directory Integration Platform on ODIPHOST1:

1. Start the Configuration Wizard by running the ORACLE_HOME/oracle_common/common/bin/config.sh script (on UNIX) or ORACLE_HOME\oracle_common\common\bin\config.cmd (on Windows).

   The Configuration Type screen is displayed.

2. Select Update an existing domain, and click Next.

   The Templates screen is displayed.

3. On the Templates screen, select Update Domain Using Product Templates and then select Oracle Directory Integration Platform - 12.2.1.3.0[dip] domain configuration option.

   Note:

   When you select the Oracle Directory Integration Platform - 12.2.1.3.0 [dip] option, Oracle Enterprise Manager 12.2.1.3.0 [em] is automatically selected.

   Click Next.

   The JDBC Data Sources screen is displayed.

4. Make changes if required and then click Next

   The JDBC Data Sources Test screen is displayed.

5. Select the data sources to test, and click Test Selected Connections.

   Click Next.

   The Database Configuration Type screen is displayed.

6. Make changes if required and then click Get RCU Configuration to retrieve the schema information. After successfully retrieving the schema information, click Next to continue.

   The JDBC Component Schema screen is displayed.

7. Verify that the values populated are correct for all schemas, and Click Next.

   Note:

   To convert one or more of the schemas to Oracle RAC multi-data source schemas, select the check boxes next to the name of those schemas, and select the Convert to RAC multi data source option. Click Next when done. When you click Next, the Oracle RAC Multi Data Source Component Schema screen appears.

   See Oracle RAC Multi Data Source Component Schema in Oracle Fusion Middleware Creating WebLogic Domains Using the Configuration Wizard.

   The JDBC Component Schema Test screen is displayed.
8. You can select the component schema to test, and click Test Selected Connections. Wait for one or more connection tests to complete. If you do not want to test connections, deselect all data sources.

   Note:

   In order to test connections, the database to which you are trying to connect must be running.

   Click Next.

   The Advanced Configuration screen is displayed.

9. Select Managed Servers, Clusters, and Coherence option. Click Next.

   The Managed Servers screen is displayed.

10. Click Add, and create one Managed Servers each for ODIPHOST1 and ODIPHOST2.

    Table 12-9 Managed Server on ODIPHOST1

    Name	Listen Address	Listen Port
    wls_ods1	odipHost1.example.com	7005

    Table 12-10 Managed Server on ODIPHOST2

    Name	Listen Address	Listen Port
    wls_ods2	odipHost2.example.com	7005

    Click Next.

    The Clusters screen is displayed.

11. Click Add and enter odip_cluster in the Cluster Name field to configure cluster for the Managed Servers on ODIPHOST1 and ODIPHOST2.

    Click Next.

    The Server Templates screen is displayed.

12. Click Next and Dynamic Servers screen is displayed.

    Click Next.

    The Assign Servers to Clusters screen is displayed.

13. Use the Assign Servers to Clusters screen to assign the wls_ods1 and wls_ods2 Managed Servers to the odip_cluster cluster. Only Managed Servers appear in the Server list box. The Administration Server is not listed because it cannot be assigned to a cluster.

    Select the name of the Managed Server in the Servers list box and click the right arrow. The name of the Managed Server is removed from the Servers list box and added below the name of the target cluster in the Clusters list box.

    The name of the Managed Server is removed from the Servers list box and added below the name of the target cluster in the Clusters list box.

    Click Next and continue clicking Next till the Machines screen is displayed.

14. Click the Machine (for Windows) or Unix Machine tab (for UNIX) and then click Add to add the following machines:

    Table 12-11 Machines

    Name	Node Manager Listen Address	Node Manager Listen Port
    odip_1	odipHost1.example.com	5556
    odip_2	odipHost2.example.com	5556

    Click Next.

    The Assign Servers to Machines screen is displayed.

15. Use the Assign Servers to Machines to assign the WebLogic Server instances to each of the machines.
    1. In the Machine list box, select the odip_1 machine.
    2. Select the wls_ods1 instance in the Server list box and click the right arrow.
       The name of the wls_ods1 instance is removed from the Server list box and added, below the name of the target machine, in the Machine list box.
    3. Repeat above steps to assign odip_2 machine to the wls_ods2 Managed Server.

    Select the name of the Managed Server in the Servers list box and click the right arrow. The name of the Managed Server is removed from the Servers list box and added below the name of the target cluster in the Clusters list box.

    The name of the Managed Server is removed from the Servers list box and added below the name of the target cluster in the Clusters list box.

    Click Next and continue clicking Next till the Configuration Summary screen is displayed.

16. Review each item on the Configuration Summary screen and verify that the information is correct.
    To make any changes, go back to a screen by clicking the Back button or selecting the screen in the navigation pane. Domain creation does not start until you click Create.
    A new WebLogic domain (for example: base_domain) is created to support Oracle Directory Integration Platform and Fusion Middleware Control in the <ORACLE_HOME>\user_projects\domains directory (on Windows). On UNIX, the domain is created in the <ORACLE_HOME>/user_projects/domains directory.

Configuring Oracle Directory Integration Platform for Oracle Internet Directory (OIDHOST1)

You must configure Oracle Directory Integration Platform for Oracle Internet Directory on OIDHOST1 instance.

Complete the following steps:

1. Run the dipConfigurator command to configure Oracle Directory Integration Platform (ODIPHOST1) for OIDHOST1. For more information, see Configuring Oracle Directory Integration Platform for Oracle Internet Directory in Oracle Fusion Middleware Administering Oracle Directory Integration Platform.

   Note:

   • If you are using a RAC database, then Oracle recommends that you specify the URL for the RAC database in the dbconfigfile file for dipConfigurator properties.

   • If the cipher suites configured for Oracle Internet Directory are not available or recognized in Oracle Directory Integration Platform then you must add those suites into Oracle Directory Integration Platform using the Oracle Fusion Middleware System MBean Browser. See Adding Cipher Suites Configured for Oracle Internet Directory into Oracle Directory Integration Platformin Oracle Fusion Middleware Administering Oracle Directory Integration Platform.

2. Run the manageDIPServerConfig command to tune the cluster:

   ./manageDIPServerConfig set -host ODIPHOST1.example.com -port 7005 -wlsuser weblogic -attribute ClusterCheckInInterval -value 30000
   
   ./manageDIPServerConfig set -host ODIPHOST1 -port 7005 -wlsuser weblogic -attribute RefreshInterval -value 120

3. Run the manageDIPServerConfig command for reconfiguring Oracle Directory Integration Platform to use the TCP load balancer.

   LB_HOST is the load balancer IP address you must configure to redirect to one of the back-end instances.

   ./manageDIPServerConfig set -host ODIPHOST1 -port 7005 -wlsuser weblogic -attribute BackendHostPort -value LB_HOST:LB_PORT

Configuring Oracle Directory Integration Platform on ODIPHOST2 (OID)

You must configure the Oracle Directory Integration Platform on ODIPHOST2 for the Oracle Internet Directory back-end directory:

1. Run the following pack command on ODIPHOST1 to create a template pack:

   cd MW_HOME/oracle_common/common/bin
   ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/domainName -template=dipdomain.jar -managed=true -template_name="dipdomain"

2. Copy the template file created in the previous step from ODIPHOST1 to ODIPHOST2. For example, on a UNIX platform:

   scp dipdomain.jar user@ODIPHOST2:MW_HOME/oracle_common/common/bin

3. Perform the following on ODIPHOST2:
   1. Run the unpack command to unpack the propagated template:

      cd MW_HOME/oracle_common/common/bin
      ./unpack.sh -domain=MW_HOME/user_projects/domains/domains/domainName -template=dipdomain.jar -overwrite_domain=true

   2. Start and stop the wls_ods2 Managed Server:

      MW_HOME/user_projects/domains/domainName/bin/startManagedWebLogic.sh wls_ods2 http://ODIPHOST1:ODIPHOST1ADMINPORT

      MW_HOME/user_projects/domains/domainName/bin/stopManagedWebLogic.sh wls_ods2 http://ODIPHOST1:ODIPHOST1ADMINPORT
      

   3. Overwrite the dip-config.xml file in wls_ods2 with the dip-config.xml in wls_ods1:

      cp MW_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/servers/wls_ods1/applications/DIP_12.2.1.3.0/configuration/dip-config.xml 
       MW_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/servers/wls_ods2/applications/DIP_12.2.1.3.0/configuration/dip-config.xml

   4. Start the Node Manager, by running the startNodeManager.cmd (Windows) or startNodeManager.sh (UNIX) command.

      MW_HOME/user_projects/domains/DOMAIN_NAME/bin/startNodeManager.sh

   5. Start the wls_ods2 Managed Server:

      MW_HOME/user_projects/domains/DOMAIN_NAME/bin/startManagedWebLogic.sh wls_ods2 http://ODIPHOST1:ODIPHOST1ADMINPORT

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 on OIDHOST1 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 and ODIPHOST2).

Configuring Oracle Directory Integration Platform on ODIPHOST1 (OUD)

To configure Oracle Directory Integration Platform on ODIPHOST1 for Oracle Unified Directory as the back-end directory:

1. Start the Configuration Wizard by running the <MW_HOME>/oracle_common/common/bin/config.sh script (on UNIX) or <MW_HOME>\oracle_common\common\bin\config.cmd (on Windows).

   The Configuration Type screen is displayed.

2. On the Configuration Type screen, select Create a new domain and enter the full path for the domain or use the Browse button to navigate to the directory in which your domains are located. Click Next.

   The Templates screen is displayed.

3. On the Templates screen, make sure Create Domain Using Product Templates is selected, and then select Oracle Directory Integration Platform - 12.2.1.3.0 [dip].

   Note:

   When you select Oracle Directory Integration Platform - 12.2.1.3.0 [dip] option, the following components are automatically selected:

   • Oracle Enterprise Manager 12.2.1.3.0 [em]

   • Oracle JRF - 12.2.1.3.0 [oracle_common]

   • Weblogic Coherence Cluster Extension 12.2.1.3 [wlserver]

   Click Next.

   Click The Application Location screen is displayed.

4. Click Browse and specify the full path to the directory in which you want to store the applications that are associated with the domain.

   Click Next.

   The Administrator Account screen is displayed.

5. Specify the user name and password for the default WebLogic Administrator account for the domain.
   The password must be at least eight characters and must contain at least one number or special character. Confirm the password and click Next.
   Make a note of these details as you will need them to start or restart the WebLogic domain in the following procedure.
   The Domain Mode and JDK screen is displayed.
6. Specify the domain mode and Java Development Kit (JDK).
   1. Select Production in the Domain Mode field.

      Note:

      If you select Production mode as the domain, the node manager has a random username and password assigned to it. Use the WebLogic Server Administration Console to reset the password.

   2. Accept Oracle Hotspot as a default JDK location.
   3. Click Next.
   The Database Configuration Type screen is displayed.
7. Select RCU Data. This option instructs the Configuration Wizard to connect to the database’s Service Table (STB) schema to automatically retrieve schema information for schemas needed to configure the domain.

   Note:

   Ensure that you have created the database schemas required for Oracle Internet Directory. See Creating the Database Schemas in Oracle Fusion Middleware Installing and Configuring Oracle Internet Directory.

   After selecting RCU Data:

   1. Enter the name of the server hosting the database in the Host Name field.
   2. Enter the database DBMS name, or service name if you selected a service type driver in the DBMS/Service field.
   3. Enter the port number on which the database listens.
   4. Enter the username and password for connecting to the database's Service Table schema.
   5. Click Get RCU Configuration to retrieve the schema information. After successfully retrieving the schema information, click Next to continue.
   The JDBC Component Schema screen is displayed.
8. Verify that the values populated are correct for all schemas, and Click Next.

   Note:

   To convert one or more of the schemas to Oracle RAC multi-data source schemas, select the check boxes next to the name of those schemas, and select the Convert to RAC multi data source option. Click Next when done. When you click Next, the Oracle RAC Multi Data Source Component Schema screen appears.

   See Oracle RAC Multi Data Source Component Schema in Oracle Fusion Middleware Creating WebLogic Domains Using the Configuration Wizard.

   The JDBC Component Schema Test screen is displayed.
9. Click Test Selected Connection to test datasource connections that you just configured.
   A green check mark in the Status column indicates a successful test. If you encounter issues, see the error message in the Connection Result Log section of the screen, fix the problem, then test the connection again.

   The Advanced Configuration screen is displayed.

10. To complete domain configuration, select the following options:
    • Administration Server: Required to properly configure the Administration Server’s listen address.
    • Node Manager: Required to configure Node Manager.
    • Topology: Required to configure the Managed Servers and cluster, and for configuring the machine and targeting Managed Servers to the machine.

    Click Next.

    The Administration Server screen is displayed.

11. Accept the default settings or change the Administration Server settings.

    Click Next.

    The Node Manager screen is displayed.

12. Use the Node Manager screen to select the Node Manager configurations that are applicable for the domain and click Next.
    The Managed Servers screen is displayed.
13. Click Add, and create one Managed Servers each for ODIPHOST1 and ODIPHOST2.

    Table 12-12 Managed Servers on ODIPHOST1

    Name	Listen Address	Listen Port
    wls_ods1	odipHost1.example.com	7005

    Table 12-13 Managed Servers on ODIPHOST2

    Name	Listen Address	Listen Port
    wls_ods2	odipHost2.example.com	7005

    Click Next.

    The Clusters screen is displayed.

14. Click Add and enter odip_cluster in the Cluster Name field to configure cluster for the Managed Servers on ODIPHOST1 and ODIPHOST2.

    Click Next.

    The Server Templates screen is displayed.

15. Click Next and Dynamic Servers screen is displayed.

    Click Next.

    The Assign Servers to Clusters screen is displayed.

16. Use the Assign Servers to Clusters screen to assign the wls_ods1 and wls_ods2 Managed Servers to the odip_cluster cluster. Only Managed Servers appear in the Server list box. The Administration Server is not listed because it cannot be assigned to a cluster.

    Select the name of the Managed Server in the Servers list box and click the right arrow. The name of the Managed Server is removed from the Servers list box and added below the name of the target cluster in the Clusters list box.

    The name of the Managed Server is removed from the Servers list box and added below the name of the target cluster in the Clusters list box.

    Click Next and continue clicking Next till the Machines screen is displayed.

17. Click the Machine or Unix Machine tab and then click Add to add the following machines:

    Table 12-14 Machines

    Name	Node Manager Listen Address	Node Manager Listen Port
    odip_1	odipHost1.example.com	5556
    odip_2	odipHost2.example.com	5556

    Click Next.

    The Assign Servers to Machines screen is displayed.

18. Use the Assign Servers to Machines to assign the WebLogic Server instances to each of the machines.
    1. In the Machine list box, select the odip_1 machine.
    2. Select the wls_ods1 instance in the Server list box and click the right arrow.
       The name of the wls_ods1 instance is removed from the Server list box and added, below the name of the target machine, in the Machine list box.
    3. Repeat above steps to assign odip_2 machine to the wls_ods2 Managed Server.

    Select the name of the Managed Server in the Servers list box and click the right arrow. The name of the Managed Server is removed from the Servers list box and added below the name of the target cluster in the Clusters list box.

    The name of the Managed Server is removed from the Servers list box and added below the name of the target cluster in the Clusters list box.

    Click Next and continue clicking Next till the Configuration Summary screen is displayed.

19. Review each item on the Configuration Summary screen and verify that the information is correct.
    To make any changes, go back to a screen by clicking the Back button or selecting the screen in the navigation pane. Domain creation does not start until you click Create.
    A new WebLogic domain (for example: base_domain) is created to support Oracle Directory Integration Platform and Fusion Middleware Control in the <MW_HOME>\user_projects\domains directory (on Windows). On UNIX, the domain is created in the <MW_HOME>/user_projects/domains 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.

Complete the following steps:

1. Run the dipConfigurator command to configure Oracle Directory Integration Platform (ODIPHOST1) for OUDHOST1. For more information, see Configuring Oracle Directory Integration Platform for Oracle Unified Directory in Oracle Fusion Middleware Administering Oracle Directory Integration Platform.
2. Run the manageDIPServerConfig command to tune the cluster:

   ./manageDIPServerConfig set -host ODIPHOST1.example.com -port 7005 -wlsuser weblogic -attribute ClusterCheckInInterval -value 30000
   
   ./manageDIPServerConfig set -host ODIPHOST1 -port 7005 -wlsuser weblogic -attribute RefreshInterval -value 120

3. Run the manageDIPServerConfig command for reconfiguring Oracle Directory Integration Platform to use the TCP load balancer.

   LB_HOST is the load balancer IP address you must configure to redirect to one of the back-end instances.

   ./manageDIPServerConfig set -host ODIPHOST1 -port 7005 -wlsuser weblogic -attribute BackendHostPort -value LB_HOST:LB_PORT

Configuring Oracle Directory Integration Platform on ODIPHOST2 (OUD)

You must configure the Oracle Directory Integration Platform on ODIPHOST2 for the Oracle Unified Directory back-end directory:

1. Run the following pack command on ODIPHOST1 to create a template pack:

   cd MW_HOME/oracle_common/common/bin
   ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/domainName -template=dipdomain.jar -managed=true -template_name="dipdomain"

2. Copy the template file created in the previous step from ODIPHOST1 to ODIPHOST2. For example, on a UNIX platform:

   scp dipdomain.jar user@ODIPHOST2:MW_HOME/oracle_common/common/bin

3. Perform the following on ODIPHOST2:
   1. Run the unpack command to unpack the propagated template:

      cd MW_HOME/oracle_common/common/bin
      ./unpack.sh -domain=MW_HOME/user_projects/domains/domains/domainName -template=dipdomain.jar -overwrite_domain=true

   2. Start and stop the wls_ods2 Managed Server:

      MW_HOME/user_projects/domains/domainName/bin/startManagedWebLogic.sh wls_ods2 http://ODIPHOST1:ODIPHOST1ADMINPORT

      MW_HOME/user_projects/domains/domainName/bin/stopManagedWebLogic.sh wls_ods2 http://ODIPHOST1:ODIPHOST1ADMINPORT
      

   3. Overwrite the dip-config.xml file in wls_ods2 with the dip-config.xml in wls_ods1:

      cp MW_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/servers/wls_ods1/applications/DIP_12.2.1.3.0/configuration/dip-config.xml 
       MW_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/servers/wls_ods2/applications/DIP_12.2.1.3.0/configuration/dip-config.xml

   4. Start the Node Manager, by running the startNodeManager.cmd (Windows) or startNodeManager.sh (UNIX) command.

      MW_HOME/user_projects/domains/DOMAIN_NAME/bin/startNodeManager.sh

   5. Start the wls_ods2 Managed Server:

      MW_HOME/user_projects/domains/DOMAIN_NAME/bin/startManagedWebLogic.sh wls_ods2 http://ODIPHOST1:ODIPHOST1ADMINPORT

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.

1. Go to the directory ORACLE_HOME/ldap/odi/conf and edit the file iplanetimp.cfg.master

2. Replace the line Reader: oracle.ldap.odip.gsi.IPlanetReader with the line oracle.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.

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.

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
  

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.

1. If you have not already done so, click Lock & Edit in the Change Center of the Administration Console.

2. In the left pane of the Console, expand Servers and AdminServer (admin).

3. Select the Configuration > SSL > Advanced Link.

4. Select None for Hostname Verification.

5. Click Save to save the setting.

6. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

7. Restart all servers.

(Optional) Enter an example to illustrate your reference here.

1. If you have not already done so, click Lock & Edit in the Change Center of the Administration Console.

2. In the left pane of the Console, expand Servers and the name of the server that is running in ADMIN mode.

3. Select the Control > Start/Stop tab.

4. Select the name of the server.

5. Click Resume.

6. 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.