Pacemaker详解一、前言二、 Pacemaker概述 三、Pacemaker集群管理工具pcs 四、Pacemaker集群资源管理 1、集群资源代理

一、前言

　　云计算与集群系统密不可分，作为分布式计算和集群计算的集大成者，云计算的基础设施必须通过集群进行管理控制，而作为拥有大量资源与节点的集群，必须具备一个强大的集群资源管理器（Cluster system Manager, CSM)来调度和管理集群资源。对于任何集群而言，集群资源管理器是整个集群能够正常运转的大脑和灵魂，任何集群资源管理器的缺失和故障都会导致集群陷人瘫痪混乱的状态。 Openstack的众多组件服务既可以集成到单个节点上运行，也可以在集群中分布式运行。但是，要实现承载业务系统的高可用集群， Openstack服务必须部署到高可用集群上，并在实现 Openstack服务无单点故障的同时，实现故障的自动转移和自我愈合，而这些功能是 Openstack的多数服务本身所不具备的。因此，在生产环境中部署 OpenStack高可用集群时，必须引人第三方集群资源管理软件，专门负责 Openstack集群资源的高可用监控调度与管理。

　　集群资源管理软件种类众多，并有商业软件与开源软件之分。在传统业务系统的高可用架构中，商业集群管理软件的使用非常普遍，如 IBM的集群系统管理器、 PowerHA SystemMirror（也称为 HACMP)以及针对 DB2的 purescale数据库集群软件；再如orcale的 Solaris Cluster系列集群管理软件，以及 oracle数据库的 ASM和 RAC集群管理软件等商业高可用集群软件都在市场上占有很大的比例。此外，随着开源社区的发展和开源生态系统的扩大，很多商业集群软件也正在朝着开源的方向发展，如IBM开源的 xCAT集软件，而在 Linux开源领域Pacemaker/Corosync、 HAproxy/Keepalived等组合的集群资源管理软件，也有着极为广泛的应用。

二、 Pacemaker概述

1、Pacemaker介绍

　　 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并将其作为集群资源管理器。

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)具有统一的脚本化的集群管理工具。

2、pacemaker的服务模式

　　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的节点均有额外的剩余可用资源。

3、Pacemaker的架构

　　从高层次的集群抽象功能来看， Pacemaker的核心架构主要由集群不相关组件、集群资源管理组件和集群底层基础模块三个部分组成。

​（1）底层基础模块

　　底层的基础架构模块主要向集群提供可靠的消息通信、集群成员关系和等功能，底层基础模块主要包括像 corosync、 CMAN和 Heartbeat等项目组件。

（2）集群无关组件

　　在 Pacemaker架构中，这部分组件主要包括资源本身以及用于启动、关闭以及监控资源状态的脚本，同时还包括用于屏蔽和消除实现这些脚本所采用的不同标准之间差异的本地进程。虽然在运行多个实例时，资源彼此之间的交互就像一个分布式的集群系统，但是，这些实例服务之间仍然缺乏恰当的 HA机制和独立于资源的集群治理能力，因此还需要后续集群组件的功能支持。

（3）资源管理

　　Pacemaker就像集群大脑，专门负责响应和处理与集群相关的事件，这些事件主要包括集群节点的加人、集群节点脱离，以及由资源故障、维护、计划的资源相关操作所引起的资源事件，同时还包括其他的一些管理员操作事件，如对配置文件的修改和服务重启等操作。在对所有这些事件的响应过程中， Pacemaker会计算出当前集群应该实现的最佳理想状态并规划出实现该理想状态后续需要进行的各种集群操作，这些操作可能包括了资源移动、节点停止，甚至包括使用远程电源管理模块来强制节点下线等。

　　当Pacemaker与Corosync集成时， Pacemaker也支持常见的主流开源集群文件系统，而根据集群文件系统社区过去一直从事的标准化工作，社区使用了一种通用的分布式锁管理器来实现集群文件系统的并行读写访问，这种分布式锁控制器利用了Corosync所提供的集群消息和集群成员节点处理能力（节点是在线或离线的状态）来实现文件系统集群，同时使用Pacemaker来对服务进行隔离。

