admin管理员组

文章数量:1130349

Pacemaker

文章目录

  • 网站
  • Pacemaker
    • 由来
    • 概念
    • 主要功能
    • 服务模式
    • 结构
      • HA集群堆栈
      • Pacemaker组件
        • 组件之间运作模式：
        • pacemaker运行组件进程
    • PCS
    • 资源
      • 概念
      • 资源代理分类
      • 资源属性
      • 资源约束
        • 位置约束
        • 顺序约束
        • 资源节点共置
      • 资源组

网站

社区网站首页：/
Pacemaker文档：/
Corosync：/
红帽官网：

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/pacemakerd -f				#Pacemaker主进程（pacemakerd）会生成所有其他守护程序，并在它们意外退出时重新生成它们1380 ? Ss 0:00 \_ /usr/libexec/pacemaker/cib		#集群信息基库1381 ? Ss 0:00 \_ /usr/libexec/pacemaker/stonithd	#stonish1382 ? Ss 0:00 \_ /usr/libexec/pacemaker/lrmd		#本地资源管理器1383 ? Ss 0:00 \_ /usr/libexec/pacemaker/attrd		#管理集群资源属性1384 ? Ss 0:00 \_ /usr/libexec/pacemaker/pengine	#策略引擎1385 ? Ss 0:00 \_ /usr/libexec/pacemaker/crmd		#资源管理

PCS

  • pcs：Pacemaker集群的管理工具
    • Pacemaker社区推出了两个常用的集群管理命令行工具，即集群管理员最为常用的 pcs和 crmsh命令；
    • 此外，需要注意的是， pcs命令行的使用对系统中安装的 pacemaker和 corosync软件版本有一定要求，即 Pacemaker1.1.8及其以上版本， Corosync 2.0及其以上版本才能使用 pcs命令行工具进行集群管理
  • cibadmin：用来查看和管理 pacemaker的集群配置信息，集群 CIB中的配置信息量非常大而且以 XML语言呈现，对于仅由极少数节点和资源所组成的集群，cibadmin也许是个可行方案
[root@node6 ~]# pcs --helpUsage: pcs [-f file] [-h] [commands]...
Control and configure pacemaker and corosync.Options:-h， --help         Display usage and exit.-f file            Perform actions on file instead of active CIB.--debug            Print all network traffic and external commands run.--version          Print pcs version information. List pcs capabilities if--full is specified.--request-timeout  Timeout for each outgoing request to another node inseconds. Default is 60s.--force            Override checks and errors， the exact behavior depends onthe command. WARNING: Using the --force option isstrongly discouraged unless you know what you are doing.Commands:cluster     Configure cluster options and nodes|配置集群选项和节点resource    Manage cluster resources|创建和管理集群资源stonith     Manage fence devices|创建和管理fence设备constraint  Manage resource constraints|管理集群资源约束和限制property    Manage pacemaker properties|管理集群节点和资源属性acl         Manage pacemaker access control lists|管理aclqdevice     Manage quorum device provider on the local host.quorum      Manage cluster quorum settings|管理quorum机制设置booth       Manage booth (cluster ticket manager).status      View cluster status|查看当前集群资源和节点以及进程状态config      View and manage cluster configuration|以用户可读格式显示完整集群配置信息pcsd        Manage pcs daemon|管理pcs守护进程node        Manage cluster nodes|管理集群节点alert       Manage pacemaker alerts|管理告警

资源

概念

  • 资源：Resource在 Pacemaker集群中，各种功能服务通常被配置为集群资源，从而接受资源管理器的调度与控制，资源是集群管理的最小单位对象
  • 分类：根据用户的配置，资源有不同的种类，其中最为简单的资源是原始资源(primitive Resource)，此外还有相对高级和复杂的资源组(Resource Group)和克隆资源(Clone Resource)等集群资源概念
  • 资源代理：在 Pacemaker集群中，每一个原始资源都有一个资源代理(Resource Agent， RA)，RA是一个与资源相关的外部脚本程序，该程序抽象了资源本身所提供的服务并向集群呈现一致的视图以供集群对该资源进行操作控制。
  • 资源代理作用：通过 RA，几乎任何应用程序都可以成为 Pacemaker集群的资源从而被集群资源管理器和控制。RA的存在，使得集群资源管理器可以对其所管理的资源“不求甚解"，即集群资源管理器无需知道资源具体的工作逻辑和原理（ RA已将其封装），资源管理器只需向 RA发出 start、 stop、Monitor等命令， RA便会执行相应的操作。从资源管理器对资源的控制过程来看，集群对资源的管理完全依赖于该资源所提供的，即资源的 RA脚本功能直接决定了资源管理器可以对该资源进行何种控制，因此一个功能完善的 RA在发行之前必须经过充分的功能测试
  • 资源属性：在 pacemaker中，每个资源都具有属性，资源属性决定了该资源 RA脚本的位置，以及该资源隶属于哪种资源标准。例如，在某些情况下，用户可能会在同一系统中安装不同版本或者不同来源的同一服务（如相同的 RabbitMQ Cluster安装程序可能来自 RabbitMQ官方社区也可能来自 Redhat提供的 RabbitMQ安装包），在这个时候，就会存在同一服务对应多个版本资源的情况，为了区分不同来源的资源，就需要在定义集群资源的时候通过资源属性来指定具体使用哪个资源
  • 资源约束：集群是由众多具有特定功能的资源组成的集合，集群中的每个资源都可以对外提供独立服务，但是资源彼此之间存在依赖与被依赖的关系。如资源B的启动必须依赖资源A的存在，因此资源A必须在资源B之前启动，再如资源A必须与资源B位于同一节点以共享某些服务，则资源 B与 A在故障切换时必须作为一个逻辑整体而同时迁移到其他节点，在 pacemaker中，资源之间的这种关系通过资源约束或限制（ Resource constraint)来实现。

