Heartbeat工作原理及其部署需求（一）

一：Heartbeat介绍

1.1 Heartbeat简介

Heartbeat是一款开源提供高可用（Highly-Available）服务的软件，通过Heartbeat可以将资源（IP及程序服务等资源）从一台已经故障的计算机快速转移到另一台可以正常运转的机器上继续提供服务，一般称之为高可用服务。在实际生产应用场景中，heartbeat的功能和keepalived有很多相同之处，但在生产中，对实际的业务应用也是有区别的。如：keepalived主要是控制ip的漂移，配置、应用简单，而heartbeat则不但可以控制ip漂移，更擅长对资源服务的控制，配置、应用比较复杂。

1.2 Heartbeat工作原理

通过修改Heartbeat的配置文件，可以指定哪台Heartbeat服务器作为主服务器，则另一台服务器自动成为热备服务器，然后在热备服务器上配置Heartbeat守护程序来监听来自主服务器的心跳消息。如果热备服务器在指定的时间内未监听到来自主服务器的心跳，就会启动故障转移程序，并取得主服务器上的相关资源服务的所有权，接替主服务器继续不间断的提供服务，从而达到资源及服务高可用性的目的。
    以上描述是heartbeat主备的模式，heartbeat还支持主主模式，即两台服务器互为主备，这时它们之间会相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未收到对方发送的心跳报文，那么，一方就会认为对方失效或者宕机了，这每个运行正常的主机就会启动自身的资源接管模块来接管运行在对方主机上的资源或者服务，继续为用户提供服务。一般情况下，可以较好的实现一台主机故障后，企业业务仍能不间断的持续运行。注意：所谓的业务不间断，在故障转移期间也是需要切换时间的<例如：停止数据库及存储服务等>heartbeat的主备高可用的切换时间一般是在5-20秒左右(服务器宕机的切换比人工切换要快)
    另外，和keepalived高可用软件一样，heartbeat高可用是操作系统级别的，不是服务（软件）级别的，可以通过简单的脚本控制，实现服务级别的高可用
   高可用服务器切换的常见场景：
    1）主服务器物理宕机（硬件损坏，操作系统故障），主要解决目标
    2）Heartbeat服务软件本身故障
    3）两台主备服务器之间心跳连接故障
    服务故障不会导致切换，可以通过服务宕机把heartbeat服务停掉

1.3 Heartbeat心跳连接

要部署heartbeat服务，至少需要两台主机来完成，那么，要实现高可用服务，这两台主机之间是如何做到互相通信和互相监测的呢？

下面是两台heartbeat主机之间通信的一些常用可行方法：
    1）利用串行电缆，即所谓的串口线连接两台服务器
    2）一根以太网电缆两网卡直连
    3）以太网电缆，通过交换机等网络设备连接（不推荐）

如何为高可用服务器端选择心跳通信方案？

1）串口线信号不好和以太网网络交集，也不需要单独配置IP地址等信息，因此传输稳定不容易出现问题，使用串口线的缺点是两个服务器之间的距离不能太远，串口线对应服务端设备为/dev/ttvS0
    高可用方案一般都在同一局域网内，跨越公网没法用
    2）使用以太网网线（无需特殊的交叉线）直连网卡的方式，配置也比较简单，只需对这两块直连网线的网卡配好独立的IP段地址能够互相通信即可，普通网线就可以
    3）使用联网以太网网线和网卡作为心跳线是次选方案，因为这个链路增加了交换机设备这样的故障点，且这个线路不是专用心跳线路，容易受以太网其他数据传输的影响，导致心跳报文发送延迟或者无法送达的问题
    生产中经常采用串口线和以太网线直连搭配使用

hearbeat心跳类型：

heartbeat集群心跳可以在/etc/ha.d/ha.cf文件中进行配置，心跳类型有4种

① 串口

