Pacemaker-学习总结（概念、结构）

网站

社区网站首页：https://clusterlabs.org/
Pacemaker文档：https://clusterlabs.org/pacemaker/doc/
Corosync：https://corosync.github.io/corosync/
红帽官网：https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/ch-overview-haar

Pacemaker

由来

• 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。
  • Heartbeat：Heartbeat项目最初的消息通信层被独立为新的 Heartbeat项目，新的 Heartbeat只负责维护集群各节点的信息以及它们之间的心跳通信，通常将 Pacemaker与 Heartbeat或者 Corosync共同组成集群管理软件， Pacemaker利用 Heartbeat或者Corosync提供的节点及节点之间的心跳信息来判断节点状态。
  • Cluster Glue：Cluster Glue 相当于一个中间层，它用来将Heartbeat和Pacemaker关联起来，主要包含两个部分，即本地资源管理器（Local Resource Manager，LRM）和Fencing设备（Shoot The Other Node In The Head，STONITH）
  • Resource Agent：资源代理（Resource Agent，RA）是用来控制服务的启停，监控服务状态的脚本集合，这些脚本会被位于本节点上的LRM调用从而实现各种资源的启动、停止、监控等操作。
  • Pacemaker：Pacemaker是整个高可用集群的控制中心，用来管理整个集群的资源状态行为，客户端通过 pacemaker来配置、管理、监控整个集群的运行状态。Pacemaker是一个功能非常强大并支持众多操作系统的开源集群资源管理器，Pacemaker支持主流的 Linux系统，如 Redhat的 RHEL系列、 Fedora系列、 openSUSE系列、Debian系列、 Ubuntu系列和 centos系列，这些操作系统上都可以运行 Pacemaker并将其作为集群资源管理器。

概念

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

主要功能

• 监测并恢复节点和服务级别的故障​
• 通过隔离故障节点来确保数据完整性的能力
• 每个集群支持一个或多个节点
• 支持多种资源接口标准（任何可以编写脚本的都可以集群）
• 支持（但不要求）共享存储
• 支持几乎任何冗余配置（主动/被动，N + 1等多种服务模式）
• 可从任何节点更新的自动复制的配置
• 能够设置集群内服务之间的的关系，例如顺序约束，位置约束和共置约束
• 支持高级服务类型，例如克隆（需要在多个节点上处于活动状态的服务），有状态资源（可以以两种模式之一运行的克隆）和容器化服务
• 统一的，可编写脚本的集群管理工具

服务模式

• Pacemaker对用户的环境没有特定的要求，这使得它支持任何类型的高可用节点冗余配置，包括 Active/Active、 Active/Passive、N+1、 N+M、 N-to-1 and N-to-N模式的高可用集群，用户可以根据自身对业务的高可用级别要求和成本预算，通过 Pacemaker部署适合自己的高可用集群。

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

• Active/Passive模式
  在这种模式下，每个节点上都部署有相同的服务实例，但是正常情况下只有一个节点上的服务实例处于激活状态，只有当前活动节点发生故障后，另外的处于 standby状态的节点上的服务才会被激活，这种模式通常意味着需要部署额外的且正常情况下不承载负载的硬件。

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

• N+M模式
  在单个集群运行多种服务的情况下，N+1模式下仅有的一个故障接管节点可能无法提供充分的冗余，因此，集群需要提供 M（M>l）个备机节点以保证集群在多个服务同时发生故障的情况下仍然具备高可用性， M的具体数目需要根据集群高可用性的要求和成本预算来权衡。

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

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

结构

HA集群堆栈

在较高的层次上，可以将集群视为具有以下部分（通常一起称为集群堆栈）：

• 资源：这就是集群得以存在的原因-需要保持高可用性的服务。
• 资源代理：这些是在给定一组资源参数的情况下启动，停止和监视资源的脚本或操作系统组件。这些提供了Pacemaker和托管服务之间的统一接口。
• fence代理：此组件提供一些管理控制设备fence的脚本。
• 群集成员资格层：此组件提供有关群集的可靠消息传递，成员资格和仲裁信息。当前，Pacemaker支持Corosync作为此层。
• 集群资源管理器：Pacemaker提供处理和响应集群中发生的事件的大脑。这些事件可能包括节点加入或离开群集。由故障，维护或计划的活动引起的资源事件；和其他行政行为。为了获得所需的可用性，Pacemaker可以启动和停止资源以及围栅节点。
• 群集工具：这些为用户提供了与群集进行交互的界面。提供了各种命令行和图形（GUI）界面

Pacemaker组件

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

• CIB：集群信息基础（ Cluster Information Base)
• CRMd：集群资源管理进程（ Cluster Resource Manager deamon)
  运行有CRMd的Master节点服务器称为DC（ Designated controller，控制器节点）
• LRMd：本地资源管理进程(Local Resource Manager deamon）
• PEngine(PE)：策略引擎(PolicyEngine)
• STONITHd：集群 Fencing进程（ Shoot The Other Node In The Head deamon)
• ATTRd #管理集群资源属性

组件之间运作模式：

• CIB主要负责集群最基本的信息配置与管理，Pacemaker中的 CIB主要使用 XML的格式来显示集群的配置信息和集群所有资源的当前状态信息。CIB所管理的配置信息会自动在集群节点之间进行同步， PE将会使用 CIB所提供的集群信息来规划集群的最佳运行状态。并根据当前 CIB信息规划出集群应该如何控制和操作资源才能实现这个最佳状态，在 PE做出决策之后，会紧接着发出资源操作指令，而 PE发出的指令列表最终会被转交给集群最初选定的DC上（运行有CRMd的Master节点服务器称为DC，Designated controller，控制器节点）。

• 在集群启动之初， 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运行组件进程

 1362 ? Ssl 0:35 corosync							#corosync进程
 1379 ? Ss 0:00 /usr/sbin/pacemaker