共计 8908 个字符，预计需要花费 23 分钟才能阅读完成。
一、什么是 Heartbeat
Heartbeat 是一个基于 Linux 开源的高可用集群系统。主要包括心跳服务和资源接管两个高可用集群组件。心跳监测服务可以通过网络链路和串口进行，而且支持冗余链路，它们之间相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运行在对方主机上的资源或者服务。
二、HeartBeat 版本
Heartbeat 是一个基于 Linux 开源的高可用集群系统。主要包括心跳服务和资源接管两个高可用集群组件，其重大的版本变更主要分为三个阶段。
1、Heartbeat v1.x
heartbeat v1 版时就有了资源管理的概念，而 v1 版的资源就是 heartbeat 自带的，叫 haresources，这个文件是个配置文件；而这个配置文件接口就叫 haresources；
Heartbeat1.x 允许集群节点和资源通过 /etc/ha.d 目录下面的两个文件来配置
ha.cf：定义集群节点，失效检测和切换时间间隔，集群时间日志机制和节点 Fence 方法
haresources: 定义集群资源组，每一行定义可以一起进行失效切换的一个默认的节点和一组资源，资源包括 IP 地址，文件系统，服务或者应用
2、Heartbeat v2.x
Heartbeat v2 第二版的时候，heartbeat 被做了很大的改进，自己可以做为一个独立进程来运行，并而可以通过它接收用户请求，它就叫 crm，在运行时它需要在各节点上运行一个叫 crmd 的进程，这个进程通常要监听在一个套接字上，端口就是 5560，所以服务器端叫 crmd，而客户端叫 crm(可以称为 crm shell)，是个命令行接口，通过这个命令行接口就可以跟服务器端的 crm 通信了，heartbeat 也有它的图形化界面工具，就叫 heartbeat-GUI 工具，通过这个界面就可以配置进行。
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 标准
当服务失败或者其中设定的标准满足时，需要执行的动作
3、Heartbeat v3.x
在 v3 版本后，整个 heartbeat 项目进行了功能拆分，分为不同的子项目来分别进行开发。但是 HA 实现原理与 Heartbeat2.x 基本相同，配置也基本一致。在 v3 版本后，被拆分为 heartbeat、pacemaker(心脏起博器)、cluster-glue(集群的贴合器)，架构分离开来了，可以结合其它的组件工作。
Heartbeat：将原来的消息通信层独立为 heartbeat 项目，新的 heartbeat 只负责维护集群各节点的信息以及它们之前通信；
Cluster Glue：相当于一个中间层，它用来将 heartbeat 和 pacemaker 关联起来，主要包含 2 个部分，即为 LRM 和 STONITH。
Resource Agent：用来控制服务启停，监控服务状态的脚本集合，这些脚本将被 LRM 调用从而实现各种资源启动、停止、监控等等。
Pacemaker：也就是 Cluster Resource Manager（简称 CRM），用来管理整个 HA 的控制中心，客户端通过 pacemaker 来配置管理监控整个集群。
Heartbeat 3 官方正式发布的首个版本是 3.0.2。原来之前的 CRM 管理由 pacemaker 来替代，底层 message layer 依旧可以使用 heartbeat v3 也可以使用 corosync 等。其具体细节本文不做介绍，可单独参考 clusterlabs.org。
pacemaker 是个资源管理器，不是提供心跳信息的，因为它似乎是一个普遍的误解，也是值得的。pacemaker 是一个延续的 CRM（亦称 Heartbeat V2 资源管理器），最初是为心跳，但已经成为独立的项目。
Pacemaker 核心组件说明：
ccm 组件（Cluster Consensus Menbership Service）：作用，承上启下，监听底层接受的心跳信息，当监听不到心跳信息的时候就重新计算整个集群的票数和收敛状态信息，并将结果转递给上层，让上层做出决定采取怎样的措施，ccm 还能够生成一个各节点状态的拓扑结构概览图，以本节点做为视角，保证该节点在特殊情况下能够采取对应的动作。
crmd 组件（Cluster Resource Manager，集群资源管理器，也就是 pacemaker）：实现资源的分配，资源分配的每个动作都要通过 crm 来实现，是核心组建，每个节点上的 crm 都维护一个 cib 用来定义资源特定的属性，哪些资源定义在同一个节点上。
cib 组件（集群信息基库，Cluster Infonation Base）：是 XML 格式的配置文件，在内存中的一个 XML 格式的集群资源的配置文件，主要保存在文件中，工作的时候常驻在内存中并且需要通知给其它节点，只有 DC 上的 cib 才能进行修改，其他节点上的 cib 都是拷贝 DC 上。配置 cib 文件的方法有，基于命令行配置和基于前台的图形界面配置。
lrmd 组件（Local Resource Manager，本地资源管理器）：用来获取本地某个资源的状态，并且实现本地资源的管理，如当检测到对方没有心跳信息时，来启动本地的服务进程等。
pengine 组件
PE（Policy Engine）：策略引擎，来定义资源转移的一整套转移方式，但只是做策略者，并不亲自来参加资源转移的过程，而是让 TE 来执行自己的策略。
TE（Transition Engine）：就是来执行 PE 做出的策略的并且只有 DC 上才运行 PE 和 TE。
stonithd 组件
STONITH(Shoot The Other Node in the Head，”爆头“)，这种方式直接操作电源开关，当一个节点发生故障时，另 一个节点如果能侦测到，就会通过网络发出命令，控制故障节点的电源开关，通过暂时断电，而又上电的方式使故障节点被重启动，这种方式需要硬件支持。
STONITH 应用案例（主从服务器），主服务器在某一端时间由于服务繁忙，没时间响应心跳信息，如果这个时候备用服务器一下子把服务资源抢过去，但是这个时候主服务器还没有宕掉，这样就会导致资源抢占，就这样用户在主从服务器上都能访问，如果仅仅是读操作还没事，要是有写的操作，那就会导致文件系统崩溃，这样一切都玩了，所以在资源抢占的时候，可以采用一定的隔离方法来实现，就是备用服务器抢占资源的时候，直接把主服务器给 STONITH，就是我们常说的”爆头”。
资源脚本（resource scripts）即 Heartbeat 控制下的脚本。这些脚本可以添加或移除 IP 别名（IP alias)或从属 IP 地址（secondary IP address），或者包含了可以启动 / 停止服务能力之外数据包的处理功能等。通常，Heartbeat 会到 /etc/init.d/ 或 /etc/ha.d/resource.d/ 目录中读取脚本文件。Heartbeat 需要一直明确了解 ” 资源 ” 归哪个节点拥有或由哪个节点提供。在编写一个脚本来启动或停止某个资源时，一定在要脚本中明确判断出相关服务是否由当前系统所提供。
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2015-12/126364p2.htm
三、Pacemaker 特点
- 主机和应用程序级别的故障检测和恢复
- 几乎支持任何冗余配置
- 同时支持多种集群配置模式
- 配置策略处理法定人数损失（多台机器失败时）
- 支持应用启动 / 关机顺序
- 支持，必须 / 必须在同一台机器上运行的应用程序
- 支持多种模式的应用程序（如主 / 从）
- 可以测试任何故障或群集的群集状态
四、Pacemaker 集群的分类
1. 双机热备（Active/Passive）
官方说明：许多高可用性的情况下，使用 Pacemaker 和 DRBD 的双节点主 / 从集群是一个符合成本效益的解决方案。
2. 多节点热备（N+1）
官方说明：支持多少节点，Pacemaker 可以显着降低硬件成本通过允许几个主 / 从群集要结合和共享一个公用备份节点。
3. 多节点共享存储（N-TO-N）
官方说明：有共享存储时，每个节点可能被用于故障转移。Pacemaker 甚至可以运行多个服务。
4. 共享存储热备（Split Site）
官方说明：Pacemaker 1.2 将包括增强简化设立分站点集群
五、Pacemaker 内部结构
群集组件说明：
stonithd：心跳系统。
lrmd：本地资源管理守护进程。它提供了一个通用的接口支持的资源类型。直接调用资源代理（脚本）。
pengine：政策引擎。根据当前状态和配置集群计算的下一个状态。产生一个过渡图，包含行动和依赖关系的列表。
CIB：群集信息库。包含所有群集选项，节点，资源，他们彼此之间的关系和现状的定义。同步更新到所有群集节点。
CRMD：集群资源管理守护进程。主要是消息代理的 PEngine 和 LRM，还选举一个领导者（DC）统筹活动（包括启动 / 停止资源）的集群。
OpenAIS：OpenAIS 的消息和成员层。
Heartbeat：心跳消息层，OpenAIS 的一种替代。
CCM：共识群集成员，心跳成员层。
功能概述
CIB 使用 XML 表示集群的集群中的所有资源的配置和当前状态。CIB 的内容会被自动在整个集群中同步，使用 PEngine 计算集群的理想状态，生成指令列表，然后输送到 DC（指定协调员）。Pacemaker 集群中所有节点选举的 DC 节点作为主决策节点。如果当选 DC 节点宕机，它会在所有的节点上，迅速建立一个新的 DC。DC 将 PEngine 生成的策略，传递给其他节点上的 LRMd（本地资源管理守护程序）或 CRMD 通过集群消息传递基础结构。当集群中有节点宕机，PEngine 重新计算的理想策略。在某些情况下，可能有必要关闭节点，以保护共享数据或完整的资源回收。为此，Pacemaker 配备了 stonithd 设备。STONITH 可以将其它节点“爆头”，通常是实现与远程电源开关。Pacemaker 会将 STONITH 设备，配置为资源保存在 CIB 中，使他们可以更容易地监测资源失败或宕机。
六、heartbeat 心跳传递
HeartBeat 运行于备用主机上的 Heartbeat 可以通过以太网连接检测主服务器的运行状态，一旦其无法检测到主服务器的 ” 心跳 ” 则自动接管主服务器的资源。通常情况下，主、备服务器间的心跳连接是一个独立的物理连接，这个连接可以是串行线缆、一个由 ” 交叉线 ” 实现的以太网连接。Heartbeat 甚至可同时通过多个物理连接检测主服务器的工作状态，而其只要能通过其中一个连接收到主服务器处于活动状态的信息，就会认为主服务器处于正常状态。从实践经验的角度来说，建议为 Heartbeat 配置多条独立的物理连接，以避免 Heartbeat 通信线路本身存在单点故障。
串行电缆：被认为是比以太网连接安全性稍好些的连接方式，因为 hacker 无法通过串行连接运行诸如 telnet、ssh 或 rsh 类的程序，从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。但串行线缆受限于可用长度，因此主、备服务器的距离必须非常短。
以太网连接：使用此方式可以消除串行线缆的在长度方面限制，并且可以通过此连接在主备服务器间同步文件系统，从而减少了从正常通信连接带宽的占用。
基于冗余的角度考虑，应该在主、备服务器使用两个物理连接传输 heartbeat 的控制信息；这样可以避免在一个网络或线缆故障时导致两个节点同时认为自已是唯一处于活动状态的服务器从而出现争用资源的情况，这种争用资源的场景即是所谓的 ” 脑裂 ”（split-brain）或 ”partitioned cluster”。在两个节点共享同一个物理设备资源的情况下，脑裂会产生相当可怕的后果。
七、Heartbeat 控制信息
“ 心跳 ” 信息:（也称为状态信息）仅 150 bytes 大小的广播、组播或多播数据包。可为以每个节点配置其向其它节点通报 ” 心跳 ” 信息的频率，以及其它节点上的 heartbeat 进程为了确认主节点出节点出现了运行等错误之前的等待时间。
集群变动事务（transition）信息：ip-request 和 ip-request-rest 是相对较常见的两种集群变动信息，它们在节点间需要进行资源迁移时为不同节点上 heartbeat 进程间会话传递信息。比如，当修复了主节点并且使其重新 ” 上线 ” 后，主节点会使用 ip-request 要求备用节点释放其此前从因主节点故障而从主节点那里接管的资源。此时，备用节点则关闭服务并使用 ip-request-resp 通知主节点其已经不再占用此前接管的资源。主接点收到 ip-request-resp 后就会重新启动服务。
重传请求：在某集群节点发现其从其它节点接收到的 heartbeat 控制信息 ” 失序 ”（heartbeat 进程使用序列号来确保数据包在传输过程中没有被丢弃或出现错误）时，会要求对方重新传送此控制信息。Heartbeat 一般每一秒发送一次重传请求，以避免洪泛。
上面三种控制信息均基于 UDP 协议进行传送，可以在 /etc/ha.d/ha.cf 中指定其使用的 UDP 端口或者多播地址（使用以太网连接的情况下）。
此外，除了使用 ” 序列号 / 确认 ” 机制来确保控制信息的可靠传输外，Heartbeat 还会使用 MD5 或 SHA1 为每个数据包进行签名以确保传输中的控制信息的安全性。
本文永久更新链接地址：http://www.linuxidc.com/Linux/2015-12/126364.htm
一、什么是 Heartbeat
Heartbeat 是一个基于 Linux 开源的高可用集群系统。主要包括心跳服务和资源接管两个高可用集群组件。心跳监测服务可以通过网络链路和串口进行，而且支持冗余链路，它们之间相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运行在对方主机上的资源或者服务。
二、HeartBeat 版本
Heartbeat 是一个基于 Linux 开源的高可用集群系统。主要包括心跳服务和资源接管两个高可用集群组件，其重大的版本变更主要分为三个阶段。
1、Heartbeat v1.x
heartbeat v1 版时就有了资源管理的概念，而 v1 版的资源就是 heartbeat 自带的，叫 haresources，这个文件是个配置文件；而这个配置文件接口就叫 haresources；
Heartbeat1.x 允许集群节点和资源通过 /etc/ha.d 目录下面的两个文件来配置
ha.cf：定义集群节点，失效检测和切换时间间隔，集群时间日志机制和节点 Fence 方法
haresources: 定义集群资源组，每一行定义可以一起进行失效切换的一个默认的节点和一组资源，资源包括 IP 地址，文件系统，服务或者应用
2、Heartbeat v2.x
Heartbeat v2 第二版的时候，heartbeat 被做了很大的改进，自己可以做为一个独立进程来运行，并而可以通过它接收用户请求，它就叫 crm，在运行时它需要在各节点上运行一个叫 crmd 的进程，这个进程通常要监听在一个套接字上，端口就是 5560，所以服务器端叫 crmd，而客户端叫 crm(可以称为 crm shell)，是个命令行接口，通过这个命令行接口就可以跟服务器端的 crm 通信了，heartbeat 也有它的图形化界面工具，就叫 heartbeat-GUI 工具，通过这个界面就可以配置进行。
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 标准
当服务失败或者其中设定的标准满足时，需要执行的动作
3、Heartbeat v3.x
在 v3 版本后，整个 heartbeat 项目进行了功能拆分，分为不同的子项目来分别进行开发。但是 HA 实现原理与 Heartbeat2.x 基本相同，配置也基本一致。在 v3 版本后，被拆分为 heartbeat、pacemaker(心脏起博器)、cluster-glue(集群的贴合器)，架构分离开来了，可以结合其它的组件工作。
Heartbeat：将原来的消息通信层独立为 heartbeat 项目，新的 heartbeat 只负责维护集群各节点的信息以及它们之前通信；
Cluster Glue：相当于一个中间层，它用来将 heartbeat 和 pacemaker 关联起来，主要包含 2 个部分，即为 LRM 和 STONITH。
Resource Agent：用来控制服务启停，监控服务状态的脚本集合，这些脚本将被 LRM 调用从而实现各种资源启动、停止、监控等等。
Pacemaker：也就是 Cluster Resource Manager（简称 CRM），用来管理整个 HA 的控制中心，客户端通过 pacemaker 来配置管理监控整个集群。
Heartbeat 3 官方正式发布的首个版本是 3.0.2。原来之前的 CRM 管理由 pacemaker 来替代，底层 message layer 依旧可以使用 heartbeat v3 也可以使用 corosync 等。其具体细节本文不做介绍，可单独参考 clusterlabs.org。
pacemaker 是个资源管理器，不是提供心跳信息的，因为它似乎是一个普遍的误解，也是值得的。pacemaker 是一个延续的 CRM（亦称 Heartbeat V2 资源管理器），最初是为心跳，但已经成为独立的项目。
Pacemaker 核心组件说明：
ccm 组件（Cluster Consensus Menbership Service）：作用，承上启下，监听底层接受的心跳信息，当监听不到心跳信息的时候就重新计算整个集群的票数和收敛状态信息，并将结果转递给上层，让上层做出决定采取怎样的措施，ccm 还能够生成一个各节点状态的拓扑结构概览图，以本节点做为视角，保证该节点在特殊情况下能够采取对应的动作。
crmd 组件（Cluster Resource Manager，集群资源管理器，也就是 pacemaker）：实现资源的分配，资源分配的每个动作都要通过 crm 来实现，是核心组建，每个节点上的 crm 都维护一个 cib 用来定义资源特定的属性，哪些资源定义在同一个节点上。
cib 组件（集群信息基库，Cluster Infonation Base）：是 XML 格式的配置文件，在内存中的一个 XML 格式的集群资源的配置文件，主要保存在文件中，工作的时候常驻在内存中并且需要通知给其它节点，只有 DC 上的 cib 才能进行修改，其他节点上的 cib 都是拷贝 DC 上。配置 cib 文件的方法有，基于命令行配置和基于前台的图形界面配置。
lrmd 组件（Local Resource Manager，本地资源管理器）：用来获取本地某个资源的状态，并且实现本地资源的管理，如当检测到对方没有心跳信息时，来启动本地的服务进程等。
pengine 组件
PE（Policy Engine）：策略引擎，来定义资源转移的一整套转移方式，但只是做策略者，并不亲自来参加资源转移的过程，而是让 TE 来执行自己的策略。
TE（Transition Engine）：就是来执行 PE 做出的策略的并且只有 DC 上才运行 PE 和 TE。
stonithd 组件
STONITH(Shoot The Other Node in the Head，”爆头“)，这种方式直接操作电源开关，当一个节点发生故障时，另 一个节点如果能侦测到，就会通过网络发出命令，控制故障节点的电源开关，通过暂时断电，而又上电的方式使故障节点被重启动，这种方式需要硬件支持。
STONITH 应用案例（主从服务器），主服务器在某一端时间由于服务繁忙，没时间响应心跳信息，如果这个时候备用服务器一下子把服务资源抢过去，但是这个时候主服务器还没有宕掉，这样就会导致资源抢占，就这样用户在主从服务器上都能访问，如果仅仅是读操作还没事，要是有写的操作，那就会导致文件系统崩溃，这样一切都玩了，所以在资源抢占的时候，可以采用一定的隔离方法来实现，就是备用服务器抢占资源的时候，直接把主服务器给 STONITH，就是我们常说的”爆头”。
资源脚本（resource scripts）即 Heartbeat 控制下的脚本。这些脚本可以添加或移除 IP 别名（IP alias)或从属 IP 地址（secondary IP address），或者包含了可以启动 / 停止服务能力之外数据包的处理功能等。通常，Heartbeat 会到 /etc/init.d/ 或 /etc/ha.d/resource.d/ 目录中读取脚本文件。Heartbeat 需要一直明确了解 ” 资源 ” 归哪个节点拥有或由哪个节点提供。在编写一个脚本来启动或停止某个资源时，一定在要脚本中明确判断出相关服务是否由当前系统所提供。
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2015-12/126364p2.htm