资源代理分类

在 pacemaker集群中，资源管理器支持不同种类的资源代理，这些受支持的资源代理包括 OCF、LSB、 Upstart、 systemd、 service、 Fencing、 Nagios Plugins，而在 Linux系统中，最为常见的有 OCF(Open Cluster Framework)资源代理、 LSB（ Linux standard Base)资源代理、Systemd和 Service资源代理 。

#资源代理标准分类
[root@node6 ~]# pcs resource standards 
lsb
ocf
service
systemd
  • LSB：最为传统的 Linux“资源标准之一，例如在 Redhat的 RHEL6及其以下版本中（或者对应的 centos版本中），经常在/etc/init.d目录下看到的资源启动脚本便是LSB标准的资源控制脚本。通常，LSB类型的脚本是由操作系统的发行版本提供的，而为了让集群能够使用这些脚本，它们必须遵循 LSB的规定， LSB类型的资源是可以配置为系统启动时自动启动的，但是如果需要通过集群资源管理器来控制这些资源，则不能将其配置为自动启动，而是由集群根据策略来自行启动
  • OCF：开放式集群框架的简称，从本质上来看， OCF标准其实是对 LSB标准约定中 init脚本的一种延伸和扩展。 OCF标准支持参数传递、自我功能描述以及可扩展性，此外，OCF标准还严格定义了操作执行后的返回代码，集群资源管理器将会根据0资源代理返回的执行代码来对执行结果做出判断。因此，如果OCF脚本错误地提供了与操作结果不匹配的返回代码，则执行操作后的集群资源行为可能会变得莫名其妙，而对于不熟悉OCF脚本的用户，这将会是个非常困惑和不解的问题，尤其是当集群依赖于OCF返回代码来在资源的完全停止状态、错误状态和不确定状态之间进行判断的时候。因此，在OCF脚本发行使用之前一定要经过充分的功能测试，否则有问题的OCF脚本将会扰乱整个集群的资源管理。在Pacemaker集群中，OCF作为一种可以自我描述和高度灵活的行业标准，其已经成为使用最多的资源类别。
  • Service：Pacemaker支持的一种特别的服务别名，由于系统中存在各种类型的服务（如 LSB、 Systemd和 OCF)，Pacemaker使用服务别名的方式自动识别在指定的集群节点上应该使用哪一种类型的服务。当一个集群中混合有 Systemd、 LSB和 OCF类型资源的时候，Service类型的资源代理别名就变得非常有用，例如在存在多种资源类别的情况下，Pacemaker将会自动按照 LSB、 Systemd、 Upstart的顺序来查找启动资源的脚本。
  • Systemd：在很多 Linux的最新发行版本中，systemd被用以替换传统“sysv"风格的系统启动初始化进程和脚本，如在 Redhat的 RHEL7和对应的centos7操作系统中，systemd已经完全替代了sysvinit启动系统，同时systemd提供了与 sysvinit以及 LSB风格脚本兼容的特性，因此老旧系统中已经存在的服务和进程无需修改便可使用systemd在 systemd中，服务不再是/etc/init.d目录下的shell脚本，而是一个单元文件（ unit-file），Systemd通过单元文件来启停和控制服务，Pacemaker提供了管理 Systemd类型的应用服务的功能。

资源属性

资源属性由以下几个部分构成：

  • Resource_id：用户定义的资源名称。
  • Standard：脚本遵循的标准，允许值为OCF、Service、Upstart、Systemd、LSB、Stonith。
  • Provider：OCF规范允许多个供应商提供同一资源代理，Provider即是指资源脚本的提供者，多数OCF规范提供的资源代均使用Heartbeat作为Provider
  • Type：具体资源代理的名称，如常见的IPaddr便是资源的。
#可提供资源代理服务的供应者列表
[root@node6 ~]# pcs resource providers 
heartbeat
openstack
pacemaker#查询具体资源代理的信息
[root@node6 ~]# pcs resource describe -hUsage: pcs resource describe...describe [<standard>:[<provider>:]]<type> [--full]Show options for the specified resource. If --full is specified, alloptions including advanced ones are shown.
#注意：type是必填项，具体要查看的资源代理名称
#standard、provider、--full：选填项，但是注意在区分同一名称的资源代理时，通过standard、provider进行具体区分[root@node6 ~]# pcs resource create -h
#创建资源的方式
Usage: pcs resource create...create <resource id> [<standard>:[<provider>:]]<type> [resource options][op <operation action> <operation options> [<operation action><operation options>]...] [meta <meta options>...][clone [<clone options>] | master [<master options>] |--group <group id> [--before <resource id> | --after <resource id>]| bundle <bundle id>] [--disabled] [--no-default-ops] [--wait[=n]]Create specified resource. If clone is used a clone resource iscreated. If master is specified a master/slave resource is created.If --group is specified the resource is added to the group named. Youcan use --before or --after to specify the position of the addedresource relatively to some resource already existing in the group.If bundle is used, the resource will be created inside of the specifiedbundle. If --disabled is specified the resource is not startedautomatically. If --no-default-ops is specified, only monitoroperations are created for the resource and all other operations usedefault settings. If --wait is specified, pcs will wait up to 'n'seconds for the resource to start and then return 0 if the resource isstarted, or 1 if the resource has not yet started. If 'n' is notspecified it defaults to 60 minutes.Example: Create a new resource called 'VirtualIP' with IP address192.168.0.99, netmask of 32, monitored everything 30 seconds,on eth2:pcs resource create VirtualIP ocf:heartbeat:IPaddr2 \ip=192.168.0.99 cidr_netmask=32 nic=eth2 \op monitor interval=30s
#注意：选填与必填选项内容

