| Oracle® Application Server High Availability Guide 10g Release 2 (10.1.2) B14003-05 |
|
 Previous |
 Next |
| Oracle® Application Server High Availability Guide 10g Release 2 (10.1.2) B14003-05 |
|
Previous |
Next |
Oracle Real Application Clusters is a computing environment that harnesses the processing power of multiple, interconnected computers. Along with a collection of hardware, called a cluster, it unites the processing power of each component to become a single, robust computing environment. A cluster comprises two or more computers, also called nodes.
This chapter discusses the ways you can run Oracle Internet Directory in an Oracle Real Application Clusters system. It contains these topics:
Section 11.2, "Installing Oracle Internet Directory against a Real Application Clusters Database"
Section 11.3, "Oracle Internet Directory in an Oracle Real Application Clusters Environment"
Section 11.6, "About Changing the ODS Password on a Real Application Clusters Node"
Node
A computer where an instance resides. It can be part of a Massively Parallel Computing Infrastructure in which it shares disk storage with other nodes. In most cases, a node has its own copy of the operating system.
A set of instances, each typically running on a different node, that coordinate with each other when accessing the shared database on the disk
An operating system-dependent component that discovers and tracks the membership state of nodes by providing a common view of cluster membership across the cluster
Transparent Application Failover (TAF)
A runtime failover for high-availability environments, such as Oracle Real Application Clusters and Oracle Fail Safe, that refers to the failover and re-establishment of application-to-service connections. It allows client applications to automatically reconnect to the database if the connection fails, and optionally resume a SELECT statement that was in progress. This reconnect happens automatically from within the Oracle Call Interface (OCI).
The client notices no connection loss as long as there is one instance left serving the application.
Failover method in which a client connect request is forwarded to another listener if the first listener is not responding. It is enabled by service registration, because the listener knows whether an instance is running before attempting a connection.
For information on installing Oracle Internet Directory against a Real Application Clusters database, see the chapter entitled "Installing in High Availability Environments: OracleAS Cluster (Identity Management)" in the Oracle Application Server Installation Guide.
To achieve a very comprehensive high availability configuration, you can configure Oracle Internet Directory to run in the Real Application Clusters active-active mode. This involves running Oracle Internet Directory processes and the Oracle Internet Directory-designated database on all the Real Application Clusters nodes.
Figure 11-1 shows a two-node cluster on which an Oracle Real Application Clusters database is configured.
As Figure 11-1 shows:
Oracle directory server instance 1 is active on Real Application Clusters Node 1 and Oracle directory server instance 2 is active on Real Application Clusters Node 2. Note that multiple Oracle directory server instances can be started on each node.
Oracle directory integration and provisioning server instances are active on both nodes.
The Oracle directory replication server instance is active on one node only. If the node fails, then the OID Monitor on the surviving node pulls the Oracle directory replication server instance from the failed node and starts it on the surviving node.
The LDAP client applications can be configured to communicate with Oracle Internet Directory on different Real Application Clusters nodes directly. Alternatively, the Oracle Internet Directory server instances can be front-ended by a LAN redirector to get a single system image of the Real Application Clusters nodes.
When one Real Application Clusters node is unavailable because of failure or maintenance purposes, Oracle Internet Directory on the other Real Applications Clusters node is available. The LDAP clients connected to Oracle Internet Directory on the failed Real Applications Clusters node must reconnect.
This section discusses the various connection modes possible for Oracle directory server instances communicating with Oracle Real Application Clusters database instances. These connection modes are transparent to the Oracle Internet Directory clients, and do not affect the way in which Oracle Internet Directory communicates with its clients.
This section contains these topics:
If the load_balance parameter in the tnsnames.ora file is set to ON, then Oracle Internet Directory connections to the Oracle Database are distributed to each Oracle Database node. During failover of any node, only connections to the failed node are redirected to the available Oracle Database nodes.
If the load_balance parameter is set to off, then all the Oracle Internet Directory connections to the Oracle Database are to one Oracle Database node only.
During failover, all the connections are redirected to the available Oracle Database nodes.
At the time of connection to the Oracle Database by the Oracle directory servers, if the primary Oracle Database node is not available, then Oracle Internet Directory servers connect to the backup—that is, secondary—database.
To configure TAF, in the tnsnames.ora file, add type=select and method=preconnect.
During any LDAP search operation, if the primary Oracle Database node fails, then the Oracle directory server transparently connects to the backup—that is, the secondary—Oracle Databasee node, and the current LDAP search operation continues.
This section shows configurations of the tnsnames.ora files on two nodes.
Node 1
db.us.acme.com=
(description=
(load_balance=off/on) /* only connect time load balancing & connection load balancing */
(failover=on) /* only connect time failover */
(address=
(protocol=tcp)
(host=db1)
(port=1521))
(address=
(protocol=tcp)
(host=db2)
(port=1521))
(connect_data=
(service_name=db.us.acme.com)
(failover_mode=
(backup=db2.acme.com)
(type=select)
(method=preconnect))))
db2.acme.com=
(description=
(address=
(protocol=tcp)
(host=db2)
(port=1521))
(connect_data=
(service_name=db.us.acme.com)
(instance_name=db2)
(failover_mode=
(backup=db2.acme.com)
(type=select)
(method=preconnect))
))
Node 2
db.us.acme.com=
(description=
(load_balance=off/on) /* only connect time load balancing & connection load balancing */
(failover=on) /* only connect time failover */
(address=
(protocol=tcp)
(host=db2)
(port=1521))
(address=
(protocol=tcp)
(host=db1)
(port=1521))
(connect_data=
(service_name=db.us.acme.com)
(failover_mode=
(backup=db1.acme.com)
(type=select)
(method=preconnect))))
db1.acme.com=
(description=
(address=
(protocol=tcp)
(host=db1)
(port=1521))
(connect_data=
(service_name=db.us.acme.com)
(instance_name=db2)
(failover_mode=
(backup=db2.acme.com)
(type=select)
(method=preconnect))))
Directory replication can be configured between two or more Oracle Internet Directory Real Application Clusters nodes.
Each node in the directory replication group (DRG) is an Oracle Internet Directory Real Application Clusters node
Directory replication brings in geographic availability, and the Oracle Internet Directory Real Application Clusters nodes in the DRG ensure local availability, manageability, and scalability
|
Note: If the primary node running either the directory replication server (oidrepld), or the Oracle directory integration and provisioning server (odisrv), or both fails, then the OID Monitor on the secondary node starts these processes on the secondary node after five minutes. However, when the primary node is restarted, these servers are not automatically restarted on the primary node.
Normal shutdown is not treated as a failover—that is, after a normal shutdown, the OID Monitor on the secondary node does not start these processes on the secondary node after five minutes. However, as in the case of a failure, when the primary node is restarted, these servers are not automatically restarted on the primary node. |
If you change the ODS password on one Real Application Clusters node by using the OID Database Password Utility, then you must update the wallet $ORACLE_HOME/ldap/admin/oidpwdlldap1 on the other Real Application Clusters nodes. Do this either by copying the changed wallet to all the nodes, or by invoking the OID Database Password Utility on all other nodes to update the wallet file only. This applies to the replication password changes also. Here the Replication Environment Management Tool is used instead of the OID Database Password Utility.
