Heartbeat使用梳理

在日常的集群系统架构中，一般用到Heartbeat的主要就2种:
1）高可用(High Availability)HA集群, 使用Heartbeat实现，也称为”双机热备”, “双机互备”, “双机”；
2）负载均衡群集(Load Balance Cluster)，使用Linux Virtual Server(LVS)实现;

Heartbeat介绍
Heartbeat项目是Linux-HA工程的一个组成部分，它实现了一个高可用集群系统。心跳服务和集群通信是高可用集群的两个关键组件，在 Heartbeat项目里，由heartbeat模块实现了这两个功能。

Heartbeat几个重要组件：
heartbeat – 节点间通信校验模块
CRM - 集群资源管理模块
CCM - 维护集群成员的一致性
LRM - 本地资源管理模块
StonithDaemon - 提供节点重启服务
logd - 非阻塞的日志记录
apphbd - 提供应用程序级的看门狗计时器
Recovery Manager - 应用故障恢复
底层结构–包括插件接口、进程间通信等
CTS – 集群测试系统，集群压力测试

我们主要分析的是Heartbeat的集群通信机制，所以这里主要关注的是heartbeat模块。
heartbeat模块由以下几个进程构成：
master进程（masterprocess）
FIFO子进程（fifochild）
read子进程（readchild）
write子进程（writechild）
在heartbeat里每一条通信通道对应于一个write子进程和一个read子进程，假设n是通信通道数，p为heartbeat模块的进程数，则p、n有以下关系：
p=2*n+2
在heartbeat里，master进程把自己的数据或者是客户端发送来的数据，通过IPC发送到write子进程，write子进程把数据发送到网络；同时read子进程从网络读取数据，通过IPC发送到master进程，由master进程处理或者由master进程转发给其客户端处理。
Heartbeat启动的时候，由master进程来启动FIFO子进程、write子进程和read子进程，最后再启动client进程。

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

HeartBeat的工作原理
heartbeat最核心的包括两个部分，心跳监测部分和资源接管部分，心跳监测可以通过网络链路和串口进行，而且支持冗 余链路，它们之间相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运行在对方主机上的资源或者服务。
通过修改Heartbeat的软件的配置文件，可以制定那一台Heartbeat服务器作为主服务器，则另一台将自动成为热备服务器。然后在热备服务器上配置Heartbeat守护程序来监听来自主服务器的心跳消息。如果热备服务器在指定时间内为监听到来自主服务器的心跳，就会启动故障转义程序，并取得主服务器上的相关资源服务的所有权，接替主服务器继续不间断的提供服务，从而达到资源以及服务高可用的目的。
以上的描述heartbeat的主备模式，heartbeat还支持主主模式，即两台服务器互为主备，这是他们之间还会互相发送报文来告诉对方自己的当前的状态，如果在指定的时间内未收到对方发送的心跳报文，那么，一方就会认为对方失效或者是已经宕机了，这时每个运行正常的主机就会启动自身的资源接管模块来接管运行在对方主机上的资源或者是服务，继续为用户提供服务。一般情况下，可以较好的实现一台主机故障后，企业业务能够不间断的持续的提供服务（注意：所谓的业务不间断）。
在故障转移期间也是需要切换时间的，heartbeat的切换时间是5-20秒。切换的常见条件：
1）服务器宕机
2）Heartbeat服务本身故障
3）中间的连接线路故障
应用服务故障则不会产生切换，可以通过服务宕机把heartbeat服务停掉。

heartbeat的心跳连接
高可用集群是指一组通过硬件和软件连接起来的独立计算机，它们在用户面前表现为一个单一系统，在这样的一组计算机系统内部的一个或者多个节点停止工作，服务会从故障节点切换到正常工作的节点上运行，不会引起服务中断。从这个定义可以看出，集群必须检测节点和服务何时失效，何时恢复为可用。这个任务通常由一组被称为“心跳”的代码完成。在Linux-HA里这个功能由一个叫做heartbeat的程序完成。
通过上面的描述，要部署heartbeat服务，至少需要两台主机才能完成。那么，要实现高可用服务，这两台主机之间，是如何做到互相通信互相监控的呢？
下面是两台heartbeat主机之间通信的一些常用的可行方法：
1）串行电缆，即所谓的串口（首选，缺点是距离不能太远）
2）一根以太网电缆量网口直连（生产环境中常用的方式）
3）以太网电缆，通过交换机等网络设备连接（次选，原因是增加了故障点，不好排查故障，同时，线路不是专用的心跳线，容易受其他数据传输的影响，导致心跳报文发送问题）

Heartbeat裂脑
什么是裂脑？
由于两台高可用服务器之间在指定的时间内，无法互相检测到对方心跳而各自启动故障转移功能，取得了资源以及服务的所有权，而此时的两台高可用服务器对都还活着并作正常运行，这样就会导致同一个IP湖综合服务在两端同时启动而发生冲突的严重问题，最严重的就是两台主机同时占用一个VIP的地址，当用户写入数据的时候可能会分别写入到两端，这样可能会导致服务器两端的数据不一致或造成数据的丢失，这种情况就本成为裂脑，也有的人称之为分区集群或者大脑垂直分隔

