failover, including storage array resynchronization. No automation of site failover or recovery is
supported or available.
Red Hat fully supports the use of multi-site disaster recovery clusters. However, a formal architecture
review and approval by Red Hat is required to obtain software support.
Stretch cluster configurations
Some users prefer to implement a disaster tolerant system by stretching a single cluster across multiple
physically separate sites. For these users, Red Hat supports four specific RHEL stretched cluster system
configurations (Red Hat uses the term stretch cluster). These configurations are limited to two sites
containing cluster nodes and optional storage replicas; optionally, a third site can be used to host a
quorum device.
There is a limit on the maximum allowable distance between sites. This limit is expressed in terms of
the maximum packet latency on networks connecting the two sites. It must not exceed a 2 ms round
trip time under moderate load conditions, a value Red Hat considers characteristic of a LAN. Red Hat
does not provide guidelines for determining acceptable physical distances between sites.
Cluster network traffic between the two sites must not be routed. When using RHEL5 cluster software,
the cluster network must support either multicasting or broadcasting. RHEL6.2 supports UDP unicast in
addition to multicasting and broadcasting.
If a stretched cluster's services require storage, the supported configurations permit use of three
different storage replication methods:
• LVM (software-based) mirroring over a shared SAN
• Synchronous coherent array-based replication
• Only one form of active/passive array-based replication
In the latter case, one site's array is active and accessible in normal operation to all nodes in the
stretched cluster through a shared SAN; the other site’s array is passive and typically inaccessible
until site failover. (The Red Hat term for this is disaster recovery mirroring.) Array-based
replication in which the arrays at both sites are simultaneously accessible is explicitly unsupported.
(The Red Hat term for this is asynchronous or active/passive array-based replication.)
Red Hat also supports a configuration that does not contain any replicated storage.
Site failover and recovery from failover (failback) are performed manually. This includes those
operations required to perform failover and recovery of replicated storage, if included in the
configuration.
All stretched clusters that are to receive software support from Red Hat require a formal architecture
review. Designing your proposed stretched cluster to match one of the four supported configurations
is strongly recommended. Red Hat is unlikely to accept a proposed configuration that does not
closely match one of these four alternatives.
The Support for Red Hat Enterprise Linux Cluster and High Availability Stretch Architectures
Knowledgebase article mentioned previously discusses each of the four supported configurations and
their individual requirements, restrictions, and limitations. It also describes use cases and
configurations that are explicitly unsupported.
HP CLX and RHEL stretched clusters
Although RHEL5 and RHEL6 clusters generally support HP’s Continuous Access storage replication
technology, Red Hat does not directly support HP's associated Cluster Extension (CLX) software in
stretched cluster configurations. However, HP provides direct support for CLX in selected stretched
cluster configurations, and works with Red Hat to assure interoperability and to resolve RHEL cluster
support issues should they arise.
Commenti su questo manuale