1. Installing and Configuring Oracle Internet Directory
  2. Configuring High Availability for Oracle Directory Services Components

7 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 (12.2.1.4.0) Oracle Directory Services Products

The following table summarizes Oracle Identity Management products that you can install using the suite-level installation program for 12c (12.2.1.4.0).

Table 7-1 The 12c (12.2.1.4.0) 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 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 and Configure Oracle Internet Directory in Oracle Fusion Middleware Installing and Configuring Oracle Internet Directory

Parent topic: Configuring High Availability for Oracle Directory Services Components

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.

Parent topic: Configuring High Availability for Oracle Directory Services Components

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.

Parent topic: Prerequisites for Oracle Directory Services High Availability Configuration

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%'

Parent topic: Prerequisites for Oracle Directory Services High Availability Configuration

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.

Parent topic: Prerequisites for Oracle Directory Services High Availability Configuration

Configuring the Database for Oracle Fusion Middleware 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 (12.2.1.4.0) 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:

Parent topic: Prerequisites for Oracle Directory Services High Availability Configuration

Database Examples in this Chapter

See the databases used in Oracle Directory Services Configuration examples in this chapter.

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

Parent topic: Configuring the Database for Oracle Fusion Middleware Metadata

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.

Parent topic: Configuring the Database for Oracle Fusion Middleware Metadata

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

Parent topic: Configuring High Availability for Oracle Directory Services Components

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

Parent topic: Oracle Internet Directory High Availability

Oracle Internet Directory Component Characteristics

Oracle Internet Directory, which is Oracle's LDAP store, is a C-based component that uses a database as its persistence store. It is a stateless process and stores all of the data and the majority of its configuration information in the back-end database. It uses Oracle Net Services to connect to the database.

  • Runtime Processes
    Oracle Internet Directory has the following runtime processes:
  • Process Lifecycle
    Node Manager is responsible for the direct start, stop, restart and monitoring of the daemon process, OIDMON (ORACLE_HOME/bin/oidmon). OIDMON is responsible for the process control of an Oracle Internet Directory instance.
  • Request Flow
    Once the Oracle Internet Directory (OID) process starts up, clients access OID using the LDAP or LDAPS protocol. There is no affect on other running instances when an OID instance starts up
  • About Configuration Artifacts
    The storage location requires a DB connect string. TNSNAMES.ORA is stored in DOMAIN_HOME/config. The wallet is stored 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:

Parent topic: About Oracle Internet Directory Component Architecture

Runtime Processes

Oracle Internet Directory has the following runtime processes:

  • OIDLDAPD: This is the main process for Oracle Internet Directory. OIDLDAPD consists of a dispatcher process and a server process. The dispatcher process spawns the OIDLDAPD server processes during startup. Each OIDLDAPD dispatcher process has its own SSL and non-SSL ports for receiving requests. Every OID instance has one dispatcher and one server process by default. The number of server processes spawned for an instance is controlled by the orclserverprocs attribute.

  • OIDMON: OIDMON is responsible for the process control of an Oracle Internet Directory instance. This process starts, stops, and monitors Oracle Internet Directory. During startup OIDMON spawns the OIDLDAPD dispatcher process and the replication server process, if replication is configured for the instance.

  • Replication server process: This is a process within Oracle Internet Directory that runs only when replication is configured. The replication server process is spawned by OIDMON during startup.

  • Node Manager: Node Manager is a daemon process that monitors Oracle Fusion Middleware components, including Oracle Internet Directory.

    Node Manager is responsible for the direct start, stop, restart and monitoring of OIDMON. It does not start or stop the server process directly.

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

Parent topic: Oracle Internet Directory High Availability

Oracle Internet Directory High Availability Architecture

Learn about the Oracle Internet Directory Cluster Configuration high availability architecture in an active-active configuration.

The Figure 7-1 shows the Oracle Internet Directory Cluster Configuration high availability architecture in an active-active configuration.

Figure 7-1 Oracle Internet Directory Cluster Configuration High Availability Architecture

Description of Figure 7-1 follows
Description of "Figure 7-1 Oracle Internet Directory Cluster Configuration High Availability Architecture"

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

Parent topic: Understanding Oracle Internet Directory High Availability Concepts

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.

Parent topic: Understanding Oracle Internet Directory High Availability Concepts

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.

Parent topic: Understanding Oracle Internet Directory High Availability Concepts

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.

Parent topic: Oracle Internet Directory High Availability

Installing Oracle Fusion Middleware Components

This section describes how to install the required binaries for the Oracle WebLogic Server (WL_HOME) and Oracle Home for (ORACLE_HOME) for Oracle Identity Management.

