Chapter 2. Installation and Setup

Contents

2.1. Hardware Requirements
2.2. Software Requirements
2.3. Shared Disk System Requirements
2.4. Preparations
2.5. Installing Heartbeat
2.6. Configuring STONITH

Abstract

A Heartbeat cluster can be installed and configured using YaST. During the Heartbeat installation, you are prompted for information that is necessary for Heartbeat to function properly. This chapter contains information to help you install, set up, and configure a Heartbeat cluster. Learn about the hardware and software requirements and which preparations to take before installing Heartbeat. Find detailed information about the installation process and the configuration of a STONITH device.

[Note]Installing Heartbeat Software Packages on Cluster Nodes

This Heartbeat installation program does not copy the Heartbeat software package to cluster nodes. Prior to running the installation program, the Heartbeat software package must be installed on all nodes that will be part of your cluster. This can be done during the SUSE Linux Enterprise Server 10 installation, or after.

The Heartbeat installation program lets you create a new cluster or add nodes to an existing cluster. To add new nodes to an existing cluster, you must run the installation program from a node that is already in the cluster, not on a node that you want to add to the cluster.

After installing Heartbeat, you need to create and configure cluster resources. You might also need to create file systems on a shared disk (Storage Area Network, SAN) if they do not already exist and, if necessary, configure those file systems as Heartbeat cluster resources.

Both cluster-aware (OCFS 2) and non-cluster-aware file systems can be configured with Heartbeat. See the Oracle Cluster File System 2 Administration Guide for more information.

2.1. Hardware Requirements

The following list specifies hardware requirements for a Heartbeat cluster. These requirements represent the minimum hardware configuration. Additional hardware might be necessary, depending on how you intend to use your Heartbeat cluster.

  • A minimum of two Linux servers. The servers do not require identical hardware (memory, disk space, etc.).

  • At least two communication media (Ethernet, etc.) that allow cluster nodes to communicate with each other. The communication media should support a data rate of 100 Mbit/s or higher.

  • A STONITH device.

2.2. Software Requirements

Ensure that the following software requirements are met:

  • SLES 10 with all available online updates installed on all nodes that will be part of the Heartbeat cluster.

  • The Heartbeat software package including all available online updates installed to all nodes that will be part of the Heartbeat cluster.

2.3. Shared Disk System Requirements

A shared disk system (Storage Area Network, or SAN) is recommended for your cluster if you want data to be highly available. If a shared disk subsystem is used, ensure the following:

  • The shared disk system is properly set up and functional according to the manufacturer’s instructions.

  • The disks contained in the shared disk system should be configured to use mirroring or RAID to add fault tolerance to the shared disk system. Hardware-based RAID is recommended. Software-based RAID1 is not supported for all configurations.

  • If you are using iSCSI for shared disk system access, ensure that you have properly configured iSCSI initiators and targets.

2.4. Preparations

Prior to installation, execute the following preparatory steps:

  • Configure hostname resolution by either setting up a DNS server or by editing the /etc/hosts file on each server in the cluster as described in Procedure 2.1, “Modifying /etc/hosts with YaST”. It is essential that members of the cluster are able to find each other by name. If the names are not available, internal cluster communication will fail.

  • Configure time synchronization by making Heartbeat nodes synchronize to a time server outside the cluster as described in Procedure 2.2, “Configuring the Heartbeat Servers for Time Synchronization”. The cluster nodes will use the time server as their time synchronization source.

    Heartbeat does not require that time is synchronized for each of the nodes in the cluster, however, it is highly recommended if you ever plan to look at logfiles.

