- Red Hat Enterprise Linux (RHEL) 6 or 7 with the High Availability Add On
- Cluster nodes operating in separate locations, datacenters, or geographical regions in any arrangement that has them coordinating their operations and/or sharing access to resources
This policy guide describes general requirements, limitations, and caveats for RHEL High Availability cluster designs that span multiple sites. Users of RHEL High Availability clusters should adhere to these policies in order to be eligible for support from Red Hat with the appropriate product support subscriptions.
Useful References and Guides
- Support Policies for RHEL High Availability Clusters
- Support Policies for RHEL Resilient Storage Clusters - Deployments Spanning Multiple Sites
Stretch and multi-site clusters are bound by standard RHEL High Availability support policies: Red Hat has lifted the previously defined limitations and policies that applied only to High Availability "stretch clusters". These clusters spanning multiple sites are bound by the standard policies, requirements, and limitations that apply to RHEL High Availability clusters in general, but are otherwise no longer considered a special class of deployment with separate rules.
Maximum number of sites: Red Hat does not place a limit on the number of sites that a cluster may span. However, the more sites involved, the more potential for a fragmented membership if the interconnects between sites are lost, possibly leaving no single partition with quorum. Attention should be given to the desired and actual behavior in such failure scenarios to ensure the design will meet expectations. See the Special considerations policy below for further guidance.
Special considerations for RHEL High Availability clusters: While stretch clusters and multi-cluster designs are not bound by any special support requirements that are specific to their multi-site nature, these clusters do have inherent complexities that may require additional consideration when compared to a standard single-site cluster.
Clusters spanning multiple sites, network infrastructures, storage infrastructures, or other components inherently have a higher number of points of failure. Network disruptions or splits become a larger threat to such clusters especially, putting the nodes at risk of losing contact with each other. These multi-site clusters must be designed with the potential for such failures in mind. Organizations deploying multi-site clusters should extensively test failure scenarios, and should consider whether the cluster has protection from all points of failure. Consult with Red Hat Support for assistance in considering the important aspects of a resilient High Availability cluster design.
RHEL Resilient Storage components continue to carry limitations and policies in "stretch" configurations.
- Multi-site clusters typically require additional arbitration methods, special quorum rules or enhancements, and/or alternative fencing designs in order to withstand all failure scenarios. Red Hat recommends consulting its design guide for multi-site cluster deployments and its multi-site cluster design examples for guidance, and contacting Red Hat Support for assistance in developing a multi-site cluster architecture.
No requirement for formal review by Red Hat: Red Hat has - at times in the past - recommended or required a formal "architecture review" for certain High Availability use cases, including those involving multiple sites. This is no longer required. Red Hat Support is available to offer guidance and input on the design or stability of High Availability clusters of all designs, but no such engagement is required in order for the deployment to be supported.