导致裂脑发生的原因：　　
一般来说，裂脑的发生，主要是由以下的几个原因导致的：
1）高可用服务器对之间心跳线路故障，导致无法正常的通信。原因比如：
    1--心跳线本身就坏了（包括断了，老化）；
    2--网卡以及相关驱动坏了,IP配置及冲突问题；
    3--心跳线间连接的设备故障（交换机的故障或者是网卡的故障）；
    4--仲裁的服务器出现问题。
2）高可用服务器对上开启了防火墙阻挡了心跳消息的传输；
3）高可用服务器对上的心跳网卡地址等信息配置的不正确，导致发送心跳失败；
4）其他服务配置不当等原因，如心跳的方式不同，心跳广播冲突，软件出现了BUG等。

防止脑裂发生的方法：
发生脑裂的时候，对业务的影响是及其严重的，有的时候甚至是致命的。
比如：两台高可用的服务器对之间发生脑裂，导致互相竞争同一个IP资源，就如同我们局域网内常见的IP地址冲突一样，两个机器就会有一个或者两个不正常，影响用户正常访问服务器。如果是应用在数据库或者是存储服务这种极重要的高可用上，那就导致用户发布的数据间断的写在两台服务器上的恶果，最终数据恢复及困难或者是难已恢复
实际的生产环境中，我们可以从以下几个方面来防止裂脑的发生：
1）同时使用串行电缆和以太网电缆连接，同时用两条心跳线路，这样一条线路坏了，另一个线路还是好的，依然能传送消息（推荐的）
2）检测到裂脑的时候强行的关闭一个心跳节点（需要特殊的节点支持，如stonith，fence），相当于程序上备节点发现心跳线故障，发送关机命令到主节点。
3）做好对裂脑的监控报警（如邮件以及手机短信等），在问题发生的时候能够人为的介入到仲裁，降低损失。当然，在实施高可用方案的时候，要根据业务的实际需求确定是否能够容忍这样的损失。对于一般的网站业务，这个损失是可控的（公司使用）
4）启用磁盘锁。正在服务一方锁住共享磁盘，脑裂发生的时候，让对方完全抢不走共享的磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的乙方不主动解锁，另一方就永远得不到共享磁盘。现实中介入服务节点突然死机或者崩溃，另一方就永远不可能执行解锁命令。后备节点也就截关不了共享的资源和应用服务。于是有人在HA中涉及了“智能”锁，正在服务的一方只在发现心跳线全部断开时才启用磁盘锁，平时就不上锁了
5）报警报在服务器接管之前，给人员处理留足够的时间就是1分钟内报警了，但是服务器不接管，而是5分钟之后接管，接管的时间较长。数据不会丢失，但就是会导致用户无法写数据。
6）报警后，不直接自动服务器接管，而是由人员接管。
7）增加仲裁的机制，确定谁该获得资源，这里面有几个参考的思路：
    1--增加一个仲裁机制。例如设置参考的IP，当心跳完全断开的时候，2个节点各自都ping一下参考的IP，不同则表明断点就出现在本段，这样就主动放弃竞争，让能够ping通参考IP的一端去接管服务。
    2--通过第三方软件仲裁谁该获得资源，这个在阿里有类似的软件应用

heartbeat配置文件
heartbeat主要的配置文件有3个：
1）认证文件authkeys
2）主配置文件ha.cf
3）资源文件haresources

接下来就重点说一下这3个文件的具体功能以及配置：
1）heartbeat的认证配置文件authkeys，内容如下
    auth 1
    1 crc
    2 sha1 HI!
    3 md5 Hello!