serial 串口名称
serial /dev/ttyS0     # Linux
serial /dev/cuaa0     # FreeBSD
serial /dev/cuad0     # FreeBSD 6.x
serial /dev/cua/a   # Solaris

②广播

广播heartbeats的接口
bcast eth0             # Linux
bcast eth1 eth2     # Linux
bcast le0               # Solaris
bcast le1 le2         # Solaris

③多播

设置一个多播心跳介质
mcast [dev] [mcast group] [port] [ttl] [loop]
    [dev]发送/接收heartbeats的设备
    [mcast group]加入到的多播组（D类多播地址224.0.0.0 - 239.255.255.255）
    [port]端口用于发送/接收udp（设置这个值跟上面的udpport为相同值）
    [ttl]外流的heartbeats的ttl值。这个影响多播包能传播多远。（0-255）必须要大于0。
    [loop]为多播heartbeat开关loopback。如果enabled，一个外流的包将被回环到原处并由发送它的接口接收。（0或者1）设置这个值为0。
mcast eth1 225.0.0.10 694 1 0

④单播

配置一个unicast / udp heartbeat介质
ucast [dev] [peer-ip-addr]
    [dev]用于发送/接收heartbeat的设备
    [peer-ip-addr]包被发送到的对端的IP地址
ucast eth0 172.10.25.27

选择方案小结：

1、和数据相关的业务，要求较高，可以串口和网线直连的方式并用
    2、WEB相关的业务可以选择串口，网线直连或者联网的方式使用

1.4 Heartbeat脑裂

什么是脑裂？

在“双机热备”高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障，2个节点上的HA软件像“裂脑人”一样，“本能”地争抢“共享资源”、争起“应用服务”，就会发生严重后果：或者共享资源被瓜分、2边“服务”都起不来了；或者2边“服务”都起来了，但同时读写“共享存储”，导致数据损坏（常见如数据库轮询着的联机日志出错）。

脑裂发生的原因？

A：高可用服务之间的心跳线路故障，导致无法正常通信
        1）心跳线坏了（断了或者老化）
        2）网卡及相关驱动坏了，IP配置及冲突问题（网卡直连）
        3）心跳线之间连接的设备故障（网卡及交换机）
        4）仲裁的机器出问题（仲裁方案）
    B：高可用服务器上开启了如iptables防火墙阻挡了心跳消息传输
    C：高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败
    D：其他服务配置不当等原因，如心跳方式不同，心跳广播冲突，软件bug等
提示：另外keepalived配置如果virtual_router_id参数，两端配置不一致，也会导致脑裂问题

防止脑裂发生的方案：

1）同时使用串行电缆和以太网电缆连接，同时使用两条心跳线路（网卡设备和网线设备）
    2）当检测到脑裂时强行关闭一个心跳节点（这个功能需特殊设备支持，如stonith、fence），相当于程序上备节点发现心跳线故障，发送关机命令到主节点（银行）
    3）做好脑裂的监控报警（如邮件及手机短信，值班），在问题发生时人为第一时间介入仲裁，降低损失。百度的报警监控是上行和下行。人工交互的过程。当然在实施高可用方案时，要根据业务实际需要确定是否能容忍这样的损失。对于一般的网站常规业务，这个损失是可控的
    4）启用磁盘锁。正在服务一方锁住共享磁盘，脑裂发生时，让对方完全抢不走共享资源，但使用锁磁盘也会有个问题，如果占用共享盘的一方不主动解锁，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了智能锁即，正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁，平时就不上锁，此功能适合共享场景
    5）报警报在服务器接管之前，给人员处理留足够的时间，就是1分钟内报警了，但是服务器不接管，而是5分钟之后接管，接管的时间较长。数据不会丢失，但就是会导致用户无法写数据。
    6）报警后，不直接自动服务器接管，而是由人员接管。
    7）增加仲裁的机制，确定谁该获得资源，这里面有几个参考的思路：
        a）增加一个仲裁机制。例如设置参考的IP，当心跳完全断开的时候，2个节点各自都ping一下参考的IP，不同则表明断点就出现在本段，这样就主动放弃竞争，让能够ping通参考IP的一端去接管服务
        b）通过第三方软件仲裁谁该获得资源，这个在阿里有类似的软件应用

