Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com › Documentación de SUSE Linux Enterprise High Availability Extension › Administration Guide › Installation, Setup and Upgrade › System Requirements and Recommendations
ContentsContents
Administration Guide
  1. About This Guide
  2. I Installation, Setup and Upgrade
    1. 1 Product Overview
    2. 2 System Requirements and Recommendations
    3. 3 Installing the High Availability Extension
    4. 4 Using the YaST Cluster Module
    5. 5 Upgrading Your Cluster and Updating Software Packages
  3. II Configuration and Administration
    1. 6 Configuration and Administration Basics
    2. 7 Configuring and Managing Cluster Resources with Hawk2
    3. 8 Configuring and Managing Cluster Resources (Command Line)
    4. 9 Adding or Modifying Resource Agents
    5. 10 Fencing and STONITH
    6. 11 Storage Protection and SBD
    7. 12 Access Control Lists
    8. 13 Network Device Bonding
    9. 14 Load Balancing
    10. 15 Geo Clusters (Multi-Site Clusters)
    11. 16 Executing Maintenance Tasks
  4. III Storage and Data Replication
    1. 17 Distributed Lock Manager (DLM)
    2. 18 OCFS2
    3. 19 GFS2
    4. 20 DRBD
    5. 21 Cluster Logical Volume Manager (cLVM)
    6. 22 Cluster Multi-device (Cluster MD)
    7. 23 Samba Clustering
    8. 24 Disaster Recovery with Relax-and-Recover (Rear)
  5. IV Appendix
    1. A Troubleshooting
    2. B Naming Conventions
    3. C Cluster Management Tools (Command Line)
    4. D Running Cluster Reports Without root Access
  6. Glossary
  7. E GNU Licenses
Navigation←→
documentation.suse.com › Documentación de SUSE Linux Enterprise High Availability Extension › Administration Guide › Installation, Setup and Upgrade › System Requirements and Recommendations
Top
←→
Applies to SUSE Linux Enterprise High Availability Extension 12 SP5

2 System Requirements and Recommendations

Abstract

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
2.2 Software Requirements
2.3 Storage Requirements
2.4 Other Requirements and Recommendations

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.

Servers

1 to 32 Linux servers with software as specified in Section 2.2, “Software Requirements”.

The servers can be bare metal or virtual machines. They do not require identical hardware (memory, disk space, etc.), but they must have the same architecture. Cross-platform clusters are not supported.

Using pacemaker_remote, the cluster can be extended to include additional Linux servers beyond the 32-node limit.

Communication Channels

At least two TCP/IP communication media per cluster node. The network equipment must support the communication means you want to use for cluster communication: multicast or unicast. The communication media should support a data rate of 100 Mbit/s or higher. For a supported cluster setup two or more redundant communication paths are required. This can be done via:

  • Network Device Bonding (to be preferred).

  • A second communication channel in Corosync.

  • Network fault tolerance on infrastructure layer (for example, hypervisor).

For details, refer to Chapter 13, Network Device Bonding and Procedure 4.3, “Defining a Redundant Communication Channel”, respectively.

Node Fencing/STONITH

To avoid a “split brain” scenario, clusters need a node fencing mechanism. In a split brain scenario, cluster nodes are divided into two or more groups that do not know about each other (because of a hardware or software failure or because of a cut network connection). A fencing mechanism isolates the node in question (usually by resetting or powering off the node). This is also called STONITH (“Shoot the other node in the head”). A node fencing mechanism can be either a physical device (a power switch) or a mechanism like SBD (STONITH by disk) in combination with a watchdog. Using SBD requires shared storage.

Unless SBD is used, each node in the High Availability cluster must have at least one STONITH device. We strongly recommend multiple STONITH devices per node.

Important
Important: No Support Without STONITH

  • You must have a node fencing mechanism for your cluster.

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

2.2 Software Requirements

On all nodes that will be part of the cluster the following software must be installed.

  • SUSE® Linux Enterprise Server 12 SP5 (with all available online updates)

  • SUSE Linux Enterprise High Availability Extension 12 SP5 (with all available online updates)

  • (Optional) For Geo clusters: Geo Clustering for SUSE Linux Enterprise High Availability Extension 12 SP5 (with all available online updates)

2.3 Storage Requirements

Some services require shared storage. If using an external NFS share, it must be reliably accessible from all cluster nodes via redundant communication paths.

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.

  • 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—never the backing device. Use bonded NICs. To leverage the redundancy it is possible to use the same NICs as the rest of the cluster.

When using SBD as STONITH mechanism, additional requirements apply for the shared storage. For details, see Section 11.3, “Requirements”.

2.4 Other Requirements and Recommendations

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

Number of Cluster Nodes

For clusters with more than two nodes, it is strongly recommended to use an odd number of cluster nodes to have quorum. For more information about quorum, see Section 6.2, “Quorum Determination”.

Time Synchronization

Cluster nodes must synchronize to an NTP server outside the cluster. For more information, see https://documentation.suse.com/sles-12/html/SLES-all/cha-netz-xntp.html.

If nodes are not synchronized, the cluster may not work properly. In addition, log files and cluster reports are very hard to analyze without synchronization. If you use the bootstrap scripts, you will be warned if NTP is not configured yet.

Network Interface Card (NIC) Names

Must be identical on all nodes.

Host Name and IP Address
SSH

All cluster nodes must be able to access each other via SSH. Tools like crm report (for troubleshooting) and Hawk2's History Explorer require passwordless SSH access between the nodes, otherwise they can only collect data from the current node.

Note
Note: Regulatory Requirements

If passwordless SSH access does not comply with regulatory requirements, you can use the work-around described in Appendix D, Running Cluster Reports Without root Access for running crm report.

For the History Explorer there is currently no alternative for passwordless login.

→Chapter 3 Installing the High Availability Extension←Chapter 1 Product Overview
Print this page

© 2024 SUSE