Chapter 3. Before Configuring the Red Hat High Availability Add-On This chapter describes tasks to perform and considerations to make before installing and configuring the Red Hat High Availability Add-On, and consists of the following sections. Important Make sure that your deployment of Red Hat High Availability Add-On meets your needs and can be supported. Consult with an authorized Red Hat representative to verify your configuration prior to deployment. In addition, allow time for a configuration burn-in period to test failure modes. Section 3.1, "General Configuration Considerations" Section 3.2, "Compatible Hardware" Section 3.3, "Enabling IP Ports" Section 3.4, "Configuring luci with /etc/sysconfig/luci " Section 3.5, "Configuring ACPI For Use with Integrated Fence Devices" Section 3.6, "Considerations for Configuring HA Services" Section 3.7, "Configuration Validation" Section 3.8, "Considerations for NetworkManager " Section 3.9, "Considerations for Using Quorum Disk" Section 3.10, "Red Hat High Availability Add-On and SELinux" Section 3.11, "Multicast Addresses" Section 3.12, "UDP Unicast Traffic" Section 3.13, "Considerations for ricci " Section 3.14, "Configuring Virtual Machines in a Clustered Environment" 3.1. General Configuration Considerations You can configure the Red Hat High Availability Add-On in a variety of ways to suit your needs. Take into account the following general considerations when you plan, configure, and implement your deployment. Number of cluster nodes supported The maximum number of cluster nodes supported by the High Availability Add-On is 16. Single site clusters Only single site clusters are fully supported at this time. Clusters spread across multiple physical locations are not formally supported. For more details and to discuss multi-site clusters, speak to your Red Hat sales or support representative. GFS2 Although a GFS2 file system can be implemented in a standalone system or as part of a cluster configuration, Red Hat does not support the use of GFS2 as a single-node file system. Red Hat does support a number of high-performance single-node file systems that are optimized for single node, which have generally lower overhead than a cluster file system. Red Hat recommends using those file systems in preference to GFS2 in cases where only a single node needs to mount the file system. Red Hat will continue to support single-node GFS2 file systems for existing customers. When you configure a GFS2 file system as a cluster file system, you must ensure that all nodes in the cluster have access to the shared file system. Asymmetric cluster configurations in which some nodes have access to the file system and others do not are not supported.This does not require that all nodes actually mount the GFS2 file system itself. 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 HA services during a failover process. This prevents two nodes from simultaneously accessing the same data and corrupting it. Fence devices (hardware or software solutions that remotely power, shutdown, and reboot cluster nodes) are used to guarantee data integrity under all failure conditions. Ethernet channel bonding Cluster quorum and node health is determined by communication of messages among cluster nodes by means of 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. As of Red Hat Enterprise Linux 6.4, bonding modes 0, 1, and 2 are supported. IPv4 and IPv6 The High Availability Add-On supports both IPv4 and IPv6 Internet Protocols. Support of IPv6 in the High Availability Add-On is new for Red Hat Enterprise Linux 6.

Commands: