Protection from Failures and Expected Behavior

Configuring High Availability for Identity Management Components 8-21 cn=dsaconfig,cn=configsets,cn=osdldapd,cn=oracle internet directory If you want to retain instance-specific server configuration attributes for each Oracle Internet Directory instance in the cluster, then you should choose a distinct Oracle Internet Directory component name for each Oracle Internet Directory instance at installconfiguration time; for example, oid1 on node1 and oid2 on node2. In this case, the configuration entries will be cn=oid1,cn=osdldapd,cn=subconfigsubentry and cn=oid2,cn=osdldapd,cn=subconfigsubentry respectively and they need to be updated separately for each Oracle Internet Directory instance. On the other hand, if you chooses to have a common set of server configuration attributes for both Oracle Internet Directory instances in the cluster, then you should choose the same Oracle Internet Directory component name for both Oracle Internet Directory instances, for example, oid1 on both Oracle Internet Directory node1 and node2. In this case, there will be one common configuration entry cn=oid1,cn=osdldapd,cn=subconfigsubentry. Oracle Internet Directory LDAP server instances cache certain LDAP metadata artifacts such as Schema, ACLs, and Password Policy. Multiple Oracle Internet Directory LDAP server processes on a given node keep their caches in sync via semantics built around a shared memory segment managed by Oracle Internet Directory on each node. OIDMON keeps these caches in sync across nodes by ensuring that these shared memory segments are in sync across the nodes, which is achieved using the Oracle Internet Directory database. Oracle Internet Directory also caches metadata and metadata changes trigger notification across the nodes. The ldapmodify utility is used to change metadata. The Oracle Internet Directory server that gets the ldapmodify request for the metadata change notifies other Oracle Internet Directory servers about the change of metadata including OIDMON. OIDMON is responsible for notifying OIDMON on other nodes about the metadata changes.

8.3.2.2 Protection from Failures and Expected Behavior

This section discusses protection from different types of failure in an Oracle Internet Directory Cluster Configuration.

8.3.2.2.1 Oracle Internet Directory Process Failure OIDMON monitors Oracle Internet

Directory processes. If the Oracle Internet Directory process goes down, OIDMON tries to restart it. OPMN monitors OIDMON. If OIDMON goes down, OPMN restarts OIDMON. If an Oracle Internet Directory process cannot be restarted, then the front-ending load balancing router detects failure of Oracle Internet Directory 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 Oracle Internet Directory instance in the Cluster Configuration gets hung, the load balancing router detects this and routes requests to surviving instances. If one of the Oracle Internet Directory instances 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 Oracle Internet Directory instance.

8.3.2.2.2 Expected Client Application Behavior When Failure Occurs Oracle Internet

Directory server failure is usually transparent to Oracle Internet Directory clients as 8-22 Oracle Fusion Middleware High Availability Guide they continue to get routed through the load balancer. External load balancers are typically configured to perform a health check of Oracle Internet Directory 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 Oracle Internet Directory instance and the request should be successful. In Oracle Internet Directory 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 Oracle Internet Directory 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.

8.3.2.2.3 External Dependency Failure This section describes the protection available for

Oracle Internet Directory from database failure. By default, the tnsnames.ora file configured in Oracle Internet Directorys ORACLE_INSTANCE ensures that Oracle Internet Directorys connections to the database are load balanced between the Oracle RAC database instances. For example, if an Oracle Internet Directory 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, Oracle Internet Directory 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 Transparent Application Failover TAF and high availability event notification are configured, Transparent Application Failover 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 allows Oracle Internet Directory to reconnect to the database. If none of the database instances are available for a prolonged period, then the Oracle Internet Directory LDAP and REPL processes will automatically be shut down. However, OIDMON and OPMN will continue to ping for the database instance availability and when the database becomes available, the Oracle Internet Directory processes LDAP and REPL are automatically restarted by OIDMON. While all the database instances are down, OIDMON will continue to be up and an opmnctl status command will show that OIDLDAPD instances are down. When a database instance becomes available, OIDMON will restart all configured Oracle Internet Directory instances. All database failover induced activity for Oracle Internet Directory is recorded in the OIDMON log file.

8.3.2.3 Oracle Internet Directory Prerequisites