Procedure 2.1. Modifying /etc/hosts with YaST

  1. On one SLES 10 server, open YaST, and in left column, select Network Services+Hostnames.

  2. In the Host Configuration window, click Add and fill in the necessary information in the pop-up window for one other server in the cluster.

    This information includes the IP address, hostname (for example node2.novell.com), and host alias (for example node2) of the other server.

    Use node names for host aliases. You can find node names by executing uname -n at a command prompt on each server.

  3. Click OK, and then repeat Step 2 to add the other nodes in the cluster to the /etc/hosts file on this server.

  4. Repeat Step 1 through Step 3 on each server in your Heartbeat cluster.

  5. To check if hostname resolution is functioning properly, ping the node name (host alias) you specified in Step 2 .

Procedure 2.2. Configuring the Heartbeat Servers for Time Synchronization

Time synchronization will not start unless the date and time on the cluster servers is already close. To manually set the date and time on cluster servers, use the date command at the command line of each cluster server to view, and if necessary change, the date and time for that server.

To configure the nodes in the cluster to use the time server as their time source proceed as follows:

  1. On a cluster server, start YaST, click Network Services, then click NTP Client.

  2. Choose to have the NTP daemon start during boot and then enter the IP address of the time server you configured.

  3. Click Finish and reboot this server to ensure the service starts correctly.

  4. Repeat Step 1 through Step 3 on the other non-time server nodes in the cluster.

  5. Reboot all cluster nodes. After rebooting the nodes, time should be synchronized properly.

  6. To check if time synchronization is functioning properly, run the ntpq -p command on each cluster node. Running the ntpq -p command on a non-time server node will display the server that is being used as the time source.

2.5. Installing Heartbeat

  1. Start YaST and select Miscellaneous+High Availability or enter yast2 heartbeat to start the YaST Heartbeat module. It lets you create a new cluster or add new nodes to an existing cluster.

  2. On the Node Configuration screen, add a node to the cluster by specifying the node name of the node you want to add, then click Add. Repeat this process for each node you want to add to the cluster, then click Next.

    Figure 2.1. Node Configuration

    Node Configuration

    You can find node names for servers by entering uname -n on each node.

    The installation program will not let you add this node, because the node name of this server is already automatically added to the cluster.

    If after adding a node to the cluster, you need to specify a different node name for that node, double-click the node you want to edit, change the node name, then click Edit.

  3. On the Authentication Keys screen, specify the authentication method the cluster will use for communication between cluster nodes, and if necessary an Authentication Key (password). Then click Next.

    Figure 2.2. Authentication Keys

    Authentication Keys

    Both the MD5 and SHA1 methods require a shared secret, which is used to protect and authenticate messages. The CRC method does not perform message authentication, and only protects against corruption, not against attacks.

    The SHA1 method is recommended, because it provides the strongest authentication scheme available. The authentication key (password) you specify will be used on all nodes in the cluster.

    When running this installation program on the other cluster nodes, you should choose the same authentication method for all nodes.

  4. On the Media Configuration screen, specify the method Heartbeat will use for internal communication between cluster nodes. This configuration is written to /etc/ha.d/ha.cf.

    Figure 2.3. Media Configuration

    Media Configuration

    This provides a way for cluster nodes to signal that they are alive to other nodes in the cluster. For proper redundancy, you should specify at least two Heartbeat media if possible. Choose at least one Heartbeat medium, and if possible, more than one:

    • If you choose Broadcast, select one of the available network devices in the Device list.

    • For Multicast, choose a network Device, Multicast Group to join (class D multicast address 224.0.0.0 - 239.255.255.255) and the TTL value (1-255).

    UDP Port sets the UDP port that is used for the broadcast media. Leave this set to the default value (694) unless you are running multiple Heartbeat clusters on the same network segment, in which case you need to run each cluster on a different port number.

    [Note] UDP Port Settings

    Note that the UDP port setting only apply to broadcast media, not to the other media you may use. When editing UDP ports manually in /etc/ha.d/ha.cf, the udpport entry must precede the bcast entry it belongs to, otherwise Heartbeat will ignore the port setting.

    After specifying a Heartbeat medium, click Add to add that medium type to Heartbeat and proceed with Next.

  5. On the Start-up Configuration screen, choose whether you want to start the Heartbeat software on this cluster server each time it is booted.

    Figure 2.4. Startup Configuration

    Startup Configuration

    If you select Off, you must start Heartbeat manually each time this cluster server is booted. You can start the Heartbeat server manually using the rcheartbeat start command.

    To start the Heartbeat server immediately, select On - Start Heartbeat Server Now and when Booting.

    To start Heartbeat on the other servers in the cluster when they are booted, enter chkconfig heartbeat on at the server console of each of those servers. You can also enter chkconfig heartbeat off at the server console to have Heartbeat not start automatically when the server is rebooted.

  6. To configure Heartbeat on the other nodes in the cluster run /usr/lib/heartbeat/ha_propagate on the heartbeat node you just configured. On 64-bit systems, the command ha_propagate is located below /usr/lib64/heartbeat/.

    This will copy the Heartbeat configuration to the other nodes in the cluster. You will be prompted to enter the root user password for each cluster node.

  7. Run rcheartbeat start to start heartbeat on each of the nodes where the configuration has been copied.

