United States (change)
Shortcuts: Downloads Fedora Red Hat Network
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/.
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:
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.
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 | NBB-1600 |
| WTI | NBB-1600-CE |
| WTI | TPS-2 |
Note: Supported on Red Hat Enterprise Linux 4 and 5
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 |
| Dell | PowerVault 56F |
| McData | Sphereon 4500 |
| Vixel | 9200 |
Note: Supported on Red Hat Enterprise Linux 4 and 5
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.
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 and 5.0 support is available for non-multipath configurations.
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.