Support Policies for RHEL Resilient Storage Clusters - Cluster Interconnect Network Latency

Contents

• Overview
  • Applicable Environments
  • Recommended Prior Reading
  • Introduction
• Policies

Overview

Applicable Environments

• Red Hat Enterprise Linux (RHEL) with the Resilient Storage Add-On
• Using or considering use of one of the Resilient Storage components - gfs2, dlm, lvmlockd, lvm2-cluster (clvmd), cmirror, ctdb

Recommended Prior Reading

• Support Policies for RHEL High Availability Clusters
• Support Policies for RHEL High Availability Clusters - Cluster Interconnect Network Latency

Introduction

This policy guide describes general requirements, limitations, and caveats around the latency of the interconnect network utilized by any RHEL High Availability cluster with Resilient Storage components in use. Users of RHEL Resilient Storage clusters should adhere to these policies in order to be eligible for support from Red Hat with the appropriate product support subscriptions.

Policies

Connection with RHEL High Availability policies: Because RHEL Resilient Storage is a collection of software that is necessarily deployed on top of RHEL High Availability, the policies and requirements specific to those High Availability components are pertinent to Resilient Storage clusters. Please review the policies regarding interconnect latency in High Availability clusters for useful context to the policies in this Resilient Storage policy-guide:

• Support Policies for RHEL High Availability Clusters - Cluster Interconnect Network Latency

The limits, requirements, and policies stated in this Resilient Storage guide supercede those applicable to High Availability clusters in the document above.

Max 2ms interconnect latency: Red Hat only provides support for Resilient Storage deployments that utilize an interconnect network with a consistent peak latency of 2ms or less.

• Networks consistently or frequently producing inter-node latency higher than 2ms may trigger unwanted behaviors, instability, or poor performance from RHEL Resilient Storage clusters.
• Red Hat recommends taking measures to test and ensure that node-interconnect networks used for Resilient Storage clusters can deliver consistently low latency less than 2ms.
• Incurring infrequent or short-lived spikes in latency above 2ms does not necessarily permanently disqualify a Resilient Storage cluster from receiving support from Red Hat. However, such events can produce unexpected or suboptimal behavior, and Red Hat may be unable to address concerns with these components' behavior that arises from such spikes. If high latency is suspected to be contributing to a concern or undesired behavior in RHEL Resilient Storage components, Red Hat may require testing or demonstration under conditions that do not produce latency above the supported 2ms limit.