资源约束

资源约束分为以下几类：
位置约束：(Location)位置约束限定了资源应该在哪个集群节点上启动运行。
顺序约束：(Order)顺序约束限定了资源之间的启动顺序。
共置约束：(Colocation)共置约束将不同的资源组合在一起作为一个逻辑整体，假如将资源A与资源B组合，若资源 A位于C节点，则资源B也必须位于C节点，并且资源 A、B将会同时进行故障切换到相同的节点上。

位置约束

位置约束方式：类似给服务器节点打标签，然后在附有不同的标签的集群机器上，按设置条件执行

#######设置分数，自动选择方式
pcs constraint  location <resource> prefers|avoids <node>[=<score>] [<node>[=<score>]]...
#<resource> 必选项目，资源名称
#prefers 为资源创建位置限制以便首先使用指定的一个或多个节点
#avoids 为资源创建位置限制以避免指定的节点
#<node>[=<score>]，可以是多个
#其中node为节点名称
#score为确定某个资源应该或避免在某个节点中运行的指数，INFINITY 是资源位置限制的默认分值
ex：
pcs property set symmetric-cluster=false
# 要创建选择加入集群，请将 symmetric-cluster 集群属性设定为 false，默认不允许资源在任意位置运行
pcs constraint location Webserver prefers example-1=200
pcs constraint location Webserver prefers example-3=0
#资源 Webserver 首选节点 example-1（分数为200），如果这个资源的首选节点宕机，则可故障切换至节点 example-3（分数为0）#######自定义规则
pcs constraint  location <resource> rule [id=<rule id>] [resource-discovery=<option>][role=master|slave] [constraint-id=<id>][score=<score> | score-attribute=<attribute>] <expression>
#rule 为资源创建位置限制，使用自定义规则形式
#resource-discovery 资源发现设置 option：always|never|exclusive
#				    always：默认选项。始终在此节点上为指定资源执行资源发现
#					never：永不在此节点上为指定资源执行资源发现
#					exclusive：仅在此节点（以及类似地标记为互斥的其他节点）上针对指定资源执行资源发现。 使用跨不同节点上的同一资源的排他发现的多个位置约束创建了资源发现专用的节点子集。 如果将资源标记为在一个或多个节点上进行排他发现，则仅允许将该资源放置在该节点子集中
#<expression> 表达式，自定规则表达式，
#格式： <attribute> lt|gt|lte|gte|eq|ne [string|integer|version] <value>
#例子：date gt|lt date
#	  date in-range date to date
#     date in-range date to duration duration_options ...
ex:
pcs property set --node web1 osprole=web
#设置节点compute1服务器， osprole属性（属性名称可自定义）的值为compute，打标签
pcs constraint location Webserver  rule resource-discovery=exclusive score=0 osprole eq web
#设置资源Webserver，根据自定义规则，服务器属性osprole是web的机器上运行资源

顺序约束

顺序约束：比较简单，直接设置资源运行顺序即可，定义再执行某一个资源动作后才能执行另一资源动作

######2个资源进行设置的方式
pcs constraint order [action] <resource id> then [action] <resource id> [options]
#action：资源执行的动作，start|stop|promote|demote
#* start - 启动该资源。默认选项
#* stop - 停止该资源。
#* promote - 将某个资源从辅资源提升为主资源。
#* demote - 将某个资源从主资源降级为辅资源。
#resource id：资源名称
#option：附加选项，kind=Optional/Mandatory/Serialize,symmetrical=true/false, require-all=true/false
[options]：
kind=Optional
#顾问排序，为一个限制指定 kind=Optional 选项后，可将该限制视为自选，且只在同时停止和/或启动两个资源时才会产生影响。对第一个指定资源进行的任何更改都不会对第二个指定的资源产生影响。
kind=Mandatory
#默认选项，强制排序表示如果指定的第一个资源未处于活跃状态，则无法运行指定的第二个资源。采用这个默认值可保证您指定的第二个资源会在指定的第一个资源更改状态时有所响应。
#1.如果指定的第一个资源正在运行，并已被停止，则指定的第二个资源也会停止（如果该资源正在运行）。
#2.如果指定的第一个资源没有运行，且无法启动，则指定的第二个资源也会停止（如果该资源正在运行）。
#3.如果指定的第一个资源已重启，同时指定的第二个资源正在运行，则指定的第二个资源会停止，然后重启。
kind=Serialize
#确定不会对一组资源同时执行 stop/start 操作
symmetrical=true/false
#默认值为true，如果使用默认值true，则以相反的顺序停止这些资源。
require-all=true/false
#默认值为true，可将其设定为 true 或 false，表示是否该组中的所有资源都必须启用
ex：
pcs constraint order start VirtualIP then start Webserver 
pcs constraint order start Webserver  then start Database 
#先启动VirtualIP 然后启动webserver服务，然后再启动Database#######多个资源设置
pcs constraint order set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ... [options]] [setoptions [constraint_options]]
#options :参数为一组资源设定以下选项
#* sequential，可将其设定为 true 或 false，表示一组节点共置限制资源是否为按顺序排列的资源组。
#* require-all，可将其设定为 true 或 false，表示是否该组中的所有资源都必须启用。
#* action，可将其设定为 start、 promote、demote 或 stop。
#* role，可将其设定为 Stopped、Started、Master 或 Slave。
#setoptions :参数为一组资源设定以下限制选项,id|score
#* id，为定义的限制提供名称。
#* score，表示这个限制的倾向性。有关这个选项的详情
ex：
pcs constraint order set VirtualIP  Webserver  Database
#按排列顺序的执行资源