4、Pacemake内部组件

　　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文件的过程中极易出现人为错误。而在开源社区里，简单实用才是真正开源精神的体现，对于开源系统中任何文件配置参数的修改，简化统一的命令行工具才是最终的归宿。

　　随着开源集群软件Pacemaker版本的不断更新，社区推出了两个常用的集群管理命令行工具，即集群管理员最为常用的 pcs和 crmsh命令。本文使用的是 pcs命令行工具，关于 crmsh的更多使用方法和手册可以参考Pacemaker的官方网站。在 pacemaker集群中PCS命令行工具几乎可以实现集群管理的各种功能，例如，全部受控的 pacemaker和配置属性的变更管理都可以通过 pcs实现。此外，需要注意的是， pcs命令行的使用对系统中安装的 pacemaker和 corosync软件版本有一定要求，即 Pacemaker1.1.8及其以上版本， Corosync 2.0及其以上版本才能使用 pcs命令行工具进行集群管理。 pcs命令可以管理的集群对象类别和具体使用方式可以通过pcs --help参数查看：

[[email protected] ~]# pcs --help

Usage: pcs [-f file] [-h] [commands]... Control and configure pacemaker and corosync.

Options: 

    -h, --help Display usage and exit. 

    -f file Perform actions on file instead of active CIB. 

    --debug Print all network traffic and external commands run. 

    --version Print pcs version information. 

    --request-timeout Timeout for each outgoing request to another node in seconds.Default is 60s.

Commands:

    cluster   Configure cluster options and nodes. 

    resource   Manage cluster resources. 

    stonith   Manage fence devices.

    constraint   Manage resource constraints.

    property   Manage pacemaker properties. 

    acl   Manage pacemaker access control lists.

    qdevice   Manage quorum device provider on the local host. 

    quorum   Manage cluster quorum settings. 

    booth   Manage booth (cluster ticket manager). 

    status   View cluster status. 

    config   View and manage cluster configuration. 

    pcsd   Manage pcs daemon.

    node   Manage cluster nodes. 

    alert  Manage pacemaker alerts.

 最为常用的管理命令有：

cluster        配置集群选项和节点

status         查看当前集群资源和节点以及进程状态

resource     创建和管理集群资源

constraint   管理集群资源约束和限制

property     管理集群节点和资源属性

config         以用户可读格式显示完整集群配置信息

四、Pacemaker集群资源管理

1、集群资源代理

　　在 pacemaker高可用集群中，资源就是集群所维护的高可用服务对象。根据用户的配置，资源有不同的种类，其中最为简单的资源是原始资源(primitive Resource)，此外还有相对高级和复杂的资源组(Resource Group)和克隆资源(Clone Resource)等集群资源概念。在 Pacemaker集群中，每一个原始资源都有一个资源代理(Resource Agent, RA)，RA是一个与资源相关的外部脚本程序，该程序抽象了资源本身所提供的服务并向集群呈现一致的视图以供集群对该资源进行操作控制。通过 RA，几乎任何应用程序都可以成为 Pacemaker集群的资源，从而被集群资源管理器控制。RA的存在使得集群资源管理器可以对其所管理的资源“不求甚解”，即集群资源管理器无需知道资源具体的工作逻辑和原理（ RA已将其封装），资源管理器只需向RA发出 start、 stop、Monitor等命令， RA便会执行相应的操作。从资源管理器对资源的控制过程来看，集群对资源的管理完全依赖于该资源所提供的，即资源的 RA脚本功能直接决定了资源管理器可以对该资源进行何种控制，因此一个功能完善的 RA在发行之前必须经过充分的功能测试。在多数情况下，资源 RA以 shell脚本的形式提供，当然也可以使用其他比较流行的如 c、 python、 perl等语言来实现 RA。

　　在 pacemaker集群中，资源管理器支持不同种类的资源代理，这些受支持的资源代理包括 OCF、LSB、 Upstart、 systemd、 service、 Fencing、 Nagios Plugins，而在 Linux系统中，最为常见的有 OCF(Open Cluster Framework)资源代理、 LSB（ Linux standard Base)资源代理、systemd和 service资源代理。

（1） OCF

