HeartBeat 集群组件概述

Heartbeat 是一个基于Linux开源的高可用集群系统。主要包括心跳服务和资源接管两个高可用集群组件。心跳监测服务可以通过网络链路和串口进行，而且支持冗余链路， 它们之间相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运行在对方主机上的资源或者服务。本文简要描述了heartbeat v2集群架构组件及其相关概念，供大家参考。

一、高可用集群的特点

高可用服务

通常使用集群方式实现，这也是集群的最大作用和体现。
其终极目标是确保服务实时可用，不会因为任意的软硬件故障导致服务出现终止和不可用的情形。

度量标准

系统的可靠性(reliability)和可维护性(maintainability)来度量。
工程上，通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均修复时间(MTTR)来度量系统的可维护性。
    计算公式，HA=MTTF/(MTTF+MTTR)*100%
    99%         全年停机时间不超过4天
    99.9%       全年停机时间不超过10小时
    99.99%      全年停机时间不超过1小时
    99.999%     全年停机时间不超过6分钟

集群节点

集群软件必须包括一种机制来定义哪些系统的可用作集群节点(定义节点，2节点或以上)。
所有位于集群中的主机都称为节点。

集群服务与资源

哪些服务或应用程序可以在节点之间进行故障转移，并互连可以在节点间传送通信。
服务通常包括多种资源，多种资源组成某种服务。
如mysql高可用服务，则vip，mysqld，共享或镜像磁盘等则为该服务所需要的资源。
对集群服务的管理，实际上是对资源的管理。

资源隔离与脑裂

由于软硬件故障导致节点宕机发生资源争用，即出现故障节点或正常并存的情形。
在故障的节点控制相同的集群资源的情况下，实施资源隔离，防止脑裂发生(Fence机制，STONITH等)。

集群状态监控

通过集群管理和监控工具以及预定义的脚本来配置常见的服务或应用程序，监控，故障转移等。
最为大家所熟知的如心跳，主要用于在集群环境中各节点之间相互感知对方的存在。
可以基于串口、多播、广播和组播通信机制。一旦心跳失败，则会发生相应的资源转移，集群重构等动作。

二、HeartBeat组件

Heartbeat 是一个基于Linux开源的高可用集群系统。主要包括心跳服务和资源接管两个高可用集群组件，其重大的版本变更主要分为三个阶段。

1、Heartbeat 1.x组件

Heartbeat1.x允许集群节点和资源通过/etc/ha.d目录下面的两个文件来配置
ha.cf：定义集群节点，失效检测和切换时间间隔，集群时间日志机制和节点Fence方法
haresources:
定义集群资源组，每一行定义可以一起进行失效切换的一个默认的节点和一组资源，资源包括IP地址，文件系统，服务或者应用

2、Heartbeat 2.x组件

Heartbeat 2.0 在基于Heartbeat1.x 基础上配置引入了模块结构的配置方法，集群资源管理器(Cluster Rescource Manager-CRM).
CRM模型可以支持最多16个节点，这个模型使用基于XML的集群信息(Cluster Information Base-CIB)配置。
Heartbeat 2.x官方最后一个STABLE release 2.x 版本是2.1.4。
CIB文件(/var/lib/heartbeat/crm/cib.xml)会在各个节点间自动复制，它定义了下面的对象和动作:
*集群节点
*集群资源，包括属性，优先级，组和依赖性
*日志，监控，仲裁和fence标准
*当服务失败或者其中设定的标准满足时，需要执行的动作

消息传递和基础设施层(Messaging and Infrastructure Layer)

初级或第一层是消息传递/基础设施层，也被称为心跳层。#Author:Leshami
此层包含了发送含有“我还活着”信号的心跳信息，以及其他信息的组件。
Heartbeat程序驻留在消息/基础设施层。#Blog:http://blog.csdn.net/leshami

成员层(Membership Layer)

成员层从底层即心跳层获取信息，负责计算集群节点的最大完全连接设置并同步到节点上的所有成员。
该层负责集群成员间的一致性，提供集群拓扑结构给上一层组件。

资源分配层(Resource Allocation Layer)

