From ClusterLabs
Jump to: navigation, search

Pacemaker is a high-availability cluster resource manager.

It achieves maximum availability for your cluster services (a.k.a. resources) by detecting and recovering from node- and resource-level failures by making use of the messaging and membership capabilities provided by Corosync.

It can do this for clusters of practically any size and comes with a powerful dependency model that allows the administrator to accurately express the relationships (both ordering and location) between the cluster resources.

Virtually anything that can be scripted can be managed as part of a Pacemaker cluster.

Project Information


Please let us know which distribution you use for Pacemaker, fill out our usage poll.

Installation Channels

Vendor Packages

Pacemaker is available pre-packaged from many major Linux distributions, including Debian, Fedora, openSUSE, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, and Ubuntu LTS.

Building from Source

Pacemaker can also be compiled from source for many Linux distributions and BSD-based operating systems. See SourceInstall for more information.

Current Releases

Supported Branches

Series First Released Latest Version Release Date Next Release Planned
2.0 6 Jul 2018 2.0.1 4 Mar 2018 second half of 2019
1.1 15 Jan 2010 1.1.20 4 Mar 2018 after next 2.0 series release

Deprecated Branches

Series Last Release First Released Last Released
1.0 1.0.13 9 Oct 2008 13 Feb 2013
0.7 0.7.3 25 Jun 2008 22 Sep 2008
0.6 0.6.7 16 Jan 2008 15 Dec 2008

See Also: Releases

Example Configurations

Common node configurations that are possible to configure with Pacemaker.

Two-node Active/Passive clusters using Pacemaker and DRBD are a cost-effective solution for many High Availability situations
By supporting many nodes, Pacemaker can dramatically reduce hardware costs by allowing several active/passive clusters to be combined and share a common backup node
When shared storage is available, every node can potentially be used for failover. Pacemaker can even run multiple copies of services to spread out the workload.
Pacemaker 1.2 will include enhancements to simplify the creation of split-site clusters


See the "Cluster Architecture" section of Pacemaker Explained from the Pacemaker documentation set.

Project History

Pacemaker came to life in late 2003 when Lars convinced SUSE to hire me to implement a new cluster resource manager for Heartbeat. Although simple to configure, the old version 1 cluster manager had four key deficiencies

  • Maximum of 2-nodes
  • Highly coupled design and implementation
  • Overly simplistic group-based resource model
  • Inability to detect and recover from resource-level failures

Then, year and a half later, on Saturday July 30 (2005), Heartbeat 2.0.0 was released containing the first public version of the CRM.

After many successful releases, the decision was made at the end of 2007 to spin-off the CRM into its own project after the 2.1.3 Heartbeat release in order to

  • support both the OpenAIS and Heartbeat cluster stacks equally
  • decouple the release cycles of two projects at very different stages of their life-cycles
  • foster clearer package boundaries, thus leading to
  • better and more stable interfaces

This transition was completed on January 16, 2008 with the 0.6.0 release of Pacemaker which was the first to support both cluster stacks. The (feature frozen) 0.6 stable series was derived from, and fully compatible with, the 2.1.3 CRM. It received bug-fix-only updates throughout 2008 and 2009 before being deprecated in March 2010.

The current Pacemaker stable series is 1.0 and contains many improvements over prior releases, including:

  • A more intuitive syntax
  • Failure (migration) thresholds and timeouts
  • Tool for making offline configuration changes
  • A unified command line configuration tool that hides the underlying xml
  • Rules, instance_attributes, meta_attributes and sets of operations can be defined once and referenced in multiple places
  • The ability to connect to the CIB from non-cluster machines
  • Allow recurring actions to be triggered at known times
  • A more powerful RelaxNG-based configuration schema