Support Policies for RHEL High Availability clusters - Transport Protocols

Contents

• Overview
  • Applicable Environments
  • Useful References and Guides
  • Introduction
• Policies

Overview

Applicable Environments

• Red Hat Enterprise Linux (RHEL) with the High Availability Add-On

Useful References and Guides

• Support Policies for RHEL High Availability Clusters
• Explore features - Overview of transport protocols
• Design guidance - Selecting the transport protocol

Introduction

This guide lays out Red Hat's policies regarding the communication transport protocols available for usage in RHEL High Availability clusters. 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.

Policies

knet transport: Red Hat's support for this transport protocol is subject to the following conditions:

• RHEL 8: The knet (a.k.a. kronosnet) transport protocol is supported on all RHEL 8 package releases.
• RHEL 7: The knet transport protocol is not supported by Red Hat.
• RHEL 6: The knet transport protocol is not supported by Red Hat.
• knet supports up to 8 communication addresses for each node; that is, it supports 8 membership rings. Each membership ring must be on different network because of a limitation in the kernel that is outlined in the following article: How to connect two network interfaces on the same subnet? Instead of using multiple rings on the same network, use bonding or teaming over a single membership ring.
• If the knet_transport option of an interface sub-directive is configured, it must be set to udp (its default value). Setting this option to sctp is not supported. Note: The knet_transport option in an interface sub-directive of totem is not the same thing as the transport option of totem. The knet_transport option is not explicitly configured by default.
• The supported link_mode values for knet are outlined in the following article: What `link_mode` values does corosync support?

udpu transport: Red Hat's support for this transport protocol is subject to the following conditions:

• RHEL 8: The udpu transport is not supported by Red Hat.
• RHEL 7: The udpu transport is supported on all package releases.
• RHEL 6: udpu is supported by Red Hat when all of the following minimum package release conditions are met:
  • corosync-1.4.1-4.el6 or later
  • cman-3.0.12.1-23.el6 or later
• Any release: When using udpu, nodes cannot be added to the cluster "on-the-fly". Rather, the cluster must be completely stopped, and then started again with an updated configuration containing the new full member list.
• Why is UDP unicast (UDPU) not recommended for use in a cluster with GFS2 in a RHEL 6 or 7 Resilient Storage cluster?

udp transport with broadcast messaging: Red Hat's support for broadcast messaging mode within the udp transport is subject to the following conditions:

• RHEL 8: udp transport with broadcast messaging is not supported by Red Hat.
• RHEL 7: udp transport with broadcast messaging is supported on all package releases.
• RHEL 6: udp transport with broadcast messaging is supported on all package releases.
• Broadcast may not be used in clusters utilizing an IPv6 network as the interconnect. Either udp with multicast or udpu must be used.

udp transport with multicast messaging: Red Hat's support for multicast messaging mode (the default unless broadcast: yes is specified) within the udp transport is subject to the following conditions:

• RHEL 8: udp transport with multicast messaging is not supported by Red Hat.
• RHEL 7: udp transport with multicast messaging is supported on all package releases.
• RHEL 6: udp transport with multicast messaging is supported on all package releases.