小结：如何写脚本判断出现脑裂

1）简单判断，只要备节点出现VIP就报警（a.主机宕机了，备机接管了。b.主机没有宕，脑裂了），不管哪种情况，人工查看
    2）严谨判断，备机出现VIP,并且主机及服务还活着，，脑裂了

有关fence设备和仲裁机制

fence只是HA集群环境下的术语，在硬件领域，fence设备其实就是一个智能电源管理设备（IPMI）或远程管理卡，fence有外部fence和内部fence(插在服务器里)，不管是内部还是外部fence,这些设备都是带有以太网口的，用来在HA切换触发时通过网络重启提供资源服务的服务器
    内部fence:
    IBM：RSA,RSAII
    HP:ILO,ILO2
    DELL:iDRAC,iDRAC3
    外部fence设备：
    APC

Stonith概述

stonith是“shoot the other node in the head”的首字母简写，它是Heartbeat软件包的一个组件，它允许使用一个远程或“智能的”连接到健康服务器的电源设备自动重启失效服务器的电源，stonith设备可以关闭电源并响应软件命令，运行Heartbeat的服务器可以通过串口线或网线向stonith设备发送命令，它控制高可用服务器对中其他服务器的电力供应，换句话说，主服务器可以复位备用服务器的电源，备用服务器也可以复位主服务器的电源。
注意：尽管理论上连接到远程或“智能的”循环电源系统的电力设备的数量是没有限制的，但大多数stonith实现只使用两台服务器，因为双服务器stonith配置是最简单的，最容易理解，它能够长时间运行且不会降低系统的可靠性和高可用性

Stonith事件触发工作步骤：

1）、当备用服务器听不到心跳时Stontih事件开始。
    注意：这并不一定意味着主服务器没有发送心跳，心跳可能有多种原因而没有抵达备用服务器，这就是为什么建议至少需要两条物理路径传输心跳以避免出现假象的原因了。
    2）、备用服务器发出一个Stonith复位命令到Stonith设备。
    3）、Stonith设备关闭主服务器的电力供应。
    4）、一经切断主服务器的电源，它就不能再访问集群资源，也不能再为客户端提供资源，保证客户端计算机不能访问主服务器上的资源，排除可能发生的头脑分裂状态。
    5）、然后备用服务器获得主服务器的资源，Heartbeat用start参数运行资源脚本，并执行ARP欺骗广播以便客户端计算机发送它们的请求到它的网络接口上。

1.5 Heartbeat消息类型

Heartbeat在工作过程中，一般来说，有三种消息类型
    1)心跳消息
    2）集群转换消息
    3）重传请求

心跳消息

心跳消息为约150字节的数据包，可能为单播，广播或多播的方式，控制心跳频率及出现故障要等待多久进行故障切换

集群转换消息

ip-request和ip-request-resp
    当主服务器恢复在线状态时，通过ip-request消息要求备机释放主服务器失败时备服务器取得的资源，然后备服务器关闭释放主服务器失败时取得的资源及服务
    备服务器释放主服务器失败时取得的资源及服务后，就会通过ip-request-resp消息通知主服务器它不再拥有该资源及服务，主服务器收到来自备节点的ip-request-resp消息通知后，启动失败时释放的资源及服务，并开始提供正常的访问服务

重传请求

rexmit-request控制重传心跳请求，此消息不太重要
提示：以上心跳控制消息都使用UDP协议发送到/etc/ha.d/ha.cf文件指定的任意端口，或指定的多播地址

1.6 Heartbeat IP地址接管和故障转移