　　OCF是开放式集群框架的简称，从本质上来看OCF标准其实是对LSB标准约定中 init脚本的一种延伸和扩展。 OCF标准支持参数传递、自我功能描述以及可扩展性，此外，OCF标准还严格定义了操作执行后的返回代码，集群资源管理器将会根据资源代理返回的执行代码来对执行结果做出判断。因此，如果OCF脚本错误地提供了与操作结果不匹配的返回代码，则执行操作后的集群资源行为可能会变得莫名其妙，而对于不熟悉OCF脚本的用户，这将会是个非常困惑和不解的问题，尤其是当集群依赖于OCF返回代码来在资源的完全停止状态、错误状态和不确定状态之间进行判断的时候。因此，在OCF脚本发行使用之前一定要经过充分的功能测试，否则有问题的OCF脚本将会扰乱整个集群的资源管理。在Pacemaker集群中，OCF作为一种可以自我描述和高度灵活的行业标准，其已经成为使用最多的资源类别。

（2） LSB

　　LSB是最为传统的 Linux“资源标准之一，例如在 Redhat的 RHEL6及其以下版本中（或者对应的 centos版本中），经常在/etc/init.d目录下看到的资源启动脚本便是LSB标准的资源控制脚本。通常，LSB类型的脚本是由操作系统的发行版本提供的，而为了让集群能够使用这些脚本，它们必须遵循 LSB的规定， LSB类型的资源是可以配置为系统启动时自动启动的，但是如果需要通过集群资源管理器来控制这些资源，则不能将其配置为自动启动，而是由集群根据策略来自行启动。

（3） Systemd

　　在很多 Linux的最新发行版本中， systemd被用以替换传统“sysv"风格的系统启动初始化进程和脚本，如在 Redhat的 RHEL7和对应的 centos7操作系统中，systemd已经完全替代了 sysvinit启动系统，同时 systemd提供了与 sysvinit以及 LSB风格脚本兼容的特性，因此老旧系统中已经存在的服务和进程无需修改便可使用 systemd在 systemd中，服务不再是/etc/init.d目录下的 shell脚本，而是一个单元文件（ unit-file），Systemd通过单元文件来启停和控制服务， Pacemaker提供了管理 Systemd类型的应用服务的功能。

（4） Service

　　Service是 Pacemaker支持的一种特别的服务别名，由于系统中存在各种类型的服务（如 LSB、 Systemd和 OCF)，Pacemaker使用服务别名的方式自动识别在指定的集群节点上应该使用哪一种类型的服务。当一个集群中混合有 Systemd、 LSB和 OCF类型资源的时候，Service类型的资源代理别名就变得非常有用，例如在存在多种资源类别的情况下，Pacemaker将会自动按照 LSB、 Systemd、 Upstart的顺序来查找启动资源的脚本。在 pacemaker中，每个资源都具有属性，资源属性决定了该资源 RA脚本的位置，以及该资源隶属于哪种资源标准。例如，在某些情况下，用户可能会在同一系统中安装不同版本或者不同来源的同一服务（如相同的 RabbitMQ Cluster安装程序可能来自 RabbitMQ官方社区也可能来自 Redhat提供的 RabbitMQ安装包），在这个时候，就会存在同一服务对应多个版本资源的情况，为了区分不同来源的资源，就需要在定义集群资源的时候通过资源属性来指定具体使用哪个资源。在 pacemaker集群中，资源属性由以下几个部分构成。

Resource_id：用户定义的资源名称。

Standard：脚本遵循的标准，允许值为OCF、Service、Upstart、Systemd、LSB、Stonith。

Type：资源代理的名称，如常见的IPaddr便是资源的。

Provider：OCF规范允许多个供应商提供同一资源代理，Provider即是指资源脚本的提供者，多数OCF规范提供的资源代均使用Heartbeat作为Provider。

例如在集群中创建一个名称为VirtualIP：

Resource_id Standard：Provider：Type

pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 nic=eth2

常用的命令方法：

pcs resource list    查看集群中所有可用资源列表

pcs resource standards 查看支持的资源代理标准

pcs resource providers 查看集群中可用资源代理提供程序列表

