玩转企业集群运维管理系列（十七）：高可用集群架构 corosync+pacemaker

在传统Linux集群种类，主要分了三类:

• 一类是LB集群，这类集群主要作用是对用户的流量做负载均衡，让其后端每个server都能均衡的处理一部分请求。
• 其次就是HA集群，这类集群的主要作用是对集群中的单点做高可用，所谓高可用就是在发生故障时，能够及时的将故障转移，从而使故障修复时间最小。
• 最后就是HP集群，HP集群主要用于在复杂计算中场景中，把多台server的算力综合一起，对复杂计算要求比较高的环境中使用；在生产环境中常见的LB和HA集群较多。

Pacemaker 介绍

Pacemaker 是 Linux环境中使用最为广泛的开源集群资源管理器，Pacemaker利用集群基础架构(Corosync 或者 Heartbeat)提供的消息和集群成员管理功能，实现节点和资源级别的故障检测和资源恢复，从而最大程度保证集群服务的高可用。

从逻辑功能而言，pacemaker在集群管理员所定义的资源规则驱动下，负责集群中软件服务的全生命周期管理，这种管理甚至包括整个软件系统以及软件系统彼此之间的交互。

Pacemaker在实际应用中可以管理任何规模的集群，由于其具备强大的资源依赖模型，这使得集群管理员能够精确描述和表达集群资源之间的关系（包括资源的顺序和位置等关系）。同时，对于任何形式的软件资源，通过为其自定义资源启动与管理脚本（资源代理），几乎都能作为资源对象而被 Pacemaker管理。

此外，需要指出的是，Pacemaker仅是资源管理器，并不提供集群心跳信息，由于任何高可用集群都必须具备心跳监测机制，因而很多初学者总会误以为 Pacemaker 本身具有心跳检测功能，而事实上 Pacemaker 的心跳机制主要基于 Corosync或 Heartbeat来实现。

Pacemaker是整个高可用集群的控制中心，用来管理整个集群的资源状态行为，客户端通过 pacemaker来配置、管理、监控整个集群的运行状态。Pacemaker是一个功能非常强大并支持众多操作系统的开源集群资源管理器，Pacemaker支持主流的 Linux系统，如 Redhat的 RHEL系列、 Fedora系列、 openSUSE系列、Debian系列、 Ubuntu系列和 centos系列，这些操作系统上都可以运行 Pacemaker并将其作为集群资源管理器。更多关于企业集群运维管理系列的学习文章，请参阅：玩转企业集群运维管理专栏，本系列持续更新中。

Pacemaker的主要功能

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

Pacemaker 内部结构

组件说明

• stonithd：心跳系统。
• lrmd：本地资源管理守护进程。它提供了一个通用的接口支持的资源类型。直接调用资源代理（脚本）。
• pengine：政策引擎。根据当前状态和配置集群计算的下一个状态。产生一个过渡图，包含行动和依赖关系的列表。
• CIB：群集信息库。包含所有群集选项，节点，资源，他们彼此之间的关系和现状的定义。同步更新到所有群集节点。
• CRMD：集群资源管理守护进程。主要是消息代理的PEngine和LRM，还选举一个领导者（DC）统筹活动（包括启动/停止资源）的集群。
• OpenAIS：OpenAIS的消息和成员层。
• Heartbeat：心跳消息层，OpenAIS的一种替代。
• CCM：共识群集成员，心跳成员层。

corosync 简介

Corosync是OpenAIS发展到Wilson版本后衍生出来的开放性集群引擎工程，corosync最初只是用来演示OpenAIS集群框架接口规范的一个应用，可以说corosync是OpenAIS的一部分，但后面的发展明显超越了官方最初的设想，越来越多的厂商尝试使用corosync作为集群解决方案。如Redhat的RHCS集群套件就是基于corosync实现。

corosync只提供了message layer，而没有直接提供CRM，一般使用Pacemaker进行资源管理。

corosync 的主要作用是提供messaging Layer，这个消息传递层的主要作用是，把个主机间的各状态信息，空闲信息等等一系列信息通过消息传递层互相传递，使得托管在corosync上的服务能够根据底层各主机传递的消息来决定，该服务该运行到那台主机上，一旦运行服务的主机发生故障时，它们又能够根据消息传递层的消息，来判断该把服务迁移到那台主机上运行，这样一来托管在corosync上的服务，就实现了高可用。

