Heartbeat介绍

一、 Heartbeat作用
通过它可以将资源（IP及程序服务等资源）从一台故障计算机快速转移到另一台运转正常的机器继续提供服务，在实际生产应用场景中，heartbeat的功能和另一个高可用开源软件keepalived有很多相同之处。

二、 Heartbeat工作原理
通过修改配置文件，指定哪一台Heartbeat服务器作为主服务器，则另一台将自动成为备份服务器。然后在指定备份服务器上配置Heartbeat守护进程来监听来自主服务器的心跳。如果备份服务器在指定时间内未监听到来自主服务器的心跳，就会启动故障转移程序，并取得主服务器上的相关资源服务所有权，接替主服务器继续不间断的提供服务，从而达到资源服务高可用性的目的。
以上描述的是Heartbeat主备的模式，Heartbeat还支持主主模式，即两台服务器互为主备，这时它们之间会相互发送报文来告诉对方自己当前的状态，如果在指定的时间内为收到对方发送的心跳报文，那么久认为对方失效或者宕机了，这时就会启动自身的资源接管模块来接管运行在对方主机上的资源或者服务，继续对用户提供服务。正常情况下，可以较好的实现主机故障后，业务仍不间断的持续运行。
keepalived主要控制IP飘移，配置应用简单，而且分层，layer3，4，5，各自配置极为简单。heartbeat不但可以控制IP飘移，更擅长对资源服务的控制，配置，应用比较复杂。lvs的高可用建议用keepavlived；业务的高可用用heartbeat。

三、可靠消息通信
Heartbeat通过插件技术实现了集群间的串口、多播、广播和组播通信，在配置的时候可以根据通信媒介选择采用的通信协议，heartbeat启动的时候检查这些媒介是否存在，如果存在则加载相应的通信模块。这样开发人员可以很方便地添加新的通信模块，比如添加红外线通信模块。
对于高可用集群系统，如果集群间的通信不可靠，那么很明显集群本身也不可靠。Heartbeat采用UDP协议和串口进行通信，它们本身是不可靠的，可靠性必须由上层应用来提供。那么怎样保证消息传递的可靠性呢？
Heartbeat通过冗余通信通道和消息重传机制来保证通信的可靠性。Heartbeat检测主通信链路工作状态的同时也检测备用通信链路状态，并把这一状态报告给系统管理员，这样可以大大减少因为多重失效引起的集群故障不能恢复。例如，某个工作人员不小心拨下了一个备份通信链路，一两个月以后主通信链路也失效了，系统就不能再进行通信了。通过报告备份通信链路的工作状态和主通信链路的状态，可以完全避免这种情况。因为这样在主通信链路失效以前，就可以检测到备份工作链路失效，从而在主通信链路失效前修复备份通信链路。
Heartbeat通过实现不同的通信子系统，从而避免了某一通信子系统失效而引起的通信失效。最典型的就是采用以太网和串口相结合的通信方式。这被认为是当前的最好实践，有几个理由可以使我们选择采用串口通信：
（1）IP通信子系统的失效不太可能影响到串口子系统。
（2）串口不需要复杂的外部设备和电源。
（3）串口设备简单，在实践中非常可靠。
（4）串口可以非常容易地专用于集群通信。
（5）串口的直连线因为偶然性掉线事件很少。
不管是采用串口还是以太网IP协议进行通信，heartbeat都实现了一套消息重传协议，保证消息包的可靠传递。实现消息包重传有两种协议，一种是发送者发起，另一种是接收者发起。
对于发送者发起协议，一般情况下接收者会发送一个消息包的确认。发送者维护一个计时器，并在计时器到时的时候重传那些还没有收到确认的消息包。这种方法容易引起发送者溢出，因为每一台机器的每一个消息包都需要确认，使得要发送的消息包成倍增长。这种现像被称为发送者（或者ACK）内爆（implosion）。
对于接收者发起协议，采用这种协议通信双方的接收者通过序列号负责进行错误检测。当检测到消息包丢失时，接收者请求发送者重传消息包。采用这种方法，如果消息包没有被送达任何一个接收者，那么发送者容易因NACK溢出，因为每个接收者都会向发送者发送一个重传请求，这会引起发送者的负载过高。这种现像被称为NACK内爆（implosion）。
Heartbeat实现的是接收者发起协议的一个变种，它采用计时器来限制过多的重传，在计时器时间内限制接收者请求重传消息包的次数，这样发送者重传消息包的次数也被相应的限制了，从而严格的限制了NACK内爆。

四、Heartbeat的心跳连接
要部署Heartbeat服务至少需要两台之际来完成。那么这两台主机之间是如何做到互相通信和互相监测的呢？
1）串行电缆（首选，缺点是距离不能太远）。
2）一根以太网电缆两网卡（推荐）。
3）以太网电缆，通过交换机等网络设备连接（次选）。
次选，增加了交换机故障端，同时，线路不是专用心跳线，容易受其他数据传输的影响。