Heartbeat是通过IP地址接管和ARP广播进行故障转移的
ARP广播：在主服务器故障时，备用节点接管资源后，会立即强制更新所有客户端本地的ARP表，（即清除客户端本地缓存的失败服务器的vip地址和mac地址的解析记录）确保客户端和新的主服务器对话。

1.7 VIP/IP 别名/辅助IP

真实IP,又称为管理IP,一般是配置在物理网卡上的实际IP,在负载均衡及高可用环境中，管理IP是不对外提供用户访问服务的，仅是管理服务器用，如ssh可以通过这个管理ip连接服务器
    VIP是虚拟IP,实际上就是heartbeat临时绑定在物理网卡上的别名IP(heartbeat3以上也采用了辅助IP),如eth0:x,x为0-255的任意数字，你可以在一块网卡上绑定多个别名，这个VIP可以看作是你的网名。在实际生产环境中，需要把DNS配置中把网站域名地址解析到这个VIP地址，由VIP对用户提供服务
    这样做的好处就是当提供服务的服务器宕机以后，在接管的服务器上会直接自动配置上同样的VIP提供服务。如果是使用管理IP,来回迁移就难以做到，而且，管理IP迁移走了，我们就只能去机房连接服务器了，VIP的实质就是确保两台服务器各有一个管理IP不动，就是随时可以连上机器，然后，增加绑定其他的IP,这样就算VIP转移走了，也不至于服务器本身连不上，因为管理IP不变

手动配置VIP的方法：
    ifconfig eth0:1 172.26.10.50 netmask 255.255.255.224 up  (ip别名)
    #==》heartbeat2默认使用这个命令来添加VIP
     ip addr add 10.25.16.30/24 broadcast 10.25.16.255 dev eth1 (辅助ip)
    #==>keepalived,heartbeat3采用的方案
    ip add可以查看包括别名和辅助ip,用ifconfig无法查看辅助ip

手动删除VIP的方法：
    ifconfig eth0:1 172.26.10.50 netmask 255.255.255.224 down
    ip addr del 10.25.16.30/24 broadcast 10.25.16.255 dev eth1

1.8 Heartbeat相关目录及文件

启动脚本：/etc/init.d/
重要资源目录：/etc/ha.d/resource.d/  存放控制服务的脚本
默认配置文件目录：/etc/ha.d/
Heartbeat常用的配置文件有3个，分别是：

1.9 Heartbeat发展分支

Heartbeat3个分支说明：
从2.1.4之后，heartbeat分了3个不同的分支，Heartbeat、Cluster Glue 、Resource Agents，以前CRM功能也独立出一个版本Pacemaker

1.10 Heartbeat生产应用场景

1、WEB高可用双机之间，Heartbeat配合nginx，haproxy较好，LVS+keepalived较好
    2、数据库的主的高可用<最好使用Heartbeat>
    3、存储方面（MFS）使用Heartbeat+Drbd较好

二：部署Heartbeat高可用需求

2.1 业务需求描述

假设有两台服务器node01/node02,其实际ip分别为172.10.25.26(node01),172.10.25.27(node02).
    配置目标：要求heartbeat服务启动后，node01机器上初始启动VIP:172.10.25.18,node02机器上初始启动VIP:172.10.25.10,一旦服务器node01或node02任意一台机器宕机，在宕机的机器上初始启动的VIP就会自动切换到在运转正常的机器上，实现IP资源自动接管，从而达到高可用无业务影响的目的
    我们这里采用heartbeat双主模式，生产环境也可以采用主备模式，即只在主的一端配置VIP,备的一端处于热备状态

2.2 部署架构简易图

2.3 生产环境服务器硬件配置

DELL R430服务器2台，具体配置如下：

2.4 系统选择及主机资源规划

系统我们可以选择centos5.8或者centos6.5的

Heartbeat主机资源规划

注意：生产中存储服务器之间、存储服务器与交换机之间可以配成双千兆网卡bonding,提升网卡的性能