Designing Disaster Recovery Clusters using Metroclusters and Continentalclusters, Reprinted October 2011 (5900-1881)

FAN capabilities can be accessed by the client application using the FAN API directly or by using
FAN-integrated clients provided by Oracle.
The Metrocluster RAC configuration uses two Oracle sub-clusters in a single SGeRAC cluster. At
any time, a given database is accessed through only one of the Oracle sub-clusters. It is referred
to as the active sub-cluster for the database. The client connectivity features mentioned above
related to fast failover and load balancing are available from the active sub-cluster. When the
database fails over to the other sub-cluster, the same features are available from that sub-cluster.
However, the client connections must be made to the VIPs configured in that Oracle sub-cluster.
There are several factors that limit the speed of client reconnection when the database fails over
across sub-clusters. Following is the sequence of steps that occur when any database fails over:
1. Ensures that the database has been completely shut down at the formerly active sub-cluster.
2. Fails over the disk device group to the newly active sub-cluster so that the database replica
LUNs become available for read-write access.
3. Starts the CVM disk groups and CFS mount points for the database at the newly active
sub-cluster, and then starts the RAC database there.
While these steps are being performed, client connections cannot be made to the database. Also,
there is no FAN event delivered to indicate site failover, so existing client connections may be
susceptible to delays as long as the TCP keep alive timeout in some cases, before a reconnect is
attempted.
To automatically reconnect clients to the database on a site failover, the Oracle Net service names
must include VIPs configured at both sub-clusters. For example:
hr_serv1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = SFO_1v.hp.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = SFO_2v.hp.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = SJC_1v.hp.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = SJC_2v.hp.com)(PORT = 1521))
(LOAD_BALANCE = yes)
)
(CONNECT_DATA=
(SERVICE_NAME=hr_serv1)
)
)
Configuring SGeRAC Cluster Interconnect Subnet Monitoring
SGeRAC provides a feature to monitor the Oracle Clusterware interconnect subnet and to ensure
that at least one RAC instance survives when a failure takes down the entire interconnect subnet
in the cluster.
To configure this feature, the interconnect subnet must be specified in a separate MNP package
using the CLUSTER_INTERCONNECT_SUBNET package attribute. The Clusterware MNP package
for the Clusterware sub-cluster must have a dependency specified on this interconnect MNP package.
For more information on network planning for Oracle Clusterware communication, see the Using
Serviceguard Extension for RAC manual available at http://www.hp.com/go/
hpux-serviceguard-docs.
The Oracle Clusterware interconnect subnet for a site Clusterware sub-cluster is a subnet spanning
only the nodes in that site (it is not required to route it across the sites). The interconnect subnets
at each site is packaged in a separate MNP package.
Complete the following procedure to configure the SGeRAC Cluster Interconnect packages:
382 Designing a Disaster Recovery Solution Using Site Aware Disaster Tolerant Architecture