How to Set Up High Availability Clustering (HAE) on SUSE Linux 15

This beginner walkthrough builds a basic two-node, active/passive cluster with SUSE Linux Enterprise High Availability (SLE HA) 15. It uses the supported CRM Shell bootstrap scripts: initialize the first node with crm cluster init, add the second with crm cluster join, check membership, and test a planned failover of the management virtual IP. The examples follow SUSE’s SLE HA 15 SP7 documentation, published September 24, 2026; prompts can vary by service pack, hardware, and platform.

“HAE” is often used informally for the High Availability Extension. SUSE’s current product documentation calls it SUSE Linux Enterprise High Availability, or SLE HA. This procedure provides a working cluster foundation and Hawk2 management access. It does not automatically make an application, database, or its data highly available; those need their own Pacemaker resources, storage design, and workload-specific testing.

The terminal and Hawk2 screen illustrations below show representative interface views, not captures from a live system. Names and addresses are examples. Replace them with values from your network.

What will this cluster do?

A cluster is a group of servers, called nodes, that coordinate to keep selected services running. Corosync handles node membership and cluster messaging. Pacemaker, the cluster resource manager, decides where managed resources should run and responds to failures. A resource is a service or address Pacemaker can start, stop, monitor, and move.

In this walkthrough, node alice and node bob form a two-node cluster. A floating management IP gives administrators a stable address for Hawk2, SUSE’s web interface. If one node is placed in standby, Pacemaker can move that IP to the other node. For a production two-node cluster, SUSE recommends adding QDevice/QNetd for quorum decisions and requires node fencing.

What should you prepare before installing?

• Two supported SUSE Linux Enterprise Server 15 systems running the same service pack and processor architecture, with root or an appropriately privileged sudo account.
• Valid SUSE registration and an entitlement for SLE HA on every node. The extension and package pattern must match the SLES service pack and architecture.
• Static node addresses, working name resolution, synchronized clocks, and reliable cluster-network connectivity. Choose the intended Corosync interface deliberately; separate or redundant paths are useful in production designs.
• A fencing plan. Fencing (STONITH, “Shoot the Other Node in the Head”) forcibly isolates or reboots a node that may be unhealthy, preventing both sides of a network split from writing to shared data. A supported cluster must have fencing enabled.
• If using SBD (STONITH Block Device), a suitable watchdog on each node and properly designed shared block storage with a stable device path. A hardware watchdog is preferred for production. If using a physical power fence instead, configure and test a supported STONITH device.
• For two nodes, plan a QDevice/QNetd witness before initialization if you intend to configure it through the bootstrap flow. A witness helps the cluster decide which side has quorum when connectivity is lost.

Do not treat a lab configuration as production-ready. SUSE’s SLE HA 15 SP7 system requirements require fencing, and its installation overview recommends testing the setup with two or three nodes before expanding it.

Step 1: Install the SLE HA extension and packages

If SLE HA was not selected during SLES installation, enable the extension on each node. For a registered x86_64 SLES 15 SP7 host, the documented pattern is:

SUSEConnect -p sle-ha/15.7/x86_64 -r ADDITIONAL_REGCODE
zypper install -t pattern ha_sles

Replace ADDITIONAL_REGCODE with the SLE HA registration code. Use the activation product identifier that matches your own service pack and architecture; do not copy the SP7 example to a different SLES 15 service pack. Run the package-pattern command on both nodes. SUSE documents the ha_sles pattern as the set of packages used to configure and manage the cluster.

Step 2: Prepare names, time, and network access

Give both nodes stable hostnames and static primary IP addresses. Confirm that each node can resolve the other by both short name and fully qualified name. SUSE’s setup guidance recommends listing cluster members in /etc/hosts when needed, because name resolution failures can break internal communication. For example, adapt entries like these to your DNS and address plan:

10.20.0.11 alice.example.net alice
10.20.0.12 bob.example.net bob

Synchronize both clocks to an NTP source outside the cluster and keep their time zones consistent. Chrony is the default NTP implementation on SLES 15. Check connectivity on the network you plan to use for Corosync. Bootstrap scripts can open the firewall ports needed for cluster communication, but confirm your host and network firewalls allow the traffic required by your selected topology. Unicast is the default in the bootstrap flow; the documented default Corosync port is 5405.

Step 3: Initialize the first node

