Understanding high availability (HA) on SUSE Linux
High availability and business continuity are crucial to keep applications and services always operational.
High availability clusters allow critical services to keep running, even if servers or hardware components fail.
SUSE Linux offers a robust set of tools for creating and managing these clusters.
In this article, we explore the current state of clustering in SUSE Linux, with a focus on key technologies such as Pacemaker, Corosync, DRBD and others.
These, with minor differences are available on x86 and ppc64le. 
Pacemaker: the brain of the cluster
Pacemaker is the engine that manages high availability clusters in SUSE Linux.
Its main function is to manage cluster resources, ensuring that critical services are operational and recover quickly in case of failure. Pacemaker continuously monitors resources (databases, web services, file systems, etc.) and, if it detects a problem, migrates those resources to other nodes in the cluster to keep them up and running.
Pacemaker stands out for its flexibility and ability to manage a wide variety of resources.
From simple services to more complex distributed systems, it is capable of handling most high-availability scenarios that a company may need. 
Corosync: the cluster’s nervous system
Corosync is responsible for communication between cluster nodes.
It ensures that all nodes have the same view of the cluster status at all times, which is essential for coordinated decision making.
It also manages quorum, which determines whether there are enough active nodes for the cluster to operate safely.
If quorum is lost, measures can be taken to prevent data loss or even service downtime.
DRBD: the backbone of the data
DRBD (Distributed Replicated Block Device) is a block-level storage replication solution that replicates data between nodes in real time.
With DRBD, data from one server is replicated to another server almost instantaneously, creating an exact copy.
This is especially useful in scenarios where it is crucial that critical data is always available, even if a node fails.
Combined with Pacemaker, DRBD allows services to continue operating with access to the same data, even if they are on different nodes.
Other key technologies in SUSE Linux clusters
In addition to Pacemaker, Corosync and DRBD, there are other essential technologies for building robust clusters on SUSE Linux:
- SBD (STONITH Block Device): SBD is a fencing tool that isolates a misbehaving node from causing problems in the cluster.
This is achieved by using a shared storage device that nodes use to communicate their state. - OCF (Open Cluster Framework): OCF scripts are the basis of the resources managed by Pacemaker.
They define how to start, stop and check the status of a resource, providing the flexibility needed to integrate a wide range of services into the cluster. - Csync2: A tool for synchronizing files between nodes in a cluster.
It ensures that configuration files and other critical data are always up to date on all nodes.
Current status and future trends
Clusters in SUSE Linux have matured and are adapting to new business demands.
With the growing adoption of containerized environments and with parts in different clouds, clusters in SUSE Linux are evolving to better integrate with them.
This includes improved support for container orchestration and distributed applications that require high availability beyond replicating two disks per DRBD and keeping a virtual IP alive :) Still, today, the combination of Pacemaker, Corosync, DRBD and other tools provides a solid foundation for creating high availability clusters that can scale and adapt to the needs of SAP HANA and other solutions that require high if not total availability. If you need help, SIXE can help.
Cheatsheet for creating and managing clusters with Pacemaker on SUSE Linux
Here are the most common commands for creating and managing Pacemaker clusters on SUSE Linux.
| Task | Command / Description |
|---|---|
| Package installation | |
| Install Pacemaker and Corosync | zypper install -y pacemaker corosync crmsh |
| Basic configuration | |
| Configure Corosync | Edit /etc/corosync/corosync.conf to define the transport, interfaces and network. |
| Start the services | systemctl start corosync && systemctl start pacemaker |
| Enable the services at boot | systemctl enable corosync && systemctl enable pacemaker |
| Cluster management | |
| View the cluster status | crm status |
| List the nodes | crm_node -l |
| Add a node (run on the new node) | crm cluster join -c <existing_node> |
| Remove a node | crm cluster remove <node_name> |
| View the cluster logs | journalctl -u pacemaker -u corosync |
| Resource configuration | |
| Create a resource | crm configure primitive <resource_name> <agent> params <parameters> |
| Delete a resource | crm configure delete <resource_name> |
| Edit a resource | crm configure edit <resource_name> |
| Show the full cluster configuration | crm configure show |
| Groups and start order | |
| Create a resource group | crm configure group <group_name> <resource1> <resource2> ... |
| Set the start order | crm configure order <order_name> Mandatory: <resource1> <resource2> |
| Constraints | |
| Keep two resources on the same node | crm configure colocation <constraint_name> inf: <resource1> <resource2> |
| Prefer a node for a resource | crm configure location <constraint_name> <resource> <score>: <node> |
| Failover and recovery | |
| Move a resource to another node | crm resource move <resource_name> <node> |
| Remove the constraint left by the move | crm resource clear <resource_name> |
| Clean up a resource’s failures | crm resource cleanup <resource_name> |
| Stop managing a resource (maintenance) | crm resource unmanage <resource_name> |
| Manage a resource again | crm resource manage <resource_name> |
| Advanced configuration | |
| What to do when quorum is lost | crm configure property no-quorum-policy=<stop|freeze|ignore> |
| Configure SBD fencing | crm configure primitive stonith-sbd stonith:external/sbd params pcmk_delay_max=<time> |
| Configure a resource’s timeouts and monitoring | crm configure primitive <resource_name> <agent> op start timeout=<time> op monitor interval=<interval> timeout=<time> |
| Validation and testing | |
| Validate the cluster configuration | crm_verify --live-check |
| Simulate the cluster’s next transition | crm_simulate --live-check --simulate |
| Policies | |
| Set the default stickiness | crm configure rsc_defaults resource-stickiness=<value> |
| Set a resource’s priority | crm resource meta <resource_name> set priority <value> |
| Stopping and starting the cluster | |
| Stop the whole cluster | crm cluster stop --all |
| Start the whole cluster | crm cluster start --all |
If you need to build or review a cluster like this, we do it through our Pacemaker implementation and support service. If it has already gone down in production, our 24/7 emergency support will contact you within 15 minutes.
