Using Serviceguard Extension for RAC, 8th Edition, March 2009

• If more than one instance of pkgA is running in the cluster and SubnetA fails on one of the
nodes where the instance of pkgA is running, the failure is handled by halting the instance
of pkgA on the node where the subnet has failed.
• If pkgA is running on only one node of the cluster and SubnetA fails on that node, pkgA
will continue to run on that node after the failure.
• If pkgA runs on all nodes of the cluster and SubnetA fails on all nodes of the cluster, the
failure is handled by halting all but one instance of pkgA. Where the instance of pkgA will
be left running is randomly determined.
The following describes the behavior of cluster interconnect subnet monitoring feature under
the following scenarios:
• For a multi-node package with CLUSTER_INTERCONNECT_SUBNET configured, upon an
explicit request to start the package on a node, no attempt to start the package instance on
that node will be made if the subnet is not up on that node.
• If a multi-node package with CLUSTER_INTERCONNECT_SUBNET configured is running
on only one node of the cluster, with the subnet that it monitors is down on all nodes of the
cluster, the restoration of the subnet on any other node does not affect the running instance.
No attempt will be made automatically to start the package instance on the restored node.
An attempt to start the instance of the package on the restored node will be made, if the user
explicitly tries to start the package instance.
• If a multi-node package with CLUSTER_INTERCONNECT_SUBNET is running on more than
one node of the cluster, upon a failure of the subnet on all nodes where the package is
running, all but one package instance will be halted one by one. Additionally if
NODE_FAIL_FAST_ENABLED is set to “YES” for such a package, all but one node will be
brought down one by one, that is one node will be brought down, cluster reformation will
happen, another node will be brought down, cluster reformation will happen and so on till
one node remains in the cluster.
NOTE: The CLUSTER_INTERCONNECT_SUBNET parameter is available only for use with
multi-node packages.
For more information on the Cluster Interconnect Subnet Monitoring feature, refer to chapter 2,
section “Cluster Communication Network Monitoring” (page 37). This section describes various
network configurations for cluster communications in an SGeRAC/10g or 11gR1 RAC cluster,
and how the package configuration parameter CLUSTER_INTERCONNECT_SUBNET can be used
to recover from Oracle Cluster Communications network failures.
Overview of SGeRAC and Oracle 9i RAC
This section describes some of the central components and functionality for SGeRAC and Oracle
9i RAC.
How Serviceguard Works with Oracle 9i RAC
Serviceguard provides the cluster framework for Oracle, a relational database product in which
multiple database instances run on different cluster nodes. A central component of Real
Application Clusters is the distributed lock manager (DLM), which provides parallel cache
management for database instances. Each node in a RAC cluster starts an instance of the DLM
process when the Oracle instance starts and the instances then communicate with each other
over the network.
Group Membership
The group membership service (GMS) is the means by which Oracle instances communicate
with the Serviceguard cluster software. GMS runs as a separate daemon process that communicates
with the cluster manager. This daemon is an HP component known as cmgmsd.
20 Introduction to Serviceguard Extension for RAC