- Who can edit this wiki?
- Why was Pacemaker started?
- How did Pacemaker get its name?
- What is Pacemaker's relationship with Corosync?
- Is there any Pacemaker documentation?
- Where should I ask questions?
- Do I need shared storage?
- Which cluster filesystems does ClusterLabs support?
- What kind of applications can I manage with Pacemaker?
- Do I need a fencing device?
- Do I need to know XML to configure Pacemaker?
- How do I synchronize the cluster configuration?
- Should I choose pcs or crm shell?
- What if my question isn't here?
- What versions of Pacemaker are supported?
- How do I install Pacemaker?
- Can I use Pacemaker with Corosync 2.x and later?
- Can I use Pacemaker with Heartbeat?
- Can I use Pacemaker with CMAN?
- Can I use Pacemaker with Corosync 1.x?
- Can I mix different cluster layers in the same cluster?
- Where can I get the source code?
- Where can I get pre-built packages?
- How do I test my Cluster?
- What are multiply active resources?
- I killed a node but the cluster didn't recover
Anyone in the Developers group can edit this wiki. If you are not in the group but would like editing privileges, please email firstname.lastname@example.org.
Pacemaker grew out of the Heartbeat project. See the Pacemaker Project History for more details.
First of all, it's not called the CRM (for Cluster Resource Manager) because of the abundance of terms that are commonly abbreviated to those three letters.
The Pacemaker name came from Kham, a good friend of Pacemaker author Andrew Beekhof's, and was originally used by a Java GUI Beekhof was prototyping in early 2007. The GUI was abandoned, and when it came time to choose a name for this project, Lars suggested it was an even better fit for an independent CRM.
The idea stems from the analogy between the role of this software and that of the little device that keeps the human heart pumping. Pacemaker monitors the cluster and intervenes when necessary to ensure the smooth operation of the services it provides.
Pacemaker keeps your applications running when they or the machines they're running on fail. However, it can't do this without connectivity to the other machines in the cluster -- a significant problem in its own right.
Corosync provides a mechanism to reliably send messages between nodes, notifications when nodes join and leave the cluster, and a list of active nodes that is consistent throughout the cluster.
Yes, see the Pacemaker documentation set.
Basic questions can often be answered on the ClusterLabs IRC Channel, but sending them to one of the relevant ClusterLabs Mailing Lists is always a good idea so that everyone can benefit from the answer.
No. We can help manage it if you have some, but Pacemaker itself has no need for shared storage.
Pacemaker is application-agnostic, able to start, stop, monitor, and otherwise interact with applications via supported standards:
- Systemd unit files
- LSB init scripts
- Open Cluster Framework (OCF) resource agents
(Before version 3.0.0, Pacemaker also supported the Upstart and Nagios standards.)
For details, see "Resource Classes" in the Pacemaker Explained document.
Yes. Fencing is the only 100% reliable way to ensure the integrity of your data and that applications are only active on one host. Although Pacemaker is able to function without fencing, there are good reasons vendors will not support such a configuration.
No. Pacemaker uses XML as its native configuration format, but command-line and graphical user interfaces are available for human-friendly management.
Any changes to Pacemaker's configuration are automatically replicated to other machines. The configuration is also versioned, so any offline machines will be updated when they return.
Arguably the best advice is to use whichever one comes with your distro. This is the one that will be tailored to that environment, receive regular bugfixes and feature in the documentation.
Of course, for years people have been side-loading all of Pacemaker onto enterprise distros that didn't ship it, so doing the same for just a configuration tool should be easy if your favorite distro does not ship your favorite tool.
See our help page and let us know!
When seeking assistance, please try to ensure you have a version still actively developed. See the Pacemaker Release Calendar for details.
See How To Install.
Yes. This is the only option supported in Pacemaker 2.0.0 and later. See "Cluster Architecture" in the Clusters from Scratch document for details.
Only with Pacemaker versions less than 2.0.0. See Linux-HA documentation for details.
Only with Pacemaker versions greater than or equal to 1.1.5 and less than 2.0.0. See the documentation for details.
Only with Pacemaker versions less than 2.0.0. You will need to configure Corosync to load Pacemaker's custom plugin. See the documentation for details.
- Alternatively, you can get a full copy of the Git repository by executing git clone git://github.com/ClusterLabs/pacemaker.git
Most users should be able to install Pacemaker directly from their distribution.
Pacemaker currently ships with Fedora (since 12), RedHat Enterprise Linux (since 6.0), openSUSE (since 11.0), Debian (since "Squeeze"), Ubuntu LTS (since 10.4 "Lucid Lynx”) and as a key component of the High Availability Extension for SUSE Linux Enterprise Server (since 11).
Users of other distributions should refer to How To Install.
Pacemaker comes with a Cluster Test Suite (CTS for short) which is an integral part of our release testing. See the CTS README for details.
Pacemaker will try to determine what resources are active on a node when it joins the cluster. To do this, it sends what we call a probe, using resource agents' monitor operation. There are two common reasons for seeing a log message about a resource being multiply active:
- Your resource really is active on more than one node
- Ensure the service is not enabled to start at system boot
- Ensure administrators do not start the service manually anywhere
- Did Pacemaker suffer an internal failure? If so, please see Getting Help and report it
- Your resource agent doesn't implement the monitor operation correctly
- Make sure your resource agent conforms to the OCF standard by using the ocf-tester script
You may also want to read the documentation for the multiple-active option which controls what Pacemaker does when it encounters this condition.
One of the most common reasons for this is the way quorum is calculated for a 2-node cluster. Corosync 2 doesn't pretend 2-node clusters always have quorum. (Corosync 3 has the two-node option to select the desired behavior.)
In order to have quorum, more than half of the total number of cluster nodes need to be online. Clearly this is not the case when a node failure occurs in a 2-node cluster.
If you want to allow the remaining node to provide all the cluster services, you need to set the no-quorum-policy to ignore.
crm configure property no-quorum-policy=ignore
Just be sure to set up fencing to ensure data integrity.
The sequential option does not refer to ordering. Instead it tells Pacemaker to create a colocation chain between the members of the set. For example:
colocation myset inf: app1 app2 app3 app4
is the equivalent of
colocation myset-1 inf: app2 app1 colocation myset-2 inf: app3 app2 colocation myset-3 inf: app4 app3
(app4 -> app3 -> app2 -> app1)
Putting them in brackets sets sequential=false and removes the internal constraints. So:
colocation myset inf: app1 ( app2 app3 app4 )
is actually the equivalent of
colocation myset-1 inf: app2 app1 colocation myset-2 inf: app3 app1 colocation myset-3 inf: app4 app1
(app2 -> app1, app3 -> app1, app4 -> app1)
The difference has implications when there is a failure. With sequential turned on, a failure in app2 results in app3 and app4 also being restarted. However with sequential turned off, a failure in app2 does not affect app3 or app4. In both cases, a failure in app1 results in all resources being restarted.