企业—pacemaker基本概念及其原理

一.现代互联网的集群简介

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

• 
  集群资源管理软件种类众多，并有商业软件与开源软件之分，在传统业务系统的高可用架构中，商业集群管理软件的使用非常普遍，如IBM的集群系统管理器，oracle 的Solaris Cluster系列的集群管理软件等。此外随着开源社区的发展和开源生态系统的扩大，很多商业集群软件也正朝着开源的方向发展，如IBM开源的xCAT集群软件，而在linux开源领域，pacemaker/Corosync,HAProxy/Keepalived等组合集群资源管理软件也有者及为广泛的应用。

二.pacemaker概述

1.pacemaker介绍

• pacemaker（直译：心脏起搏器）是Linux环境中使用最为广泛的开源集群资源管理器，pacemaker利用基础集群架构（Corosync或者Heartbeat）提供地消息和集群成员管理功能，实现节点和资源级别的故障检测和资源恢复，从最大程度上保证集群服务的高可用。
• Pacemaker是整个高可用集群的控制中心，用来管理这个集群的资源状态形为，客户端通过pacemaker来配置，管理，监控真个集群的运行状态。Pacemaker是一个功能非常强大的并且支持众多操作系统的开源集群资源管理器，Pacemaker支持主流的Linux系统，如Redhat的RHEL系列，Fedora系列，openSUSE系列，Debain系列，Ubuntu系列。

2.pacemaker的主要功能

• 监测并恢复节点和服务级别的故障​
• 存储无关，并不需要共享存储​
• 资源无关，任何能用脚本控制的资源都可以作为服务来管理
• 支持使用STONITH来保证数据一致性
• 支持大型或者小型的集群​
• 支持quorate(法定人数) 或 resource(资源) 驱动的集群​
• 支持几乎所有的冗余配置，包括Active/Active, Active/Passive, N+1, N+M, N-to-1 and N-to-N
• 自动同步各个节点的配置文件​
• 可以设定集群范围内的ordering, colocation , anti-colocation约束
• 支持更多高级服务类型:支持需要在多个节点运行的服务​,支持需要多种模式的服务。(比如 主/从,主/备)
• 统一的，脚本化的，cluster shell

（1）Heartbeat

Heartbeat项目最初的消息通信层被独立为新的Heartbeat项目，新的heartbeat只负责集群各节点的信息以及它们之间的心跳通信，通常将heartbeat和corosync与pacemaker共同组成集群管理软件。pacemaker通过heartbeat或者corosync提供的节点及其节点之间的心跳信息来判断节点状态。

(2)Cluster Clue

Cluster Clue相当于一个中间层，它用来将heartbeat和pacemaker关联起来，主要包含俩个部分，即本地资源管理器（Local Recource Manager，LRM）和Fence设备。

（3）Resource Agent

资源代理是用来控制服务的启停，监控服务状态的脚本集合，这些恶脚本会被位与本节点上的LRM调用从而实现资源的启动，停止，监控等操作。

三.pacemaker的架构

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

• 1.底层基础模块
  底层基础架构模块主要向集群提供可靠的消息通信，集群成员关系等功能，底层基础模块主要包括corosync，CMAN和heartbeat等项目组件。
• 2.集群无关组件
  在pacemaker架构中，这些部分组件主要包括资源本身以及用于启动，关闭以及监控资源状态的脚本，同时还包括用于屏蔽和消除实现这些脚本所采用的不同标准之间的差异的本地进程。虽然在运行多个实例时，资源之间的彼此交互就像一个分布的集群系统，但是这些示例服务之间仍然缺乏恰当的HA机制和独立于资源的集群治理能力，因此还需要后续集群组件的功能的支持。
