General Configuration Considerations - Red Hat ENTERPRISE LINUX 4 - ADMINISTRATION Manual

Configuring and managing a red hat cluster
Hide thumbs Also See for ENTERPRISE LINUX 4 - ADMINISTRATION:
Table of Contents

Advertisement

Chapter 2. Before Configuring a Red Hat Cluster

2.8. General Configuration Considerations

You can configure a Red Hat Cluster in a variety of ways to suit your needs. Take into account the
following considerations when you plan, configure, and implement your Red Hat Cluster.
No-single-point-of-failure hardware configuration
Clusters can include a dual-controller RAID array, multiple bonded network channels, multiple
paths between cluster members and storage, and redundant un-interruptible power supply (UPS)
systems to ensure that no single failure results in application down time or loss of data.
Alternatively, a low-cost cluster can be set up to provide less availability than a no-single-point-of-
failure cluster. For example, you can set up a cluster with a single-controller RAID array and only a
single Ethernet channel.
Certain low-cost alternatives, such as host RAID controllers, software RAID without cluster
support, and multi-initiator parallel SCSI configurations are not compatible or appropriate for use
as shared cluster storage.
Data integrity assurance
To ensure data integrity, only one node can run a cluster service and access cluster-service
data at a time. The use of power switches in the cluster hardware configuration enables a node
to power-cycle another node before restarting that node's cluster services during a failover
process. This prevents two nodes from simultaneously accessing the same data and corrupting
it. It is strongly recommended that fence devices (hardware or software solutions that remotely
power, shutdown, and reboot cluster nodes) are used to guarantee data integrity under all failure
conditions. Watchdog timers provide an alternative way to to ensure correct operation of cluster
service failover.
Ethernet channel bonding
Cluster quorum and node health is determined by communication of messages among cluster
nodes via Ethernet. In addition, cluster nodes use Ethernet for a variety of other critical cluster
functions (for example, fencing). With Ethernet channel bonding, multiple Ethernet interfaces are
configured to behave as one, reducing the risk of a single-point-of-failure in the typical switched
Ethernet connection among cluster nodes and other cluster hardware.
22

Advertisement

Table of Contents
loading

Table of Contents