pcs resource describe Standard:Provider:Type  查看Standard：Provider：Type指定的资源代理的详细信息。

pcs resource  cleanup resource_id 重置资源状态

1、查看http的资源代理

[[email protected] ~]# pcs resource list |grep http service:httpd - systemd unit file for httpd systemd:httpd - systemd unit file for httpd 

2、查看怎么创建http资源

 [[email protected] ~]# pcs resource describe systemd:httpd systemd:httpd - systemd unit file for httpd Cluster Controlled httpd Default operations: start: interval=0s timeout=100 stop: interval=0s timeout=100 monitor: interval=60 timeout=100

3、创建http资源

 [[email protected] ~]# pcs resource create http systemd:httpd

2、集群资源约束

　　集群是由众多具有特定功能的资源组成的集合，集群中的每个资源都可以对外提供独立服务，但是资源彼此之间存在依赖与被依赖的关系。如资源B的启动必须依赖资源A的存在，因此资源A必须在资源B之前启动，再如资源A必须与资源B位于同一节点以共享某些服务，则资源 B与 A在故障切换时必须作为一个逻辑整体而同时迁移到其他节点，在 pacemaker中，资源之间的这种关系通过资源约束或限制（ Resource constraint)来实现。 pacemaker集群中的资源约束可以分为以下几类:

        位置约束(Location)：位置约束限定了资源应该在哪个集群节点上启动运行。

        顺序约束(Order)：顺序约束限定了资源之间的启动顺序。

        资源捆绑约束(Colocation)：捆绑约束将不同的资源捆绑在一起作为一个逻辑整体，即资源 A位于 c节点，则资源 B也必须位于 c节点，并且资源 A、 B将会同时进 行故障切换到相同的节点上。

　　在资源配置中， Location约束在限定运行资源的节点时非常有用，例如在 Openstack高可用集群配置中，我们希望 Nova-ompute资源仅运行在计算节点上，而nova-api和 Neutron-sever等资源仅运行在控制节点上，这时便可通过资源的Location约束来实现。例如，我们先给每一个节点设置不同的 osprole属性（属性名称可自定义），计算节点中该值设为 compute，控制节点中该值设为 controller，如下：

pcs property set --node computel Osprole=compute

pcs property set --node computel osprole=compute

pcs property set --node controller1 osprole=controller

pcs property set --node controller2 osprole=controller

pcs property set --node controller3 osprole=controller

然后，通过为资源设置 Location约束，便可将 Nova-compute资源仅限制在计算节点上运行，Location约束的设置命令如下：

pcs constraint location nova-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute

即资源 Nova-compute-clone仅会在 osprole等于 compute的节点上运行，也即计算节点上运行。

　　在 pacemaker集群中，order约束主要用来解决资源的启动依赖关系，资源启动依赖在Linux系统中非常普遍。例如在Openstack高可用集群配置中，需要先启动基础服务如 RabbitMQ和 MySQL等，才能启动 Openstack的核心服务，因为这些服务都需要使用消息队列和数据库服务；再如在网络服务 Neutron中，必须先启动Neutron-server服务，才能启动Neutron的其他 Agent服务，因为这些 Agent在启动时均会到 Neutron-sever中进行服务注册。 Pacemaker集群中解决资源启动依赖的方案便是 order约束。例如，在 openstack的网络服务 Neutron配置中，与 Neutron相关的资源启动顺序应该如下：Keystone-->Neutron-server-->Neutron-ovs-cleanup-->Neutron-netns-cleanup-->Neutron-openvswitch-agent-->Neutron-dncp-agent-->Neutron-l3-agent。上述依赖关系可以通过如下Order约束实现：

pcs constraint order start keystone-clone then neutron-server-api-clone

pcs constraint order start neutron-server-api-clone then neutron-ovs-cleanup-clone

pcs constraint order start neutron-ovs-cleanup-clone then Neutron-netns-cleanup-clone

pcs constraint order start Neutron-netns-cleanup-clonethen Neutron-openvswitch-agent-clone

pcs constraint order start Neutron-openvswitch-agent-clone then Neutron-dncp-agent-clone

