Pacemaker技术总结

2021-06-01 本文已影响0人 doverxu

Pacemaker总结

Openstack&Pacemaker

Openstack的众多组件服务既可以集成到单个节点上运行，也可以在集群中分布式运行。但是，要实现承载业务系统的高可用集群， Openstack服务必须部署到高可用集群上，并在实现 Openstack服务无单点故障的同时，实现故障的自动转移和自我愈合，而这些功能是Openstack的多数服务本身所不具备的。因此，在生产环境中部署 OpenStack高可用集群时，必须引人第三方集群资源管理软件，专门负责 Openstack集群资源的高可用监控调度与管理。

Pacemaker是 Linux环境中使用最为广泛的开源集群资源管理器，Pacemaker利用集群基础架构(如Corosync)提供的消息和集群成员管理功能，实现节点和资源级别的故障检测和资源恢复，从而最大程度保证集群服务的高可用。从逻辑功能而言，pacemaker在集群管理员所定义的资源规则驱动下，负责集群中软件服务的全生命周期管理。Pacemaker在实际应用中可以管理几乎任何规模的集群，由于其具备强大的资源依赖模型，这使得集群管理员能够精确描述和表达集群资源之间的关系（包括资源的顺序和位置等关系）。同时，对于任何形式的软件资源，通过为其自定义资源启动与管理脚本（资源代理），几乎都能作为资源对象而被Pacemaker管理。此外，需要指出的是，Pacemaker仅是资源管理器，并不提供集群心跳信息，Pacemaker的心跳机制主要基于Corosync（或Heartbeat）来实现。

Pacemaker内部结构

图片1.png

corosync主要提供底层各主机消息状态，集群状态信息。
pacemaker主要对托管在其上的服务进行管理，pacemaker也可以通过调用corosync的接口来管理底层的主机，比如让某一台主机下线上线等等操作。
(1) CIB：集群信息基础（ Cluster Information Base)。
主要负责集群最基本的信息配置与管理，Pacemaker中的CIB主要使用XML的格式来显示集群的配置信息和集群所有资源的状态信息。CIB所管理的配置信息会自动在集群节点之间进行同步
(2) LRMd：本地资源管理进程(Local Resource Manager deamon)。
LRM的主要作用是对本地的资源做各种管理；它通常不会自己去管理本地资源，而是通过委派RA去管理，所谓RA（resource agent）就是资源代理。
(3) 资源代理（Resource Agent，RA）
用来控制服务的启停，监控服务状态的脚本集合，这些脚本会被位于本节点上的LRM调用从而实现各种资源的启动、停止、监控等操作。
(4) PEngine(PE)：策略引擎(PolicyEngine)。
PE将会使用CIB所提供的集群信息来规划集群的最佳运行状态。并根据当前CIB信息规划出集群应该如何控制和操作资源才能实现这个最佳状态。在PE做出决策之后，会紧接着发出资源操作指令，而PE发出的指令列表最终会被转交给集群最初选定的控制器节点（Designated controller，DC)。
(5) CRMd：集群资源管理进程（ Cluster Resource Manager deamon)。
在集群启动之初，pacemaker便会选择某个节点上的CRM进程实例来作为集群Master CRM进程，然后集群中的CRM进程便会集中处理PE决策出的全部指令集。在这个过程中，如果作为Master的CRM进程出现故障或拥有 Master CRM进程的节点出现故障，则集群会马上在其他节点上重新选择一个新的Master CRM进程。
DC处理指令的过程就是把指令发送给本地节点上的LRMd或者通过集群消息层将指令发送给其他节点上的 CRMd进程，然后这些节点上的CRMd再将指令转发给当前节点的LRMd去处理。当集群节点运行完指令后，运行有CRMd进程的其他节点会把他们接收到的全部指令执行结果以及日志返回给DC（即DC最终会收集全部资源在运行节点执行后的结果和状态），然后根据执行结果与预期的对比，从而决定下一步动作（例如：当前节点是应该等待之前发起的操作执行完成再进行下一步的操作，还是直接取消当前执行的操作并要求PE根据实际执行结果再重新规划集群的理想状态并发出操作指令）。
(6) STONITHd：集群 Fencing进程（ Shoot The Other Node In The Head deamon)。
在某些情况下，集群可能会要求节点关闭电源以保证共享数据和资源恢复的完整性，为此，Pacemaker引人了节点隔离机制，而隔离机制主要通过STONITH进程实现。

