Core Components


At its core, Pacemaker is a distributed finite state machine capable of co-ordinating the startup and recovery of inter-related services across a set of machines.

Pacemaker understands many different resource types (OCF, SYSV, systemd) and can accurately model the relationships between them (colocation, ordering).

It can even use technology such as Docker to automatically isolate the resources managed by the cluster.


Corosync APIs provide membership (a list of peers), messaging (the ability to talk to processes on those peers), and quorum (do we have a majority) capabilities to projects such as Apache Qpid and Pacemaker.


libqb is a library with the primary purpose of providing high performance client server reusable features. It provides high performance logging, tracing, ipc, and poll.

The initial features of libqb come from the parts of corosync that were thought to useful to other projects.

Resource Agents

Resource agents are the abstraction that allows Pacemaker to manage services it knows nothing about. They contain the logic for what to do when the cluster wishes to start, stop or check the health of a service.

This particular set of agents conform to the Open Cluster Framework (OCF) specification. A guide to writing agents is also available.

Fence Agents

Fence agents are the abstraction that allows Pacemaker to isolate badly behaving nodes. They achieve this by either powering off the node or disabling its access to the network and/or shared storage.

Many types of network power switches exist and you will want to choose the one(s) that match your hardware. Please be aware that some (ones that don't loose power when the machine goes down) are better than others.

Agents are generally expected to expose OCF-compliant metadata.

OCF specification

The original documentation that sparked a lot of this work. Mostly we only use the "RA" specification. Efforts are underway to revive the process for updating and modernizing the spec.

Configuration Tools

Pacemaker's internal configuration format is XML, which is great for machines but terrible for humans.

The community's best minds have created GUIs and Shells to hide the XML and allow the configuration to be viewed and updated in a more human friendly format.

Command Line Interfaces (Shells)


The original configuration shell for Pacemaker. Written and actively maintained by SUSE, it may be used either as an interactive shell with tab completion, for single commands directly on the shell's command line or as batch mode scripting tool. Documentation for crmsh can be found here.


An alternate vision for a full cluster lifecycle configuration shell and web based GUI. Handles everything from cluster installation through to resource configuration and status.

GUI Tools


The original GUI for Pacemaker written in Python by IBM China. Mostly deprecated on SLES in favor of Hawk


Hawk is a web-based GUI for managing and monitoring Pacemaker HA clusters. It is generally intended to be run on every node in the cluster, so that you can just point your web browser at any node to access it. There is a usage guide at, and it is documented as part of the SUSE Linux Enterprise High Availability Extension documentation


The Linux Cluster Management Console (LCMC) is a GUI with an inovative approach for representing the status of and relationships between cluster services. It uses SSH to let you install, configure and manage clusters from your desktop.


An alternate vision for a full cluster lifecycle configuration shell and web based GUI. Handles everything from cluster installation through to resource configuration and status.


Striker is the user interface for the Anvil! (virtual) server platform and the ScanCore autonomous self-defence and alert system.

Other Add-ons


The Booth cluster ticket manager extends Pacemaker to support geographically distributed clustering. It does this by managing the granting and revoking of 'tickets' which authorizes one of the cluster sites, potentially located in geographically dispersed locations, to run certain resources.


SBD provides a node fencing mechanism through the exchange of messages via shared block storage such as for example a SAN, iSCSI, FCoE. This isolates the fencing mechanism from changes in firmware version or dependencies on specific firmware controllers, and it can be used as a STONITH mechanism in all configurations that have reliable shared storage. It can also be used as a pure watchdog-based fencing mechanism.