Oracle Internet Directory Administrator's Guide Release 9.0.2 Part Number A95192-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:
A computer where an instance resides. It can be part of a Massively Parallel Computing Infrastructure where 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 different nodes, that coordinate with one another 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.
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 a another listener if the first listener is not responding. It is enabled by service registration, because the listener knows if an instance is running before attempting a connection.
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 26-1 shows the setup in detail.
Figure 26-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 = 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 connect-time failover on my_host_1.
LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0)) ) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_1)(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) on my_host_1:
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 26-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.
Depending on how the Oracle Net Services routes the LDAP request, when all nodes in Figure 26-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.
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 on my_host_1:
# LISTENER.ORA Network Configuration # Generated by Oracle configuration tools. LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0)) ) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = my_host_1)(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) ) ) 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_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 26-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 © 1999, 2002 Oracle Corporation. All Rights Reserved. |
|