第三层是资源分配层。这一层是最复杂的，且由以下部分组成：
集群资源管理器(Cluster Resource Manager)
    在资源分配层的每一个动作由集群资源管理器管理。
    资源分配层的任意组件，或其他更高层的任何组件需要通信，则由本地集群资源管理器管理。

    在每一个节点上，集群资源管理器维护集群信息库，或CIB（见下文集群信息库）。
    集群中的一个节点会被选为指定协调器(DC)，这意味着它具有主CIB。集群中的所有其他CIB是主CIB的副本。
    对CIB正常的读写操作都通过主CIB序列化。
    在集群中，DC可以决定一个群集范围的变化需要执行的相关变更，如隔离一个节点或移动资源等。

集群信息库(Cluster Information Base)         
    集群信息库或CIB是整个集群配置和状态，包括节点成员，资源约束等，是一个驻留内存的XML文件。
    在集群中，有一个由DC维护的主CIB，所有其他节点包含一个CIB副本。
    如果管理员想管理集群，则可以使用cibadmin命令行工具或heartbeat GUI工具。
    heartbeat GUI工具可以用于从任何机器到集群的连接。
    cibadmin命令必须在集群节点上使用，并且不限制于只能在DC节点。

策略引擎和转换引擎(Policy Engine (PE) and Transition Engine (TE))
    每当指定协调器需要进行集群范围的变化(重构新的CIB)，策略引擎用于计算集群的下一个状态和(资源)来实现它需要操作的列表。
    由策略引擎计算出的命令然后由转换引擎执行。
    DC将向集群资源管理器发送相关信息，然后用自己的本地资源管理器(LRM)，进行必要的资源操作。
    PE和TE必须成对运行在DC节点上。

本地资源管理器LRM(Local Resource Manager)
    本地资源管理器调用本地资源代理代表CRM。因此它可以执行启动/停止/监视操作并将结果报告给CRM。
    LRM保留的是本地节点上所有资源相关的信息。

资源层(Resource Layer)

第四和最高层是资源层。资源层包括一个或多​​个资源代理（RA）。
资源代理是一个程序，通常是一个shell脚本，包含启动，停止和监视某种服务（资源）。
最常见的资源代理是LSB初始化脚本。然而，HeartBeat也支持更加灵活和强大的开放式集群架构资源代理API。
提供心跳的代理被写入OCF规范。资源代理只由本地资源管理器调用。
第三方可以在文件系统中定义自己的代理，整合自己的软件到集群中。

3、Heartbeat 3.x组件

在v3版本后，整个heartbeat项目进行了功能拆分，分为不同的子项目来分别进行开发。但是HA实现原理与Heartbeat2.x基本相同，配置也基本一致。在v3版本后，被拆分为heartbeat、pacemaker(心脏起博器)、cluster-glue(集群的贴合器)，架构分离开来了，可以结合其它的组件工作。
Heartbeat 3官方正式发布的首个版本是3.0.2。原来之前的CRM管理由pacemaker来替代，底层message layer依旧可以使用heartbeat v3也可以使用corosync等。 其具体细节本文不做介绍，可单独参考clusterlabs.org。

三、heartbeat集群处理流程

在群集中执行的任意行为将导致整个群集的更改。这些操作包括像添加或删除集群资源或改变资源的限制。当执行这样操作的时候，重要的是要了解集群中会发生什么。

例如，假设需要添加一个集群IP地址资源。要做到这一点，使用的cibadmin命令行工具或Heartbeat GUI工具来修改主CIB。它不要求使用cibadmin命令或在指定协调器上的GUI工具。你可以在集群中的任何节点上使用任何工具，本地的CIB将重放的请求的更改到指定协调器。然后指定协调会复制CIB变化到所有群集节点，并启动转换过程。

在策略引擎和过渡引擎的帮助下，指定协调器获得的一系列需要在集群中完成的步骤，有可能在多个节点上的步骤。指定协调器通过消息层向其他集群资源管理器发送命令。

如果需要的话，其他的群集资源管理使用它们的本地资源管理器来执行资源的修改并返回其结果给指定协调器。一旦指定协调的上的TE推断出在集群中所有必须的操作已成功完成，集群将回到空闲状态并等待进一步事件。

如果任何操作并没有按计划进行，该策略引擎再次调用记录在CIB中的新信息。

当一个服务或节点死亡，同样的事情会发生。指定协调器会被集群一致成员服务（在一个节点死亡）或本地资源管理通知（如遇失败的监视器操作）。指定协调器需要确定将要变更到一个新的群集状态的行为。新的群集状态将由一个新的CIB表示。