On alice, run the bootstrap command as root:

crm cluster init --name demo-ha

Review the prompts before accepting them. Select the interface and network address intended for Corosync, then confirm the port. The script checks time synchronization and watchdog availability, and can prepare SSH keys and related cluster configuration. It asks whether to configure SBD, a Hawk2 administration virtual IP, and QDevice/QNetd. SBD requires that the watchdog and shared device are already ready. If configuring QDevice in this bootstrap, prepare the QNetd server first. The script creates a running one-node cluster; it does not add bob at this stage.

Do not choose a random shared disk or device path for SBD. The path must identify the same appropriate storage on every node, and its failure behavior and timeouts need to match the storage design. SUSE notes that softdog cannot reboot a machine if all CPUs are stuck, so use the correct hardware watchdog for production wherever available.

Step 4: Join the second node

After the first node is initialized, log in to bob and run:

crm cluster join

Follow the prompt to identify the existing cluster node, alice. If you used a sudo account rather than root for the first node, SUSE documents specifying that account with -c, for example:

sudo crm cluster join -c USER@alice

The join script copies the Corosync configuration, configures SSH and Csync2, brings the current machine online as a cluster node, and starts the service needed for Hawk2. Do not initialize both machines independently; the second node must join the cluster created by the first.

Step 5: Confirm that both nodes are online

From either node, check the cluster summary:

crm status

Look for both node names under Online and a cluster partition with quorum. Check for failed actions or a node that is offline before proceeding. You can also sign in to Hawk2 using the administration VIP selected during initialization, typically at https://ADMIN-VIP:7630/. A first-visit certificate warning can occur when a self-signed certificate is in use; verify certificate details with the cluster administrator instead of ignoring an unknown certificate in a production environment.

Step 6: Secure the management account

The bootstrap procedure creates a hacluster account for Hawk2. SUSE’s setup guide documents a default password during the basic setup, so change it immediately before leaving the system accessible:

passwd hacluster

Use a unique strong password and follow your organization’s credential policy. Restrict access to the Hawk2 management network, install trusted certificates as appropriate, and do not expose the management interface directly to the public internet.

Step 7: Test a planned failover safely

A planned standby test checks whether the management virtual IP can move when one node is intentionally removed from resource placement. Before testing, confirm both nodes are healthy, the cluster has quorum, and you have console or out-of-band access in case something behaves unexpectedly. From a client on the same network, continuously ping the management VIP, for example:

ping 10.20.0.20

In Hawk2, open the node currently hosting the administration IP and select Standby. Then check Status > Resources. SUSE’s quick start describes the floating resource moving to the other node while the ping continues. When the test is complete, return the node to service using Hawk2’s corresponding action, confirm both nodes are online, and verify the resource is in the expected location.

What does this test prove—and what does it not prove?

If both nodes remain visible and the administration IP moves to the peer, you have evidence that basic cluster membership and that floating IP resource work in this planned scenario. A ping alone does not prove an application is available, that client sessions survive, that shared data is protected, or that the cluster can recover from every network, storage, power, or software failure.

For an application, add the correct resource agent and configure ordering, colocation, monitoring, storage access, and fencing according to the application’s design. Never let two nodes write to ordinary shared storage at once. Test the workload’s recovery and data integrity in a staging environment, including realistic node and network failures, before production.

Common mistakes to avoid

• Skipping fencing: a cluster without working STONITH cannot safely resolve split-brain and does not meet SUSE’s support requirements.
• Assuming two nodes can decide alone: plan QDevice/QNetd for an even-numbered cluster, especially a two-node cluster.
• Using unstable or mismatched node identity: use static addresses, consistent hostnames, working forward and reverse name resolution, and synchronized time.
• Reusing the wrong network: select the intended Corosync interface and verify firewall policy across every network path.
• Assuming the cluster automatically protects an app: a cluster can only manage resources that have been configured and tested.
• Calling the initial bootstrap “production ready”: the quick start is a basic setup. Production readiness requires workload-specific recovery tests, fencing validation, monitoring, backup and restore procedures, and documented operations.

Official SUSE references

• SLE HA 15 SP7 Installation and Setup Quick Start
• SLE HA 15 SP7 System Requirements and Recommendations
• SLE HA 15 SP7 Installation Overview
• SLE HA 15 SP7 Storage Protection and SBD