前言：这里是小白工作学习中对pacemaker的见解，大神可以直接绕道了，如果写的不对的地方欢迎大神指正。对于初学的小白来说推荐一个网站，这个网站讲的还是挺全的：http://clusterlabs.org/pacemaker.html

pacemaker简介

下面我们用一张图来简易说明下这个到底是干啥用的。

在硬件层面我们可以看到多个节点上启用了不同服务，如数据库，Apache服务等，这里你可以看到有个standby machine，这台机器就是当前两个服务不能在它原来的节点上运行时提供备用的。这样能保证如果某一台机器的Apache服务或者某一台机器的数据库服务挂了，那么马上在另外一个节点上能够启动该服务。当然首先这三个节点都是要默认安装这些服务并且做配置的。那么这样看起来我们能够通过增加节点来提供高可用解决单点故障。这也是HA要做的主要工作。

pacemaker作为linux系统高可用HA的资源管理器，位于HA集群架构中的资源管理，资源代理层，它不提供底层心跳信息传递功能。(心跳信息传递是通过corosync来处理的这个使用有兴趣的可以在稍微了解一下，其实corosync并不是心跳代理的唯一组件，可以用hearbeat等来代替)。pacemaker管理资源是通过脚本的方式来执行的。我们可以将某个服务的管理通过shell,python等脚本语言进行处理，在多个节点上启动相同的服务时，如果某个服务在某个节点上出现了单点故障那么pacemaker会通过资源管理脚本来发现服务在改节点不可用。

pacemaker只是作为HA的资源管理器，所以不要想当然理解它能够直接管控资源，如果你的资源没有做脚本配置那么对于pacemaker来说它就是不可管理的。

pacemaker集群种类

pacemaker对环境没有特定的要求，这使得它支持任何的冗余配置，包括Active/Active,Active/Passive,N+1,N+M,N-to-1和N-to-N. 但是就冗余性来说可以直观地分为两类Active/Passive HA 和Active/Active HA，其余的只是这两类的变种。
Active/Passive HA：集群只包括两个节点简称主备。在这种配置下，系统采用主和备用机器来提供服务，系统只在主设备上提供服务。在主设备故障时，备设备上的服务被启动来替代主设备提供的服务。典型地，可以采用 CRM 软件比如 Pacemaker 来控制主备设备之间的切换，并提供一个虚机 IP 来提供服务。
Active/Active HA：集群只包括两个节点时简称双活，包括多节点时成为多主（Multi-master）。在这种配置下，系统在集群内所有服务器上运行同样的负载。以数据库为例，对一个实例的更新，会被同步到所有实例上。这种配置下往往采用负载均衡软件比如 HAProxy 来提供服务的虚拟 IP。

Active/Passive HA的架构：

这种方案是在多个节点（两个或者两个以上）构成集群，但是当前现在就只有一个节点的服务活动对外提供服务。如果该节点上服务故障则立马将服务切换到备用节点。

Active/Active HA架构：

这种配置主要是对服务提供高可用和负载均衡，借助haproxy来将某个服务的业务流量平均的分配在多个节点上，而通过pacemaker来保证该服务至少是可用得。

pacemaker整体结构

在最高一个层次，集群由三个部分组成：
1.提供消息和集群关系功能的集群核心基础组建（标红的部分）
2.集群无关的组件（蓝色部分）。在Pacemaker架构中，这部分不仅包含有怎么样启动，关闭，监控资源的脚本，而且还有一个本地的守护进程来消除这些脚本实现的（采用的）不同标准之间的差异。
3.大脑（绿色部分）处理并响应来自集群和资源的事件（比如节点的离开和加入，资源的失效），以及管理员对配置文件的修改。在对所有这些事件的响应中，Pacemaker会计算集群理想的状态，并规划一个途径来实现它。这个操作可能会包含移动资源，停止节点，甚至使用远程电源管理来强制使他们下线。

当与Corosync（实现HA心跳信息传输的功能就是Corosync）集成时，Pacemaker也支持常见的开源集群文件系统，根据来着集群文件系统社区的最新标准，他们用一个通用的分布式锁控制器，它靠Corosync通信并且用Pacemaker管理成员关系（哪些节点是开启或关闭的）和隔离服务。

pacemaker内部组件

1.CIB（集群信息基础，在内存中的一个xml格式集群配置文件）
2.CRMd（集群资源管理守护进程,每个crmd上有一个cib用来定义维护资源， 主要是消息代理的PEngine和LRM，还选举一个领导者（DC）统筹活动（包括启动/停止资源）的集群。）
3.PEngine（PE或者策略引擎）
4.STONITHd
5.ccm:cluster consensus membership service 共识集群成员，心跳成员层。

CIB用XML来展示集群的配置和资源的当前状态。CIB的内容会自动地在集群之间同步，并被PEngine用来计算集群的理想状态和如何达到这个理想状态。

这个指令列表然后会被交给DC（指定协调者）。Pacemaker会推举一个CRMd实例作为master来集中做出所有决策。如果推举的CRMd繁忙中，或者这个节点不够稳定，一个新的master会马上被推举出来。

DC会按顺序处理PEngine的指令，然后把他们发送给LRMd（本地资源管理守护进程）或者通过集群消息层发送给其他CRMd成员（就是把这些指令一次传给LRMd）

节点会把他们所有操作的日志发给DC，然后根据预期的结果和实际的结果（之间的差异），执行下一个等待中的命令，或者取消操作，并让PEngine根据非预期的结果重新计算集群的理想状态。

在某些情况下，可能会需要关闭节点的电源来保证共享数据的完整性是完全地恢复资源。为此Pacemaker引入了STONITHd。STONITH是Shoot-The-Other-Node-In-The-Head（爆其他节点的头）的缩写，并且通常是远程电源开关来实现的。在Pacemaker中，STONITH设备被当成资源（并且是在CIB中配置）从而轻松地监控，然而STONITHd会注意理解STONITH拓扑，比如他的客户端请求隔离一个节点，它会重启那个机器。（不同的爆头设备驱动会对相同的请求有不同的理解，这些都是在驱动中定义的。）

lrmd：本地资源管理守护进程。它提供了一个通用的接口支持的资源类型。直接调用资源代理（脚本）。

pacemaker资源简介

Pacemaker的资源主要有两类，即LSB和OCF。其中LSB即linux标准服务，通常就是/etc/init.d目录下那些脚本。Pacemaker可以用这些脚本来启停服务。在crm ra list lsb中可以看到。另一类OCF实际上是对LSB服务的拓展，增加了一些高可用集群管理的功能如故障监控等和更多的元信息。可以通过crm ra list ocf 看到当前支持的资源。要让pacemaker可以很好的对服务进行高可用保障就得实现一个OCF资源。

Pacemaker自带的资源管理程序都在/usr/lib/ocf/resource.d下。其中的hearbeat目录中就包含了那些自带的常用服务。哪些服务的脚本可以作为我们自己实现时候的参考。