资源节点共置

资源节点共置：类似于将一些资源捆绑为一体，进行使用
在两个资源间创建节点共置限制有一个很重要的负面作用：它会影响为某个节点分配资源的顺序。
因为无法将资源 A 放在相对资源 B 的位置，除非您知道资源 B 在哪里。
因此当创建节点共置限制时，关键是要考虑是应将资源 A 与资源 B 共置，还是将资源 B 与资源 A 共置

######2个资源进行设置的方式
pcs constraint colocation add [master|slave] source_resource with [master|slave] target_resource [score] [options]source_resource
#共置资源。如果对该限制不满意，集群会决定根本不允许该资源运行。
target_resource
#共置目标。集群将决定首先将这个资源放在哪里，然后决定在哪里防止源资源。
score
#正数值代表资源应在同一节点中运行。负数值代表资源不应再同一节点中运行。默认值，即 + INFINITY 值代表 source_resource 必须作为 target_resource 在同一节点中运行。- INFINITY 值代表 source_resource 一定不能作为 target_resource 在同一节点中运行
ex：
pcs constraint colocation start VirtualIP then start Webserver 
#先启动VirtualIP 然后启动webserver服务，并且2个服务必须运行在统一节点服务器上#######多个资源设置
pcs constraint colocation set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ... [options]] [setoptions [constraint_options]]
#options :参数为一组资源设定以下选项
#* sequential，可将其设定为 true 或 false，表示一组节点共置限制资源是否为按顺序排列的资源组。
#* require-all，可将其设定为 true 或 false，表示是否该组中的所有资源都必须启用。
#* action，可将其设定为 start、 promote、demote 或 stop。
#* role，可将其设定为 Stopped、Started、Master 或 Slave。
#setoptions :参数为一组资源设定以下限制选项,id|score
#* kind，表示如何强制执行限制。kind=Optional/Mandatory/Serialize与order中的选项使用一样
#* symmetrical，表示停止资源的顺序。如果为 true（即默认选项），则会以相反的顺序停止资源。默认值为 true。
#* id，为定义的限制提供名称。
ex：
pcs constraint colocation set VirtualIP  Webserver  Database
#按排列顺序的执行资源，并且服务必须运行在统一节点服务器上

资源组

Pacemaker集群中，经常需要将多个资源作为一个资源组进行统一操作，例如将多个相关资源全部位于某个节点或者同时切换到另外的节点，并且要求这些资源按照一定的先后顺序启动，然后以相反的顺序停止，为了简化同时对多个资源进行配置，供了高级资源类型一资源组。通过资源组，用户便可并行配置多个资源。

pcs resource group add group_name resource_id  ... [resource_id] [--before resource_id] --after resource_id
#使用该命令创建资源组时，如果指定的资源组目前不存在，则此命令会新建一个资源组
#如果指定的资源组已经存在，则此命令会将指定的资源添加到该资源组中并且组中的资源会按照该命令中出现的先位置顺序启动，并以相反的顺序停止。
#在该命令中，还可使用--before和--after参数指定所添加的资源与组中已有资源的相对启动顺序pcs resource create resource_id Standard:Provider:Type丨 type [ resource_options] [op operation_action operation_options] --group group_name
#为资源组添加资源，不仅可以将已有资源添加到组中，还可以在创建资源的同时顺便将其添加到指定的资源组中pcs resource group remove group_name resource_id ...
#将资源从组中删除，如果该组中没有资源，这个命令会将该组删除pcs resource group list
#查看目前巳经配置的资源组ex：
pcs resource group add MyGroup IPaddr HAproxy
#创建名为Mygroup的资源组，并添加资源 IPaddr和 HAproxy
  • 在 Pacemaker集群中，资源组所包含的资源数目是不受限的，资源组中的资源具有如下的基本特性：
  1. 资源按照其指定的先后顺序启动，如在前面示例的 MyGroup资源组中，首先启动 IPaddr，然后启动 HAproxy。
  2. 资源按照其指定顺序的相反顺序停止，如首先停止 HAproxy，然后停止 IPaddr
  3. 如果资源组中的某个资源无法在任何节点启动运行，那么在该资源后指定的任何资源都将无法运行，如 IPaddr不能启动，则 HAproxy也不能启动。
  4. 资源组中后指定资源不影响前指定资源的运行，如 HAproxy不能运行，但IPaddr却可以正常运行。
  • 资源组具有组属性：
    • Priority：资源优先级，其默认值是0，如果集群无法保证所有资源都处于运行状态，则低优先权资源会被停止，以便让高优先权资源保持运行状态。
    • Target-role：资源目标角色，其默认值是started表示集群应该让这个资源处于何种状态，允许值为：
      • Stopped：表示强制资源停止；
      • Started：表示允许资源启动，但是在多状态资源的情况下不能将其提升为 Master资源；
      • Master：允许资源启动，并在适当时将其提升为 Master。
    • is-managed：其默认值是true，表示是否允许集群启动和停止该资源，false表示不允许。
    • Resource-stickiness：默认值是0，表示该资源保留在原有位置节点的倾向程度值。
    • Requires：默认值为 fencing，表示资源在什么条件下允许启动。

Pacemaker