Corosync/totem协议

图片2.png

在多个节点组成的集群中，totem实现让一个节点发送消息，其它所有节点都能全部收到，并且有序的提交给上层应用。
totem的节点有四个状态，也是组建集群的4个阶段。
Gather 阶段：
这个阶段用于每个节点向外界广播自己的存在并收集其它节点的存在
Commit 阶段：
这个阶段会产生一个代表节点，该节点向其它所有节点收集信息，并将收集的信息传递给其它所有节点，用于后续阶段
Recovery 阶段：
这个阶段用于新旧集群交替时，旧集群成员用新集群传递旧集群的消息，使旧集群成员达到所有节点消息全部有序提交到上层
Operational阶段：
这个阶段是集群组建完成正常工作的状态，这个状态一个节点发送的消息其它节点都会全部有序提交给上层

协议在工作状态是这样的，token在每个节点循环，节点拿到token之后才能发送消息，节点在拿到token后做这么些事：
(1) 取消token重传定时器
(2) 查看令牌rtr是否有消息记录，如果本节点有那些消息则广播这些消息，并从rtr上删除这些消息
(3) 对比my_aru和令牌的seq，查看是否有消息本节点没有收到，如果有则设置令牌上的aru和rtr以及aru_id
(4) 如果new_message_queue有消息，则广播消息，并修改令牌中的seq
(5) 如果两次token中的aru的值都大于某个值m，则向上提交序号大于m的消息
(6) 发送令牌给下一个节点
(7) 启动token重传定时器，再次收到token或者regular message的时候取消

token有重传机制，用于防止消息丢失和发现网络问题重组集群，本地变量my_aru和token里的aru和seq用于确认所有节点都收到消息，aru_id和rtr用于重传消息给某节点。

参考：https://blog.csdn.net/zancijun1666/article/details/83512038

Pacemaker主要特性

监测并恢复节点和服务级别的故障
存储无关，并不需要共享存储
资源无关，任何能用脚本控制的资源都可以作为集群服务
支持节点STONITH功能以保证集群数据的完整性和防止集群脑裂
支持各种规模的集群
支持Quorum机制
支持几乎任何类型的冗余配置
自动同步各个节点集群配置信息
可以设定集群范围内的Ordering、Location和Colocation等约束
具有统一的的集群管理工具pcs

资源代理标准

LSB(Linux standard Base)

Redhat RHEL6及其以下版本的服务类型

Systemd

Redhat RHEL7版本的服务类型

OCF(open Cluster Framework)

OCF是开放式集群框架的简称，从本质上来看， OCF标准其实是对 LSB标准约定中init脚本的一种延伸和扩展。 OCF标准支持参数传递、自我功能描述以及可扩展性

资源约束

位置约束(Location)

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

顺序约束(Order)

顺序约束限定了资源之间的启动顺序

捆绑约束(Colocation)

捆绑约束将不同的资源捆绑在一起作为一个逻辑整体，即资源 A位于C节点，则资源B也必须位于C节点

高级资源类型

资源组

资源克隆

多状态资源

监控资源的事件通知

参考：https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-eventnotification-haar

Pacemaker 集群是一个事件驱动系统，其中事件可以是资源失败，或配置更改。ocf:pacemaker:ClusterMon 资源可监控集群状态，并触发每个集群事件警报。这个资源以常规间隔在后端运行 crm_mon，它还可以使用 extra_options 参数执行外部程序。

图片3.png

pacemaker_remote服务

参考：https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html/Pacemaker_Remote/index.html

Pacemaker通过运行在远程节点上的pacemaker_remote服务来管理远程节点上的各种服务。
Pacemaker监控到每个远程节点上的pacemaker_remote的连接，来检查该节点是否处于活动状态。发现它不可以连接的话，启动恢复（recovery）过程。
远程节点限制：
(1) 不能成为DC节点
(2) 不能发起fence动作
(3) 不能参与投票

服务异常监控

为保证资源正常工作，可在资源定义中添加监控操作。如果没有为资源指定监控操作，默认情况下pcs会创建一个以60秒为间隔的监控操作。所有节点上的LRM进程周期执行状态检查脚本，实现对资源状态的检测，LRM将结果上报本地CRM进程，本地CRM进程再上报master CRM进程，由pengine策略引擎计算监控结果的响应动作，并最终由master CRM按相反路径将动作发送至具体资源，执行对应动作（redis服务支持的动作包括如下图的操作）。