一、Heartbeat 的作用

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

      Heartbeat 官方地址： http://linux-ha.org/wiki/Main_Page

二、Heartbeat工作原理

      通过修改 heartbeat 软件的配置文件，可以指定哪一台 Heartbeat 服务器作为主服务器，则另一台将自动成为热备服务器，然后在热备服务器上配置 Heartbeat 守护程序来监听来自主服务器的心跳消息。如果热备服务器在指定时间内未监听到来自主服务器的心跳，就会启动故障转移程序，并取得主服务器上的相关资源服务的所有权，接管主服务器继续不间断的提供服务，从而达到资源及服务高可用性的目的。

      以上描述的是 Heartbeat 主备的模式，Heartbeat 还支持主主模式，即两台服务器互为主备，这时它们之间会相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未收到对方发送的心跳报文，那么，一方就会认为对方失败或者宕机了，这时每个运行正常的主机就会启动自身的资源接管模块来接管运行在对方主机上的资源或者服务，继续为用户提供服务。一般情况下，可以较好的实现一台主机故障后，企业业务仍能够不间断的持续运行。注意，所谓的业务不间断，在故障转移期间也是需要切换时间的（例如：停止数据库及存储服务等），Heartbeat 的主备高可用的切换时间一般是在 5~20 秒左右（服务器宕机的切换比人工切换要快）。

      另外，和 Keepalived 高可用软件一样，Heartbeat 高可用是 操作系统级别的，不是服务器（软件）级别的，可以通过简单的脚本控制，实现软件级别的高可用。

      高可用服务器切换的常见条件场景：
         · 主服务器物理宕机（硬件损坏，操作系统故障）。 【主要解决目标】
         · Heartbeat 服务器软件本身故障。
         · 两台主服务器之间心跳连接故障。

        服务故障不会导致切换 ，可以通过服务宕机把 Heartbeat 服务停掉。

三、Heartbeat 心跳连接

      经过前面那段叙述，大家应该很清楚了，要部署 heartbeat 服务，至少需要两台主机来完成。那么，要实现高可用服务，这两台主机之间是如何做到互相通信和互相监测的呢？

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

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

      1. 串口线信号不会和以太网络交集，也不需要单独配置IP地址等信息，因此传输稳定不容易出现问题，使用串口线的缺点是两个服务器对之间的距离不能太远，串口线形状如下图所示：

       串口线对应服务器端的设备为 /dev/ttyS0。这是在生产环境常用的方法组合之一。

       2. 使用以太网网线（无需特殊的交叉线了）直连网卡的方式，配置也比较简单，值需对这两块直连网线的网卡配好独立的 IP 段地址能够互相通信即可，普通的网线就可以了。这也是在生产环境常用的方式组合之一。
      3. 使用联网以太网网线和网卡作为心跳线是次选的方案，因为这个链路里增加了交换机设备这样的故障点，且这个线路不是专用心跳线路，容易受以太网其他数据传输的影响，导致心跳报文发送延迟或者无法送达问题。

选择方案小结：

• 1） 和数据相关的业务，要求较高的，可以串口和网线直连的方式并用。
• 2） Web业务，可以网线直连的方式或局域网通信方式也可。

四、Heartbeat 裂脑

1、什么是裂脑？

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

参考英文解释：
What does “split-brain” mean ?

      “Split brain” is a condition whereby two or more computers or groups of computers lose contact with one another but still act as if the cluster were intact. This is like having two governments trying to rule the same country. If multiple computers are allowed to write to the same file system without knowledge of what the other nodes are doing, it will quickly lead to data corruption and other serious problems.
      Split-brain is prevented by enforcing quorum rules (which say that no group of nodes may operate unless they are in contact with a majority of all nodes) and fencing (which makes sure nodes outside of the quorum are prevented from interfering with the cluster).
      A split-brain condition is the result of a Cluster Partition, where each side believes the other is dead, and then proceeds to take over resources as though the other side no longer owned any resources.
      After this, a variety of Bad Things Will Happen - including destroying shared disk data.
       This is the result of acting on incomplete information - neglecting Dunns Law. That is, when a node is declared “dead”, its status is, by definition, not known. Perhaps it is dead, perhaps it is merely incommunicado. The only thing that is known is that its status is not known.
      The ultimate cure to this is to use Fencing and lock the other side out.
         The problem with merely using quorum without fencing, is that the loss of quorum can take an unbounded amount time ot detect and react to in the worst case.
       Fencing does not require knowledge of the timing to behavior of the “errant” nodes, nor does it require the cooperation or sanity of errant nodes. In addition, fencing operations receive positive confirmation. Hence, fencing has a high degree of certainty.
       A good way of avoiding split brain conditions in most cases without having to resort to fencing is to configure redundant and independent cluster communications paths - so that loss of a single interface or path does not break communication between the nodes - that is the communications should not have a single point of failure (SPOF).
      Using both redundant communications and fencing is a good way to go. We highly recommend both.

http://linux-ha.org/wiki/Split_Brain

2、导致裂脑发生的多种原因

       一般来说，裂脑的发生，有以下几个原因：

        · 高可用服务器对之间心跳线链路故障 ，导致无法正常通信。
                1、心跳线坏了（包括断了，老化）。
                2、网卡及相关驱动坏了，IP 配置及冲突问题（网卡直连）。
                3、心跳线间连接的设备故障（网卡及交换机）。
                4、仲裁的机器出问题（仲裁的方案）。
        · 高可用服务器对上开启了如 iptables 防火墙阻挡了心跳消息传输。
        · 高可用服务器对上心跳网卡地址等信息配置不正确，导致发送心跳失败。
        · 其它服务配置不当等原因，如心跳方式不同，心跳广播冲突、软件BUG等。

提示：另外的高可用软件 keepalived 配置里如果 virtual_router_id 参数，两端配置不一致，也会导致裂脑问题发生。

3、防止裂脑发生的多种秘籍

      发生裂脑时，对业务的影响是极其严重的，有时甚至是致命的。如：两台高可用服务器对之间发生裂脑，导致互相争用同一 IP 资源，就如同我们在局域网内常见的 IP 地址冲突一样，两个机器就会有一个或者两个都不正常，影响用户正常访问服务器。如果是应用在数据库或者存储服务这种极重要的高可用上，那就可能会导致用户发布的数据间断的写在两台不同服务器上的恶果，最终数据恢复极困难或难以恢复（当然，有 NAS 等公共存储的硬件也许会好一些）。

      实际生产环境中，我们可以从以下几个方面来防止裂脑问题的发生。

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