网站

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

pacemaker 支持的集群模式

Pacemaker 支持多种类型的集群，包括 Active/Active, Active/Passive, N+1, N+M, N-to-1 and N-to-N 等。

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的节点均有额外的剩余可用资源。

主要特性

1、监测并恢复节点和服务级别的故障。
2、存储无关，并不需要共享存储。
3、资源无关，任何能用脚本控制的资源都可以作为集群服务。
4、支持节点 STONITH功能以保证集群数据的完整性和防止集群脑裂。
5、支持大型或者小型集群。
6、支持 Quorum机制和资源驱动类型的集群。
7、支持几乎是任何类型的冗余配置。
8、自动同步各个节点的配置文件。
9、可以设定集群范围内的 Ordering、 Colocation and Anti-colocation等约束。
10、高级服务类型支持，例如：
Clone功能：即那些要在多个节点运行的服务可以通过Clone功能实现,Clone功能将会在多个节点上启动相同的服务；
Multi-state功能：
即那些需要运行在多状态下的服务可以通过 Multi--state实现,
在高可用集群的服务中，有很多服务会运行在不同的高可用模式下，如：Active/Active模式或者 Active/passive模式等，
并且这些服务可能会在 Active 与standby(Passive)之间切换。
11、具有统一的、脚本化的集群管理工具。

结构

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

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

但行好事，莫问前程