【Linux系统之heartbeat 】

我们用到的集群系统主要就2种:

高可用(High Availability)HA集群, 使用Heartbeat实现;也会称为”双机热备”, “双机互备”, “双机”。

负载均衡群集(Load Balance Cluster)，使用Linux Virtual Server(LVS)实现;

 

 

heartbeat （Linux-HA）的工作原理：heartbeat最核心的包括两个部分，心跳监测部分和资源接管部分，心跳监测可以通过网络链路和串口进行，而且支持冗 余链路，它们之间相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未受到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运 行在对方主机上的资源或者服务。

 

 

Heartbeat 项目是 Linux-HA 工程的一个组成部分，它实现了一个高可用集群系统。心跳服务和集群通信是高可用集群的两个关键组件，在 Heartbeat 项目里，由 heartbeat 模块实现了这两个功能。下面描述了 heartbeat 模块的可靠消息通信机制，并对其实现原理做了一些介绍。

 

Heartbeat is a daemon that provides cluster infrastructure (communication and membership) services to its clients. This allows clients to know about the presence (or disappearance!) of peer processes on other machines and to easily exchange messages with them.

In order to be useful to users, the Heartbeat daemon needs to be combined with a cluster resource manager (CRM) which has the task of starting and stopping the services (IP addresses, web servers, etc.) that cluster will make highly available. Pacemaker is the preferred cluster resource manager for clusters based on Heartbeat.

 

heartbeat 原理

heartbeat （Linux-HA）的工作原理：heartbeat最核心的包括两个部分，心跳监测部分和资源接管部分，心跳监测可以通过网络链路和串口进行，而且支持冗 余链路，它们之间相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运 行在对方主机上的资源或者服务。

 

 

高可用集群

高可用集群是指一组通过硬件和软件连接起来的独立计算机，它们在用户面前表现为一个单一系统，在这样的一组计算机系统内部的一个或者多个节点停止工作，服务会从故障节点切换到正常工作的节点上运行，不会引起服务中断。从这个定义可以看出，集群必须检测节点和服务何时失效，何时恢复为可用。这个任务通常由一组被称为“心跳”的代码完成。在Linux-HA里这个功能由一个叫做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启动的时候检查这些媒介是否存在，如果存在则加载相应的通信模块。这样开发人员可以很方便地添加新的通信模块，比如添加红外线通信模块。

对于高可用集群系统，如果集群间的通信不可靠，那么很明显集群本身也不可靠。Heartbeat采用UDP协议和串口进行通信，它们本身是不可靠的，可靠性必须由上层应用来提供。那么怎样保证消息传递的可靠性呢？

Heartbeat通过冗余通信通道和消息重传机制来保证通信的可靠性。Heartbeat检测主通信链路工作状态的同时也检测备用通信链路状态，并把这一状态报告给系统管理员，这样可以大大减少因为多重失效引起的集群故障不能恢复。例如，某个工作人员不小心拨下了一个备份通信链路，一两个月以后主通信链路也失效了，系统就不能再进行通信了。通过报告备份通信链路的工作状态和主通信链路的状态，可以完全避免这种情况。因为这样在主通信链路失效以前，就可以检测到备份工作链路失效，从而在主通信链路失效前修复备份通信链路。

Heartbeat通过实现不同的通信子系统，从而避免了某一通信子系统失效而引起的通信失效。最典型的就是采用以太网和串口相结合的通信方式。这被认为是当前的最好实践，有几个理由可以使我们选择采用串口通信：

（1）IP通信子系统的失效不太可能影响到串口子系统。

（2）串口不需要复杂的外部设备和电源。

（3）串口设备简单，在实践中非常可靠。

（4）串口可以非常容易地专用于集群通信。

（5）串口的直连线因为偶然性掉线事件很少。

不管是采用串口还是以太网IP协议进行通信，heartbeat都实现了一套消息重传协议，保证消息包的可靠传递。实现消息包重传有两种协议，一种是发送者发起，另一种是接收者发起。

对于发送者发起协议，一般情况下接收者会发送一个消息包的确认。发送者维护一个计时器，并在计时器到时的时候重传那些还没有收到确认的消息包。这种方法容易引起发送者溢出，因为每一台机器的每一个消息包都需要确认，使得要发送的消息包成倍增长。这种现像被称为发送者（或者ACK）内爆（implosion）。

对于接收者发起协议，采用这种协议通信双方的接收者通过序列号负责进行错误检测。当检测到消息包丢失时，接收者请求发送者重传消息包。采用这种方法，如果消息包没有被送达任何一个接收者，那么发送者容易因NACK溢出，因为每个接收者都会向发送者发送一个重传请求，这会引起发送者的负载过高。这种现像被称为NACK内爆（implosion）。

Heartbeat实现的是接收者发起协议的一个变种，它采用计时器来限制过多的重传，在计时器时间内限制接收者请求重传消息包的次数，这样发送者重传消息包的次数也被相应的限制了，从而严格的限制了NACK内爆。

 

 

HeartBeat的作用：

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

 

HeartBeat的工作原理：

通过修改Heartbeat的软件的配置文件，可以制定那一台Heartbeat服务器作为主服务器，则另一台将自动成为热备服务器。然后在热备服务器上配置Heartbeat守护程序来监听来自主服务器的心跳消息。如果热备服务器在指定时间内为监听到来自主服务器的心跳，就会启动故障转义程序，并取得主服务器上的相关资源服务的

 

所有权，接替主服务器继续不间断的提供服务，从而达到资源以及服务高可用的目的。以上的描述heartbeat的主备模式，heartbeat还支持主主模式，即两台服务器互为主备，这是他们之间还会互相发送报文来告诉对方自己的当前的状态，如果在

 

指定的时间内未收到对方发送的心跳报文，那么，一方就会认为对方失效或者是已经宕机了，这时每个运行正常的主机就会启动自身的资源接管模块来接管运行在对方

 

主机上的资源或者是服务，继续为用户提供服务。一般情况下，可以较好的实现一台主机故障后，企业业务能够不间断的持续的提供服务。注意：所谓的业务不间断，

 

在故障转移期间也是需要切换时间的，heartbeat的切换时间是5-20秒。

切换的常见条件：

1）服务器宕机

2）Heartbeat服务本故障

3）中间的连接线路故障

 

应用服务故障则不会产生切换，可以通过服务宕机把heartbeat服务停掉。

 

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）通过第三方软件仲裁谁该获得资源，这个在阿里有类似的软件应用