文章目录

  • 网站
  • Pacemaker
    • 由来
    • 概念
    • 主要功能
    • 服务模式
    • 结构
      • HA集群堆栈
      • Pacemaker组件
        • 组件之间运作模式：
        • pacemaker运行组件进程
    • PCS
    • 资源
      • 概念
      • 资源代理分类
      • 资源属性
      • 资源约束
        • 位置约束
        • 顺序约束
        • 资源节点共置
      • 资源组

网站

社区网站首页：/
Pacemaker文档：/
Corosync：/
红帽官网：

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/pacemakerd -f				#Pacemaker主进程（pacemakerd）会生成所有其他守护程序，并在它们意外退出时重新生成它们1380 ? Ss 0:00 \_ /usr/libexec/pacemaker/cib		#集群信息基库1381 ? Ss 0:00 \_ /usr/libexec/pacemaker/stonithd	#stonish1382 ? Ss 0:00 \_ /usr/libexec/pacemaker/lrmd		#本地资源管理器1383 ? Ss 0:00 \_ /usr/libexec/pacemaker/attrd		#管理集群资源属性1384 ? Ss 0:00 \_ /usr/libexec/pacemaker/pengine	#策略引擎1385 ? Ss 0:00 \_ /usr/libexec/pacemaker/crmd		#资源管理

PCS

  • pcs：Pacemaker集群的管理工具
    • Pacemaker社区推出了两个常用的集群管理命令行工具，即集群管理员最为常用的 pcs和 crmsh命令；
    • 此外，需要注意的是， pcs命令行的使用对系统中安装的 pacemaker和 corosync软件版本有一定要求，即 Pacemaker1.1.8及其以上版本， Corosync 2.0及其以上版本才能使用 pcs命令行工具进行集群管理
  • cibadmin：用来查看和管理 pacemaker的集群配置信息，集群 CIB中的配置信息量非常大而且以 XML语言呈现，对于仅由极少数节点和资源所组成的集群，cibadmin也许是个可行方案
[root@node6 ~]# pcs --helpUsage: pcs [-f file] [-h] [commands]...
Control and configure pacemaker and corosync.Options:-h， --help         Display usage and exit.-f file            Perform actions on file instead of active CIB.--debug            Print all network traffic and external commands run.--version          Print pcs version information. List pcs capabilities if--full is specified.--request-timeout  Timeout for each outgoing request to another node inseconds. Default is 60s.--force            Override checks and errors， the exact behavior depends onthe command. WARNING: Using the --force option isstrongly discouraged unless you know what you are doing.Commands:cluster     Configure cluster options and nodes|配置集群选项和节点resource    Manage cluster resources|创建和管理集群资源stonith     Manage fence devices|创建和管理fence设备constraint  Manage resource constraints|管理集群资源约束和限制property    Manage pacemaker properties|管理集群节点和资源属性acl         Manage pacemaker access control lists|管理aclqdevice     Manage quorum device provider on the local host.quorum      Manage cluster quorum settings|管理quorum机制设置booth       Manage booth (cluster ticket manager).status      View cluster status|查看当前集群资源和节点以及进程状态config      View and manage cluster configuration|以用户可读格式显示完整集群配置信息pcsd        Manage pcs daemon|管理pcs守护进程node        Manage cluster nodes|管理集群节点alert       Manage pacemaker alerts|管理告警

资源

概念

  • 资源：Resource在 Pacemaker集群中，各种功能服务通常被配置为集群资源，从而接受资源管理器的调度与控制，资源是集群管理的最小单位对象
  • 分类：根据用户的配置，资源有不同的种类，其中最为简单的资源是原始资源(primitive Resource)，此外还有相对高级和复杂的资源组(Resource Group)和克隆资源(Clone Resource)等集群资源概念
  • 资源代理：在 Pacemaker集群中，每一个原始资源都有一个资源代理(Resource Agent， RA)，RA是一个与资源相关的外部脚本程序，该程序抽象了资源本身所提供的服务并向集群呈现一致的视图以供集群对该资源进行操作控制。
  • 资源代理作用：通过 RA，几乎任何应用程序都可以成为 Pacemaker集群的资源从而被集群资源管理器和控制。RA的存在，使得集群资源管理器可以对其所管理的资源“不求甚解"，即集群资源管理器无需知道资源具体的工作逻辑和原理（ RA已将其封装），资源管理器只需向 RA发出 start、 stop、Monitor等命令， RA便会执行相应的操作。从资源管理器对资源的控制过程来看，集群对资源的管理完全依赖于该资源所提供的，即资源的 RA脚本功能直接决定了资源管理器可以对该资源进行何种控制，因此一个功能完善的 RA在发行之前必须经过充分的功能测试
  • 资源属性：在 pacemaker中，每个资源都具有属性，资源属性决定了该资源 RA脚本的位置，以及该资源隶属于哪种资源标准。例如，在某些情况下，用户可能会在同一系统中安装不同版本或者不同来源的同一服务（如相同的 RabbitMQ Cluster安装程序可能来自 RabbitMQ官方社区也可能来自 Redhat提供的 RabbitMQ安装包），在这个时候，就会存在同一服务对应多个版本资源的情况，为了区分不同来源的资源，就需要在定义集群资源的时候通过资源属性来指定具体使用哪个资源
  • 资源约束：集群是由众多具有特定功能的资源组成的集合，集群中的每个资源都可以对外提供独立服务，但是资源彼此之间存在依赖与被依赖的关系。如资源B的启动必须依赖资源A的存在，因此资源A必须在资源B之前启动，再如资源A必须与资源B位于同一节点以共享某些服务，则资源 B与 A在故障切换时必须作为一个逻辑整体而同时迁移到其他节点，在 pacemaker中，资源之间的这种关系通过资源约束或限制（ Resource constraint)来实现。

