Hardware Configuration Guidelines

Cluster configurations deliver high availability and performance using a mixture of software and hardware. While the software components are all included, selection of appropriate hardware for the configuration should be done as part of the overall system design. Note that with Red Hat Enterprise Linux 4 and 5, GFS and Cluster Suite share a common cluster infrastructure so these notes apply to both products.

Most cluster hardware is self-certified by hardware suppliers, so please contact your hardware vendor for specific product details. A list of Red Hat certified hardware components is maintained at http://hardware.redhat.com/.

A storage subsystem.

The storage subsystem is at the heart of the cluster configuration. Since all servers in the cluster will access data located on the shared storage subsystem it is important that it offer high availability through technologies such as RAID. Selecting a storage subsystem involves three steps:

1. Selecting a storage technology.
   Cluster Manager systems can be configured using iSCSI, Fibre Channel, or Multi-Initiator (MI) SAS hardware. In general, MI SAS will be appropriate for smaller configurations with 2-4 servers, while iSCSI and Fibre Channel are better suited to larger configurations.
2. Choosing a Host Bus Adapter (HBA).
   Red Hat Cluster Suite imposes no specific requirements on the host I/O adapter, so any adapter supported by Red Hat Enterprise Linux can be used in a cluster configuration. (Note that HBAs that provide RAID capabilities cannot be used systems because products currently on the market do not support multihost configurations.) MI SAS, iSCSI and Fibre Channel host adapters from all the major suppliers are supported, including:
   
3. Choosing an external shared storage array/controller
   The storage controller must support concurrent access to any disk from multiple hosts. Also, MI SAS storage controllers must provide electrically separate ports for each connected host server (multi-host SCSI bus configurations are not supported). Provided these requirements are met any good quality storage controller can be expected to work with Red Hat Cluster Suite, including products from:
   
   To ensure that application data is continuously available it is recommended that the storage controller provide high availability features such as RAID, redundant controllers, mirrored data cache, and battery backup.

Cluster Fencing

Fencing is the mechanism which protects your information from a failed node in the cluster. It's purpose it to "fence" a partially failed node from trying to re-assert activities, possibly corrupting data.

Power Fencing Systems

The power fencing subsystem allows operational cluster nodes to control the power of failed nodes to ensure that they do not access storage in an uncoordinated manner. Most power control systems are network-based. They are available from system vendors as add-in cards or integrated into the motherboard. We support:

Manufacturer	Model
Bull	Fame (PAP) Management Console
Dell	DRAC 3
Dell	DRAC 4
Dell	DRAC 5
Dell	DRAC/MC
Fujitsu-Siemens	RSB
HP	ILO
HP	ILO 2
IBM	Blade Center
IBM	RSA II
Intel	IPMI over LAN

External power fencing devices are also available. These are typically rack or cabinet mounted units which servers then plug into. We support the following vendors and units.

Manufacturer	Model
APC	MasterSwitch AP7902
APC	MasterSwitch AP7930 - AP7998
APC	MasterSwitch AP7900
APC	MasterSwitch AP7901
APC	MasterSwitch AP7911
APC	MasterSwitch AP7920
APC	MasterSwitch AP7921
WTI	IPS-15
WTI	IPS-1600
WTI	IPS-1600-CE
WTI	IPS-400
WTI	IPS-400-CE
WTI	IPS-800
WTI	IPS-800-CE
WTI	MPC-8H (5.3)
WTI	NBB-1600
WTI	NBB-1600-CE
WTI	RSM-8R4 (5.3)
WTI	TPS-2

Note: Supported on Red Hat Enterprise Linux 4 and 5

SAN Based Fencing

While we prefer our customers employ a power fencing solution for the robustness a system reboot provides, we also support SAN switch fencing for several manufacturers. Like Power Fencing, the need is to protect shared data and SAN switch fencing works by blocking access to storage at the SAN switch. The following units are supported.

Manufacturer	Model
Brocade	Silkworm 2400
Brocade	Silkworm 2800
Brocade	Silkworm 3200
Cisco	MDS 9124 (RHEL 5.4+)
Cisco	MDS 9134 (RHEL 5.4+)
Dell	PowerVault 56F
McData	Sphereon 4500
Vixel	9200

Note 1: Supported on Red Hat Enterprise Linux 4 and 5
Note 2: Cisco MDS supported from Red Hat Enterprise Linux 5.4

Virtual Machine Fencing

With the advent of Red Hat Enterprise Linux 5, virtual machine support was added. One configuration is to create a cluster of virtual machines. This means that the virtual machine can potentially hang and will also need to be rebooted as a fencing operation. This is supported as the fence_xvm agent; software which signals the parent Host running the virtual machine to reboot the guest.

SCSI-3 Persistent Reservations

One additional SAN fencing mechanism is provided through the use of SCSI-3 persistent reservations. This technique directly uses the storage array to block LUN access by failed machines. As of Red Hat Enterprise Linux 4.5 support is available for non-multipath configurations in Red Hat Enterprise Linux 4. As of Red Hat Enterprise Linux 5.0, SCSI-3 Persistent Reservation fencing is supported over multipath in Red Hat Enterprise Linux 5. For more information on configuring and using SCSI-3 Reservation based fencing, please consult the Knowledgebase Articles and Documentation.

Load Balancing

The IP Load Balancing capability that is provided as part of Red Hat Cluster Suite has no specific hardware requirements beyond standard network connectivity. Red Hat Enterprise Linux supports Network Channel Bonding, so performance can be improved by configuring multiple network adapters in each cluster node.