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

19
Figure 8 – Example tnsnames.ora configuration file for a single instance and a RAC database in non cross-subnet
configuration.
DB_SRV =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = db-srv.hp.com)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = DB_SRV)
)
)
DB_RAC =
(DESCRIPTION =
(ADDRESS_LIST=
(FAILOVER = on)
(LOAD_BALANCE = on)
(ADDRESS = (PROTOCOL = TCP)(HOST = racvip1.hp.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = racvip2.hp.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = racvip3.hp.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = racvip4.hp.com)(PORT = 1521))
)
(CONNECT_DATA=
(SERVICE_NAME = DB_RAC)
)
)
In a non-cross-subnet cluster, the first entry would be appropriate for clients connecting to a single
instance Oracle database which is available through a relocatable IP address that maps to the
db-serv.hp.com name. The second entry would be appropriate for clients connecting to a 4 node
SGeRAC cluster through one of the Oracle VIPs. In both cases, clients use the service name “DB_SRV”
or “DB_RAC” in their connect string and will be directed to the listener on an appropriate cluster
node.
Client access to a single instance Oracle database
The two IP addresses under which a single instance Oracle database can be available to clients in a
cross-subnet cluster is controlled by Serviceguard. Serviceguard relocates the IP address along with
the database from one node to another. Serviceguard guarantees that:
 Only one of them is active at any given time.
 The appropriate relocatable IP address is active on the node where the database is running.
 If multiple single instance databases are configured in a cluster, each of them has its own dedicated
pair of relocatable IP addresses.
The connect descriptor for the single instance database from Figure 8 can also be used in a cross-
subnet configuration if the name resolution for “db-srv.hp.com” changes on a package failover to
an IP address of a different subnet. Methods of how to achieve this are discussed in the “General
application integration considerations” section.
Guiding new client connections to an available database instance after a failure
Adding a second protocol address to the connect descriptor in the tnsnames.ora file allows the
configuration of Oracle client side connect-time failover (CTF). Each of the HOST definitions in the
protocol address would resolve to a relocatable IP address of a different subnet. E.g.: db-srv1
would resolve to an IP address in a subnet at site 1 and db-srv2 would resolve to an IP address in a
subnet at site 2. With this method, the clients are aware of the two potential different location of the