- 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 is a high-availability cluster resource manager. + 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). +
Pacemaker supports a number of resource agent standards (LSB init + scripts, OCF resource agents, systemd unit files, etc.) to manage + any service, and can model complex relationships among them + (colocation, ordering, etc.).
-- It can even use technology such - as Docker to - automatically isolate the resources managed by the - cluster. +
Pacemaker supports advanced service configurations such as groups + of dependent resources, cloned resources that must be active on + multiple machines, resources that can switch between two different + roles, and containerized services.
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. + projects such as Pacemaker that need to be cluster-aware.
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. + high-performance, reusable features for client/server applications, + including high-performance logging, tracing, IPC, and polling.
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 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. + isolate badly behaving nodes, by either powering off the node or + disabling its access to common resources. The fence-agents project + provides fence agents for commonly used fence devices, including + intelligent power and network switches, IPMI, popular cloud + services, virtualization hosts, and shared storage access.
- 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. +
The Open Cluster Framework specification is a set of standards for + cluster components. Currently, only the resource agent standard is + in use.
- -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. + The community's best minds have created command-line and graphical + interfaces to hide the XML and allow the configuration to be viewed + and updated in a more human-friendly format.
-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. -
- -- The original GUI for Pacemaker written in Python by IBM - China. Mostly deprecated on SLES in favor of Hawk + directly on the shell's command line, or as a batch mode + scripting tool.
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 hawk-guide.readthedocs.io, 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 + an innovative approach for representing the status of and relationships between cluster services. It uses SSH to - let you install, configure and manage clusters from your + let you install, configure, and manage clusters from your desktop.
-+ pcs provides both a command-line tool and Web-based GUI for + managing the complete life cycle of all cluster components, + including Pacemaker, Corosync, QDevice, SBD, and Booth. +
+- 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. + The original GUI for Pacemaker, written in Python by IBM + China. It is no longer actively developed.
Striker is the user interface for the Anvil! (virtual) server platform and the ScanCore autonomous self-defence and alert system.
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.
Q: Where can I get Pacemaker?
-A: Pacemaker ships as part of most modern - distributions, so you can usually just launch your - favorite package manager on: -
A: Pacemaker ships as part of most common Linux + distributions, including CentOS, Debian, Fedora, Gentoo, OpenSUSE, + Red Hat Enterpise Linux, SUSE Linux Enterprise Server, Ubuntu, and + their derivatives, so you can usually just launch your favorite + package manager.
If all else fails, you can try installing from source.
Q: Is there any documentation?
A: Yes. You can find the set relevant to your version in our documentation index.
Q: Where should I ask questions?
-A: Often basic questions can be answered - on irc, - but sending them to the - mailing list is - always a good idea so that everyone can benefit from the - answer. +
A: The ClusterLabs + mailing lists + are usually the best place, as there is an active community with a wide + range of experience, and the answers will be archived to benefit + all users. There is also the + #clusterlabs IRC channel on freenode + for more immediate gratification, though with fewer participants.
-Q: Do I need shared storage?
-A: No. We can help manage it if you have - some, but Pacemaker itself has no need for shared storage. +
Q: What kind of applications can I manage with Pacemaker?
+A: Pacemaker has no direct intelligence about + specific services. Instead, it relies on resource agents, which are + small applications (often shell scripts) that provide a + standardized, generic interface to particular services. This means + that any service can be made highly available, using a script + conforming to one of the supported standards: + LSB ("init scripts"), + OCF resource agents, + and depending on the environment and options selected when + Pacemaker was built, systemd units, upstart, and + Nagios Plugins. + The ClusterLabs resource-agents + project provides a set of OCF agents for common services, and other + projects provide additional agents.
-Q: Which cluster filesystems does Pacemaker support?
-A: Pacemaker supports the - popular OCFS2 - and GFS2 - filesystems. As you'd expect, you can use them on top of - real disks or network block devices - like DRBD. +
Q: Do I need shared storage?
+A: No. Pacemaker can manage shared storage, and + there are fencing techniques that can utilize shared storage, + but Pacemaker itself does not require it.
-Q: What kind of applications can I manage with Pacemaker?
-A: Pacemaker is application-agnostic, meaning - anything that can be scripted can be made highly available, - provided the script conforms to one of the supported standards: - LSB, - OCF, - Systemd, - or Upstart. +
Q: Which cluster filesystems does Pacemaker support?
+A: Pacemaker can support any filesystem with an appropriate + resource agent. The resource-agents project provides agents for + OCFS2 + and GFS2. + You can use these cluster filesystems with physical disks or + network block devices such as + DRBD.
-Q: Can I use Pacemaker with Heartbeat?
-A: Only Pacemaker versions less than 2.0.0. See - this documentation for details.
-Q: Can I use Pacemaker with CMAN?
-A: Only Pacemaker versions greater than or equal to - 1.1.5 and less than 2.0.0. See the - documentation - for details.
- -Q: Can I use Pacemaker with Corosync 1.x?
-A: Only Pacemaker versions less than 2.0.0. You will need to configure - Corosync to load Pacemaker's custom plugin. See - the documentation for details.
- -Q: Can I use Pacemaker with Corosync 2.x or greater?
-A: Yes. This is the only option supported by - Pacemaker 2.0.0 and greater. See the documentation - for details.
- -Q: Do I need a fencing device?
-A: 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 technically able to function without Fencing, - there are a good reasons SUSE and Red Hat will not support - such a configuration. +
Q: What does Pacemaker use for cluster quorum and communication?
+A: Pacemaker relies on external software for + cluster formation. Pacemaker 2.0.0 and above supports only Corosync + version 2.0 or above for this purpose. Older Pacemaker versions + additionally supported Heartbeat + and Corosync 1 with either CMAN or the Pacemaker plugin.
+ +Q: Does my cluster need fencing?
+A: Yes.
+ +Q: No, really, isn't fencing optional?
+A: Fencing is the only way to recover from certain + failure scenarios and ensure the integrity of your data by avoiding + a "split-brain" situation. Although Pacemaker is technically able + to function without fencing, organizations that provide commercial + support generally require it, for good reason.
-Q: Do I need to know XML to configure Pacemaker?
-A: No. Although Pacemaker uses XML as its - native configuration format, there - exist 2 CLIs and at least 4 GUIs - that present the configuration in a human friendly format. +
Q: How is Pacemaker configured?
+A: Pacemaker uses XML as its native configuration + format, but users do not have to deal with XML directly. Pacemaker + provides low-level command-line tools for common tasks, and other + projects provide more user-friendly, high-level + command-line and graphical user interfaces.
Q: How do I synchronize the cluster configuration?
A: 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.
-Q: Should I choose pcs or crmsh?
+Q: Should I choose pcs or the crm shell as a high-level interface?
A: 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. + Of course, if you have a strong preference, you can build your + favorite configuration tool from source if your distro doesn't ship + it.
Q: What if my question isn't here?
A: See the getting help section and let us know!
- -