五、Heartbeat裂脑
1）什么是裂脑？
由于两台搞科研服务器对之间在指定时间内，无法互相检查到对法心跳而各自启动故障转移功能，取得了资源及服务的所有权，而此时的两台高可用服务器对都还活着并在正常运行，这样就会导致同一个IP或服务器在两端同时启动而发生冲突的严重问题，最严重的事故两台主机占用一个IP地址，这样会导致两端的数据不一致或造成数据丢失，这种情况被称为裂脑，也有人称其为分区集群或大脑垂直分割，英文为spilt brain。

2）导致裂脑发生的多种原因
一般来说，裂脑的发生，有以下几个原因导致：
A 高可用服务器对之间心跳链路故障，导致无法正常通信。
B 高可用服务器对上开启了防火墙阻挡了心跳消息传输。
C 高可用服务器对上心跳网卡抵制等信息配置不正确，导致发送心跳失败。
D 其他服务配置不宕机等原因，如心跳方式不同，心跳广播冲突，软件BUG等。

3）防止裂脑发生的8种秘籍
A.同时使用串行电缆和以太网电缆连接，同时用两条心跳线路，这样一条线路坏了，另一条还是好的，依然能传送心跳消息。
B.检测到裂脑时强行关闭一个心跳节点。相当于程序上备节点发现心跳线故障，发送关机命令到主节点。
C.做好裂脑的监控报警（如邮件及手机短信等），在问题发生时人为第一时间介入仲裁，降低损失。
D.启用磁盘锁。正在服务一方锁住共享磁盘，“裂脑”发生时，让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动解锁，另一方就永远得不到共享磁盘。现实中假如服务器节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了‘智能’锁。即，正在服务的一方只在发现心跳线全部断开时才启用磁盘锁。平时就不上锁。
E.报警在服务器接管之前，给人员处理留足够的时间。
F.不直接自动服务器接管，而是由人为人员控制接管。
G.增加仲裁机制，确定谁该获得资源。
例如：设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下参考IP，不同则表明断点就处在本端，不仅心跳线、还有对外服务的本地网络链路断了，这样就主动放弃竞争，让能够ping通参考IP的一段去接管服务。ping不通参考IP的一方可以自我重启，以彻底释放有可能还占用着的那些共享资源。

六、Heartbeat消息类型
Heartbeat软件在工作过程中，一般来说，有三种消息类型，具体为
1）心跳消息
心跳消息为约150字节的数据包，可能为单播、广播或多播的方式，控制心跳频率及出现故障要等待多久进行故障转换
2）集群转换消息
ip-request和ip-request-resp
当主服务器恢复在线状态时，通过ip-request消息要求备机释放主服务器失败时备服务器取得的资源，然后备份服务器关闭释放主服务器失败时取得的资源及服务
备服务器释放主服务器失败时取得的资源及服务后，就会通过ip-request-resp消息通知主服务器它不在拥有该资源及服务，主服务器收到来自备节点的ip-request-resp消息通知后，启动失败时释放的资源及服务，并开始提供正常的访问服务
3）重传请求

七、Heartbeat IP地址接管和故障转移
Heartbeat是通过IP地址接管和ARP广播进行故障转移的
ARP广播：在主服务器故障时，备用节点接管资源后，会立即强制更新所有客户端本地的ARP表（即清除客户端本地缓存的失败服务器的vip地址和mac地址的解析记录）。确保客户端和新的主服务器对话。
ifconfig eth0:1 192.168.1.181 netmask 255.255.255.224 up (ip alias)
====>heartbeat软件默认是使用这个命令来添加VIP的
ip addr add 192.168.1.181/24 broadcast 192.168.1.255 dev eth1 (辅助ip)
====>keepalived软件默认使用这个命令来添加VIP

八、Heartbeat的版本与组件
说明：Heartbeat有三个版本分别为Heartbeat v1.x，Heartbeat v2.x，Heartbeat v3.x。Heartbeat v1.x和Heartbeat v2.x版本的组成结构十分简单，所有模块都集中在heartbeat中，到了v3版本后，整个heartbeat项目进行了拆分，分为不同的项目来分别进行开发。
1、Heartbeat v1.x与v2.x的组件
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。

2、Heartbeat v3.x的组件
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

八、Heartbeat脚本的默认目录
/etc/init.d/
/etc/ha.d/resource.d/
Heartbeat配置文件
Heartbeat的默认配置文件目录为/etc/ha.d。Heartbeat常用的配置文件有三个，ha.cf、authkey、haresource

配置名称 作用 备注
Ha.cf Heartbeat参数配置文件 在这里配置heartbeat的一些基本参数
Authkey Heartbeat认证文件 高可用服务器对之间根据对端的authkey,对对端进行认证
Haresource Heartbeat资源配置文件 如配置IP资源及脚本程序等

