架构图
Messaging and Infrastructure Layer
第一层是messaging/infrastructure层，也就是Corosync/OpenAIS层。通过这一层发送“我还活着”的信号。
Resource Allocation Layer
第二层是resource allocation layer.这一层最为复杂，包含以下组件：
ClusterResource Manager (CRM)
在资源分配层，每一个动作的执行都要经过CRM。资源分配层上的其它组件（或者更高层的组件）通信也要通过CRM。在每一个节点上，CRM都会维护一个CIB。
Cluster Information Base (CIB)
CIB使用XML表示整个集群的配置和当前状态信息。它包含所有集群选项、节点、资源、约束的定义和彼此之间的关系。并且CIB同步更新至所有的集群节点。在集群内有一个通过DC维护的主CIB节点。其它所有节点存在一个CIB的副本。
Designated Coordinator (DC)
某一个CRM被推选为DC。DC 是群集中唯一可以决定需要在整个群集执行更改（例如节点屏蔽或资源移动）的实体。其它所有的节点从当前DC获得配置和资源分配信息。
Policy Engine (PE)
只要DC需要进行群集范围的更改（对新 CIB 作出反应），PE会根据当前集群状态和配置计算出下一个状态并反馈生成一列指令给DC。PE通常在DC上运行。
Local Resource Manager (LRM)
LRM是CRM的代理，代表 CRM 调用本地RA.它可以执行start/stop/monitor操作并把结果反馈给CRM。并且可以隐藏不同RA(OCF,LSB)直接的差异。LRM 是其本地节点上所有资源相关信息的权威来源。
Resource Layer
最顶层是RL，RL包含不同的RA。RA是已写入的用来启动、停止和监视某种服务（资源）的程序（通常是shell脚本），仅能被LRM调用。
执行流程
Pacemaker作为CRM。CRM作为守护进程(crmd)执行。Pacemaker集中所有集群决策通过推选一个crmd 实例作为DC。如果这个节点故障，会立即推选一个新的DC。
每个节点保留了一个CIB，反映的是集群的配置和当前所有资源状态信息。CIB中的内容会自动同步到整个集群。
集群中很多操作的执行会导致集群的改变。这些动作可能包含增加或移除一个集群资源或改变资源约束。理解执行这些动作在集群上发生了什么是非常重要的。
例如，你想增加一个集群IP地址资源。要想完成，你可能使用命令行工具或GUI去修改CIB。并不要求在DC上执行动作，你可以在其它节点使用一个工具修改，这些操作会通知给DC。然后DC会复制CIB中改变的部分到所有的集群节点。
根据CIB中的信息，PE计算出集群的理想状态以及实现过程，并且反馈指令列表给DC。DC 通过messaging/infrastructure layer发送指令，这些指令被其它节点上的crmd对等体接收。每一个crmd使用LRM执行资源的修改。lrmd是非集群可感知的，它直接与资源源代理（scripts）交互。
所有同等的节点反馈执行的结果给DC。一旦DC推断出所有必要的操作执行成功，集群将会返回到空闲状态并等待进一步事件。如果任一操作未执行成功，则会再次调用PE，CIB中将记录新信息。
在某些情况下，为了保护共享数据不被破坏和资源恢复需要关闭某一节点。
为此，Pacemaker 附带了一个屏蔽子系统，stonithd。STONITH 是 “Shoot The Other NodeIn The Head” 的首字母缩写，通常通过一个远程电源交换机实施。Pacemaker中，STONITH设备配置为资源保存在CIB中，使他们可以更容易地监测资源故障。
本文出自 “在路上” 博客，谢绝转载！
原文地址：http://mingxiao.blog.51cto.com/8124243/1654721
