Contents
Abstract
The following section informs you about system requirements and some prerequisites for SUSE® Linux Enterprise High Availability Extension, including hardware, software, shared disk system, and other essentials.
The following list specifies hardware requirements for a cluster based on SUSE® Linux Enterprise High Availability Extension. These requirements represent the minimum hardware configuration. Additional hardware might be necessary, depending on how you intend to use your cluster.
1 to 32 Linux servers with software as specified in Section 2.2, “Software Requirements”. The servers do not require identical hardware (memory, disk space, etc.), but they must have the same architecture. Cross-platform clusters are not supported.
At least two TCP/IP communication media. Cluster nodes use multicast or unicast for communication so the network equipment must support the communication means you want to use. The communication media should support a data rate of 100 Mbit/s or higher. Preferably, the Ethernet channels should be bonded.
Optional: A shared disk subsystem connected to all servers in the cluster from where it needs to be accessed.
A STONITH mechanism. STONITH is an acronym for “Shoot the other node in the head”. A STONITH device is a power switch which the cluster uses to reset nodes that are thought to be dead or behaving in a strange manner. Resetting non-heartbeating nodes is the only reliable way to ensure that no data corruption is performed by nodes that hang and only appear to be dead.
![]() | No Support Without STONITH |
|---|---|
A cluster without STONITH is not supported. | |
For more information, refer to Chapter 9, Fencing and STONITH.
Ensure that the following software requirements are met:
SUSE® Linux Enterprise Server 11 SP2 with all available online updates installed on all nodes that will be part of the cluster.
SUSE Linux Enterprise High Availability Extension 11 SP2 including all available online updates installed on all nodes that will be part of the cluster.
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. Host-based software RAID 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.
When using DRBD* to implement a mirroring RAID system that distributes data across two machines, make sure to only access the device provided by DRBD, and never the backing device. Use the same (bonded) NICs that the rest of the cluster uses to leverage the redundancy provided there.
Cluster nodes should synchronize to an NTP server outside the cluster. For more information, see the SUSE Linux Enterprise Server Administration Guide, available at http://www.suse.com/documentation/sles11. Refer to the chapter Time Synchronization with NTP.
If nodes are not synchronized, log files or cluster reports are very hard to analyze.
Must be identical on all nodes.
Configure hostname resolution by editing the
/etc/hosts file on each
server in the cluster. To ensure that cluster communication is not
slowed down or tampered with by any DNS:
Use static IP addresses.
List all cluster nodes in this file with their fully qualified hostname and short hostname. 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.
For more information, see the SUSE Linux Enterprise Server Administration Guide, available at http://www.suse.com/documentation. Refer to chapter Basic Networking > Configuring Hostname and DNS.
All cluster nodes must be able to access each other via SSH. Tools like hb_report (for troubleshooting) and the history explorer require passwordless SSH access between the nodes, otherwise they can only collect data from the current node.
![]() | Regulatory Requirements |
|---|---|
If passwordless SSH access does not comply with regulatory requirements, you can use the following work-around for hb_report:
Create a user that can log in without a password (for example, using
public key authentication). Configure sudo for
this user so it does not require a For the history explorer there is currently no alternative for passwordless login. | |