资源代理分类

在 pacemaker集群中，资源管理器支持不同种类的资源代理，这些受支持的资源代理包括 OCF、LSB、 Upstart、 systemd、 service、 Fencing、 Nagios Plugins，而在 Linux系统中，最为常见的有 OCF(Open Cluster Framework)资源代理、 LSB（ Linux standard Base)资源代理、Systemd和 Service资源代理 。

#资源代理标准分类
[root@node6 ~]# pcs resource standards 
lsb
ocf
service
systemd
  • LSB：最为传统的 Linux“资源标准之一，例如在 Redhat的 RHEL6及其以下版本中（或者对应的 centos版本中），经常在/etc/init.d目录下看到的资源启动脚本便是LSB标准的资源控制脚本。通常，LSB类型的脚本是由操作系统的发行版本提供的，而为了让集群能够使用这些脚本，它们必须遵循 LSB的规定， LSB类型的资源是可以配置为系统启动时自动启动的，但是如果需要通过集群资源管理器来控制这些资源，则不能将其配置为自动启动，而是由集群根据策略来自行启动
  • OCF：开放式集群框架的简称，从本质上来看， OCF标准其实是对 LSB标准约定中 init脚本的一种延伸和扩展。 OCF标准支持参数传递、自我功能描述以及可扩展性，此外，OCF标准还严格定义了操作执行后的返回代码，集群资源管理器将会根据0资源代理返回的执行代码来对执行结果做出判断。因此，如果OCF脚本错误地提供了与操作结果不匹配的返回代码，则执行操作后的集群资源行为可能会变得莫名其妙，而对于不熟悉OCF脚本的用户，这将会是个非常困惑和不解的问题，尤其是当集群依赖于OCF返回代码来在资源的完全停止状态、错误状态和不确定状态之间进行判断的时候。因此，在OCF脚本发行使用之前一定要经过充分的功能测试，否则有问题的OCF脚本将会扰乱整个集群的资源管理。在Pacemaker集群中，OCF作为一种可以自我描述和高度灵活的行业标准，其已经成为使用最多的资源类别。
  • Service：Pacemaker支持的一种特别的服务别名，由于系统中存在各种类型的服务（如 LSB、 Systemd和 OCF)，Pacemaker使用服务别名的方式自动识别在指定的集群节点上应该使用哪一种类型的服务。当一个集群中混合有 Systemd、 LSB和 OCF类型资源的时候，Service类型的资源代理别名就变得非常有用，例如在存在多种资源类别的情况下，Pacemaker将会自动按照 LSB、 Systemd、 Upstart的顺序来查找启动资源的脚本。
  • Systemd：在很多 Linux的最新发行版本中，systemd被用以替换传统“sysv"风格的系统启动初始化进程和脚本，如在 Redhat的 RHEL7和对应的centos7操作系统中，systemd已经完全替代了sysvinit启动系统，同时systemd提供了与 sysvinit以及 LSB风格脚本兼容的特性，因此老旧系统中已经存在的服务和进程无需修改便可使用systemd在 systemd中，服务不再是/etc/init.d目录下的shell脚本，而是一个单元文件（ unit-file），Systemd通过单元文件来启停和控制服务，Pacemaker提供了管理 Systemd类型的应用服务的功能。

资源属性

资源属性由以下几个部分构成：

  • Resource_id：用户定义的资源名称。
  • Standard：脚本遵循的标准，允许值为OCF、Service、Upstart、Systemd、LSB、Stonith。
  • Provider：OCF规范允许多个供应商提供同一资源代理，Provider即是指资源脚本的提供者，多数OCF规范提供的资源代均使用Heartbeat作为Provider
  • Type：具体资源代理的名称，如常见的IPaddr便是资源的。
#可提供资源代理服务的供应者列表
[root@node6 ~]# pcs resource providers 
heartbeat
openstack
pacemaker#查询具体资源代理的信息
[root@node6 ~]# pcs resource describe -hUsage: pcs resource describe...describe [<standard>:[<provider>:]]<type> [--full]Show options for the specified resource. If --full is specified, alloptions including advanced ones are shown.
#注意：type是必填项，具体要查看的资源代理名称
#standard、provider、--full：选填项，但是注意在区分同一名称的资源代理时，通过standard、provider进行具体区分[root@node6 ~]# pcs resource create -h
#创建资源的方式
Usage: pcs resource create...create <resource id> [<standard>:[<provider>:]]<type> [resource options][op <operation action> <operation options> [<operation action><operation options>]...] [meta <meta options>...][clone [<clone options>] | master [<master options>] |--group <group id> [--before <resource id> | --after <resource id>]| bundle <bundle id>] [--disabled] [--no-default-ops] [--wait[=n]]Create specified resource. If clone is used a clone resource iscreated. If master is specified a master/slave resource is created.If --group is specified the resource is added to the group named. Youcan use --before or --after to specify the position of the addedresource relatively to some resource already existing in the group.If bundle is used, the resource will be created inside of the specifiedbundle. If --disabled is specified the resource is not startedautomatically. If --no-default-ops is specified, only monitoroperations are created for the resource and all other operations usedefault settings. If --wait is specified, pcs will wait up to 'n'seconds for the resource to start and then return 0 if the resource isstarted, or 1 if the resource has not yet started. If 'n' is notspecified it defaults to 60 minutes.Example: Create a new resource called 'VirtualIP' with IP address192.168.0.99, netmask of 32, monitored everything 30 seconds,on eth2:pcs resource create VirtualIP ocf:heartbeat:IPaddr2 \ip=192.168.0.99 cidr_netmask=32 nic=eth2 \op monitor interval=30s
#注意：选填与必填选项内容

