Pacemaker是Linux环境中使用最为广泛的开源集群资源管理器，Pacemaker利用集群基础架构(Corosync或者Heartbeat)提供的消息和集群成员管理功能，实现节点和资源级别的故障检测和资源恢复，从而最大程度保证集群服务的高可用。从逻辑功能而言，pacemaker在集群管理员所定义的资源规则驱动下，负责集群中软件服务的全生命周期管理，这种管理甚至包括整个软件系统以及软件系统彼此之间的交互。Pacemaker在实际应用中可以管理任何规模的集群，由于其具备强大的资源依赖模型，这使得集群管理员能够精确描述和表达集群资源之间的关系（包括资源的顺序和位置等关系）。同时，对于任何形式的软件资源，通过为其自定义资源启动与管理脚本（资源代理），几乎都能作为资源对象而被Pacemaker管理。此外，需要指出的是，Pacemaker仅是资源管理器，并不提供集群心跳信息，由于任何高可用集群都必须具备心跳监测机制，因而很多初学者总会误以为Pacemaker本身具有心跳检测功能，而事实上Pacemaker的心跳机制主要基于Corosync或Heartbeat来实现
从起源上来看，Pacemaker是为Heartbeat项目而开发的CRM项目的延续，CRM最早出现于2003年，是专门为 Heartbeat项目而开发的集群资源管理器，而在2005年，随着Heartbeat2.0版本的发行才正式推出第一版本的CRM,即 Pacemaker的前身。在2007年末，CRM正式从Heartbeat2.1.3版本中独立，之后于2008年Pacemaker0.6稳定版本正式发行，随后的2010年3月CRM项目被终止，作为CRM项目的延续，Pacemaker被继续开发维护，如今Pacemaker已成为开源集群资源管理器的事实标准而被广泛使用。此外，Heartbeat到了3．0版本后已经被拆分为几个子项目了，这其中便包括 Pacemaker、Heartbeat3.0、Cluster Glue和Resource Agent。
（1）Heartbeat
Heartbeat项目最初的消息通信层被独立为新的Heartbeat项目，新的Heartbeat只负责维护集群各节点的信息以及它们之间的心跳通信，通常将Pacemaker与Heartbeat或者Corosync共同组成集群管理软件，Pacemaker利用Heartbeat或者Corosync提供的节点及节点之间的心跳信息来判断节点状态。
（2）Cluster Clue
Cluster Clue相当于一个中间层，它用来将Heartbeat和Pacemaker关联起来，主要包含两个部分，即本地资源管理器（Local Resource Manager，LRM）和Fencing设备（Shoot The Other Node In The Head，STONITH）
（3）Resource Agent
资源代理（Resource Agent，RA）是用来控制服务的启停，监控服务状态的脚本集合，这些脚本会被位于本节点上的LRM调用从而实现各种资源的启动、停止、监控等操作。
（4）pacemaker
Pacemaker是整个高可用集群的控制中心，用来管理整个集群的资源状态行为，客户端通过pacemaker来配置、管理、监控整个集群的运行状态。Pacemaker是一个功能非常强大并支持众多操作系统的开源集群资源管理器，Pacemaker支持主流的 Linux系统，如 Redhat的 RHEL系列、Fedora系列、openSUSE系列、Debian系列、Ubuntu系列和centos系列，这些操作系统上都可以运行Pacemaker并将其作为集群资源管理器。
1、监测并恢复节点和服务级别的故障。
2、存储无关，并不需要共享存储。
3、资源无关，任何能用脚本控制的资源都可以作为集群服务。
4、支持节点STONITH功能以保证集群数据的完整性和防止集群脑裂。
5、支持大型或者小型集群。
6、支持Quorum机制和资源驱动类型的集群。
7、支持几乎是任何类型的冗余配置。
8、自动同步各个节点的配置文件。
9、可以设定集群范围内的Ordering、Colocation and Anti-colocation等约束。
10、高级服务类型支持，例如：
Clone功能，即那些要在多个节点运行的服务可以通过Clone功能实现，Clone功能将会在多个节点上启动相同的服务；
Multi-state功能，即那些需要运行在多状态下的服务可以通过Multi--state实现，在高可用集群的服务中，有很多服务会运行在不同的高可用模式下，
如：Active/Active模式或者Active/passive模式等，并且这些服务可能会在Active与standby(Passive)之间切换。
11、具有统一的、脚本化的集群管理工具。
Pacemaker对用户的环境没有特定的要求，这使得它支持任何类型的高可用节点冗余配置，包括Active/Active、 Active/Passive、N+1、N+M、N-to-1 and N-to-N模式的高可用集群，用户可以根据自身对业务的高可用级别要求和成本预算，通过Pacemaker部署适合自己的高可用集群。
（1）Active/Active模式
在这种模式下，故障节点上的访问请求或自动转到另外一个正常运行节点上，或通过负载均衡器在剩余的正常运行的节点上进行负载均衡。这种模式下集群中的节点通常部署了相同的软件并具有相同的参数配置，同时各服务在这些节点上并行运行。
（2）Active/Passive模式
在这种模式下，每个节点上都部署有相同的服务实例，但是正常情况下只有一个节点上的服务实例处于激活状态，只有当前活动节点发生故障后，另外的处于standby状态的节点上的服务才会被激活，这种模式通常意味着需要部署额外的且正常情况下不承载负载的硬件。
（3）N+1模式
所谓的N+1就是多准备一个额外的备机节点，当集群中某一节点故障后该备机节点会被激活从而接管故障节点的服务。在不同节点安装和配置有不同软件的集群中，即集群中运行有多个服务的情况下，该备机节点应该具备接管任何故障服务的能力，而如果整个集群只运行同一个服务，则N+1模式便退变为Active/Passive模式。
（4）N+M模式
在单个集群运行多种服务的情况下，N+1模式下仅有的一个故障接管节点可能无法提供充分的冗余，因此，集群需要提供M（M>l）个备机节点以保证集群在多个服务同时发生故障的情况下仍然具备高可用性，M的具体数目需要根据集群高可用性的要求和成本预算来权衡。
（5）N-to-l模式
在N-to-l模式中，允许接管服务的备机节点临时成为活动节点（此时集群已经没有备机节点），但是，当故障主节点恢复并重新加人到集群后，备机节点上的服务会转移到主节点上运行，同时该备机节点恢复standby状态以保证集群的高可用。
（6）N-to-N模式
N-to-N是Active/Active模式和N+M模式的结合，N-to-N集群将故障节点的服务和访问请求分散到集群其余的正常节点中，在N-to-N集群中并不需要有Standby节点的存在、但是需要所有Active的节点均有额外的剩余可用资源。
从高层次的集群抽象功能来看，Pacemaker的核心架构主要由集群不相关组件、集群资源管理组件和集群底层基础模块三个部分组成。
（1）底层基础模块
底层的基础架构模块主要向集群提供可靠的消息通信、集群成员关系和等功能，底层基础模块主要包括像 corosync、CMAN和Heartbeat等项目组件。
（2）集群无关组件
在Pacemaker架构中，这部分组件主要包括资源本身以及用于启动、关闭以及监控资源状态的脚本，同时还包括用于屏蔽和消除实现这些脚本所采用的不同标准之间差异的本地进程。虽然在运行多个实例时，资源彼此之间的交互就像一个分布式的集群系统，但是，这些实例服务之间仍然缺乏恰当的HA机制和独立于资源的集群治理能力，因此还需要后续集群组件的功能支持。
（3）资源管理
Pacemaker就像集群大脑，专门负责响应和处理与集群相关的事件，这些事件主要包括集群节点的加人、集群节点脱离，以及由资源故障、维护、计划的资源相关操作所引起的资源事件，同时还包括其他的一些管理员操作事件，如对配置文件的修改和服务重启等操作。在对所有这些事件的响应过程中，Pacemaker会计算出当前集群应该实现的最佳理想状态并规划出实现该理想状态后续需要进行的各种集群操作，这些操作可能包括了资源移动、节点停止，甚至包括使用远程电源管理模块来强制节点下线等。
当Pacemaker与Corosync集成时，Pacemaker也支持常见的主流开源集群文件系统，而根据集群文件系统社区过去一直从事的标准化工作，社区使用了一种通用的分布式锁管理器来实现集群文件系统的并行读写访问，这种分布式锁控制器利用了Corosync所提供的集群消息和集群成员节点处理能力（节点是在线或离线的状态）来实现文件系统集群，同时使用Pacemaker来对服务进行隔离
Pacemaker作为一个独立的集群资源管理器项目，其本身由多个内部组件构成，这些内部组件彼此之间相互通信协作并最终实现了集群的资源管理，Pacemaker项目由五个内部组件构成，各个组件之间的关系如右图所示。
CIB：集群信息基础（Cluster Information Base)。
CRMd：集群资源管理进程（Cluster Resource Manager deamon)。
LRMd：本地资源管理进程(Local Resource Manager deamon)。
PEngine(PE)：策略引擎(PolicyEngine)。
STONITHd：集群Fencing进程（Shoot The Other Node In The Head deamon)。
CIB主要负责集群最基本的信息配置与管理，Pacemaker中的CIB主要使用XML的格式来显示集群的配置信息和集群所有资源的当前状态信息。CIB所管理的配置信息会自动在集群节点之间进行同步，PE将会使用 CIB所提供的集群信息来规划集群的最佳运行状态。并根据当前 CIB信息规划出集群应该如何控制和操作资源才能实现这个最佳状态，在 PE做出决策之后，会紧接着发出资源操作指令，而 PE发出的指令列表最终会被转交给集群最初选定的控制器节点（ Designated controller，DC),通常 DC便是运行 Master CRMd的节点。
在集群启动之初，pacemaker便会选择某个节点上的CRM进程实例来作为集群Master CRMd,然后集群中的CRMd便会集中处理PE根据集群CIB信息所决策出的全部指令集。在这个过程中，如果作为Master的CRM进程出现故障或拥有 Master CRM进程的节点出现故障，则集群会马上在其他节点上重新选择一个新的Master CRM进程。
在PE的决策指令处理过程中，DC会按照指令请求的先后顺序来处理PEngine发出的指令列表，简单来说，DC处理指令的过程就是把指令发送给本地节点上的LRMd（当前节点上的CRMd已经作为Master在集中控制整个集群，不会再并行处理集群指令）或者通过集群消息层将指令发送给其他节点上的CRMd进程，然后这些节点上的CRMd再将指令转发给当前节点的 LRMd去处理。当集群节点运行完指令后，运行有CRMd进程的其他节点会把他们接收到的全部指令执行结果以及日志返回给 DC（即DC最终会收集全部资源在运行集群指令后的结果和状态），然后根据执行结果的实际情况与预期的对比，从而决定当前节点是应该等待之前发起的操作执行完成再进行下一步的操作，还是直接取消当前执行的操作并要求PEngine根据实际执行结果再重新规划集群的理想状态并发出操作指令。
在某些情况下，集群可能会要求节点关闭电源以保证共享数据和资源恢复的完整性，为此，Pacemaker引人了节点隔离机制，而隔离机制主要通过STONITH进程实现。STONITH是一种强制性的隔离措施，STONINH功能通常是依靠控制远程电源开关以关闭或开启节点来实现。在Pacemaker中，STONITH设备被当成资源模块并被配置到集群信息CIB中，从而使其故障情况能够被轻易地监控到。同时，STONITH进程（STONITHd)能够很好地理解STONITH设备的拓扑情况，因此，当集群管理器要隔离某个节点时，只需STONITHd的客户端简单地发出Fencing某个节点的请求，STONITHd就会自动完成全部剩下的工作，即配置成为集群资源的STONITH设备最终便会响应这个请求，并对节点做出Fenceing操作，而在实际使用中，根据不同厂商的服务器类型以及节点是物理机还是虚拟机，用户需要选择不同的STONITH设备。
三、Pacemaker集群管理工具pcs
可以用用cibadmin命令行工具来查看和管理pacemaker的集群配置信息，集群CIB中的配置信息量非常大而且以 XML语言呈现，对于仅由极少数节点和资源所组成的集群，cibadmin也许是个可行方案。但是，对于拥有大量节点和资源的大规模集群，通过编辑XML文件来查看修改集群配置显然是非常艰难而且极为不现实的工作由于XML文件内容条目极多，因此用户在修改XML文件的过程中极易出现人为错误。而在开源社区里，简单实用才是真正开源精神的体现，对于开源系统中任何文件配置参数的修改，简化统一的命令行工具才是最终的归宿。
下载APP>