2.6. Configuring STONITH

STONITH is the service used by Heartbeat to protect shared data. Heartbeat is capable of controlling a number of network power switches, and can prevent a potentially faulty node from corrupting shared data by using STONITH to cut the power to that node.

With the STONITH service configured properly, Heartbeat does the following if a node fails:

  • Notices that the node is not sending I'm alive packets out to the cluster.

  • Sends out pre-stop notifications to the other cluster nodes.

    These notifications include messages that the failed node will be powered off.

  • Instructs the STONITH service to power off the failed node.

  • Sends post-stop notifications to other cluster nodes after successfully powering off the failed node.

    These notifications include messages that the failed node will be powered off.

For Heartbeat, STONITH must be configured as a cluster resource. After reviewing Chapter 4, Configuring and Managing Cluster Resources, continue with Procedure 2.3, “Configuring STONITH as a Cluster Resource”.

Procedure 2.3. Configuring STONITH as a Cluster Resource

  1. Start the HA Management Client and log in to the cluster as described in Section 4.1, “Graphical HA Management Client”.

  2. To generally enable the use of STONITH, select the linux-ha entry in the left pane and click the Configurations tab on the right.

  3. Activate the STONITH Enabled check box.

  4. From the menu, select Resources+Add New Item or click the + button.

  5. Choose Native as the item type.

  6. Specify the Resource ID (name) for the STONITH resource.

  7. In the Type section of the window, scroll down and select the type of STONITH device that corresponds to your network power switch.

  8. (Conditional) After selecting a STONITH resource type, a line for that resource type might be added to the Parameters section of the screen. If a line is added, click the line once and then click the line again under the Value heading to open a field where you can add the needed value.

    Some STONITH options require you to add parameter values in the parameters section of the page. For example, you may be required to add host names (server names) for each cluster node in your cluster. You can find the hostname for each server using the uname -n command on the server. You can add multiple hostnames in the provided field using a comma or a space to separate the names.

  9. Select the Clone check box. This allows the resource to simultaneously run on multiple cluster nodes.

  10. In the clone_node_max field, enter the number of instances of STONITH that will run on a given node. This value should normally be set to 1.

  11. In the clone_max field, enter the number of nodes in the cluster that will run the STONITH service. Be mindful of the number of concurrent connections your STONITH device supports.

  12. Enter the Clone or Master/Slave ID.

  13. Click Add to add the STONITH resource to the cluster. It now appears below the Resources entry in the left pane.

  14. Select the resource in the left pane and click Resource+Start to start the STONITH resource.

After creating the STONITH resource, you must create location constraints for it. Location constraints determine which nodes STONITH can run on in the cluster. See the Constraints chapter in http://clusterlabs.org/mwiki/images/7/7d/Configuration_Explained_0.6.pdf for more information.

Starting the STONITH resource will cause it to start on the nodes that have been specified with its resource location constraints.


Heartbeat Guide