Oracle strongly recommends that you read the release notes for any additional installation and deployment considerations prior to starting the setup process.

Parent topic: Oracle Internet Directory High Availability Configuration Steps

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 Planning the Oracle WebLogic Server Installation 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 (12.2.1.4.0) 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.

Parent topic: Oracle Internet Directory High Availability Configuration Steps

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

Parent topic: Oracle Internet Directory High Availability

Oracle Internet Directory Failover and Expected Behavior

This section describes how to perform a failover of Oracle Internet Directory and Oracle RAC.

This section includes the following topics:

  • Performing Oracle Internet Directory Failover
    This procedure describes the steps to be followed to perform Oracle Internet Directory failover.
  • Performing an Oracle RAC Failover
    The orclfailoverenabled attribute is a configuration entry ("cn=configset,cn=oidmon,cn=subconfigsubentry") that configures failover for Oracle Internet Directory processes. This attribute specifies the failover time in minutes before the OID Monitor will start failed processes on a surviving node. The default failover time is 5 minutes. A value of zero (0) specifies that Oracle Internet Directory processes will not fail over to another node.

Parent topic: Oracle Internet Directory High Availability

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

Related Topics

Parent topic: Oracle Internet Directory High Availability

Additional Oracle Internet Directory High Availability Issues

This section describes issues for Oracle Internet Directory in a high availability environment.

This section describes issues for Oracle Internet Directory in a high availability environment.

See Changing the Password of the ODS Schema Used by Oracle Internet Directory

  • Changing the Password of the ODS Schema Used by Oracle Internet Directory
    You can change the OID database schema password (that is, the password of the ODS user in the database) using the Oracle Internet Directory Database Password Utility (oidpasswd) from OIDHOST1 (Where AdminServer is installed). However, since the ODS schema password is stored in a password wallet under the DOMAIN_HOME on each host. This is propagated from OIDHOST1 to all other hosts automatically by Weblogic Domain Framework.

Parent topic: Oracle Internet Directory High Availability

Changing the Password of the ODS Schema Used by Oracle Internet Directory

You can change the OID database schema password (that is, the password of the ODS user in the database) using the Oracle Internet Directory Database Password Utility (oidpasswd) from OIDHOST1 (Where AdminServer is installed). However, since the ODS schema password is stored in a password wallet under the DOMAIN_HOME on each host. This is propagated from OIDHOST1 to all other hosts automatically by Weblogic Domain Framework.

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

Parent topic: Configuring High Availability for Oracle Directory Services Components

Understanding Oracle Directory Integration Platform Component Architecture

Oracle Directory Integration Platform is a J2EE application that enables you to integrate your applications and directories, including third-party LDAP directories, with an Oracle back-end directory: Oracle Internet Directory, Oracle Unified Directory, and Oracle Directory Server Enterprise Edition.

Note:

Oracle Directory Integration Platform does not support Oracle Directory Server Enterprise Edition in high availability mode in this release.

See Introduction to Oracle Directory Integration Platform in Oracle Fusion Middleware Administering Oracle Directory for more on Oracle Directory Integration Platform architecture.

Parent topic: Oracle Directory Integration Platform High Availability

Understanding Oracle Directory Integration Platform High Availability Concepts

This section describes the Oracle Directory Integration Platform high availability concepts.

Parent topic: Oracle Directory Integration Platform High Availability

About Oracle Directory Integration Platform High Availability Architecture (OID Back-End)

Learn about the Oracle Directory Integration Platform high availability architecture with Oracle Internet Directory as the back-end directory.

Figure 7-2 Oracle Directory Integration Platform with Oracle Internet Directory (Back-End Directory) in a High Availability Architecture

This figure describes Oracle Directory Integration Platform with Oracle Internet Directory (Back-End Directory) in a High Availability Architecture.

In Figure 7-2 , Connected Directory 1 and Connected Directory 2 replicate information with each other. A load balancing router routes requests to the Connected Directories.

The Application Tier includes the ODIPHOST1 and ODIPHOST2 computers.

ODIP1 and ODIP2 go through the load balancer when they must communicate with the Connected Directories.

On ODIPHOST1, the following installations are performed:

  • An Oracle Directory Integration Platform instance is installed (ODIP1) on the Managed Server.

  • A Quartz Scheduler is installed on ODIP1 by default. It connects to the Oracle RAC database using a WebLogic multi data source. The Quartz Scheduler invokes EJBs that do the actual work; if the EJB fails, the Quartz Scheduler marks the job as failed and reschedules it to run at later time by another EJB.

  • An Administration Server is installed. Under normal operations, this is the active Administration Server.

On ODIPHOST2, the following installations are performed:

  • An Oracle Directory Integration Platform instance is installed (ODIP2) on the Managed Server.

  • A Quartz Scheduler is installed on ODIP2 by default. Quartz Scheduler connects to the Oracle RAC database using a WebLogic multi data source.

  • An Administration Server is installed. Under normal operations, this is the passive Administration Server instance. You make this Administration Server active if the Administration Server on ODIPHOST1 becomes unavailable.

The Oracle Directory Integration Platform instances on the ODIPHOST1 and ODIPHOST2 Managed Servers are configured as a cluster.

A load balancer is set up for the back-end directories OIDHOST1 and OIDHOST2. The load balancer routes requests to either OIDHOST1 or OIDHOST2.

Note:

When you use a RAC database, multi data source is used with Oracle Directory Integration Platform to protect the instances from RAC failure.
About Starting and Stopping the Cluster

By default, the WebLogic Server starts, stops, and monitors the applications and Oracle Directory Integration Platform leverages the high availability features of the underlying clusters. If there is a hardware or other failure, session state is available to other cluster nodes that can resume the work of the failed node.

Node Manager monitors the WebLogic servers. If failure occurs, Node Manager restarts the WebLogic Server.

See Configuring Java Node Manager 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 7-3 Oracle Directory Integration Platform with Oracle Unified Directory (Back-End Directory) in a High Availability Architecture

This figure describes the Oracle Directory Integration Platform with Oracle Unified Directory (Back-End Directory) in a High Availability Architecture.

Figure 7-3, Connected Directory 1 and Connected Directory 2 replicate information with each other. A load balancing router routes requests to the Connected Directories.

The Application Tier includes the ODIPHOST1 and ODIPHOST2 computers.

On ODIPHOST1, the following installations are performed:

  • An Oracle Directory Integration Platform instance is installed (ODIP1) on the Managed Server. ODIP1 goes through the load balancer for connected directories when it must connect to them.

  • The Quartz Scheduler is installed. It goes through the load balancer for the back-end directories.

  • An Administration Server is installed. Under normal operations, this is the active Administration Server.

On ODIPHOST2, the following installations are performed:

  • An ODIP instance is installed (ODIP2) on the Managed Server. ODIP2 goes through the load balancer for connected directories when it must connect to them.

  • The Quartz Scheduler is installed. It goes through the load balancer for backend directories.

  • An Administration Server is installed. Under normal operations, this is the passive Administration Server instance. You make this Administration Server active if the Administration Server on ODIPHOST1 becomes unavailable.

The Oracle Directory Integration Platform instances on the ODIPHOST1 and ODIPHOST2 Managed Servers are configured as a cluster.

A load balancer is set up for the back-end directories OUDHOST1 and OUDHOST2. The load balancer routes requests to either OUDHOST1 or OUDHOST2.

Cluster-Wide Configuration Changes (OUD)

Oracle Unified Directory supports cluster-wide configuration changes. All Oracle Unified Directory instances that are part of the same replication topology share the same content. Any changes made to Oracle Directory Integration Platform on one Oracle Unified Directory node automatically propagate to all Oracle Unified Directory instances in the replication topology.

Protection from Failures and Expected Behavior

This section describes protection from different types of failure in an Oracle Directory Integration Platform active-active cluster

About Process Failure

In a high availability environment, you deploy the Oracle Directory Integration Platform application to a cluster that comprises at least two Oracle WebLogic instances.

By default, the Oracle Directory Integration Platform application leverages high availability features of the underlying WebLogic clusters. When you deploy Oracle Directory Integration Platform, the Quartz scheduler starts with a clustering option. Depending on the load on the node, the scheduler then runs the job on any available nodes in the cluster. If hardware or other failures occur on one or more nodes, the Quartz scheduler runs the jobs on available nodes.

Also, Node Manager monitors WebLogic servers. In case of failure, Node Manager restarts the WebLogic server.

Within the Oracle Directory Integration Platform application, the Quartz Scheduler invokes the Provisioning or Synchronization EJBs that do the actual work. As soon as the Quartz scheduler invokes an EJB, it tags that EJB as running the job. If the EJB fails, the Quartz scheduler marks the job as failed and reschedules it to run later by another EJB.

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.

Parent topic: Oracle Directory Integration Platform High Availability

Configuring High Availability for an Oracle Internet Directory Back-End Server
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:

Configuring Oracle Directory Integration Platform on ODIPHOST1 (OID)
To configure Oracle Directory Integration Platform on ODIPHOST1:
  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 7-6 Managed Server on ODIPHOST1

    Name Listen Address Listen Port

    wls_ods1

    odipHost1.example.com

    7005

    Table 7-7 Managed Server 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 7-8 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 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)

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 7-9 Managed Servers on ODIPHOST1

    Name Listen Address Listen Port

    wls_ods1

    odipHost1.example.com

    7005

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

  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.

