Architecture



{| cellpadding=1

Cluster Components
! Component !! align=center|Description
 * stonithd || The Heartbeat fencing subsystem.
 * lrmd || Short for Local Resource Management Daemon. Non-cluster aware daemon that presents a common interface to the supported resource types.  Interacts directly with resource agents (scripts).
 * pengine || Short for Policy Engine. Computes the next state of the cluster based on the current state and the configuration. Produces a transition graph contained a list of actions and dependancies.
 * cib || Short for Cluster Information Base. Contains definitions of all cluster options, nodes, resources, their relationships to one another and current status.  Synchronizes updates to all cluster nodes.
 * crmd || Short for Cluster Resource Management Daemon. Largely a message broker for the PEngine and LRM, it also elects a leader to co-ordinate the activities (including starting/stopping resources) of the cluster.
 * openais || The OpenAIS messaging and membership layer.
 * heartbeat || The Heartbeat messaging layer, an alternative to OpenAIS.
 * ccm || Short for Consensus Cluster Membership. The Heartbeat membership layer.
 * }
 * crmd || Short for Cluster Resource Management Daemon. Largely a message broker for the PEngine and LRM, it also elects a leader to co-ordinate the activities (including starting/stopping resources) of the cluster.
 * openais || The OpenAIS messaging and membership layer.
 * heartbeat || The Heartbeat messaging layer, an alternative to OpenAIS.
 * ccm || Short for Consensus Cluster Membership. The Heartbeat membership layer.
 * }
 * ccm || Short for Consensus Cluster Membership. The Heartbeat membership layer.
 * }
 * }
 * }

Functional Overview
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 Co-ordinator). 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.