1、下面对ha.cf文件的每个选项进行详细介绍
logfile /var/log/ha-log 指名heartbeat的日志存放位置
crm yes 是否开启Cluster Resource Manager（集群资源管理）功能
bcast eth1 指明心跳方式使用以太广播方式，并且是在eth1接口上进行广播
keepalive 2 指定心跳间隔时间为2秒（即每两秒钟在eth1上发送一次广播）
deadtime 30 指定备用节点在30秒内没有收到主节点的心跳信号后，则立即接管主节点的服务资源
warntime 10 指定心跳延迟的时间为十秒。当10秒钟内备份节点不能接收到主节点的心跳信号时，就会往日志中写入一个警告日志，但此时不会切换服务。
initdead 120 在某些系统上，系统启动或重启之后需要经过一段时间网络才能正常工作，该选项用于解决这种情况产生的时间间隔。取值至少为deadtime的两倍。
udpport 694 设置广播通信使用的端口，694为默认使用的端口号
baud 19200 设置串行通信的波特率。
serial /dev/ttyS0 选择串行通信设备，用于双机使用串口线连接的情况。如果双机使用以太网连接，则应该关闭该选项。
auto_failback on 用来定义当主节点恢复后，是否将服务自动切回，heartbeat的两台主机分别为主节点和备份节点。主节点在正常情况下占用资源并运行所有的服务，遇到故障时把资源交给备份节点并由备份节点运行服务。在该选项设为on的情况下，一旦主节点恢复运行，则自动获取资源并取代备份节点，如果该选项设置为off，那么当主节点恢复后，将变为备份节点，而原来的备份节点成为主节点。
Stonith baytech /etc/ha.d/conf/stonith.baytech stonith的主要作用是使出现问题的节点从集群环境中脱离，进而释放集群资源，避免两个节点争用一个资源的情形发生。保证共享数据的安全性和完整性。
watchdog /dev/watchdog 该选项是可选配置，是通过Heartbeat来监控系统的运行状态。使用该特性，需要在内核中载入”softdog”内核模块，用来生成实际的设备文件，如果系统中没有这个内核模块，就需要指定此模块，重新编译内核。编译完成输入”insmod softdog”加载该模块。然后输入”grep misc /proc/devices”(应为10)，输入”cat /proc/misc |grep watchdog”(应为130)。最后，生成设备文件：”mknod /dev/watchdog c 10 130” 。即可使用此功能。

node node1 主节点主机名，可以通过命令“uanme –n”查看。
node node2 备用节点主机名。
ping 192.168.60.1 选择ping的节点，ping 节点选择的越好，HA集群就越强壮，可以选择固定的路由器作为ping节点，但是最好不要选择集群中的成员作为ping节点，ping节点仅仅用来测试网络连接。
respawn hacluster /usr/lib/heartbeat/ipfail 该选项是可选配置，列出与heartbeat一起启动和关闭的进程，该进程一般是和heartbeat集成的插件，这些进程遇到故障可以自动重新启动。最常用的进程是ipfail，此进程用于检测和处理网络故障，需要配合ping语句指定的ping node来检测网络的连通性。其中hacluster表示启动ipfail进程的身份。

2、资源文件(/etc/ha.d/haresources)
Haresources文件用于指定双机系统的主节点、集群IP、子网掩码、广播地址以及启动的服务等集群资源，文件每一行可以包含一个或多个资源脚本名，资源之间使用空格隔开，参数之间使用两个冒号隔开，在两个HA节点上该文件必须完全一致，此文件的一般格式为：
node-name network
node-name表示主节点的主机名，必须和ha.cf文件中指定的节点名一致，network用于设定集群的IP地址、子网掩码、网络设备标识等，需要注意的是，这里指定的IP地址就是集群对外服务的IP地址，resource-group用来指定需要heartbeat托管的服务，也就是这些服务可以由heartbeat来启动和关闭，如果要托管这些服务，必须将服务写成可以通过start/stop来启动和关闭的脚步，然后放到/etc/init.d/或者/etc/ha.d/resource.d/目录下，heartbeat会根据脚本的名称自动去/etc/init.d或者/etc/ha.d/resource.d/目录下找到相应脚步进行启动或关闭操作。

3．认证文件(/etc/ha.d/authkeys)
authkeys文件用于设定heartbeat的认证方式，共有三种可用的认证方式：crc、md5和sha1，三种认证方式的安全性依次提高，但是占用的系统资源也依次增加。如果heartbeat集群运行在安全的网络上，可以使用crc方式，如果HA每个节点的硬件配置很高，建议使用sha1，这种认证方式安全级别最高，如果是处于网络安全和系统资源之间，可以使用md5认证方式。这里我们使用crc认证方式，设置如下：
auth 1
1 crc

#2 sha1 sha1_any_password
#3 md5 md5_any_password

需要说明的一点是：无论auth后面指定的是什么数字，在下一行必须作为关键字再次出现，例如指定了“auth 6”，下面一定要有一行“6 认证类型”。
最后确保这个文件的权限是600（即-rw——-）。