Understanding and Designing Serviceguard Disaster Recovery Architectures

(cluster) license beyond Serviceguard is required for this solution, making it the least expensive
to implement.
• You may choose any storage supported by Serviceguard, and the storage can be a mix of
any Serviceguard-supported storage.
• This configuration may be the easiest to understand and manage because it is similar to
Serviceguard in many ways
• Application failover is minimized. All disks are available to all nodes, so that if a primary disk
fails but the node stays up and the replica is available, there is no failover (that is, the
application continues to run on the same node while accessing the replica).
• Data copies are peers, so there is no issue with reconfiguring a replica to function as a primary
disk after failover.
• Writes are synchronous, unless the link or disk is down, so data remains current between the
primary disk and its replica.
• Support for Cross-Subnet configurations; allows you to configure multiple subnets, joined by
a router, both for the cluster heartbeat and for data network, with some nodes using one
subnet and some another.
Benefits of Extended Distance Cluster for RAC
• In addition to the benefits of Extended Distance Cluster, RAC runs in active/active mode in
the cluster, so that all resources in both data centers are utilized. The database and data are
synchronized and replicated across two data centers up to 100km apart. In the event of a
site failure, no failover is required because the instance is already running at the remote site.
• Extended Cluster for RAC implements SLVM so that SGeRAC has a “built-in” mechanism for
determining the status of volume group extents in both data centers (that is, the state of the
volume groups is kept in memory at the remote site), and SLVM does not operate on non-current
data. For Veritas environments, Extended Cluster for RAC is also supported with Cluster File
System (CFS) and Veritas Cluster Volume Manager (CVM).
NOTE: For the most up-to-date support and compatibility information, see the SGeRAC for SLVM,
CVM and CFS Matrix, and the Serviceguard Compatibility and Feature Matrix at http://
www.hp.com/go/hpux-serviceguard-docs.
Support for Cross-Subnet Configurations in Extended Clusters
Beginning with the Serviceguard A.11.18 patches, PHSS_37094 (11i v2) and PHSS_37095 (11i
v3), Cross-Subnet configurations are supported. This allows the nodes in each data center to
configure their heartbeats on subnets that are locally unique to their own data centers. The following
restrictions apply for Cross-Subnet configurations:
• All nodes in the cluster must belong to the same network domain (that is, the domain portion
of the fully-qualified domain name must be the same).
• The nodes must be fully connected at the IP level.
• A minimum of two heartbeat paths must be configured for each cluster node.
• Each heartbeat subnet on each node must be physically routed separately to the heartbeat
subnet on another node; that is, each heartbeat path must be physically separate:
◦ The heartbeats must be statically routed; static route entries must be configured on each
node to route the heartbeats through different paths.
◦ Failure of a single router must not affect both heartbeats at the same time.
Benefits of Extended Distance Cluster for RAC 53