Support Policies for RHEL Resilient Storage Clusters - Deployments Spanning Multiple Sites

Updated -

Contents

Overview

Applicable Environments

  • Red Hat Enterprise Linux (RHEL) with the Resilient Storage 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
  • Using or considering use of one of the Resilient Storage components - gfs2, dlm, lvmlockd, lvm2-cluster (clvmd), cmirror, ctdb

Recommended Prior Reading

Introduction

This policy guide describes general requirements, limitations, and caveats for all RHEL Resilient Storage cluster designs that span multiple sites. Users of RHEL Resilient Storage components should adhere to these policies in order to be eligible for support from Red Hat with the appropriate product support subscriptions.

Policies

Definition of a "Site" in Support Policies: The distinguishing characteristic of a site is any collection of servers or virtual machines that shares a single direct connection to the same storage and network devices.

  • Nodes connected to different network switches - even if those switches are interconnected - are considered to be in separate sites
  • Nodes connected to different storage arrays or backends - even if those targets are interconnected or bridged by a virtual frontend - are considered to be in separate sites

No Support for Resilient Storage In Single Cluster Spanning Multiple Sites: In any single stretched cluster design - where nodes operating in different sites form a single membership - Resilient Storage components are not supported by Red Hat. gfs, gfs2, dlm, lvmlockd, lvm2-cluster (clvmd), and cmirror will receive no support from Red Hat in cluster configurations that span multiple sites.

  • A cluster that has members spanning multiple sites will not receive support from Red Hat if using Resilient Storage components in any way. This is true even if usage of Resilient Storage or access to shared devices is limited to nodes within a single site. The presence of nodes in multiple sites disqualifies the entire cluster for eligibility for support with Resilient Storage.

Support for Resilient Storage in Multi-Cluster Designs: Resilient Storage components can be used within a cluster that spans only a single site and storage resources are shared only by nodes within that site. One or more clusters may exist - each using Resilient Storage amongst the local members - for disaster recovery purposes or redundancy purposes, as long as no cluster concurrently or simultaneously shares access to the same storage devices as another active cluster.

  • In a cluster that has all nodes of the membership operating in a single site and uses Resilient Storage components to share access to storage devices, no other server or system may have write access to those devices. Sharing of such devices outside of the primary cluster disqualifies the cluster(s) involved from being eligible for support from Red Hat.

  • Supported alternatives to a single multi-site-cluster with Resilient Storage:

    • booth cluster ticketing: Individual clusters are deployed in separate sites - each cluster having a completely separate membership - with those clusters running in parallel. Storage resources that back any Resilient Storage components are accessible/writable to only one cluster at a time. booth constraints can be created to grant permission to one cluster at a time to run individual resources, ensuring an active/passive management strategy - protecting Resilient Storage resources from corruption by concurrent access across clusters.

    • Primary and disaster-recovery clusters with replicated storage and manual failover: Deploy a primary cluster consisting of members in a single site, and a "backup" disaster-recovery cluster at another site for redundancy. Use a storage-replication solution to make those shared devices available to a similar cluster in the disaster-recovery site. The replication solution should ensure that access to the storage devices is not shared between the primary and disaster-recovery clusters at any time; often there is some manual action that must be taken by an administrator to "activate" the storage at the alternate site during a failover.

General Support Policies for High Availability Also Apply: With Resilient Storage being a set of components that operate on top of a High Availability cluster, the support policies that apply to High Availability in general are all applicable in Resilient Storage clusters as well. In any area in which there there is overlap - such as in the case of multi-site cluster deployments - the Resilient Storage policies supercede those defined for High Availability.

Storage Compatibility: Red Hat does not certify other vendors' storage solutions for compatibility with RHEL Resilient Storage components. In multi-cluster designs that span multiple sites with each cluster using Resilient Storage for concurrent data access, advanced storage solutions are often required to maintain data availability and redundancy across those sites. Organizations deploying such configurations must ensure that their chosen replication or redundancy methods do not introduce any potential for multiple clusters to operate on shared data at the same time. Red Hat may require demonstration that such conflicts are not occurring before providing support for such clusters, or may require reproduction of the problem without involvement of concerning storage replication components involved.

Comments