SUSE Linux Enterprise High Availability Extension Documentation › Administration Guide › Installation and Setup › System Requirements and Recommendations
ContentsContents
Administration Guide
  1. About This Guide
  2. I Installation and Setup
    1. 1 Product Overview
    2. 2 System Requirements and Recommendations
    3. 3 Installation and Basic Setup
  3. II Configuration and Administration
    1. 4 Configuration and Administration Basics
    2. 5 Configuring and Managing Cluster Resources (Web Interface)
    3. 6 Configuring and Managing Cluster Resources (Command Line)
    4. 7 Adding or Modifying Resource Agents
    5. 8 Fencing and STONITH
    6. 9 Access Control Lists
    7. 10 Network Device Bonding
    8. 11 Load Balancing
    9. 12 GEO Clusters (Multi-Site Clusters)
  4. III Storage and Data Replication
    1. 13 OCFS2
    2. 14 GFS2
    3. 15 DRBD
    4. 16 Cluster Logical Volume Manager (cLVM)
    5. 17 Storage Protection
    6. 18 Samba Clustering
    7. 19 Disaster Recovery with Rear (Relax-and-Recover)
  5. IV Appendix
    1. A Troubleshooting
    2. B Naming Conventions
    3. C Cluster Management Tools
    4. D Upgrading Your Cluster and Updating Software Packages
    5. E Documentation Updates
  6. Terminology
  7. F GNU Licenses
Navigation←→
SUSE Linux Enterprise High Availability Extension Documentation › Administration Guide › Installation and Setup › System Requirements and Recommendations
Top
←→
Applies to SUSE Linux Enterprise High Availability Extension 12

2 System Requirements and Recommendations

2.1 Hardware Requirements
2.2 Software Requirements
2.3 Storage Requirements
2.4 Other Requirements and Recommendations

The following section informs you about system requirements, and some prerequisites for SUSE® Linux Enterprise High Availability Extension. It also includes recommendations for cluster setup.

2.1 Hardware Requirements

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 per cluster node. 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. See Section 2.3, “Storage Requirements”.

  • A STONITH mechanism. 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. This is the only reliable way to ensure that no data corruption is performed by nodes that hang and only appear to be dead.

2.2 Software Requirements

Ensure that the following software requirements are met:

  • SUSE® Linux Enterprise Server 12 (with all available online updates) is installed on all nodes that will be part of the cluster.

  • SUSE Linux Enterprise High Availability Extension 12 (with all available online updates) is installed on all nodes that will be part of the cluster.

  • If you want to use GEO clusters, make sure that GEO Clustering for SUSE Linux Enterprise High Availability Extension 12 (with all available online updates) is installed on all nodes that will be part of the cluster.

2.3 Storage Requirements

To make data highly available, a shared disk system (Storage Area Network, or SAN) is recommended for your cluster. 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.

2.4 Other Requirements and Recommendations

For a supported and useful High Availability setup, consider the following recommendations:

Number of Cluster Nodes

Each cluster must consist of at least two cluster nodes.

Important
Important: Odd Number of Cluster Nodes

It is strongly recommended to use an odd number of cluster nodes with a minimum of three nodes.

A cluster needs quorum to keep services running. Therefore a three-node cluster can tolerate only failure of one node at a time, whereas a five-node cluster can tolerate failures of two nodes etc.

STONITH
Important
Important: No Support Without STONITH

A cluster without STONITH is not supported.

For a supported High Availability setup, ensure the following:

  • Each node in the High Availability cluster must have at least one STONITH device (usually a piece of hardware). We strongly recommend multiple STONITH devices per node, unless SBD is used. SBD provides a way to enable STONITH and fencing in clusters without external power switches, but it requires shared storage.

  • The global cluster options stonith-enabled and startup-fencing must be set to true. As soon as you change them, you will lose support.

Redundant Communication Paths

For a supported High Availability setup, it is required to set up cluster communication via two or more redundant paths. This can be done via:

If possible, choose network device bonding.

Time Synchronization

Cluster nodes should synchronize to an NTP server outside the cluster. For more information, see the Administration Guide, for SUSE Linux Enterprise Server 12, available at http://www.suse.com/doc/. Refer to the chapter Time Synchronization with NTP.

If nodes are not synchronized, log files and cluster reports are very hard to analyze.

NIC Names

Must be identical on all nodes.

Hostname and IP Address

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 Administration Guide for SUSE Linux Enterprise Server 12, available at http://www.suse.com/doc. Refer to chapter Basic Networking > Configuring Hostname and DNS.

Storage Requirements

Some services may require shared storage. For requirements, see Section 2.3, “Storage Requirements”. You can also use an external NFS share or DRBD. If using an external NFS share, it must be reliably accessible from all cluster nodes via redundant communication paths. See Redundant Communication Paths.

When using SBD as STONITH device, additional requirements apply for the shared storage. For details, see http://linux-ha.org/wiki/SBD_Fencing, section Requirements.

SSH

All cluster nodes must be able to access each other via SSH. Tools like hb_report or crm_report (for troubleshooting) and the history explorer require passwordless SSH access between the nodes, otherwise they can only collect data from the current node. In case you use a non-standard SSH port, use the -X option (see man page). For example, if your SSH port is 3479, invoke a hb_report with:

root # hb_report -X "-p 3479" [...]
Note
Note: Regulatory Requirements

If passwordless SSH access does not comply with regulatory requirements, you can use the following work-around for crm_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 root password. Start crm_report from command line with the -u option to specify the user's name. For more information, see the crm_report man page.

For the history explorer there is currently no alternative for passwordless login.

→Chapter 3 Installation and Basic Setup←Chapter 1 Product Overview
Print this page

© 2017 SUSE