Managing Serviceguard Sixteenth Edition, March 2009

monitored for this package are configured for PARTIAL access, each node on the
node_name list must have at least one of these subnets configured.
— As in other configurations, a package will not start on a node unless the subnets
configured on that node, and specified in the package configuration file as
monitored subnets, are up.
NOTE: See also the Rules and Restrictions (page 39) that apply to all cluster
networking configurations.
For More Information
For more information on the details of configuring the cluster and packages in a
cross-subnet context, see “Obtaining Cross-Subnet Information” (page 220), “About
Cross-Subnet Failover” (page 188) and (for legacy packages only) “Configuring
Cross-Subnet Failover” (page 347).
IMPORTANT: Although cross-subnet topology can be implemented on a single site,
it is most commonly used by extended-distance clusters, and specifically site-aware
disaster-tolerant clusters, which require HP add-on software.
Design and configuration of such clusters are covered in the disaster-tolerant
documentation delivered with Serviceguard. For more information, see the following
documents at http://www.docs.hp.com -> High Availability:
• Understanding and Designing Serviceguard Disaster Tolerant Architectures
• Designing Disaster Tolerant HA Clusters Using Metrocluster and Continentalclusters
• The white paper Configuration and Administration of Oracle 10g R2 RAC Database in
HP Metrocluster
Replacing Failed Network Cards
Depending on the system configuration, it is possible to replace failed network cards
while the cluster is running. The process is described under “Replacement of LAN
Cards” in the chapter “Troubleshooting Your Cluster.” With some restrictions, you
can also add and delete LAN interfaces to and from the cluster configuration while the
cluster is running; see “Changing the Cluster Networking Configuration while the
Cluster Is Running” (page 331).
Redundant Disk Storage
Each node in a cluster has its own root disk, but each node is also physically connected
to several other disks in such a way that more than one node can obtain access to the
data and programs associated with a package it is configured for. This access is provided
by a Storage Manager, such as Logical Volume Manager (LVM), or Veritas Volume
Manager (VxVM) (or Veritas Cluster Volume Manager (CVM). LVM and VxVM disk
storage groups can be activated by no more than one node at a time, but when a failover
Redundant Disk Storage 43