最近在老师的带领下学习linux下的高可用技术，使用的是heartbeat这款软件来实现服务器集群的高可用。下面我将记录在学习和试验过称中遇到的问题和一些个人看法，供广大博友们参考借鉴，本人水平可能不够，大神请轻喷。
首先遇到的第一个问题就是我是在VMWARE的ESXI上面做的虚拟机上面做的实验，按照老师的步骤一路做过来，但是结果是脑裂了，后来清空配置又重新配置了一遍，结果还是发生脑裂现象。于是采用了在本机上面使用VMware workstation安装虚拟机来做这个实验，同样的实验步骤，但是一次性就成功。由此可见是ESXI上面出了问题，具体问题出在哪目前还没有排查到。。。。。QAQ，水平有限哈。
然后是本打算用CentOS7来做这个实验的，但是在CentOS7上面死活找不到yum安装heartbeat的包，安装epel-release-7.5之后也还是无法找到，后来打算使用rpm包安装，结果发现需要安装好几十个rpm依赖包，很难实现，于是退而求其次，使用centos6.6来完成这个实验。我相信在centos7上面应该也是可以做这个实验的，可能我没有找对方法。
好了，废话了这么多，各位看官都看累了，于是给大家来点干货吧。
首先，拓扑图如下：
两台服务器用来做高可用，虚拟IP式10.6.0.187，通过心跳线来确定对方是否存活。
下面我们使用heartbeat来做HA集群，并且把nginx服务作为HA对应的服务。
试验准备：
两个机器, 都是centos6.6，网卡eth0 ip如下：
test1 10.6.0.188
test2 10.6.0.189
两个eth1 ip如下：
test1 10.6.100.188
test2 10.6.100.189
下面操作1-5都是在两个机器上操作
1. hostname 设置好，分别为test1 和 test2
2. 关闭防火墙 iptables -F;
关闭selinux： setenforce 0
3. vi /etc/hosts // 增加内容如下：
10.6.0.188 test1
10.6.0.189 test2
4. 安装epel扩展源：
yum -y install epel-release
5. 两个机器都安装heartbeat / libnet
yum install -y heartbeat nginx
6. 主上（test1）配置
cd /usr/share/doc/heartbeat-3.0.4/ cp authkeys ha.cf haresources /etc/ha.d/ cd /etc/ha.d vi authkeys #打开下面两项：一共有三种认证方式供选择，第一种是CRC循环冗余校验，第二种是SHA1哈希算法，第三种是MD3哈希算法，其中他们的密码可以任意设置，但是两边密码必须保持一致。 auth 3 md5 Hello! chmod 600 authkeys #给认证文件授权为600 vi haresources #加入如下语句 test1 10.6.0.187/24/eth0:0 nginx #设定虚拟IP和对应的接口，并且指定启动虚拟IP时启动NGINX服务，这里的NGINX服务必须是能够直接在/etc/init.d/目录下启动的服务。 vi ha.cf #改为如下内容： debugfile /var/log/ha-debug #设定debug文件目录 logfile /var/log/ha-log #设定日志文件目录 logfacility local0 keepalive 2 #设定检查时间间隔为2s deadtime 30 #设定死亡时间为30s warntime 10 #设定告警时间为10s（10s以上没有收到对方的回应就报警） initdead 60 #设定初始化时间为60s udpport 694 #启动udp694监听端口（该端口可以修改） ucast eth1 10.6.100.189 #设定侦听的心跳线的接口和对应的对端接口的IP地址 auto_failback on #启动抢占模式（主在挂了以后重新起来后备会自动切换成备） node test1 #指定两个节点 node test2 ping 10.6.100.1 #指定一个第三方的仲裁节点 respawn hacluster /usr/lib/heartbeat/ipfail #使用这个脚本去侦听对方是否还活着（使用的是ICMP报文检测）
7. 把主上的三个配置拷贝到从上：
cd /etc/ha.d/
scp authkeys ha.cf haresources test2:/etc/ha.d/
8. 到从上(aming1) 编辑ha.cf
vi /etc/ha.d/ha.cf //只需要更改一个地方
ucast eth1 10.6.100.189 改为 ucast eth1 10.6.100.188
9. 启动heartbeat :
先主，后从
service heartbeat start
启动后主上面会出现一个eth0:0，备上面则不会启动eth0:0
可以查看debug日志和软件日志来检查是否正常启动：
主上面自动启动了NGINX，备上面没有启动eth0:0接口。
于是我扩展了一下，在主上面的心跳线接口给down掉之后，备上面因为检测不到主还活着，于是自己成为主，启动了虚拟IP接口，接替了主的工作。当把主的心跳线接口up起来之后备主动把虚拟IP交还给主，自己成为备。
然后我将主上面的对外接口给down之后，备因为检测到心跳接口还是正常的，还以为主还活着，于是高可用就失败了。当主把对外接口up之后需要重新启动heartbeat服务才能从备上面把工作接管过来。
由这里可以看出心跳线是至关重要的，心跳线挂了之后将有可能导致脑裂行为的发生（即主和备一起在抢占虚拟IP的控制权），实际环境中最好给心跳线做冗余，使用以太端口捆绑保障心跳线的健壮性。
同时，假如主的对外接口挂了，但是心跳线没有挂，备就无法检测到主挂了，也就无法实现高可用了。
以上观点仅是本人的拙见，欢迎各位大神提出更好地解决办法和观点。