Building Disaster Recovery Serviceguard Solutions Using Metrocluster with EMC SRDF

gather information about service availability on the RAC servers and assist in making client
connections to the RAC instances. In addition, they provide failure notifications and load advisories
to clients, therefore enable fast failover of client connections and client-side load-balancing. These
capabilities are facilitated by an Oracle 10g feature called Fast Application Notification (FAN).
For more information about Fast Application Notification, see the following documents:
http://www.oracle.com/technology/products/database/clustering/pdf/twpracwkldmgmt.pdf
http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_ClientFailoverBestPractices.pdf
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
as the active sub-cluster for the database. The client connectivity features related to fast failover
and load balancing described earlier 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 is 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 keeps 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 brings 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 about network planning for Oracle Clusterware communication, see the latest
edition of Using Serviceguard Extension for RAC manual available at http://www.hp.com/go/
hpux-serviceguard-docs-> HP Serviceguard Extension for RAC.
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.
118 Configuring Oracle RAC in SADTA