Technical Considerations for a Serviceguard Cluster that Spans Multiple IP Subnets, July 2009

“15.84.120.5 ” will return “db-srv1.hp.com” and not “db-srv.hp.com”. Clients and

applications need to be analyzed if they require a consistent reverse lookup.

Oracle in a cross-subnet cluster

Oracle single-instance and RAC databases can be protected in a cross-subnet Serviceguard cluster.

The Enterprise Cluster Master Toolkit (ECMT) simplifies the integration of a single-instance Oracle

database in a Serviceguard cluster. The Serviceguard Extension for RAC (SGeRAC) increases

availability and simplifies management of Oracle RAC. Both deliver rapid automatic detection and

recovery from a wide range of hardware, software, network, and storage failures thus increasing the

availability of your applications.

SGeRAC is supported in cross-subnet environments only when used with Metrocluster in a Site Aware

Disaster Tolerant Architecture (SADTA). This architecture consists of 2 Oracle sub-clusters in a single

SGeRAC cluster. At any time, a given database is accessed through only one of the Oracle sub-

clusters. Oracle does not allow a single RAC cluster to span multiple subnets.

For details about how to configure SGeRAC with Metrocluster in a SADTA, please see Chapter 7 of

the “Designing Disaster Tolerant HA Clusters Using Metrocluster and Continentalclusters” manual.

The installation and configuration of ECMT and SGeRAC are documented in the respective manuals.

This document focuses on the client connectivity to an Oracle database that becomes available at a

different IP address after a site failure in a cross-subnet cluster.

Client access to Oracle databases

Oracle client libraries are linked with applications that need to connect to an Oracle database.

Depending on the applications software development technology, different client libraries are

available from Oracle. Some examples are: Java Database Connectivity (JDBC) for Java applications

and Oracle Call Interface (OCI) for applications coded in C. These client libraries are responsible for

the communication layer between the application (client) and the database. Such applications are

considered database clients in this document.

To assist with client failover and reconnect capabilities, clients don’t connect directly to database

instances, but rather use an “abstraction” layer called “services” and request connection information

from an Oracle LISTENER process. The information about how to connect to a LISTENER is stored

in a configuration file - TNSNAMES.ORA on the client.

In a tnsnames.ora file, connection information for an Oracle service is associated with an alias, or

Oracle net service name. Each net service name entry contains connect descriptors that define listener

and service information. The following example in Figure 8 shows connection information in a

tnsnames.ora file configured for the net service name entry DB_SRV and DB_RAC .