资源约束

资源约束分为以下几类：
位置约束：(Location)位置约束限定了资源应该在哪个集群节点上启动运行。
顺序约束：(Order)顺序约束限定了资源之间的启动顺序。
共置约束：(Colocation)共置约束将不同的资源组合在一起作为一个逻辑整体，假如将资源A与资源B组合，若资源 A位于C节点，则资源B也必须位于C节点，并且资源 A、B将会同时进行故障切换到相同的节点上。

位置约束

位置约束方式：类似给服务器节点打标签，然后在附有不同的标签的集群机器上，按设置条件执行

#######设置分数，自动选择方式
pcs constraint  location <resource> prefers|avoids <node>[=<score>] [<node>[=<score>]]...
#<resource> 必选项目，资源名称
#prefers 为资源创建位置限制以便首先使用指定的一个或多个节点
#avoids 为资源创建位置限制以避免指定的节点
#<node>[=<score>]，可以是多个
#其中node为节点名称
#score为确定某个资源应该或避免在某个节点中运行的指数，INFINITY 是资源位置限制的默认分值
ex：
pcs property set symmetric-cluster=false
# 要创建选择加入集群，请将 symmetric-cluster 集群属性设定为 false，默认不允许资源在任意位置运行
pcs constraint location Webserver prefers example-1=200
pcs constraint location Webserver prefers example-3=0
#资源 Webserver 首选节点 example-1（分数为200），如果这个资源的首选节点宕机，则可故障切换至节点 example-3（分数为0）#######自定义规则
pcs constraint  location <resource> rule [id=<rule id>] [resource-discovery=<option>][role=master|slave] [constraint-id=<id>][score=<score> | score-attribute=<attribute>] <expression>
#rule 为资源创建位置限制，使用自定义规则形式
#resource-discovery 资源发现设置 option：always|never|exclusive
#				    always：默认选项。始终在此节点上为指定资源执行资源发现
#					never：永不在此节点上为指定资源执行资源发现
#					exclusive：仅在此节点（以及类似地标记为互斥的其他节点）上针对指定资源执行资源发现。 使用跨不同节点上的同一资源的排他发现的多个位置约束创建了资源发现专用的节点子集。 如果将资源标记为在一个或多个节点上进行排他发现，则仅允许将该资源放置在该节点子集中
#<expression> 表达式，自定规则表达式，
#格式： <attribute> lt|gt|lte|gte|eq|ne [string|integer|version] <value>
#例子：date gt|lt date
#	  date in-range date to date
#     date in-range date to duration duration_options ...
ex:
pcs property set --node web1 osprole=web
#设置节点compute1服务器， osprole属性（属性名称可自定义）的值为compute，打标签
pcs constraint location Webserver  rule resource-discovery=exclusive score=0 osprole eq web
#设置资源Webserver，根据自定义规则，服务器属性osprole是web的机器上运行资源

顺序约束

顺序约束：比较简单，直接设置资源运行顺序即可，定义再执行某一个资源动作后才能执行另一资源动作

######2个资源进行设置的方式
pcs constraint order [action] <resource id> then [action] <resource id> [options]
#action：资源执行的动作，start|stop|promote|demote
#* start - 启动该资源。默认选项
#* stop - 停止该资源。
#* promote - 将某个资源从辅资源提升为主资源。
#* demote - 将某个资源从主资源降级为辅资源。
#resource id：资源名称
#option：附加选项，kind=Optional/Mandatory/Serialize,symmetrical=true/false, require-all=true/false
[options]：
kind=Optional
#顾问排序，为一个限制指定 kind=Optional 选项后，可将该限制视为自选，且只在同时停止和/或启动两个资源时才会产生影响。对第一个指定资源进行的任何更改都不会对第二个指定的资源产生影响。
kind=Mandatory
#默认选项，强制排序表示如果指定的第一个资源未处于活跃状态，则无法运行指定的第二个资源。采用这个默认值可保证您指定的第二个资源会在指定的第一个资源更改状态时有所响应。
#1.如果指定的第一个资源正在运行，并已被停止，则指定的第二个资源也会停止（如果该资源正在运行）。
#2.如果指定的第一个资源没有运行，且无法启动，则指定的第二个资源也会停止（如果该资源正在运行）。
#3.如果指定的第一个资源已重启，同时指定的第二个资源正在运行，则指定的第二个资源会停止，然后重启。
kind=Serialize
#确定不会对一组资源同时执行 stop/start 操作
symmetrical=true/false
#默认值为true，如果使用默认值true，则以相反的顺序停止这些资源。
require-all=true/false
#默认值为true，可将其设定为 true 或 false，表示是否该组中的所有资源都必须启用
ex：
pcs constraint order start VirtualIP then start Webserver 
pcs constraint order start Webserver  then start Database 
#先启动VirtualIP 然后启动webserver服务，然后再启动Database#######多个资源设置
pcs constraint order set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ... [options]] [setoptions [constraint_options]]
#options :参数为一组资源设定以下选项
#* sequential，可将其设定为 true 或 false，表示一组节点共置限制资源是否为按顺序排列的资源组。
#* require-all，可将其设定为 true 或 false，表示是否该组中的所有资源都必须启用。
#* action，可将其设定为 start、 promote、demote 或 stop。
#* role，可将其设定为 Stopped、Started、Master 或 Slave。
#setoptions :参数为一组资源设定以下限制选项,id|score
#* id，为定义的限制提供名称。
#* score，表示这个限制的倾向性。有关这个选项的详情
ex：
pcs constraint order set VirtualIP  Webserver  Database
#按排列顺序的执行资源

