Pacemaker技术总结

Openstack&Pacemaker

Pacemaker内部结构

Corosync/totem协议

Pacemaker主要特性

资源代理标准

资源约束

高级资源类型

服务异常监控

虚拟IP功能

负载均衡功能

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

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

在多个节点组成的集群中，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用于重传消息给某节点。

参考： /red_hat_enterprise_linux/7/html-single/high_availability_add-on_reference/index#s1-configfileoverview-HAAR