Using Serviceguard Extension for RAC, 9th Edition, September 2010

How Cluster Interconnect Subnet Works
The CLUSTER_INTERCONNECT_SUBNET parameter works similar to the existing SUBNET package
configuration parameter. The most notable difference is in the failure handling of the subnets
monitored using these individual parameters.
While the failure of subnets monitored using SUBNET package configuration parameter is handled
by halting the instance of the package on the node where the subnet has failed, the failure of
subnets monitored using CLUSTER_INTERCONNECT_SUBNET package configuration parameter
is handled by ensuring at least one instance of the multi-node package remains running in the
cluster.
For example, when a multi-node package (pkgA) is configured to run on all nodes of the cluster,
and configured to monitor a subnet (SubnetA) using the CLUSTER_INTERCONNECT_SUBNET
parameter:
• 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. For example, one node will be brought down, cluster reformation
will happen, another node will be brought down, and cluster reformation will happen until
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/11gR2 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.
20 Introduction to Serviceguard Extension for RAC