Understanding and Designing Serviceguard Disaster Recovery Architectures

The Volume Monitor must be configured as a service within a Metrocluster package. For Site
Controller package, the volume monitor must be configured as part of workload packages that
requires access to VxVM or LVM storage volumes.
When a monitored volume fails or becomes inaccessible, the monitor service exits, causing the
package to fail on the current node. The failover of package depends on its configured settings
and on the application behavior.
For more information, see About the Volume Monitor in the document Managing Serviceguard,
the latest edition is available at www.hp.com/go/hpux-serviceguard-docs -> HP Serviceguard.
Disk Monitor Configuration
HP Serviceguard for Linux A.11.20.10 includes a Disk Monitor which you can use to detect
problems accessing the disks. In the case of a disk connectivity failure, the disk monitor configuration
allows you to failover a package from one node to another node in a cluster. The disk monitor
must be configured as a service within a Metrocluster or Continentalclusters package. To configure
disk monitoring, see Creating a Disk Monitor Configuration section in Managing HP Serviceguard
A.11.20.10 for Linux available at www.hp.com/go/linux-serviceguard-docs.
Benefits of Metrocluster
The following are the benefits of Metrocluster:
• Metrocluster offers a more resilient solution than Extended Distance Cluster, because provides
full integration between Serviceguard’s application package and the data replication subsystem.
The storage subsystem is queried to determine the state of the data on the arrays. In a
Metrocluster configuration, application data is replicated between two data centers.
Metrocluster evaluates the status of the local and remote copies of the data, including whether
the local site holds the primary copy or the secondary copy of data, whether the local data
is consistent or not and whether the local data is current or old. Based on the result of this
evaluation, Metrocluster checks if it is safe to start the application package, whether a
resynchronization of data is needed before the package can start, or whether manual
intervention is required to determine the state of the data before the application package is
started. Metrocluster allows for customization of the startup behavior for application packages
depending on your requirements, such as data currency or application availability. This means
that by default, Metrocluster will always prioritize data consistency and data currency over
application availability. If, however, you choose to prioritize availability over currency, you
can configure Metrocluster to start up even when the state of the data cannot be determined
to be fully current (but the data is consistent).
• Metrocluster can be configured using any one of the replication modes supported by Continuous
Access XP or P9000, Continuous Access EVA or P6000, or EMC SRDF (on HP-UX only) or
3PAR Remote Copy. These replication modes enable you to prioritize performance and data
currency between data centers based on your requirements. Details on the replication modes
supported are available in the Compatibility Feature Matrix documents. For the HP-UX
Compatibility Feature Matrix, see www.hp.com/go/hpux-serviceguard-docs and select the
respective Metrocluster Product. For the Linux Compatibility Feature Matrix, see www.hp.com/
go/linux-serviceguard-docs.
• Metrocluster may provide significantly better performance than Extended Distance Cluster
during recovery because data replication and resynchronization are performed by the storage
subsystem. Unlike Extended Distance Cluster, Metrocluster does not require any additional
CPU time, which minimizes the impact on the host.
• The data written to the local copy is updated to the remote copy with little or no lag time. So,
the data remains current in the remote copy as well. Data can be copied in both directions,
so that if the primary site fails and the replica takes over, data can be copied back to the
primary site when it comes back up. Disk resynchronization is independent of CPU failure
26 Metrocluster and Continentalclusters