资源节点共置

资源节点共置：类似于将一些资源捆绑为一体，进行使用
在两个资源间创建节点共置限制有一个很重要的负面作用：它会影响为某个节点分配资源的顺序。
因为无法将资源 A 放在相对资源 B 的位置，除非您知道资源 B 在哪里。
因此当创建节点共置限制时，关键是要考虑是应将资源 A 与资源 B 共置，还是将资源 B 与资源 A 共置

######2个资源进行设置的方式
pcs constraint colocation add [master|slave] source_resource with [master|slave] target_resource [score] [options]source_resource
#共置资源。如果对该限制不满意，集群会决定根本不允许该资源运行。
target_resource
#共置目标。集群将决定首先将这个资源放在哪里，然后决定在哪里防止源资源。
score
#正数值代表资源应在同一节点中运行。负数值代表资源不应再同一节点中运行。默认值，即 + INFINITY 值代表 source_resource 必须作为 target_resource 在同一节点中运行。- INFINITY 值代表 source_resource 一定不能作为 target_resource 在同一节点中运行
ex：
pcs constraint colocation start VirtualIP then start Webserver 
#先启动VirtualIP 然后启动webserver服务，并且2个服务必须运行在统一节点服务器上#######多个资源设置
pcs constraint colocation set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ... [options]] [setoptions [constraint_options]]
#options :参数为一组资源设定以下选项
#* sequential，可将其设定为 true 或 false，表示一组节点共置限制资源是否为按顺序排列的资源组。
#* require-all，可将其设定为 true 或 false，表示是否该组中的所有资源都必须启用。
#* action，可将其设定为 start、 promote、demote 或 stop。
#* role，可将其设定为 Stopped、Started、Master 或 Slave。
#setoptions :参数为一组资源设定以下限制选项,id|score
#* kind，表示如何强制执行限制。kind=Optional/Mandatory/Serialize与order中的选项使用一样
#* symmetrical，表示停止资源的顺序。如果为 true（即默认选项），则会以相反的顺序停止资源。默认值为 true。
#* id，为定义的限制提供名称。
ex：
pcs constraint colocation set VirtualIP  Webserver  Database
#按排列顺序的执行资源，并且服务必须运行在统一节点服务器上

资源组

Pacemaker集群中，经常需要将多个资源作为一个资源组进行统一操作，例如将多个相关资源全部位于某个节点或者同时切换到另外的节点，并且要求这些资源按照一定的先后顺序启动，然后以相反的顺序停止，为了简化同时对多个资源进行配置，供了高级资源类型一资源组。通过资源组，用户便可并行配置多个资源。

pcs resource group add group_name resource_id  ... [resource_id] [--before resource_id] --after resource_id
#使用该命令创建资源组时，如果指定的资源组目前不存在，则此命令会新建一个资源组
#如果指定的资源组已经存在，则此命令会将指定的资源添加到该资源组中并且组中的资源会按照该命令中出现的先位置顺序启动，并以相反的顺序停止。
#在该命令中，还可使用--before和--after参数指定所添加的资源与组中已有资源的相对启动顺序pcs resource create resource_id Standard:Provider:Type丨 type [ resource_options] [op operation_action operation_options] --group group_name
#为资源组添加资源，不仅可以将已有资源添加到组中，还可以在创建资源的同时顺便将其添加到指定的资源组中pcs resource group remove group_name resource_id ...
#将资源从组中删除，如果该组中没有资源，这个命令会将该组删除pcs resource group list
#查看目前巳经配置的资源组ex：
pcs resource group add MyGroup IPaddr HAproxy
#创建名为Mygroup的资源组，并添加资源 IPaddr和 HAproxy
  • 在 Pacemaker集群中，资源组所包含的资源数目是不受限的，资源组中的资源具有如下的基本特性：
  1. 资源按照其指定的先后顺序启动，如在前面示例的 MyGroup资源组中，首先启动 IPaddr，然后启动 HAproxy。
  2. 资源按照其指定顺序的相反顺序停止，如首先停止 HAproxy，然后停止 IPaddr
  3. 如果资源组中的某个资源无法在任何节点启动运行，那么在该资源后指定的任何资源都将无法运行，如 IPaddr不能启动，则 HAproxy也不能启动。
  4. 资源组中后指定资源不影响前指定资源的运行，如 HAproxy不能运行，但IPaddr却可以正常运行。
  • 资源组具有组属性：
    • Priority：资源优先级，其默认值是0，如果集群无法保证所有资源都处于运行状态，则低优先权资源会被停止，以便让高优先权资源保持运行状态。
    • Target-role：资源目标角色，其默认值是started表示集群应该让这个资源处于何种状态，允许值为：
      • Stopped：表示强制资源停止；
      • Started：表示允许资源启动，但是在多状态资源的情况下不能将其提升为 Master资源；
      • Master：允许资源启动，并在适当时将其提升为 Master。
    • is-managed：其默认值是true，表示是否允许集群启动和停止该资源，false表示不允许。
    • Resource-stickiness：默认值是0，表示该资源保留在原有位置节点的倾向程度值。
    • Requires：默认值为 fencing，表示资源在什么条件下允许启动。

本文标签： Pacemaker

版权声明：本文标题：Pacemaker 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://it.en369.cn/IT/1686525003a5847.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。