pcs constraint order start Neutron-dncp-agent-clone then Neutron-l3-agent-clone

　　Colocation约束主要用于根据资源 A的节点位置来决定资源 B的位置，即在启动资源 B的时候，会依赖资源 A的节点位置。例如将资源 A与资源 B进行 Colocation约束，假设资源A已经运行在 node1上，则资源 B也会在node1上启动，而如果node1故障，则资源B与 A会同时切换到node2而不是其中某个资源切换到 node3。在 Openstack高可用集群配置中，通常需要将 Libvirtd-compute与 Neutron-openvswitch-agent进行资源捆绑，要将 Nova-compute与 Libvirtd-compute进行资源捆绑，则 Colocation约束的配置如下：

pcs constraint colocation add nova-compute-clone with libvirtd-compute-clone

pcs constraint colocation add libvirtd-compute-clone with neutron-openvswitch-agent-compute-clone

　　Location约束、 Order约束和 Colocation约束是 Pacemaker集群中最为重要的三个约束通过这几个资源约束设置，集群中看起来彼此独立的资源就会按照预先设置有序运行。

3、集群资源类型

　　在 Pacemaker集群中，各种功能服务通常被配置为集群资源，从而接受资源管理器的调度与控制，资源是集群管理的最小单位对象。在集群资源配置中，由于不同高可用模式的需求，资源通常被配置为不同的运行模式，例如 Active/Active模式、 Active/Passive模式以及 Master/Master模式和 Master/Slave模式，而这些不同资源模式的配置均需要使用 Pacemaker提供的高级资源类型，这些资源类型包括资源组、资源克隆和资源多状态等。

（1）资源组

　　在Pacemaker集群中，经常需要将多个资源作为一个资源组进行统一操作，例如将多个相关资源全部位于某个节点或者同时切换到另外的节点，并且要求这些资源按照一定的先后顺序启动，然后以相反的顺序停止，为了简化同时对多个资源进行配置，供了高级资源类型一资源组。通过资源组，用户便可并行配置多个资源，资源组的创建很简单，其语法格式如下：

pcs resource group add group_name resource_id  ... [resource_id] [--before resource_id] --after resource_id

　　使用该命令创建资源组时，如果指定的资源组目前不存在，则此命令会新建一个资源组，如果指定的资源组已经存在，则此命令会将指定的资源添加到该资源组中并且组中的资源会按照该命令中出现的先位置顺序启动，并以相反的顺序停止。在该命令中，还可使用--before和--after参数指定所添加的资源与组中已有资源的相对启动顺序。在为资源组添加资源时，不仅可以将已有资源添加到组中，还可以在创建资源的同时顺便将其添加到指定的资源组中，命令语法如下：

pcs resource create resource_id Standard:Provider:Type丨 type [ resource_options] [op operation_action operation_options] --group group_name

如下是资源组操作中经常使用的命令语法：

将资源从组中删除，如果该组中没有资源，这个命令会将该组删除：

pcs resource group remove group_name resource_id ...

查看目前巳经配置的资源组：

pcs resource group list

创建名为Mygroup的资源组，并添加资源 IPaddr和 HAproxy：

pcs resource group add MyGroup IPaddr HAproxy

在 Pacemaker集群中，资源组所包含的资源数目是不受限的，资源组中的资源具有如下的基本特性：

　　资源按照其指定的先后顺序启动，如在前面示例的 MyGroup资源组中，首先启动 IPaddr，然后启动 HAproxy。

　　资源按照其指定顺序的相反顺序停止，如首先停止 HAproxy，然后停止 IPaddr

　　如果资源组中的某个资源无法在任何节点启动运行，那么在该资源后指定的任何资源都将无法运行，如 IPaddr不能启动，则 HAproxy也不能启动。

　　资源组中后指定资源不影响前指定资源的运行，如 HAproxy不能运行，但IPaddr却可以正常运行。

　　在集群资源配置过程中，随着资源组成员的增加，集群资源的配置工作将会明显减少，因为管理员只需要添加资源到资源组中，然后便可对资源组进行整体操作。资源组具有组属性，并且资源组会继承组成员的部分属性，主要被继承的资源属性包括 Priority、Targct-role、Is-managed等，资源属性决定了资源在集群中的行为规范，以及资源管理器可以对其进行哪些操作，因此，了解资源的常见属性也是非常有必要的，如下是资源属性中比较重要的几个属性解释及其默认值。

