HeartBeat的概述
Linux-HA的全称是High-Availability Linux，它是一个开源项目，这个开源项目的目标是：通过社区开发者的共同努力，提供一个增强linux可靠性（reliability）、可用性（availability）和可服务性（serviceability）（RAS）的群集解决方案。
Heartbeat 项目是 Linux-HA 工程的一个组成部分，自1999年开始到现在，发布了众多版本，是目前开源Linux-HA项目最成功的一个例子，它实现了一个高可用集群系统。心跳服务和集群通信是高可用集群的两个关键组件，在 Heartbeat 项目里，由 heartbeat 模块实现了这两个功能：心跳监测部分和资源接管部分。
心跳监测可以通过网络链路和串口进行，而且支持冗 余链路，它们之间相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运 行在对方主机上的资源或者服务。更多关于企业集群运维管理系列的学习文章，请参阅：玩转企业集群运维管理专栏，本系列持续更新中。
Linux-HA的官方网站：http://www.linux-ha.org
HeartBeat的作用
通过HeartBeat，可以将资源（IP以及程序服务等资源）从一台已经故障的计算机快速转移到另一台正常运转的机器上继续提供服务，一般称之为高可用的服务。在实际的生产应用场景中，heartbeat的功能和另一个高可用的开源软件keepalived有很多的相同之处，在我们实际的生产业务中也是有区别的。
Heartbeat的组成
Heartbeat提供了高可用集群最基本的功能，例如，节点间的内部通信方式、集群合作管理机制、监控工具和失效切换功能等。
Heartbeat内部组成，主要分为以下几大部分：
- heartbeat：节点间通信检测模块
- ha-logd：集群事件日志服务
- CCM（Consensus Cluster Membership）：集群成员一致性管理模块
- LRM （Local Resource Manager）：本地资源管理模块
- Stonith Daemon：使出现问题的节点从集群环境中脱离
- CRM（Cluster Resource Management）：集群资源管理模块
- Cluster Policy Engine：集群策略引擎
- Cluster Transition Engine：集群转移引擎
HeartBeat的工作原理
集群成员一致性管理模块（CCM）用于管理集群节点成员，同时管理成员之间的关系和节点间资源的分配，heartbeat模块负责检测主次节点的运行状态，以判断节点是否失效。ha-logd模块用于记录集群中所有模块和服务的运行信息。
本地资源管理器（LRM）负责本地资源的启动，停止和监控，一般由LRM守护进程lrmd和节点监控进程（Stonith Daemon）组成，lrmd守护进程负责节点间的通信，Stonith Daemon通常是一个Fence设备，主要用于监控节点状态，当一个节点出现问题时处于正常状态的节点会通过Fence设备将其重启或关机以释放IP、磁盘等资源，始终保持资源被一个节点拥有，防止资源争用的发生。
集群资源管理模块（CRM）用于处理节点和资源之间的依赖关系，同时，管理节点对资源的使用，一般由CRM守护进程crmd、集群策略引擎和集群转移引擎三个部分组成，集群策略引擎（Cluster policy engine）具体实施这些管理和依赖，集群转移引擎（Cluster transition engine）监控CRM模块的状态，当一个节点出现故障时，负责协调另一个节点上的进程进行合理的资源接管。
在Heartbeat集群中，最核心的是heartbeat模块的心跳监测部分和集群资源管理模块的资源接管部分，心跳监测一般由串行接口通过串口线来实现，两个节点之间通过串口线相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未受到对方发送的报文，那么就认为对方失效，这时资源接管模块将启动，用来接管运行在对方主机上的资源或者服务。
Heartbeat仅仅是个HA软件，它仅能完成心跳监控和资源接管，不会监视它控制的资源或应用程序，要监控资源和应用程序是否运行正常，必须使用第三方的插件，例如ipfail、Mon、Ldirector等。Heartbeat自身包含了几个插件，分别是ipfail、Stonith和Ldirectord，介绍如下：
- ipfail的功能直接包含在Heartbeat里面，主要用于检测网络故障，并作出合理的反应，为了实现这个功能，ipfail使用ping节点或者ping节点组来检测网络连接是否出现故障，从而及时的做出转移措施。
- Stonith插件可以在一个没有响应的节点恢复后，合理接管集群服务资源，防止数据冲突，当一个节点失效后，会从集群中删除，如果不使用Stonith插件，那么失效的节点可能会导致集群服务在多于一个节点运行，从而造成数据冲突甚至是系统崩溃。因此，使用Stonith插件可以保证共享存储环境中的数据完整性。
- Ldirector是一个监控集群服务节点运行状态的插件。Ldirector如果监控到集群节点中某个服务出现故障，就屏蔽此节点的对外连接功能，同时将后续请求转移到正常的节点提供服务，这个插件经常用在LVS负载均衡集群中。
切换的常见条件
- 服务器宕机
- Heartbeat服务本故障
- 中间的连接线路故障
应用服务故障则不会产生切换，可以通过服务宕机把heartbeat服务停掉。更多关于企业集群运维管理系列的学习文章，请参阅：玩转企业集群运维管理专栏，本系列持续更新中。
Heartbeat的心跳连接
讲过上面的描述，要部署heartbeat服务，至少需要两台主机才能完成。那么，要实现高可用服务，这两台主机之间，是如何做到互相通信互相监控的呢？
下面是两台heartbeat主机之间通信的一些常用的可行的方法：
- 串行电缆，即所谓的串口（首选，缺点是距离不能太远）。
- 一根以太网电缆量网口直连（生产环境中常用的方式）。
- 以太网电缆，通过交换机等网络设备连接（次选，原因是增加了故障点，不好排查故障，同时，线路不是专用的心跳线，容易受其他数据传输的影响，导致心跳报文发送问题）。
HeartBeat的消息类型：
heartBeat高可用软件在工作的过程中，一般来说，有三种消息的类型，具体为：
心跳消息
心跳消息为约150字节的数据包，可能为单播，广播或者多播的方式，控制心跳频率以及出现故障要等待多久进行故障转换
集群转换消息
当主服务器恢复在线状态时，通过ip-request消息是要求备机释放主服务器失败时被服务器取得的的资源，然后被服务器关闭是仿主服务器失败时取得的资源以及服务。
备服务器释放主服务器失败时取得的资源以及服务后，就会通过ip-request-resp消息通知主服务器它不在拥有该资源以及服务，主服务器收到来自备节点的ip-request-resp消息通知后，启动失败时释放的资源以及服务，并开始提供正常的访问服务。
重传消息请求
rexmit-request控制重传心跳请求。
提示：以上的心跳控制消息都使用的是UDP协议发送到/etc/ha.d/ha.cf文件指定到任意的端口，或者指定到多播地址。
Heartbeat ip地址接管和故障转移
Heartbeat是通过IP地址接管和ARP广播进行故障转移的。
ARP广播
在主服务器故障的时候，备用节点接管资源后，会强制更新所有的客户端本地的ARP表（即清除客户端本地缓存的失败服务器的VIP地址和mac地址的解析记录）。确保客户端和新的主服务器进行对话。
这提到的客户端机器是和Heartbeat高可用服务器对在同一个网络中的客户机，并不是最终的互联网用户，这里的客户端及其是相对Heartbeat高可用服务器对说的，这点，请注意下。
VIP/IP 别名/辅助IP：
真实IP，又被称为管理IP，一般是配置在物理网卡上的实际IP，这可以看做是你本人的真实姓名，如：张三。在负载均衡以及高可用环境中，管理IP是不会对外提
供用户的访问服务的，而是仅作管理服务器使用，如ssh可以通过这个管理IP连接服务器。
VIP是虚拟的IP，只是个概念而已，可能会误导，实际上就是Heartbeat临时绑在物理网卡上的别名IP，如eth0：x，x为0-255的任意数字，可以在一块网卡上绑。
定多个别名，这样做的好处是当提供服务的服务器宕机之后，在接管的服务器上会直接会自动配置上同样的VIP提供服务。如果使用管理IP的话，来回迁移就难以做到，而且，管理IP迁移过去了我们就不能够登录到这台机器上，这就需要到机房登陆了。VIP的实质就是确保两台服务器有一个管理IP不懂，就是随时可以连上机器。
然后，增加绑定其他的VIP，这样就算VIP转移走了，也不至于服务器本身连不上，因为还有管理的IP呢。更多关于企业集群运维管理系列的学习文章，请参阅：玩转企业集群运维管理专栏，本系列持续更新中。
手工配置VIP的方法
代码语言：javascript复制ifconfig eth0:1 124.42.61.109 netmask 255.255.255.224 up（ip alias） #heartbeat2软件默认是使用这个命令来添加VIP的
ip addr add 10.0.15.1/24 broadcast 10.0.15.255 dev eth1（辅助Ip） #keepalived以及heartbeat3采用的方案添加VIP的
注意：使用ip addr能够查看到包括别名和辅助IP，用ifconfig无法查到辅助IP的配置情况。
手工删除VIP的方法
代码语言：javascript复制ip addr del 10.0.15.1/24 broadcast 10.0.15.255 dev eth1（辅助IP）
ifconfig eth0:1 124.42.61.109 netmask 255.255.255.244 down(ip alias)
Heartbeat的版本与组件
说明：Heartbeat有三个版本分别为Heartbeat v1.x，Heartbeat v2.x，Heartbeat v3.x。Heartbeat v1.x和Heartbeat v2.x版本的组成结构十分简单，所有模块都集中在heartbeat中，到了v3版本后，整个heartbeat项目进行了拆分，分为不同的项目来分别进行开发。
Heartbeat v1.x与v2.x的组件
代码语言：javascript复制heartbeat #节点间通信检测模块
ha-logd #集群事件日志服务
CCM（Consensus Cluster Membership） #集群成员一致性管理模块
LRM （Local Resource Manager） #本地资源管理模块
Stonith Daemon #使出现问题的节点从集群环境中脱离或重启
CRM（Cluster resource management） #集群资源管理模块
Cluster policy engine #集群策略引擎
Cluster transition engine #集群转移引擎（也叫策略执行引擎）
Heartbeat v1.x与Heartbeat v2.x区别：在Heartbeat v2.x中增加了一个新的集群资源管理器crm，在Heartbeat v1.x中的集群资源管理器是haresource，Heartbeat v2.x中为了兼容v1.x保留了haresource，但同时又新增了一个功能更强大的crm资源管理器。crm管理方式有，一种是基于命令行crmsh，一种是基于图形界面的hb_gui。
Heartbeat v3.x的组件
代码语言：javascript复制Heartbeat
#将原来的消息通信层独立为heartbeat项目，新的heartbeat只负责维护集群各节点的信息以及它们之前通信。
Cluster Glue
#相当于一个中间层，它用来将heartbeat和pacemaker关联起来，主要包含2个部分，即为LRM和STONITH。
Resource Agent
#用来控制服务启停，监控服务状态的脚本集合，这些脚本将被LRM调用从而实现各种资源启动、停止、监控等等。
Pacemaker
#也就是Cluster Resource Manager（集群资源管理器，简称CRM），用来管理整个HA的控制中心，客户端通过pacemaker来配置管理监控整个集群。
Pacemaker 提供了多种用户管理接口，分别如下：
- (1).基于命令的管理方式
- Crmsh、pcs
- (2).基于图形界面的管理方式
- Pygui、hawk、LCMC、pcs
Keepalived VS Heartbeat 的选择
两款高可用开源方案：Keepalived和Heartbeat。两者都很流行，但差异还是很大的，现将试用过程中的感受以及相关知识点简单总结一下，供大家选择方案的时候参考。
1）Keepalived使用更简单：从安装、配置、使用、维护等角度上对比，Keepalived都比Heartbeat要简单得多，尤其是Heartbeat2.1.4后拆分成3个子项目，安装、配置、使用都比较复杂，尤其是出问题的时候，都不知道具体是哪个子系统出问题了；而Keepalived只有1个安装文件、1个配置文件，配置文件也简单很多；
2）Heartbeat功能更强大：Heartbeat虽然复杂，但功能更强大，配套工具更全，适合做大型集群管理，而Keepalived主要用于集群倒换，基本没有管理功能；
3）协议不同：Keepalived使用VRRP协议进行通信和选举，Heartbeat使用心跳进行通信和选举；Heartbeat除了走网络外，还可以通过串口通信，貌似更可靠；
4）使用方式基本类似：如果要基于两者设计高可用方案，最终都要根据业务需要写自定义的脚本，Keepalived的脚本没有任何约束，随便怎么写都可以；Heartbeat的脚本有约束，即要支持service
start/stop/restart这种方式，而且Heartbeart提供了很多默认脚本，简单的绑定ip，启动apache等操作都已经有了；
使用建议：优先使用Keepalived，当Keepalived不够用的时候才选择Heartbeat。更多关于企业集群运维管理系列的学习文章，请参阅：玩转企业集群运维管理专栏，本系列持续更新中。
参考链接：https://blog.csdn.net/annita2019/article /details/105865130 https://blog.csdn.net/sj349781 478/article/details/77865621
