Oracle Internet Directory Administrator's Guide Release 3.0.1 Part Number A90151-01 |
|
Oracle9i 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:
You can run a directory server on a node that is different from the one running the cluster database. The computer on which the directory server runs may be part of the cluster.
This section contains these topics:
In this case, a single directory server connects to two or more Real Application Clusters instances, each running on different nodes. This scenario is easy to configure and, on the node where the primary instance is running, it provides greater resilience after either a hardware or software failure.
Figure 21-1 shows the setup in detail.
Figure 21-1 shows a three-node cluster. Real Application Clusters Instance 1 runs on Node 1. Real Application Clusters Instance 2 runs on Node 2. The directory server instance runs on Node 3.
Normally, the directory server instance communicates with the Real Application Clusters Instance on Node 1, which is the primary instance. However, in the event of either a hardware or software failure on a Node 1, Oracle Net Services can redirect database requests to the Real Application Clusters instance on Node 2, the secondary instance.
To specify the primary instance, in the initialization file, set the ACTIVE_INSTANCE_COUNT
parameter to 1
for both instances. The instance you start first becomes the primary instance.
The primary instance can accept connections from its local listener, as well as from the secondary instance listener. A secondary instance registers with its local listener as a secondary instance, and like the primary instance, its ACTIVE_INSTANCE_COUNT
parameter is set to 1
. If the primary instance fails, then the secondary instance assumes the primary role and registers with its listeners. When the failed instance can once again start, it does so as the secondary instance. If you have failover configured, then directory server connections to the failed primary instance fail over to the secondary instance.
The following is an example of a tnsnames.ora
file configured for a connect-time failover. In this example, the LOAD_BALANCE
must be set to OFF
.
MY_CLUSTER = (DESCRIPTION = (LOAD_BALANCE = OFF) (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_2)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com)) ) MY_CLUSTER_1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_2)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com) (INSTANCE_NAME = my_cluster_1) ) ) MY_CLUSTER_2 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = dlsun722)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com) (INSTANCE_NAME = my_cluster_2) ) )
The following is an example of a listener.ora
file configured for a connect-time failover.
LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0)) ) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = my_host)(PORT = 1521)) ) ) )
The following is an example of a tnsnames.ora
file configured for a transparent application failover (TAF).
MY_CLUSTER = (DESCRIPTION = (FAILOVER = ON) (LOAD_BALANCE = OFF) (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_2)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = PRECONNECT) (BACKUP = ops1)) ) ) MY_CLUSTER_1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_2)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com) (INSTANCE_NAME = ops1) ) ) MY_CLUSTER_2 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_1)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com) (INSTANCE_NAME = my_cluster_2) ) )
The following is an example of a listener.ora
file configured for a transparent application failover (TAF)
LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0)) ) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_1)(PORT = 1521)) ) ) )
In this case, there are multiple directory server threads connecting to two or more Real Application Clusters instances on different nodes. To achieve this, you can set the LOAD_BALANCE
parameter of Oracle Net Services to ON
.
Figure 21-2 shows a three-node cluster. Real Application Clusters Instance 1 runs on Node 1. Real Application Clusters Instance 2 runs on Node 2. A directory server instance with Directory Server Thread #1 and Directory Server Thread #2 runs on Node #3.
See Also:
Oracle9i Net Services Administrator's Guide for instructions on setting the |
Depending on how the Oracle Net Services routes the LDAP request, when all nodes in Figure 21-2 are running, directory server thread 1 may connect to Real Application Clusters Instance 1, and directory server thread 2 may connect to Real Application Clusters Instance 2. Incoming LDAP requests to the directory server are distributed in round-robin fashion to both directory database connections. If there is a hardware or software failure on node 1, then directory server thread 1 reconnects to Real Application Clusters Instance 2 by using connection time failover or Oracle Net transparent application failover.
The scenario in this example provides higher availability and scalability. If the database or database host fails, then it provides resilience by using connection time failover or Oracle Net transparent application failover. Moreover, it provides higher throughput for complicated LDAP subtree searches. However, it may induce a cluster pinging problem if there is a large volume of updates, and it does not recover in the event of failure on the node running the directory server.
To configure your system for this scenario, examine the following examples of the various configuration files.
The following example shows a tnsnames.ora
file configured for a connect-time failover.
MY_CLUSTER = (DESCRIPTION = (LOAD_BALANCE = ON) (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_2)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com)) ) MY_CLUSTER_1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_2)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com) (INSTANCE_NAME = my_cluster_1) ) ) MY_CLUSTER_2 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_1)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com) (INSTANCE_NAME = my_cluster_2) ) )
The following example shows a listener.ora
file configured for connect time failover.
# LISTENER.ORA Network Configuration # File: D:\oracle\ora81\database\opstemp\atlnt10i\network\admin\listener.ora # Generated by Oracle configuration tools. LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0)) ) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = dlsun722)(PORT = 1521)) ) ) )
The following two examples show two tnsnames.ora
files, one for my_host_1
and the other for my_host_2
, configured for a transparent application failover (TAF).
The tnsnames.ora
on my_host_1
:
MY_CLUSTER = (DESCRIPTION = (FAILOVER = ON) (LOAD_BALANCE = ON) (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_2)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = PRECONNECT) (BACKUP = my_host_1)) ) ) MY_CLUSTER_1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_2)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com) (INSTANCE_NAME = my_company_1) ) ) OPS2 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_1)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com) (INSTANCE_NAME = my_company_2) ) )
The tnsnames.ora
on my_host_2
:
MY_CLUSTER = (DESCRIPTION = (FAILOVER = ON) (LOAD_BALANCE = ON) (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_2)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = PRECONNECT) (BACKUP = my_company_2)) ) ) MY_CLUSTER_1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_1)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com) (INSTANCE_NAME = my_cluster_1) ) ) MY_CLUSTER_2 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_2)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = my_cluster.my_company.com) (INSTANCE_NAME = my_cluster_2) ) )
Figure 21-3 shows a possible Oracle directory replication server in an Oracle Real Application Clusters environment.
There are three nodes in this configuration. A directory server instance runs on Node 3, and Real Application Clusters instances run on Node 1 and Node 2. When all nodes are running, the directory replication server connects to the directory server instance, and the Oracle9i Replication push jobs are running on both Real Application Clusters instances. If there is any hardware failure on Node 3, the directory replication server on Node 2 restarts and connects to directory server instance 2. If any hardware failure happens on Node 2, then, after cluster reconfiguration, the Oracle9i Replication push job continues on Real Application Clusters instance 1.
This scenario provides resilience in the event of database or database host failure for replication data transfer, that is, an Oracle9i Replication push job. It also provides resilience in the event of a directory server instance or host failure, or failure for the directory replication server.
|
Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|