　　　　Priority：资源优先级，其默认值是0，如果集群无法保证所有资源都处于运行状态，则低优先权资源会被停止，以便让高优先权资源保持运行状态。　　　　

　　　　Target-role：资源目标角色，其默认值是started'表示集群应该让这个资源处于何种状态，允许值为：

　　　　　　Stopped：表示强制资源停止；

　　　　　　Started：表示允许资源启动，但是在多状态资源的情况下不能将其提升为 Master资源；

　　　　　　Master：允许资源启动，并在适当时将其提升为 Master。

　　　　is-managed：其默认值是true，表示是否允许集群启动和停止该资源，false表示不允许。

 　　　 Resource-stickiness：默认值是0，表示该资源保留在原有位置节点的倾向程度值。

　　　　Requires：默认值为 fencing，表示资源在什么条件下允许启动。　　　　

（2）资源克隆

　　克隆资源是Pacemaker集群中的高级资源类型之一，通过资源克隆，集群管理员可以将资源克隆到多个节点上并在启动时使其并行运行在这些节点上，例如可以通过资源克隆的形式在集群中的多个节点上运行冗余IP资源实例，并在多个处于 Active状态的资源之间实现负载均衡。通常而言，凡是其资源代理支持克隆功能的资源都可以实现资源克隆，但需要注意的是，只有己经规划为可以运行在Active/Active高可用模式的资源才能在集群中配置为克隆资源。配置克隆资源很简单，通常在创建资源的过程中同时对其进行资源克隆，克隆后的资源将会在集群中的全部节点上存在，并且克隆后的资源会自动在其后添加名为 clone的后缀并形成新的资源 ID，资源创建并克隆资源的语法如下：

pcs resource create resource_id standard:provider: type| type [resource options] --clone[meta clone_options]

　　克隆后的资源 ID不再是语法中指定的 Resource_id,而是 Resource_id-clone并且该资源会在集群全部节点中存在。在 Pacemaker集群中，资源组也可以被克隆，但是资源组克隆不能由单一命令完成，必须先创建资源组然后再对资源组进行克隆，资源组克隆的命令语法如下：

pcs resource clone resource_id group_name [clone_optione] ...

克隆后资源的名称为 Resource_id-clone或 Group_name-clone在资源克隆命令中，可以指定资源克隆选项(clone_options)，如下是常用的资源克隆选项及其意义。

Priority/Target-role/ls-manage：这三个克隆资源属性是从被克隆的资源中继承而来的，具体意义可以参考上一节中的资源属性解释。　　　　

Clone-max：该选项值表示需要存在多少资源副本才能启动资源，默认为该集群中的节点数。　　　　

Clone-node-max：表示在单一节点上能够启动多少个资源副本，默认值为1。　　　　 

Notify：表示在停止或启动克隆资源副本时，是否在开始操作前和操作完成后告知其他所有资源副本，允许值为 False和 True，默认值为 False。　　　　

Globally-unique：表示是否允许每个克隆副本资源执行不同的功能，允许值为 False和 True。如果其值为 False,则不管这些克隆副本资源运行在何处，它们的行为都是完全和同的，因此每个节点中有且仅有一个克隆副本资源处于 Active状态。其值为 True,则运行在某个节点上的多个资源副本实例或者不同节点上的多个副本实例完全不一样。如果Clone-node-max取值大于1，即一个节点上运行多个资源副本，那么 Globally-unique的默认值为 True，否则为 False。

Ordered：表示是否顺序启动位于不同节点上的资源副本，“。为顺序启动，、为并行启动，默认值是 False。

Interleave：该属性值主要用于改变克隆资源或者 Masters资源之间的 ordering约束行为， Interleave可能的值为 True和 False,如果其值为 False,则位于相同节点上的后一个克隆资源的启动或者停止操作需要等待前一个克隆资源启动或者停止完成才能进行，而如果其值为 True,则后一个克隆资源不用等待前一个克隆资源启动或者停止完成便可进行启动或者停止操作。 Interleave的默认值为 False。

