26
Directory Failover in an Oracle9i Real Application Clusters Environment

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:

Terminology

Node

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

A set of instances, each typically running on different nodes, that coordinate with one another when accessing the shared database on the disk.
Cluster Manager

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.
Connect-time failover

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.

The Oracle Directory Server in an Oracle9i Real Application Clusters Environment

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:

Oracle Internet Directory with Basic High Availability Configuration

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 Oracle Internet Directory with Basic High Availability Configuration

Text description of oidag040.gif follows

Text description of the illustration oidag040.gif

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

Note:

Depending on the state of the directory server when the database failure occurs, Oracle Internet Directory may not successfully manage the transparent application failover. In this case, Oracle Internet Directory logs "ORA-3113--End of file on Communication Channel" in the log file and re-establishes a new database connection against a live database instance.

If failover happens during any LDAP operation, then the client receives either the "DSA unwilling to perform" or the "ldapbind: Operations" error. When this happens, the client can simply reissue the request to the directory server.

Oracle Internet Directory with Default N-Node Configuration

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.

See Also:

Oracle9i Net Services Administrator's Guide in the Oracle Database Documentation Library for instructions on setting the LOAD_BALANCE parameter

Figure 26-2 Single Directory Server Instance on One Node and Multiple Real Application Clusters Instances

Text description of oidag039.gif follows

Text description of the illustration oidag039.gif

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

The Oracle Directory Replication Server in an Oracle9i Real Application Clusters Environment

Figure 26-3 shows a possible Oracle directory replication server in an Oracle Real Application Clusters environment.

Figure 26-3 Directory Replication Server in an Oracle Real Application Clusters Environment

Text description of oidag042.gif follows

Text description of the illustration oidag042.gif

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.

26Directory Failover in an Oracle9i Real Application Clusters Environment