简单点讲，托管在corosync之上的服务对底层主机是不可见的，这也意味着托管在corosync上的服务是能够调用和理解Messaging Layer中的消息，这样一来托管在上面的服务就必须得提供接口来调用messaging Layer对外提供的接口，然后实现服务的迁移，而对于大多数程序来讲，它根本就没有这样的接口，这样一来我们要使用corosync实现服务高可用就变得困难。

为了解决托管在corosync的服务能够调用corosync提供的接口。我们需要开发一个中间件，让这个中间件能够向下理解和调用coroysnc提供的接口，向上能够托管服务，这个中间层就是pacemaker。它的主要作用是通过调用corosync提供的接口，来判断把集群资源该怎么分配，服务该怎么迁移和运行。

同时pacemaker还提供一个管理界面，能够让管理员来管理这些集群资源，而对于pacemaker来讲，它主要有3个层次，

• CRM（cluster resource manager）的主要作用是通过调用messaging Layer提供的接口和各节点的状态信息来决策集群资源的管理；然后通过接口把决策信息传递给LRM（local resource manager）；
• LRM的主要作用是对本地的资源做各种管理；而对于LRM来讲，它要怎么管理本地资源呢？它通常不会自己去管理本地资源，而是通过委派RA去管理，所谓RA（resource agent）就是资源代理；它会根据LRM发送的信息来对本地资源进行管理，而这种管理通常是基于各种服务提供的起停脚本来实现的。

比如，我们要把httpd服务托管在corosync+pacemaker这个架构上，首先我们得提供一个管理httpd的服务的脚本，比如centos7上的httpd.service，centos6上的/etc/init.d/httpd来实现；而这些脚本通常在我们使用yum安装都会提供，这样一来，我们要托管httpd服务就变得简单，我们只需要在pacemaker上配置，把httpd识别成集群资源即可；只要配置httpd为集群的资源，此时我们就可以在各主机上迁移httpd服务来实现httpd服务的高可用，要实现httpd服务在各节点上迁移，我们需要注意各节点上必须有httpd服务，对于其他服务也是同样的逻辑。

简单讲corosync主要提供底层各主机消息状态，集群状态信息，而pacemaker主要对托管在其上的服务进行管理；当然pacemaker也可以通过调用corosync的接口来管理底层的主机，比如让某一台主机下线上线等等操作。

Pacemaker 支持的集群

基于OpenAIS的集群

基于心跳信息的传统集群架构

Corosync+Pacemaker 支持的集群

可实现多种集群模型，包括 Active/Active, Active/Passive, N+1, N+M, N-to-1 and N-to-N。

主从架构集群：许多高可用性的情况下，使用Pacemaker和DRBD的双节点主/从集群是一个符合成本效益的解决方案。

多节点备份集群：支持多少节点，Pacemaker可以显着降低硬件成本通过允许几个主/从群集要结合和共享一个公用备份节点。

共享存储集群（多个节点多个服务）：有共享存储时，每个节点可能被用于故障转移，Pacemaker甚至可以运行多个服务。

资源类型

在corosync+pacemaker架构上，最为核心的就是资源，前边说了那么多，最终目的是为了管理托管在上面的资源；而对于资源来讲资源是有类型的；简单讲就是可以用来调配的服务称为资源，比如一个httpd服务，一个ip地址，一个后端共享存储等等，这些都叫做资源；而对于一个完整的服务来讲，它是由多个单一的资源组合而成；比如一个完整的httpd服务它应该由ip地址、httpd服务进程、在特殊场景中很有可能会有后端共享存储；而这些资源在corosync+pacemaker上，每个资源是有类型的，不同类型的资源运行方式各不相同。

primitive：基本资源，主资源；通常仅能运行为一份，运行在单个节点上的资源；

group：组；将一个或多个资源组织成一个可统一管理的单一单位资源；什么意思呢？默认情况托管在corosync+pacemaker上的资源会均衡的运行在多个主机之上，如果我们不将这些资源逻辑的关联在一起，就会存在，ip地址在A主机上，服务进程在B主机上，后端存储在C主机上，这样一来，我们托管的服务就没有办法向外提供服务，为了解决各依赖资源分散的问题，我们需要将多个有关联依赖的资源逻辑的组织成一个组，然后根据这个组为单位进行调度和管理；

clone：克隆；一个资源可以在集群中运行多个副本，可以运行于多个节点；

mutil-state(master/slave)：是clone类型的资源的特殊表现，可以存在多个副本，副本间存在主从关系；

参考链接：https://blog.csdn.net/weixin_44209804/ article/details/89345101 https://www.cnblogs.com /qiuhom-1874/p/13585921.html dandelioncloud.cn /article/details/1555501395464114178