前文Nova创建一个虚拟机可知OpenStack有nova、neutron、cinder、keystone、ceilometer还有queue队列组件以及数据库等等，按照组件的各个功能，一般搭建OpenStack会有控制节点，网络节点和存储节点以及计算节点。控制节点部署nova-api，nova-schduler，nova-conductor，queue，数据库，keystone，cinder-api，cinder-volume，neutron-server等组件；网络节点会部署OpenvSwitch等组件，存储节点会部署cinder-volume等组件，计算节点会部署nova-compute等组件。但这些组件的如何管理?高可用如何管理?
这就需要通过集群进行管理控制，而作为拥有大量资源与节点的集群，必须具备一个强大的集群资源管理器(Cluster System Manager，CSM)来调度和管理集群资源。对于任何集群而言，集群资源管理器是整个集群能够正常运转的大脑和灵魂，任何集群资源管理器的缺失和故障都会导致集群陷入瘫痪混乱的状态。
要实现承载业务系统的高可用集群，OpenStack服务必须部署到高可用集群上，并在实现OpenStack服务无单点故障的同时，实现故障的自动转移和自我愈合，而这些功能是OpenStack的多数服务本身所不具备的。因此，在生产环境中部署OpenStack高可用集群时，必须引入第三方集群资源管理软件，专门负责OpenStack集群资源的高可用监控调度与管理。
集群资源管理软件种类众多，并有商业软件与开源软件之分。在传统业务系统的高可用架构中，商业集群管理软件的使用非常普遍，如IBM的集群系统管理器IBM System Director、PowerHA SystemMirror(也称为HACMP)以及针对DB2的PureScale数据库集群软件；再如Orcale的Solaris Cluster系列集群管理软件，以及Oracle数据库的ASM和RAC集群管理软件等商业高可用集群软件都在市场上占有很大的比例。此外，随着开源社区的发展和开源生态系统的扩大，很多商业集群软件也正在朝着开源的方向发展，如IBM开源的xCAT集群软件。而在Linux开源领域，Pacemaker、Corosync、HAProxy、Keepalived等组合集群资源管理软件也有着极为广泛的应用。
各个厂商的OpenStack高可用部署方案表明，Pacemaker、Corosync、HAProxy、Keepalived已经成为OpenStack高可用集群部署的集群资源管理器和负载均衡器的标准，而Pacemaker作为Linux集群资源高可用的管理软件，已被OpenStack官方社区指定为OpenStack集群高可用部署的集群资源管理器。
Pacemaker概述
Pacemaker是Linux环境中使用最为广泛的开源集群资源管理器，Pacemaker利用集群基础架构(Corosync或者Heartbeat)提供的消息和集群成员管理功能，实现节点和资源级别的故障检测和资源恢复，从而最大程度保证集群服务的高可用。从逻辑功能而言，Pacemaker在集群管理员所定义的资源规则驱动下，负责集群中软件服务的全生命周期管理，这种管理甚至包括整个软件系统以及软件系统彼此之间的交互。Pacemaker在实际应用中可以管理任何规模的集群，由于其具备强大的资源依赖模型，这使得集群管理员能够精确描述和表达集群资源之间的关系(包括资源的顺序和位置等关系)。同时，对于任何形式的软件资源，通过为其自定义资源启动与管理脚本（资源代理），几乎都能作为资源对象而被Pacemaker管理。此外，需要指出的是，Pacemaker仅是资源管理器，并不提供集群心跳信息，由于任何高可用集群都必须具备心跳监测机制，事实上Pacemaker的心跳机制主要基于Corosync或Heartbeat来实现。
Pacemaker的主要功能包括以下11个方面：
1) 监测并恢复节点和服务级别的故障。
2) 存储无关，并不需要共享存储。
3) 资源无关，任何能用脚本控制的资源都可以作为集群服务。
4) 支持节点STONITH功能以保证集群数据的完整性和防止集群脑裂。
5) 支持大型或者小型集群。
6) 支持Quorum机制和资源驱动类型的集群。
7) 支持几乎是任何类型的冗余配置(比如主主Active/Active、主备Active/Passive)。
8) 自动同步各个节点的配置文件。
9) 可以设定集群范围内的Ordering、Colocation and Anti-colocation等约束(Ordering约束服务在集群中的启动顺序，Colocation约束某些服务同时运行在某个节点)。
10) 高级服务类型支持，例如：
Clone功能，即那些要在多个节点运行的服务可以通过Clone功能实现，Clone功能将会在多个节点上启动相同的服务；
Multi-State功能，即那些需要运行在多状态下的服务可以通过Multi-State来实现，在高可用集群的服务中，有很多服务会运行在不同的高可用模式下，如Active/Active模式或者Active/Passive模式等，并且这些服务可能会在Active与Standby(Passive)之间切换。
11) 具有统一的、脚本化的集群管理工具。
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模式便退变为Active/Passive模式。
4) N＋M模式：在单个集群运行多种服务的情况下，N＋1模式下仅有的一个故障接管节点可能无法提供充分的冗余，因此，集群需要提供M（M＞1）个备机节点以保证集群在多个服务同时发生故障的情况下仍然具备高可用性，M的具体数目需要根据集群高可用性的要求和成本预算来权衡。
5) N-to-1模式：允许接管服务的备机节点临时成为活动节点(此时集群已经没有备机节点)，但是，当故障主节点恢复并重新加入到集群后，备机节点上的服务会转移到主节点上运行，同时该备机节点恢复Standby状态以保证集群的高可用。
6) N-to-N模式：N-to-N是Active/Active模式和N＋M模式的结合，N-to-N集群将故障节点的服务和访问请求分散到集群其余的正常节点中，在N-to-N集群中并不需要Standby节点的存在，但是需要所有Active节点均有额外的剩余可用资源。
两节点主备高可用模式(Active/Passive)是一种较为常见的部署模式。在Active/Passive模式下，只有主节点运行服务，备节点处于Standby模式，当主节点发生故障时，备节点将迅速接管故障服务并对外提供访问。在Linux环境中，使用Pacemaker和DRBD的双节点主备方案作为一种高效、经济的开源解决方案在很多企业高可用环境中被采用，当Active节点故障后，共享存储锁将被释放，与此同时Standby节点将挂载共享存储，之后与故障节点相同的服务将在Passive节点重新启动并对外提供服务。
在Active/Passive模式中，如果需要配置多个独立Cluster，而每个Cluster又都配置一个Standby节点，则势必对物理资源造成极大浪费，因为Standby节点在多数时间均处于空闲状态。而在Pacemaker集群中，实现了多集群共享Standby节点，即多个Cluster同时使用一个Standby节点，从而使得Standby节点发挥了最大利用价值并最终减少硬件资源浪费。
如果使用分布式共享存储，则Pacemaker也支持Active/Active模式，即相同的服务同时运行在集群中的多个节点上，并且每个节点都可以接管故障节点的服务(N-to-N模式)，在这种模式下，Pacemaker在多个节点上同时运行服务副本从而实现对外服务请求的负载均衡
Pacemaker集群架构
从高层次的集群抽象功能来看，Pacemaker核心架构主要由集群底层基础模块、集群资源管理组件和集群无关组件3个部分组成。
1) 集群底层基础模块主要向集群提供可靠的消息通信、集群成员关系和Quorum等功能，底层基础模块主要包括像Corosync、CMAN和Heartbeat等项目组件。
2) 集群资源管理组件专门负责响应和处理与集群相关的事件，这些事件主要包括集群节点的加入、集群节点脱离，以及由资源故障、维护、计划的资源相关操作所引起的资源事件，同时还包括其他的一些管理员操作事件，如对配置文件的修改和服务重启等操作。在对所有这些事件的响应过程中，Pacemaker会计算出当前集群应该实现的最佳理想状态，并规划出实现该理想状态后续需要进行的各种集群操作，这些操作可能包括了资源移动、节点停止，甚至包括使用远程电源管理模块来强制节点下线等
3) 集群无关组件主要包括资源本身以及用于启动、关闭以及监控资源状态的脚本，同时还包括用于屏蔽和消除实现这些脚本所采用的不同标准之间差异的本地进程。虽然在运行多个实例时，资源彼此之间的交互就像一个分布式的集群系统，但是，这些实例服务之间仍然缺乏恰当的HA机制和独立于资源的集群治理能力，因此需要集群组件的功能支持。
1) 新的Heartbeat只负责维护集群各节点的信息以及它们之间的心跳通信，通常将Pacemaker与Heartbeat或者Corosync共同组成集群管理软件，Pacemaker利用Heartbeat或者Corosync提供的节点及节点之间的心跳信息来判断节点状态。
2) Cluster Glue相当于一个中间层，它用来将Heartbeat和Pacemaker关联起来，主要包含两个部分，即本地资源管理器（Local Resource Manager，LRM）和Fencing设备(Shoot The Other Node In The Head，STONITH，对服务进行隔离Fencing操作)。
3) 资源代理(Resource Agent，RA)是用来控制服务启停、监控服务状态的脚本集合，这些脚本会被位于本节点上的LRM调用从而实现各种资源的启动、停止、监控等操作。
4) Pacemaker是整个高可用集群的控制中心，用来管理整个集群的资源状态行为，客户端通过Pacemaker来配置、管理、监控整个集群的运行状态。
Pacemaker内部组件
Pacemaker作为一个独立的集群资源管理器项目，其内部组件彼此之间相互通信协作并最终实现了集群的资源管理，Pacemaker项目由5个内部组件构成，各个组件之间的关系如图所示。
1) CIB：集群信息基础(Cluster Information Base)。
2) CRMd：集群资源管理进程(Cluster Resource Manager deamon)。
3) LRMd：本地资源管理进程(Local Resource Manager deamon)。
4) PEngine(PE)：策略引擎(PolicyEngine)。
5) 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集群配置信息管理
Pacemaker集群是通过CIB以XML的形式进行定义的，而CIB主要由集群配置信息与集群状态信息两大部分构成。在Pacemaker集群中，未进行任何配置（初始集群）的集群拥有最简单的CIB，初始集群的CIB信息如下
<cib crm_feature_set="3.0.7" validate-with="pacemaker-1.2" admin_epoch="1" epoch="0"
num_updates="0">
<configuration>
<crm_config/>
<nodes/>
<resources/>
<constraints/>
</configuration>
<status/>
</cib>
上述初始集群的CIB输出信息中包含了构成CIB的主要模块，其中开始和末尾的cib标记表明中间内容为集群的CIB信息，而CIB中的主要内容又分为配置段（configuration标记）和状态段（status标记），同时配置段又分为crm_config、nodes、resources、constraints四个部分。CIB中的配置段主要包含当前集群的配置信息，是CIB中最为核心的信息，该配置段的信息直接决定了当前集群的资源配置以及集群所能提供的服务，并决定了这些服务彼此之间的联系，以及服务与节点之间的约束和限制。而CIB中的状态信息段主要包含有集群当前的资源运行状态信息，状态信息直接反应了当前集群的运行情况，通常而言，CIB中的集群状态信息主要取决于集群配置信息。
1) 集群状态信息包含了集群中每个节点所运行资源的历史信息，根据这些资源的历史数据，集群PE将会规划出集群下一阶段应该实现的最理想状态。集群状态信息源自每个节点上的本地资源管理器进程(LRMd)，集群运行状态信息会在运行时动态刷新，因此集群不会将状态信息永久性写入磁盘进行保存(这对集群而言并无意义)，同时也不建议管理员手动更改集群状态信息，因为集群状态信息的变更应该由集群资源管理器自动刷新。
在Pacemaker集群中，查看集群状态信息的工具是CRM_MON，CRM_MON是一个用于显示活动Pacemaker集群当前状态信息的命令行工具，利用此工具可以通过不同的模式来显示集群的各种状态信息。用户可以在限定节点或资源的前提下运行CRM_MON命令行工具。CRM_MON的输出信息即包含以节点和资源为组执行的操作列表，也包含资源运行失败的相关信息。使用CRM_MON工具，用户可以检测到集群中的非法操作所引起的集群状态变化，同时还可以通过CRM_MON工具进行集群故障仿真等验证性的操作。
在CRM_MON命令中，通过不同的mode参数和options参数组合，用户可以将Pacemaker集群当前状态信息以不同的形式输出并进行查看，例如通过-f参数可以查看资源运行失败的信息，通过-h参数可以将结果以HTML的形式输出到指定的文件中，通过-i参数可以指定输出结果自动刷新的时间间隔，通过-l参数可以将结果定向到标准输出并退出，通过-o参数可以查看资源的操作历史等。
[root@controller1-vm ~]# crm_mon -f -1
Last updated: Fri Apr 15 16:49:402016 Last change: Sun Apr 10 21:37:31
2016 by haCluster via crmd on controller3-vm
Stack: corosync
Current DC: controller3-vm (version 1.1.13-a14efad)- partition with quorum
5 nodes and 231 resources configured
Online: [ controller1-vm controller2-vm controller3-vm ]
RemoteOnline: [ computer1 computer2 ]
fence1 (stonith:fence_xvm):Started controller3-vm
fence2 (stonith:fence_xvm):Started controller3-vm
fence3 (stonith:fence_xvm):Started controller3-vm
Clone Set: lb-HAproxy-clone [lb-HAproxy]
Started: [ controller1-vm controller2-vm controller3-vm ]
vip-db (ocf::heartbeat:IPaddr2): Started controller1-vm
vip-RabbitMQ(ocf::heartbeat: IPaddr2):Started controller1-vm
vip-keystone (ocf::heartbeat:IPaddr2): Started controller2-vm
从CRM_MON输出的OpenStack高可用集群的当前状态信息中，可以看到集群最近一次状态信息更新的时间和最近一次集群配置变更的时间，还可以看到当前集群的Stack是Corosync（也可以选择Heatbeat），同时能看到当前集群的DC是controller3-vm节点。在该集群中，一共配置了5个节点（三个本地控制节点和两个远端计算节点）和231个资源（以节点为单位进行资源统计）。
2) 集群配置信息是Pacemaker集群中CIB信息的关键组成部分，Pacemaker的集群配置信息决定了集群最终应该如何工作以及集群最终的运行状态，因为只有一个正确的集群配置才能驱动集群资源运行在正常的状态。通常情况下，集群的配置信息由集群配置选项(crm_config)、集群节点(nodes)、集群资源(resources)和资源约束(constraints)四个配置段组成，通过cibadmin --query可查。
1）crm_config配置段的内容在CIB中是以<crm_config>标记起始并以<crm_config>标记结尾的配置段。
cibadmin --query --scope crm_config
2) nodes配置段定义了集群的全部节点的ID和节点名称，以及节点在集群中的属性等信息，节点配置段在CIB中以<nodes>标记起始并以<nodes >标记结尾。
cibadmin --query --scope nodes
3) 在Resources配置段中，每个资源都会通过Class、Type、Provider等属性对其进行定义，并且每个资源位于一个资源定义段内。资源配置段在CIB中以<resources>标记起始并以<resources>标记结尾。
cibadmin --query --scope resources
4) Pacemaker集群中各种资源之间的启动顺序及依赖关系等约束都被定义在Constraints配置段中，在由众多资源组成的集群中，资源之间的启动依赖关系以及资源彼此之间的粘性设置都称为资源约束，这些约束被统一定义到Constraints配置段中，CIB中的Constraints配置段以<constraints>标记起始并以< constraints >标记结尾。
cibadmin --query --scope constraints
在Pacemaker集群中，cibadmin命令行工具是更改和查询集群资源配置信息最为强大的工具。cibadmin命令行工具能够与运行中的Pacemaker集群进行实时交互，通过cibadmin，集群管理员可以实时执行集群配置信息的查看、删除、更新或者替换配置信息中的任何部分等操作，并且，使用cibadmin命令所做的更改会对当前集群立即生效，而无需使用reload或restart之类的命令重新加载集群配置。
更改配置信息最常用的方式是利用cibadmin将当前集群配置信息保存到一个临时文件中，然后使用自己喜欢的XML编辑器对保存配置信息的临时文件进行修改，在确认修改完成之后，再使用cibadmin命令将修改后的XML配置文件替换掉集群的当前配置，而且这种配置信息的替换将会立即生效。
//将当前集群配置信息保存到tmp.xml文件中 cibadmin --query > tmp.xml
//使用编辑器对XML文件进行修改 vim tmp.xml
//将修改后的XML文件替换掉当前集群的配置信息 cibadmin --replace --xml-file tmp.xml
笔记整理来自山金孝的《OpenStack高可用集群（上册）：原理与架构》3.1到3.5章节，如有侵权请通知删除
