pacemaker浅析

      因为数据库部署在Linux上，需要做数据库集群实现高可用，而所有的PostgresqlHA方案中，流复制HA的可用性，部署成本，性能都是比较好的，而管理流复制集群的工具，pacemaker+corosync则是比较成熟可靠的，借此机会学习下Pacemaker。Pacemaker官网 http://clusterlabs.org/

简要介绍

Pacemaker是 Linux环境中使用最为广泛的开源集群资源管理器。

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

特性

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、具有统一的、脚本化的集群管理工具。

pacemaker 总体架构与详细架构

总体架构

在最高一个层次，集群由三个部分组成：

• 提供消息和集群关系功能的集群核心基础组建（标红的部分）
• 集群无关的组件（蓝色部分）。在Pacemaker架构中，这部分不仅包含有怎么样启动，关闭，监控资源的脚本，而且还有一个本地的守护进程来消除这些脚本实现的（采用的）不同标准之间的差异。
• 大脑（绿色部分）处理并响应来自集群和资源的事件（比如节点的离开和加入，资源的失效），以及管理员对配置文件的修改。在对所有这些事件的响应中，Pacemaker会计算集群理想的状态，并规划一个途径来实现它。这个操作可能会包含移动资源，停止节点，甚至使用远程电源管理来强制使他们下线。

详细架构

• Pacemaker – 资源管理器(CRM)，负责启动和停止服务，而且保证它们是一直运行着的以及某个时刻某服务只在一个节点上运行（避免多服务同时操作数据造成的混乱）。
• Corosync – 消息层组件（Messaging Layer），管理成员关系、消息和仲裁。
• Resource Agents – 资源代理，实现在节点上接收 CRM 的调度对某一个资源进行管理的工具，这个管理的工具通常是脚本，所以我们通常称为资源代理。任何资源代理都要使用同一种风格，接收四个参数：{start|stop|restart|status}，包括配置IP地址的也是。每个种资源的代理都要完成这四个参数据的输出。Pacemaker 的 RA 可以分为三种：（1）Pacemaker 自己实现的 （2）第三方实现的，比如 RabbitMQ 的 RA （3）自己实现的，比如 OpenStack 实现的它的各种服务的RA，这是 mysql 的 RA。

pacemaker 内部组件

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

• CIB：集群信息基础（ Cluster Information Base):集群信息基础，在内存中的一个xml格式集群配置文件,包含所有群集选项，节点，资源，他们彼此之间的关系和现状的定义。同步更新到所有集群节点。
• CRMd：集群资源管理进程（ Cluster Resource Manager deamon):集群资源管理守护进程,每个crmd上有一个cib用来定义维护资源， 主要是消息代理的PEngine和 LRM，还选举一个领导者（DC）统筹活动（包括启动/停止资源）的集群。
• LRMd：本地资源管理进程(Local Resource Manager deamon):本地资源管理守护进程。它提供了一个通用的接口支持的资源类型。直接调用资源代理（脚本）。
• PEngine(PE)：策略引擎(PolicyEngine):根据当前状态和配置集群计算的下一个状态。产生一个过渡图，包含行动和依赖关系的列表。
• STONITHd：集群 Fencing进程（ Shoot The Other Node In The Head deamon)。

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