• 3.资源管理
• pacemaker专门负责和响应处理与集群相关的事件，这些事件主要包括集群节点的添加，集群节点的脱离，以及由资源故障，维护，计划的资源相关操作所引起的资源事件，同时还包括一些管理员操作事件。pacemaker会计算出当前集群应该实现的最佳状态并规划出实现该理想状态后续要进行的各种集群操作。
• pacemaker与Corosync集成时，paceamker也支持常见的主流开源集群文件系统，而根据文件系统社区过去一直从事的标准化工作，社区使用了一种通用的分布式锁管理器来实现集群文件系统的并行读写访问，这种分布式锁控制器利用了Corosync所提供的集群消息和集群成员节点处理能力来实现文件系统的集群，同时使用pacemaker对服务进行隔离。

四.Pacemaker的内部组件

Pacemaker作为一个独立的集群资源管理器项目，其本身由多个内部组件构成，这些内部组件之间彼此相互通信协作并最终实现了集群资源管理，Pacemaker项目由5个内部组件构成，各个组件的关系如下图：

• crmd(Cluster Resource Management daemon 集群资源管理守护进程):主要作为pengine和lrm的消息代理，它同时也得选举一个leader去协调管理集群的活动（包括集群资源的停止和启动）
• lrmd(local resource manager demaon):本地资源管理守护进程（非集群感知守护进程），提供一个统一的接口去支持不同的资源类型，直接与Resource agents（脚本）交互.
• pengine(PE or Policy EnginePE 或者策略引擎):主要负责将CRM发过来的一些信息按照配置文件中的各种设置（基于目前的状态和配置）计算集群的下一个状态。产生一个包括一系列行动和依赖关系的过渡图
• stonithd(Shoot-The-Other-Node-In-The-Head ):通常用远程电源开关来充当。在 Pacemaker 中,STONITH设备被当成资源(并且是在CIB中配置)从而轻松地监控，然而Stonithd会注意理解STONITH拓扑，比如它的客户端请求隔离一个节点，它会重启那个机器。
• cib(Cluster Information Base 集群信息基础):CIB在系统中充当的是当前集群中各资源原始配置以及之后动态变化了的状态，统计信息收集分发中心，是一个不断更新的信息库（包含所有群集选项，节点，资源以及他们的相互关系和当前状态的定义）。当他收集到任何资源的变化，以及节点统计信息的变化后，都会集成整合到一起组成当前集群最新的信息，并分发到集群各个节点。

五.pacemaker的服务模式

由Pacemaker的特性我们知道Pacemaker对环境的要求不高，支持几乎所有的冗余配置，包括Active/Active, Active/Passive ，N+1, N+M, N-to-1 and N-to-N

1. Active/Active模式
   在这种模式下，故障节点请求会自动的转移到另外一个正常的结点上或通过负载均衡器在剩余的正常的节点上进行负载均衡，这种模式下集群中的节点通常部署了相同的软件并具有相同的参数配置，同时各服务在这些节点上并行运行。

2. Active/Passive模式
   在这种模式下每个节点上都部署有相同的服务示例，但是正常情况下只有一个节点的服务示例处于激活状态，只有当前的活动节点发生故障后，另外的处于standby状态的节点上的服务才会被激活
   

3. N+1模式
   N+1模式就是多准备一个额外的备机节点，当集群中某一节点故障后该备机节点会被激活从而接管故障节点的服务。在不同节点安装和配置有不同软件的集群中，即集群中运行多个服务的情况下，该备机节点具备接管任何故障服务的能力，而如果整个集群中只运行一个服务，则N+1模式退变为Active/Passive模式。
   

4. N+M模式
   在单个集群运行多种服务的情况下，N+1模式下仅有一个故障接管节点可能无法提供充分的冗余，因此集群需要提供M个备机节点以保证集群在多个服务同时发生故障的情况下仍然具备高可用性。

5. N-to-1模式
   在该模式下，允许接管的服务的备机节点临时成为活动节点（此时集群中已经没有备机节点），但是当故障主节点恢复并重新加入到集群后，备机节点上的服务会转移到主节点上运行，同时该备机节点恢复standby状态以保证集群的高可用性。

6. N-to-N模式
   该模式是Active/Active模式和N+M模式的结合，该模式集群将故障节点的服务和访问请求分散到集群其余的正常节点中，在该模式下的集群中并不需要有standby节点的存在，但是需要所有的Active节点均有额外的剩余可用资源。