　　在通常情况下，克隆资源会在集群中的每个在线节点上都存在一个副本，即资源副本数目与集群节点数目相等，但是，集群管理员可以通过资源克隆选项Clone-max将资源副本数目设为小于集群节点数目，如果通过设置使得资源副本数目小于节点数目，则需要通过资源位置约束（ Location Constraint)将资源副本指定到相应的节点上，设置克隆资源的位置约束与设置常规资源的位置约束类似。例如要将克隆资源 Web-clone限制在 node1节点上运行，则命令语法如下：

pcs constraint location web-clone prefers node1

（3）资源多态

　　多状态资源是 Pacemaker集群中实现资源 Master/Master或 Master/S1ave高可用模式的机制，并且多态资源是一种特殊的克隆资源，多状态资源机制允许资源实例在同一时刻仅处于 Master状态或者Slave状态。多状态资源的创建只需在普通资源创建的过程中指定一 Master参数即可，Master/Slave多状态类型资源的创建命令语法如下：

pcs resource create resource_id standard：provider: type| type [resource options] --master [meta master_options]

　　多状态资源是一种特殊的克隆资源，默认情况下，多状态资源创建后也会在集群的全部节点中存在，多状态资源创建后在集群中的资源名称形如 Resource_id-master。需要指出的是，在 Master/Slave高可用模式下，尽管在集群中仅有一个节点上的资源会处于 Master状态，其他节点上均为 Slave状态，但是全部节点上的资源在启动之初均为 Slave状态，之后资源管理器会选择将某个节点的资源提升为 Master。另外，用户还可以将已经存在的资源或资源组创建为多状态资源，命令语法如下：

pcs resource master master/slave_name resource_id group_name [master_options]

在多状态资源的创建过程中，可以通过Master选项（ Master_options)来设置多状态资源的属性，Master_options主要有以下两种属性值：　　　　

　　Master-max：其值表示可将多少个资源副本由Slave状态提升至 Master状态，默认值为1，即仅有一个 Master。　　　　

　　Master-node-max：其值表示在同一节点中可将多少资源副本提升至Master状态，默认值为1。

　　在通常情况下，多状态资源默认会在每个在线的集群节点中分配一个资源副本，如果希望资源副本数目少于节点数目，则可通过资源的Location约束指定运行资源副本的集群节点，多状态资源的Location约束在实现的命令语法上与常规资源没有任何不同。此外，在配置多状态资源的Ordering约束时，可以指定对资源进行的操作是提升（Promote）还是降级(Demote)操作：

pcs constraint order [action] resource_id then [action] resource_id [options]

　　Promote操作即是将对应的资源（resource_id)提升为 Master状态， Demote操作即是将资源(resource_id)降级为 Slave状态，通过 ordering约束即可设定被提升或降级资源的顺序。

（4）集群资源规则

　　资源规则（Rule）使得 pacemaker集群资源具备了更强的动态调节能力，资源规则最常见的使用方式就是在集群资源运行时设置一个合理的粘性值（Resource-stickness)'以防止资源回切到资源创建之初指定的高优先级节点上，即动态改变资源粘性值以防止资源意外回切。在大规模的集群资源配置中，资源规则的另一重要作用就是通过设置节点属性，将多个具有某一相同属性值的物理节点聚合到一个逻辑组中，然后通过资源的 Location约束，利用节点组的这个共有节点属性值，将资源限制在该节点组上运行，即只允许此节点组中的节点运行该资源，在 Openstack高可用集群配置中，将会使用这种方式来限制不同的资源运行在不同的节点组上（控制节点组和计算节点组），大致的配置方式就是先为选定的节点设置某一自定义属性，以将其归纳到一个节点组，如下配置命令将计算节点和控制节点分别设置为不同的节点属性：

pcs property set --node computel osprole=compute

pcs property set --node computel osprole=compute

pcs property set --node controller1 osprole=controller

pcs property set --node controller2 osprole=controller

pcs property set --node controller3 osprole=controller

