Product SiteDocumentation Site

1.3. Pacemaker Architecture

At the highest level, the cluster is made up of three pieces:
When combined with Corosync, Pacemaker also supports popular open source cluster filesystems. footnote:[ Even though Pacemaker also supports Heartbeat, the filesystems need to use the stack for messaging and membership and Corosync seems to be what they’re standardizing on.
Technically it would be possible for them to support Heartbeat as well, however there seems little interest in this. ]
Due to past standardization within the cluster filesystem community, they make use of a common distributed lock manager which makes use of Corosync for its messaging and membership capabilities (which nodes are up/down) and Pacemaker for fencing services.
The Pacemaker stack

Figure 1.1. The Pacemaker Stack


1.3.1. Internal Components

Pacemaker itself is composed of five key components:
  • CIB (aka. Cluster Information Base)
  • CRMd (aka. Cluster Resource Management daemon)
  • LRMd (aka. Local Resource Management daemon)
  • PEngine (aka. PE or Policy Engine)
  • STONITHd
Subsystems of a Pacemaker cluster

Figure 1.2. Internal Components


The CIB uses XML to represent both the cluster’s configuration and current state of all resources in the cluster. The contents of the CIB are automatically kept in sync across the entire cluster and are used by the PEngine to compute the ideal state of the cluster and how it should be achieved.
This list of instructions is then fed to the DC (Designated Controller). Pacemaker centralizes all cluster decision making by electing one of the CRMd instances to act as a master. Should the elected CRMd process, or the node it is on, fail… a new one is quickly established.
The DC carries out the PEngine’s instructions in the required order by passing them to either the LRMd (Local Resource Management daemon) or CRMd peers on other nodes via the cluster messaging infrastructure (which in turn passes them on to their LRMd process).
The peer nodes all report the results of their operations back to the DC and, based on the expected and actual results, will either execute any actions that needed to wait for the previous one to complete, or abort processing and ask the PEngine to recalculate the ideal cluster state based on the unexpected results.
In some cases, it may be necessary to power off nodes in order to protect shared data or complete resource recovery. For this Pacemaker comes with STONITHd.
STONITH is an acronym for Shoot-The-Other-Node-In-The-Head and is usually implemented with a remote power switch.
In Pacemaker, STONITH devices are modeled as resources (and configured in the CIB) to enable them to be easily monitored for failure, however STONITHd takes care of understanding the STONITH topology such that its clients simply request a node be fenced and it does the rest.