Parent topic: Oracle Directory Integration Platform High Availability

Understanding Oracle Directory Integration Platform Failover and Expected Behavior

In a high availability environment, you deploy the Oracle Directory Integration Platform application on a WebLogic Server cluster that comprises at least two WebLogic instances.

By default, the Oracle Directory Integration Platform application leverages high availability features of the underlying WebLogic clusters. In case of hardware or other failures, session state is available to other cluster nodes that can resume the work of the failed node.

In addition, in a high availability environment, Node Manager is configured to monitor the WebLogic servers. In case of failure, Node Manager restarts the WebLogic Server.

If an instance of Oracle Internet Directory fails, the load balancer redirects to the surviving instance of Oracle Internet Directory and the Oracle RAC database. If Oracle Unified Directory fails, the load balancer redirects to the surviving instance of Oracle Unified Directory.

In case of a database instance failure, the surviving Oracle RAC node takes over any remaining processes. There may be innocuous errors in the Managed Servers logs during an Oracle RAC failover; see Troubleshooting Oracle Directory Integration Platform High Availability.

Parent topic: Oracle Directory Integration Platform High Availability

Troubleshooting Oracle Directory Integration Platform High Availability

This section describes how to manage issues involving Oracle Directory Integration Platform high availability.

Parent topic: Oracle Directory Integration Platform High Availability

Managed Server Log File Exception May Occur During an Oracle RAC Failover

During an Oracle RAC failover, exceptions similar to the ones below are seen in the Managed Server log files running the Oracle Directory Integration Platform application. These errors are thrown when the multi data sources configured on the WebLogic Server platform try to verify the health of the Oracle RAC database instances during failover. These are innocuous errors that you can ignore. The Oracle Directory Integration Platform application recovers and begins to operate normally after a lag of one or two minutes. During an Oracle RAC failover, there will be no Oracle Directory Integration Platform down time if one Oracle RAC instance is running at all times.

RuntimeException:
[2008-11-21T00:11:10.915-08:00] [wls_ods] [ERROR] []
[org.quartz.impl.jdbcjobstore.JobStoreTX] [tid: 25] [userId: <anonymous>]
[ecid: 0000Hqy69UiFW7V6u3FCEH199aj0000009,0] [APP: DIP] ClusterManager: Error
managing cluster: Failed to obtain DB connection from data source
'schedulerDS': java.sql.SQLException: Could not retrieve datasource via JNDI
url 'jdbc/schedulerDS' java.sql.SQLException: Cannot obtain connection:
driverURL = jdbc:weblogic:pool:schedulerDS, props =
{EmulateTwoPhaseCommit=false, connectionPoolID=schedulerDS,
jdbcTxDataSource=true, LoggingLastResource=false,
dataSourceName=schedulerDS}.[[
Nested Exception: java.lang.RuntimeException: Failed to setAutoCommit to true
for pool connection

AuthenticationException while connecting to OID:
[2008-11-21T00:12:08.812-08:00] [wls_ods] [ERROR] [DIP-10581] [oracle.dip]
[tid: 11] [userId: <anonymous>] [ecid: 0000Hqy6m54FW7V6u3FCEH199apO000000,0]
[APP: DIP] DIP was not able to get the context with the given details {0}[[
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
Credentials]

Most exceptions are related to the scheduler or LDAP, for example:

  • Could not retrieve datasource via JNDI url 'jdbc/schedulerDS' java.sql.SQLException

  • javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]

Node Manager Fails to Start

If the Node Manager fails to start, ensure that you have copied the nodemanager.domains file from ODIPHOST1 to ODIPHOST2: 

WL_HOME/common/nodemanager/nodemanager.domains
Error Messages May Appear After Starting Node Manager

If you see the following error message after starting Node Manager, follow the procedure described after the error message:

<Dec 15, 2008 8:40:05 PM> <Warning> <Uncaught exception in server handler:
javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was
received from stbee21.example.com - 152.68.64.2155. Check the peer to 
determine why it rejected the certificate chain (trusted CA configuration,
hostname verification). SSL debug tracing may be required to determine the
exact reason the certificate was rejected.> javax.net.ssl.SSLKeyException:
[Security:090482]BAD_CERTIFICATE alert was received from stbee21.example.com -
152.68.64.215. Check the peer to determine why it rejected the certificate chain 
(trusted CA configuration, hostname verification). SSL debug tracing may be
required to determine the exact reason the certificate was rejected.

  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.

Parent topic: Configuring High Availability for Oracle Directory Services Components