Red Hat ENTERPRISE LINUX 4 - DEVELOPER TOOLS GUIDE User manual

Red Hat Enterprise Linux 4
Cluster Suite Overview
Red Hat Cluster Suite for Red Hat Enterprise Linux

Cluster Suite Overview
Red Hat Enterprise Linux 4 Cluster Suite Overview
Red Hat Cluster Suite for Red Hat Enterprise Linux
Edition 1.0
Copyright © 2009 Red Hat, Inc. This material may only be distributed subject to the terms and
conditions set forth in the Open Publication License, V1.0 or later (the latest version of the OPL is
presently available at http://www.opencontent.org/openpub/).
Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United
States and other countries.
All other trademarks referenced herein are the property of their respective owners.
1801 Varsity Drive
Raleigh, NC 27606-2072 USA
Phone: [phone]
Phone: [phone]
Fax: [phone]
PO Box 13588 Research Triangle Park, NC 27709 USA
Red Hat Cluster Suite Overview provides an overview of Red Hat Cluster Suite for Red Hat Enterprise
Linux 4.

iii
Introduction v
1. Document Conventions ................................................................................................... vi
1.1. Typographic Conventions ..................................................................................... vi
1.2. Pull-quote Conventions ........................................................................................ vii
1.3. Notes and Warnings ........................................................................................... viii
2. Feedback ....................................................................................................................... ix
1. Red Hat Cluster Suite Overview 1
1.1. Cluster Basics .............................................................................................................. 1
1.2. Red Hat Cluster Suite Introduction ................................................................................ 2
1.3. Cluster Infrastructure .................................................................................................... 4
1.3.1. Cluster Management .......................................................................................... 4
1.3.2. Lock Management ............................................................................................. 6
1.3.3. Fencing ............................................................................................................. 6
1.3.4. Cluster Configuration System ........................................................................... 11
1.4. High-availability Service Management .......................................................................... 13
1.5. Red Hat GFS ............................................................................................................. 16
1.5.1. Superior Performance and Scalability ................................................................ 18
1.5.2. Performance, Scalability, Moderate Price .......................................................... 18
1.5.3. Economy and Performance .............................................................................. 19
1.6. Cluster Logical Volume Manager ................................................................................. 20
1.7. Global Network Block Device ...................................................................................... 24
1.8. Linux Virtual Server .................................................................................................... 25
1.8.1. Two-Tier LVS Topology ................................................................................... 27
1.8.2. Three-Tier LVS Topology ................................................................................. 29
1.8.3. Routing Methods ............................................................................................. 30
1.8.4. Persistence and Firewall Marks ........................................................................ 33
1.9. Cluster Administration Tools ........................................................................................ 34
1.9.1. Conga ............................................................................................................. 34
1.9.2. Cluster Administration GUI ............................................................................... 37
1.9.3. Command Line Administration Tools ................................................................. 40
1.10. Linux Virtual Server Administration GUI ..................................................................... 41
1.10.1. CONTROL/MONITORING .............................................................................. 42
1.10.2. GLOBAL SETTINGS ...................................................................................... 43
1.10.3. REDUNDANCY .............................................................................................. 45
1.10.4. VIRTUAL SERVERS ...................................................................................... 46
2. Red Hat Cluster Suite Component Summary 53
2.1. Cluster Components ................................................................................................... 53
2.2. Man Pages ................................................................................................................ 58
2.3. Compatible Hardware ................................................................................................. 60
A. Revision History 61
Index 63

iv

v
Introduction
This document provides a high-level overview of Red Hat Cluster Suite for Red Hat Enterprise Linux
4. Although the information in this document is an overview, you should have advanced working
knowledge of Red Hat Enterprise Linux and understand the concepts of server computing to gain a
good comprehension of the information. For more information about using Red Hat Enterprise Linux,
refer to the following resources:
•Red Hat Enterprise Linux Installation Guide — Provides information regarding installation.
•Red Hat Enterprise Linux Introduction to System Administration — Provides introductory information
for new Red Hat Enterprise Linux system administrators.
•Red Hat Enterprise Linux System Administration Guide — Provides more detailed information about
configuring Red Hat Enterprise Linux to suit your particular needs as a user.
•Red Hat Enterprise Linux Reference Guide — Provides detailed information suited for more
experienced users to reference when needed, as opposed to step-by-step instructions.
•Red Hat Enterprise Linux Security Guide — Details the planning and the tools involved in creating a
secured computing environment for the data center, workplace, and home.
This document contains overview information about Red Hat Cluster Suite for Red Hat Enterprise
Linux 4 and is part of a documentation set that provides conceptual, procedural, and reference
information about Red Hat Cluster Suite for Red Hat Enterprise Linux 4.
Red Hat Cluster Suite documentation and other Red Hat documents are available in HTML,
PDF, and RPM versions on the Red Hat Enterprise Linux Documentation CD and online at http://
www.redhat.com/docs/.
For more information about Red Hat Cluster Suite for Red Hat Enterprise Linux 4, refer to the following
resources:
•Configuring and Managing a Red Hat Cluster — Provides information about installing, configuring
and managing Red Hat Cluster components.
•LVM Administrator's Guide: Configuration and Administration — Provides a description of the
Logical Volume Manager (LVM), including information on running LVM in a clustered environment.
•Global File System: Configuration and Administration — Provides information about installing,
configuring, and maintaining Red Hat GFS (Red Hat Global File System).
•Using Device-Mapper Multipath — Provides information about using the Device-Mapper Multipath
feature of Red Hat Enterprise Linux 4.
•Using GNBD with Global File System — Provides an overview on using Global Network Block
Device (GNBD) with Red Hat GFS.
•Linux Virtual Server Administration — Provides information on configuring high-performance
systems and services with the Linux Virtual Server (LVS).
•Red Hat Cluster Suite Release Notes — Provides information about the current release of Red Hat
Cluster Suite.

Introduction
vi
Red Hat Cluster Suite documentation and other Red Hat documents are available in HTML,
PDF, and RPM versions on the Red Hat Enterprise Linux Documentation CD and online at http://
www.redhat.com/docs/.
1. Document Conventions
This manual uses several conventions to highlight certain words and phrases and draw attention to
specific pieces of information.
In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts1 set. The
Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not,
alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes
the Liberation Fonts set by default.
1.1. Typographic Conventions
Four typographic conventions are used to call attention to specific words and phrases. These
conventions, and the circumstances they apply to, are as follows.
Mono-spaced Bold
Used to highlight system input, including shell commands, file names and paths. Also used to highlight
key caps and key-combinations. For example:
To see the contents of the file my_next_bestselling_novel in your current
working directory, enter the cat my_next_bestselling_novel command at the
shell prompt and press Enter to execute the command.
The above includes a file name, a shell command and a key cap, all presented in Mono-spaced Bold
and all distinguishable thanks to context.
Key-combinations can be distinguished from key caps by the hyphen connecting each part of a key-
combination. For example:
Press Enter to execute the command.
Press Ctrl+Alt+F1 to switch to the first virtual terminal. Press Ctrl+Alt+F7 to
return to your X-Windows session.
The first sentence highlights the particular key cap to press. The second highlights two sets of three
key caps, each set pressed simultaneously.
If source code is discussed, class names, methods, functions, variable names and returned values
mentioned within a paragraph will be presented as above, in Mono-spaced Bold. For example:
File-related classes include filesystem for file systems, file for files, and dir for
directories. Each class has its own associated set of permissions.
Proportional Bold
This denotes words or phrases encountered on a system, including application names; dialogue
box text; labelled buttons; check-box and radio button labels; menu titles and sub-menu titles. For
example:
1 https://fedorahosted.org/liberation-fonts/

Pull-quote Conventions
vii
Choose System > Preferences > Mouse from the main menu bar to launch Mouse
Preferences. In the Buttons tab, click the Left-handed mouse check box and click
Close to switch the primary mouse button from the left to the right (making the mouse
suitable for use in the left hand).
To insert a special character into a gedit file, choose Applications > Accessories
> Character Map from the main menu bar. Next, choose Search > Find… from the
Character Map menu bar, type the name of the character in the Search field and
click Next. The character you sought will be highlighted in the Character Table.
Double-click this highlighted character to place it in the Text to copy field and then
click the Copy button. Now switch back to your document and choose Edit > Paste
from the gedit menu bar.
The above text includes application names; system-wide menu names and items; application-specific
menu names; and buttons and text found within a GUI interface, all presented in Proportional Bold and
all distinguishable by context.
Note the > shorthand used to indicate traversal through a menu and its sub-menus. This is to avoid
the difficult-to-follow 'Select Mouse from the Preferences sub-menu in the System menu of the main
menu bar' approach.
Mono-spaced Bold Italic or Proportional Bold Italic
Whether Mono-spaced Bold or Proportional Bold, the addition of Italics indicates replaceable or
variable text. Italics denotes text you do not input literally or displayed text that changes depending on
circumstance. For example:
To connect to a remote machine using ssh, type ssh [e-mail] at
a shell prompt. If the remote machine is example.com and your username on that
machine is john, type ssh [email protected].
The mount -o remount file-system command remounts the named file
system. For example, to remount the /home file system, the command is mount -o
remount /home.
To see the version of a currently installed package, use the rpm -q package
command. It will return a result as follows: package-version-release.
Note the words in bold italics above — username, domain.name, file-system, package, version and
release. Each word is a placeholder, either for text you enter when issuing a command or for text
displayed by the system.
Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and
important term. For example:
When the Apache HTTP Server accepts requests, it dispatches child processes
or threads to handle them. This group of child processes or threads is known as
a server-pool. Under Apache HTTP Server 2.0, the responsibility for creating and
maintaining these server-pools has been abstracted to a group of modules called
Multi-Processing Modules (MPMs). Unlike other modules, only one module from the
MPM group can be loaded by the Apache HTTP Server.
1.2. Pull-quote Conventions
Two, commonly multi-line, data types are set off visually from the surrounding text.

Introduction
viii
Output sent to a terminal is set in Mono-spaced Roman and presented thus:
books Desktop documentation drafts mss photos stuff svn
books_tests Desktop1 downloads images notes scripts svgs
Source-code listings are also set in Mono-spaced Roman but are presented and highlighted as
follows:
package org.jboss.book.jca.ex1;
import javax.naming.InitialContext;
public class ExClient
{
public static void main(String args[])
throws Exception
{
InitialContext iniCtx = new InitialContext();
Object ref = iniCtx.lookup("EchoBean");
EchoHome home = (EchoHome) ref;
Echo echo = home.create();
System.out.println("Created Echo");
System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
}
}
1.3. Notes and Warnings
Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.
Note
A note is a tip or shortcut or alternative approach to the task at hand. Ignoring a note
should have no negative consequences, but you might miss out on a trick that makes your
life easier.
Important
Important boxes detail things that are easily missed: configuration changes that only
apply to the current session, or services that need restarting before an update will apply.
Ignoring Important boxes won't cause data loss but may cause irritation and frustration.

Feedback
ix
Warning
A Warning should not be ignored. Ignoring warnings will most likely cause data loss.
2. Feedback
If you spot a typo, or if you have thought of a way to make this document better, we would love to
hear from you. Please submit a report in Bugzilla (http://bugzilla.redhat.com/bugzilla/) against the
component rh-cs-en.
Be sure to mention the document's identifier:
Cluster_Suite_Overview(EN)-4.8 (2009-04-24:T15:25)
By mentioning this document's identifier, we know exactly which version of the guide you have.
If you have a suggestion for improving the documentation, try to be as specific as possible. If you have
found an error, please include the section number and some of the surrounding text so we can find it
easily.

x

Chapter 1.
1
Red Hat Cluster Suite Overview
Clustered systems provide reliability, scalability, and availability to critical production services. Using
Red Hat Cluster Suite, you can create a cluster to suit your needs for performance, high availability,
load balancing, scalability, file sharing, and economy. This chapter provides an overview of Red Hat
Cluster Suite components and functions, and consists of the following sections:
•Section 1.1, “Cluster Basics”
•Section 1.2, “Red Hat Cluster Suite Introduction”
•Section 1.3, “Cluster Infrastructure”
•Section 1.4, “High-availability Service Management”
•Section 1.5, “Red Hat GFS”
•Section 1.6, “Cluster Logical Volume Manager”
•Section 1.7, “Global Network Block Device”
•Section 1.8, “Linux Virtual Server”
•Section 1.9, “Cluster Administration Tools”
•Section 1.10, “Linux Virtual Server Administration GUI”
1.1. Cluster Basics
A cluster is two or more computers (called nodes or members) that work together to perform a task.
There are four major types of clusters:
• Storage
• High availability
• Load balancing
• High performance
Storage clusters provide a consistent file system image across servers in a cluster, allowing the
servers to simultaneously read and write to a single shared file system. A storage cluster simplifies
storage administration by limiting the installation and patching of applications to one file system.
Also, with a cluster-wide file system, a storage cluster eliminates the need for redundant copies of
application data and simplifies backup and disaster recovery. Red Hat Cluster Suite provides storage
clustering through Red Hat GFS.
High-availability clusters provide continuous availability of services by eliminating single points
of failure and by failing over services from one cluster node to another in case a node becomes
inoperative. Typically, services in a high-availability cluster read and write data (via read-write
mounted file systems). Therefore, a high-availability cluster must maintain data integrity as one cluster
node takes over control of a service from another cluster node. Node failures in a high-availability
cluster are not visible from clients outside the cluster. (High-availability clusters are sometimes
referred to as failover clusters.) Red Hat Cluster Suite provides high-availability clustering through its
High-availability Service Management component.

Chapter 1. Red Hat Cluster Suite Overview
2
Load-balancing clusters dispatch network service requests to multiple cluster nodes to balance the
request load among the cluster nodes. Load balancing provides cost-effective scalability because you
can match the number of nodes according to load requirements. If a node in a load-balancing cluster
becomes inoperative, the load-balancing software detects the failure and redirects requests to other
cluster nodes. Node failures in a load-balancing cluster are not visible from clients outside the cluster.
Red Hat Cluster Suite provides load-balancing through LVS (Linux Virtual Server).
High-performance clusters use cluster nodes to perform concurrent calculations. A high-performance
cluster allows applications to work in parallel, therefore enhancing the performance of the applications.
(High performance clusters are also referred to as computational clusters or grid computing.)
Note
The cluster types summarized in the preceding text reflect basic configurations; your
needs might require a combination of the clusters described.
1.2. Red Hat Cluster Suite Introduction
Red Hat Cluster Suite (RHCS) is an integrated set of software components that can be deployed
in a variety of configurations to suit your needs for performance, high-availability, load balancing,
scalability, file sharing, and economy.
RHCS consists of the following major components (refer to Figure 1.1, “Red Hat Cluster Suite
Introduction”):
• Cluster infrastructure — Provides fundamental functions for nodes to work together as a cluster:
configuration-file management, membership management, lock management, and fencing.
• High-availability Service Management — Provides failover of services from one cluster node to
another in case a node becomes inoperative.
• Cluster administration tools — Configuration and management tools for setting up, configuring, and
managing a Red Hat cluster. The tools are for use with the Cluster Infrastructure components, the
High-availability and Service Management components, and storage.
• Linux Virtual Server (LVS) — Routing software that provides IP-Load-balancing. LVS runs in a pair
of redundant servers that distributes client requests evenly to real servers that are behind the LVS
servers.
You can supplement Red Hat Cluster Suite with the following components, which are part of an
optional package (and not part of Red Hat Cluster Suite):
• Red Hat GFS (Global File System) — Provides a cluster file system for use with Red Hat Cluster
Suite. GFS allows multiple nodes to share storage at a block level as if the storage were connected
locally to each cluster node.
• Cluster Logical Volume Manager (CLVM) — Provides volume management of cluster storage.

Red Hat Cluster Suite Introduction
3
Note
When you create or modify a CLVM volume for a clustered environment, you must
ensure that you are running the clvmd daemon. For further information, refer to
Section 1.6, “Cluster Logical Volume Manager”.
• Global Network Block Device (GNBD) — An ancillary component of GFS that exports block-level
storage to Ethernet. This is an economical way to make block-level storage available to Red Hat
GFS.
For a lower level summary of Red Hat Cluster Suite components and optional software, refer to
Chapter 2, Red Hat Cluster Suite Component Summary.
Figure 1.1. Red Hat Cluster Suite Introduction
Note
Figure 1.1, “Red Hat Cluster Suite Introduction” includes GFS, CLVM, and GNBD, which
are components that are part of an optional package and not part of Red Hat Cluster
Suite.

Chapter 1. Red Hat Cluster Suite Overview
4
1.3. Cluster Infrastructure
The Red Hat Cluster Suite cluster infrastructure provides the basic functions for a group of computers
(called nodes or members) to work together as a cluster. Once a cluster is formed using the cluster
infrastructure, you can use other Red Hat Cluster Suite components to suit your clustering needs (for
example, setting up a cluster for sharing files on a GFS file system or setting up service failover). The
cluster infrastructure performs the following functions:
• Cluster management
• Lock management
• Fencing
• Cluster configuration management
1.3.1. Cluster Management
Cluster management manages cluster quorum and cluster membership. One of the following Red
Hat Cluster Suite components performs cluster management: CMAN (an abbreviation for cluster
manager) or GULM (Grand Unified Lock Manager). CMAN operates as the cluster manager if a cluster
is configured to use DLM (Distributed Lock Manager) as the lock manager. GULM operates as the
cluster manager if a cluster is configured to use GULM as the lock manager. The major difference
between the two cluster managers is that CMAN is a distributed cluster manager and GULM is a
client-server cluster manager. CMAN runs in each cluster node; cluster management is distributed
across all nodes in the cluster (refer to Figure 1.2, “CMAN/DLM Overview”). GULM runs in nodes
designated as GULM server nodes; cluster management is centralized in the nodes designated as
GULM server nodes (refer to Figure 1.3, “GULM Overview”). GULM server nodes manage the cluster
through GULM clients in the cluster nodes. With GULM, cluster management operates in a limited
number of nodes: either one, three, or five nodes configured as GULM servers.
The cluster manager keeps track of cluster quorum by monitoring the count of cluster nodes that
run cluster manager. (In a CMAN cluster, all cluster nodes run cluster manager; in a GULM cluster
only the GULM servers run cluster manager.) If more than half the nodes that run cluster manager
are active, the cluster has quorum. If half the nodes that run cluster manager (or fewer) are active,
the cluster does not have quorum, and all cluster activity is stopped. Cluster quorum prevents the
occurrence of a "split-brain" condition — a condition where two instances of the same cluster are
running. A split-brain condition would allow each cluster instance to access cluster resources without
knowledge of the other cluster instance, resulting in corrupted cluster integrity.
In a CMAN cluster, quorum is determined by communication of heartbeats among cluster nodes via
Ethernet. Optionally, quorum can be determined by a combination of communicating heartbeats via
Ethernet and through a quorum disk. For quorum via Ethernet, quorum consists of 50 percent of the
node votes plus 1. For quorum via quorum disk, quorum consists of user-specified conditions.
Note
In a CMAN cluster, by default each node has one quorum vote for establishing quorum.
Optionally, you can configure each node to have more than one vote.
In a GULM cluster, the quorum consists of a majority of nodes designated as GULM servers according
to the number of GULM servers configured:

Cluster Management
5
• Configured with one GULM server — Quorum equals one GULM server.
• Configured with three GULM servers — Quorum equals two GULM servers.
• Configured with five GULM servers — Quorum equals three GULM servers.
The cluster manager keeps track of membership by monitoring heartbeat messages from other cluster
nodes. When cluster membership changes, the cluster manager notifies the other infrastructure
components, which then take appropriate action. For example, if node A joins a cluster and mounts
a GFS file system that nodes B and C have already mounted, then an additional journal and lock
management is required for node A to use that GFS file system. If a cluster node does not transmit
a heartbeat message within a prescribed amount of time, the cluster manager removes the node
from the cluster and communicates to other cluster infrastructure components that the node is not
a member. Again, other cluster infrastructure components determine what actions to take upon
notification that node is no longer a cluster member. For example, Fencing would fence the node that
is no longer a member.
Figure 1.2. CMAN/DLM Overview

Chapter 1. Red Hat Cluster Suite Overview
6
Figure 1.3. GULM Overview
1.3.2. Lock Management
Lock management is a common cluster-infrastructure service that provides a mechanism for other
cluster infrastructure components to synchronize their access to shared resources. In a Red Hat
cluster, one of the following Red Hat Cluster Suite components operates as the lock manager: DLM
(Distributed Lock Manager) or GULM (Grand Unified Lock Manager). The major difference between
the two lock managers is that DLM is a distributed lock manager and GULM is a client-server lock
manager. DLM runs in each cluster node; lock management is distributed across all nodes in the
cluster (refer to Figure 1.2, “CMAN/DLM Overview”). DLM can be the lock manager only in a cluster
configured with CMAN as its cluster manager. GULM runs in nodes designated as GULM server
nodes; lock management is centralized in the nodes designated as GULM server nodes. GULM
server nodes manage locks through GULM clients in the cluster nodes (refer to Figure 1.3, “GULM
Overview”). With GULM, lock management operates in a limited number of nodes: either one, three,
or five nodes configured as GULM servers. GFS and CLVM use locks from the lock manager. GFS
uses locks from the lock manager to synchronize access to file system metadata (on shared storage).
CLVM uses locks from the lock manager to synchronize updates to LVM volumes and volume groups
(also on shared storage).
1.3.3. Fencing
Fencing is the disconnection of a node from the cluster's shared storage. Fencing cuts off I/O from
shared storage, thus ensuring data integrity.
The cluster infrastructure performs fencing through one of the following programs according to the
type of cluster manager and lock manager that is configured:
• Configured with CMAN/DLM — fenced, the fence daemon, performs fencing.
• Configured with GULM servers — GULM performs fencing.
When the cluster manager determines that a node has failed, it communicates to other cluster-
infrastructure components that the node has failed. The fencing program (either fenced or GULM),
when notified of the failure, fences the failed node. Other cluster-infrastructure components determine

Fencing
7
what actions to take — that is, they perform any recovery that needs to done. For example, DLM and
GFS (in a cluster configured with CMAN/DLM), when notified of a node failure, suspend activity until
they detect that the fencing program has completed fencing the failed node. Upon confirmation that
the failed node is fenced, DLM and GFS perform recovery. DLM releases locks of the failed node;
GFS recovers the journal of the failed node.
The fencing program determines from the cluster configuration file which fencing method to use.
Two key elements in the cluster configuration file define a fencing method: fencing agent and fencing
device. The fencing program makes a call to a fencing agent specified in the cluster configuration
file. The fencing agent, in turn, fences the node via a fencing device. When fencing is complete, the
fencing program notifies the cluster manager.
Red Hat Cluster Suite provides a variety of fencing methods:
• Power fencing — A fencing method that uses a power controller to power off an inoperable node
• Fibre Channel switch fencing — A fencing method that disables the Fibre Channel port that
connects storage to an inoperable node
• GNBD fencing — A fencing method that disables an inoperable node's access to a GNBD server
• Other fencing — Several other fencing methods that disable I/O or power of an inoperable node,
including IBM Bladecenters, PAP, DRAC/MC, HP ILO, IPMI, IBM RSA II, and others
Figure 1.4, “Power Fencing Example” shows an example of power fencing. In the example, the fencing
program in node A causes the power controller to power off node D. Figure 1.5, “Fibre Channel Switch
Fencing Example” shows an example of Fibre Channel switch fencing. In the example, the fencing
program in node A causes the Fibre Channel switch to disable the port for node D, disconnecting node
D from storage.

Chapter 1. Red Hat Cluster Suite Overview
8
Figure 1.4. Power Fencing Example

Fencing
9
Figure 1.5. Fibre Channel Switch Fencing Example
Specifying a fencing method consists of editing a cluster configuration file to assign a fencing-method
name, the fencing agent, and the fencing device for each node in the cluster.
Note
Other fencing parameters may be necessary depending on the type of cluster manager
(either CMAN or GULM) selected in a cluster.
The way in which a fencing method is specified depends on if a node has either dual power supplies
or multiple paths to storage. If a node has dual power supplies, then the fencing method for the
node must specify at least two fencing devices — one fencing device for each power supply (refer
to Figure 1.6, “Fencing a Node with Dual Power Supplies”). Similarly, if a node has multiple paths to
Fibre Channel storage, then the fencing method for the node must specify one fencing device for each
path to Fibre Channel storage. For example, if a node has two paths to Fibre Channel storage, the
fencing method should specify two fencing devices — one for each path to Fibre Channel storage
(refer to Figure 1.7, “Fencing a Node with Dual Fibre Channel Connections”).

Chapter 1. Red Hat Cluster Suite Overview
10
Figure 1.6. Fencing a Node with Dual Power Supplies