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