Product SiteDocumentation Site

1.3. Architettura di Pacemaker

Al livello più elevato il cluster è composto da tre componenti:
Conceptual overview of the cluster stack

Figura 1.1. Panoramica concettuale dello Stack


When combined with Corosync, Pacemaker also supports popular open source cluster filesystems. [3]
Due to recent standardization within the cluster filesystem community, they make use of a common distributed lock manager which makes use of Corosync for its messaging capabilities and Pacemaker for its membership (which nodes are up/down) and fencing services.
The Pacemaker StackThe Pacemaker stack when running on Corosync

Figura 1.2. Lo stack Pacemaker


1.3.1. Componenti interni

Pacemaker stesso è composto da quatto componenti chiave (illustrati sotto nello stesso schema di colori del diagramma precedente):
  • CIB (acronimo di come Cluster Information Base)
  • CRMd (acronimo di Cluster Resource Management daemon)
  • PEngine (acronimo di Policy Engine)
  • STONITHd
Subsystems of a Pacemaker cluster running on Corosync

Figura 1.3. Componenti interni


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).
Gli altri nodi riferiscono i risultati delle loro operazioni al DC. Attraverso l'analisi dei risultati aspettati e di quelli attuali, i nodi eseguiranno qualsiasi azione necessaria per attendere il completamento della precedente oppure interromperanno il processo, richiedendo al PEngine di calcolare nuovamente lo stato ideale del cluster basandosi sui risulati inaspettati.
In alcuni casi, potrebbe essere necessario spegnere i nodi per preservare dati condifivi o completare il ripristino di una risorsa. Per questo in Pacemaker esiste STONITHd. STONITH è un acronimo per Shoot-The-Other-Node-In-The-Head e viene implementato tipicamente con un switch di potenza remoto. In Pacemaker i dispositivi STONITH sono modellati come risorse (e configurati all'interno del CIB) per facilitare il monitoraggio delle anomalie. STONITHd si prende cura di capire la topologia STONITH così che i suoi client debbano unicamente richiedere unicamente la morte di un nodo ed esso si preoccupi del resto.


[3] 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.