　　此处通过为节点分别设置不同的osprole属性值，将节点划分为两个集合，即计算节点组和控制节点组，将节点 compute1和 compte2归纳到 compute节点组，节点controller1、controller2以及 controller3归纳到 controller节点组，然后通过资源的 Location约束将资源限制到不同的节点组中运行，配置命令如下：

pcs constraint location nova-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute

pcs constraint location nova-api-clone rule resource-discovery=exclusive score=0 osprole eq controller

　　在上述命令中，当Rule表达式“osprole-compute" 或者"osprole=controller"成立，即Rule为True，则执行对应资源的Location约束。此处，通过资源Location 约束的“ resource-discovery-exclusive"配置，资源nova-compute-clone只能运行在compute节点组中，而 compute组中只有 compute1和compute2节点，因此nova-compute-clone只能在 compute1和 compute2上运行，绝不会在 controller1、controller2及controller3上运行。同样， nova-api-clone资源只会在controller组中的三个节点上运行。绝不会在 compute1和 compute2节点上运行。

　　在 Pacemaker集群中，每个资源的 Rule都会包含一个或多个数字、时间及日期表达式， Rule最终的取值则取决于多个表达式布尔运算的结果。布尔运算可以是管理员指定的逻辑与或者逻辑或操作，此外， Rule的效果总是以 constraint的形式体现。因此， Rule通常在 Constraint命令中配置，如下语句是配置资源 Rule的语法格式：

pcs constraint rule add constraint_id [rule_type] [score=score] (id=rule-id] expression丨date_expression丨date-spec options

　　如果忽略 score值，则使用默认值 INFINITY,如果忽略 ID,则自动从 Constraint_id生成一个规则 ID，而 Rule-type可以是字符表达式或者日期表达式。需要注意的是，在删除资源 Rule时候，如果此 Rule是 Constraint中的最后一个 Rule，则该 Constraint将被删除，删除资源 Rule语法如下：

pcs constraint rule remove rule_id

资源 Rule的表达式主要分为节点属性表达式和时间/日期表达式，节点属性表达式由以下几个部分组成。

　　　　Value：用户提供的用于同节点属性值进行比较的值。

　　　　Attribute：节点属性变量名，其值即是 value要匹配的节点属性值。

　　　　Type：确定使用哪种类型的值匹配，允许的值包括字符串、整数、版本号(Version)。

　　　　Operation：操作符，确定用户提供的1“与节点 Attribute的值如何匹配，主要包括以下几种操作符。

　　　　　　lt：如果 value 小于 Attribute的值，表达式为正 True；

　　　　　　gt：如果 value 大于 Attribute的值，表达式为正 True；

　　　　　　lte：如果value 小于等于 Attribute的值，表达式为正 True；

　　　　　　gte：如果 value 大于等于 Attribute的值，表达式为正 True；

　　　　　　eq：如果 value 等于 Attribute的值，表达式为正；

　　　　　　ne：如果 value不等于 Attribute的值，表达式为正 True；

　　　　　　defined：如果表达式中的 Attribute在节点中有定义，则表达式为 True;

　　　　　　not_defined：如果节点中没有定义表达式中的 Attribute，则表达式为True。

要通过Rule的节点属性表达式来确定资源的Location，则通常的命令语法如下：

pcs resource constraint location resource_id rule [rule_id] [role=master|slave] [score=score expression]

此处的表达式可以是以下几种形式：

　　　　defined|not_defined attribute

　　　　attribute lt|gt|Ite|gte|eq|ne value

　　　　date [start=start] [end=end] operation=gt|lt|in-range

　　　　date-spec date_spec_options

在 Openstack高可用集群配置中，使用最多的是第二种形式的表达式，例如要限制 Nova-compute服务仅运行在计算节点上，则可以通过如下 Rule和 Location配置实现：

pcs constraint location nova-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute

　　上述命令中，"osprole eq compute"即是 Rule的表达式，其中 osprole是节点的Atfribute, Compute是用户指定的节点属性值，该表达式的操作符是等于符号（该命令语句中的规则表达式的意思就是，当节点的值等于用户指定值（ compute)的时候，则 Rule表达式为 True（计算节点属性中已经预先设置了osprole属性值为compute )。