该文件主要是用于集群中两个节点的认证，采用的算法和密钥(如果有的话)在集群中节点上必须相同，目前提供了3种算法：md5,sha1和crc。
其中crc不能够提供认证，它只能够用于校验数据包是否损坏，而sha1,md5需要一个密钥来进行认证，从资源消耗的角度来讲，md5消耗的比较多，sha1次之，因此建议一般使用sha1算法。
如果要采用sha1算法，只需要将authkeys中的auth 指令(去掉注释符)改为2，而对应的2 sha1行则需要去掉注释符(#)，后面的密钥自己改变(两节点上必须相同)。改完之后，保存，同时需要改变该文件的属性为600，否则heartbeat启动将失败。

2）heartbeat的主要配置文件ha.cf
第一个是ha.cf该文件位于在安装后创建的/etc/ha.d目录中。该文件中包括为Heartbeat使用何种介质通路和如何配置他们的信息。在源代码目录中的ha.cf文件包含了您可以使用的全部选项，详述如下：

debugfile /var/log/ha-debug     用于记录heartbeat的调试信息
logfile /var/log/ha-log        用于记录heartbeat的日志信息
如果未定义上述的日志文件，那么日志信息将送往local0(对应的#/var/log/messages)，如果这3个日志文件都未定义，那么heartbeat默认情况下
将在/var/log下建立ha-debug和ha-log来记录相应的日志信息。

keepalive 2        发送心跳报文的间隔，默认单位为秒，如果你毫秒为单位，那么需要在后面跟ms单位，如1500ms即代表1.5s
deadtime 30      用于配置认为对方节点菪掉的间隔
warntime 10      发出最后的心跳警告报文的间隔
initdead 120      网络启动的时间
udpport 694       广播/单播通讯使用的udp端口
bcast eth0 Linux      心跳所使用的网络接口

baud 19200      波特率，串口通信的速度。
udpport 694     使用端口694进行bcast和ucast通信。这是默认的，并且在IANA官方注册的端口号。

mcast eth0 225.0.0.1 694 1 0
如果采用组播通讯，在这里可以设置组播通讯所使用的接口，绑定的组播ip地#址(在224.0.0.0 - 239.255.255.255间)，通讯端口，ttl(time to live)所能经过路由的#跳数，是否允许环回(也就是本地发出的数据包时候还接收)

ucast eth0 192.168.1.2       如果采用单播，那么可以配置其网络接口以及所使用的ip地址
auto_failback on        该选项是必须配置的！用于决定当拥有该资源的属主恢复之后，资源是否变迁：是迁移到属主上，还是在当前节点上继续运行，直到当前节点出现故障。
stonith baytech /etc/ha.d/conf/stonith.baytech        用于共享资源的集群环境中，采用stonith防御技术来保证数据的一致性

watchdog /dev/watchdog       该指令是用于设置看门狗定时器，如果节点一分钟内都没有心跳，那么节点将重新启动
node ken3      设置集群中的节点，注意：节点名必须与uname –n相匹配

node primary.mydomain.com    该选项是必须配置的。集群中机器的主机名，与“uname –n”的输出相同。
node backup.mydomain.com    该选项是必须配置的。同上。
respawn     该选项是可选配置的：列出将要执行和监控的命令。例如：要执行ccm守护进程，则要添加如下的内容：

ping 10.10.10.254
ping指令以及下面的ping_group指令是用于建立伪集群成员，它们必须与下述#的ipfail指令一起使用，它们的作用是监测物理链路，也就是说如果集群节点与上述伪设备不相通，那么该节点也将无权接管资源或服务，它将释放掉资源。

respawn hacluster /usr/lib/heartbeat/ccm
使得Heartbeat以userid（在本例中为hacluster）的身份来执行该进程并监视该进程的执行情况，如果其死亡便重启之。
对于ipfail，则应该是：
respawn hacluster /usr/lib/heartbeat/ipfail
对于pingd则应该是：
respawn hacluster /usr/lib64/heartbeat/pingd -m 100 -d 5s

注意：如果结束进程的退出代码为100，则不会重启该进程。
apiauth pingd gid=haclient uid=hacluster

apiauth client-name gid=gidlist uid=uidlist
apiauth ipfail gid=haclient uid=hacluster 设置你所指定的启动进程的权限

3）heartbeat的资源配置文件haresources
配置好ha.cf文件之后，便是haresources文件。
该文件列出集群所提供的服务以及服务的默认所有者，该文件主要是为部署的集群配置资源或者服务。
注意：两个集群节点上的该文件必须相同。集群的IP地址是该选项是必须配置的，不能在haresources文件以外配置该地址, haresources文件用于指定双机系统的主节点、集群IP、子网掩码、广播地址以及启动的服务等。

它的每一有效行的格式如下：
node-name resource1 resource2 ... resourceN
其中node-name即为集群中某一节点的名称，必须与uname –n相同，
后面的资源组resource1 resource2 …resourceN中每一个资源都是一个shell脚本，它们的搜索路径为/etc/init.d/和/usr/local/etc/ha.d/resource.d(该路径根据你所安装heartbeat的路径有所不同)，heartbeat为我们提供了一个非常好的资源扩展框架，如果我们需要控制一种自己的资源，只需要实现一个支持start和stop参数的shell脚本就可以了，目前heartbeat所支持的资源脚本可以在我提供的上述路径中去查看。

如下配置进行说明：
node-name network-config
其中node-name指定双机系统的主节点，取值必须匹配ha.cf文件中node选项设置的主机名中的一个，node选项设置的另一个主机名成为从节点。network-config用于网络设置，包括指定集群IP、子网掩码、广播地址等。resource-group用于设置heartbeat启动的服务，该服务最终由双机系统通过集群IP对外提供。在本文中我们假设要配置的HA服务为Apache和Samba。
在haresources文件中需要如下内容：
primary.mydomain.com 192.168.85.3 httpd smb
该行指定在启动时，节点linuxha1得到IP地址192.168.85.3，并启动Apache和Samba。在停止时，Heartbeat将首先停止smb，然后停止Apache，最后释放IP地址192.168.85.3。这里假设命令“uname –n”的输出为“primary.mydomain.com”－如果输出为“primary”，便应使用“primary”。
primary.mydomain.com IPaddr::192.168.21.107/24/eth0 drbddisk::r0 Filesystem::/dev/drbd1::/data::ext4 nfs
正确配置好haresources文件之后，将ha.cf和haresource拷贝到/etc/ha.d目录。
注意：资源文件中能执行的命令必须在/etc/ha.d/resource.d/ 中可见