高可用集群是指一组通过硬件和软件连接起来的独立计算机，它们在用户面前表现为一个单一系统，在这样的一组计算机系统内部的一个或者多个节点停止工作，服务会从故障节点切换到正常工作的节点上运行，不会引起服务中断。从这个定义可以看出，集群必须检测节点和服务何时失效，何时恢复为可用。这个任务通常由一组被称为“心跳”的代码完成。在Linux-HA里这个功能由一个叫做heartbeat的程序完成。
Heartbeat是Linux-HA工程的一个组件，自1999年开始到现在，发布了众多版本，是目前开源Linux-HA项目最成功的一个例子，在行业内得到了广泛的应用。
下面以2.1.3版本为例讲解其框架和基础概念。
一、基本框架
Heartbeat分1.x和2.x两个大版本，v2版本是可以兼容之前v1的配置文件的，但从功能的角度来看，v2要强不少：
引用
a）2.x支持CRM管理，资源文件由原来的haresources变为cib.xml；
b）支持ocf、lsb、stonith等格式的resource agent；
c）可以对多资源组进行独立监控，不再需要依赖mon或ldirectord等第三方脚本；
d）支持多节点；
e）提供GUI图形配置和管理工具。
Heartbeat 2.x基于集群资源管理器（Cluster Resource Manager-CRM）CRM模式：可以支持最多16个节点，这些模式使用基于XML的集群信息（Cluster Information Base-CIM）配置。CIB文件（/var/lib/heartbeat/crm/cib.xml）会在各个节点间自动复制，可以实现下面的对象和动作：
引用
a）集群节点配置和监控；
b）集群资源，包括属性、优先级、组和依赖性的定制；
c）日志、监控、仲裁和fence标准管理；
d）当服务失败或其中设定的标准满足时，需要执行的动作。
二、基础概念
Heartbeat包括以下几个组件：
引用
heartbeat – 节点间通信校验模块
CRM - 集群资源管理模块
CCM - 维护集群成员的一致性
LRM - 本地资源管理模块
StonithDaemon - 提供节点重启服务
logd - 非阻塞的日志记录
apphbd - 提供应用程序级的看门狗计时器
Recovery Manager - 应用故障恢复
底层结构–包括插件接口、进程间通信等
CTS – 集群测试系统，集群压力测试
三、可靠消息通信
以下内容转自：互动百科
Heartbeat通过插件技术实现了集群间的串口、多播、广播和组播通信，在配置的时候可以根据通信媒介选择采用的通信协议，heartbeat启动的时候检查这些媒介是否存在，如果存在则加载相应的通信模块。这样开发人员可以很方便地添加新的通信模块。
对于高可用集群系统，如果集群间的通信不可靠，那么很明显集群本身也不可靠。Heartbeat采用UDP协议和串口进行通信，它们本身是不可靠的，可靠性必须由上层应用来提供。那么怎样保证消息传递的可靠性呢？
Heartbeat 通过冗余通信通道和消息重传机制来保证通信的可靠性。Heartbeat检测主通信链路工作状态的同时也检测备用通信链路状态，并把这一状态报告给系统管理员，这样可以大大减少因为多重失效引起的集群故障不能恢复。例如，某个工作人员不小心拨下了一个备份通信链路，一两个月以后主通信链路也失效了，系统就不能再进行通信了。通过报告备份通信链路的工作状态和主通信链路的状态，可心完全避免这种情况。因为这样在主通信链路失效以前，就可以检测到备份工作链路失效，从而在主通信链路失效前修复备份通信链路。
Heartbeat通过实现不同的通信子系统，从而避免了某一通信子系统失效而引起的通信失效。最典型的就是采用以太网和串口相结合的通信方式。这被认为是当前的最好实践，有几个理由可以使我们选择采用串口通信：
引用
（1）IP通信子系统的失效不太可能影响到串口子系统。
（2）串口不需要复杂的外部设备和电源。
（3）串口设备简单，在实践中非常可靠。
（4）串口可以非常容易地专用于集群通信。
（5）串口的直连线因为偶然性掉线事件很少。
不管是采用串口还是以太网IP协议进行通信，heartbeat都实现了一套消息重传协议，保证消息包的可靠传递。实现消息包重传有两种协议，一种是发送者发起，另一种是接收者发起。
对于发送者发起协议，一般情况下接收者会发送一个消息包的确认。发送者维护一个计时器，并在计时器到时的时候重传那些还没有收到确认的消息包。这种方法容易引起发送者溢出，因为每一台机器的每一个消息包都需要确认，使得要发送的消息包成倍增长。这种现像被称为发送者（或者ACK）内爆（implosion）。
对于接收者发起协议，采用这种协议通信双方的接收者通过序列号负责进行错误检测。当检测到消息包丢失时，接收者请求发送者重传消息包。采用这种方法，如果消息包没有被送达任何一个接收者，那么发送者容易因NACK溢出，因为每个接收者都会向发送者发送一个重传请求，这会引起发送者的负载过高。这种现像被称为NACK内爆（implosion）。
Heartbeat实现的是接收者发起协议的一个变种，它采用计时器来限制过多的重传，在计时器时间内限制接收者请求重传消息包的次数，这样发送者重传消息包的次数也被相应的限制了，从而严格的限制了NACK内爆
------------------------------------------------------------
昨天介绍了heartbeat 2.x的基础概念，其中提到v2版本是可以兼容v1的配置文件，而v2提供了更加强大的集群控制功能。使用v1还是v2的配置文件，是以ha.cf主配置文件决定的。实际使用中，虽然v2功能强大，但配置比较麻烦，GUI图形工具更是复杂难用，似乎要完全弄懂并不容易。不过，要实现基础的配置却是比较简单的，官方也提供了大量的说明文档，建议大家对比来看。
一、安装
heartbeat 官方网站：http://linux-ha.org/
测试环境为：
引用
node1: hatest3 192.168.228.233
node2: hatest4 192.168.228.234
FIP: 192.168.228.235
操作系统以红旗DC Server 5.0 SP2为例，其自带的heartbeat是1.x版本的，必须先卸载：
# rpm -e heartbeat heartbeat-ldirectord heartbeat-pils heartbeat-stonith
而2.x版本依赖多个perl包，我是使用centos 4.7的yum源来安装的。在红旗上配置好yum工具后，使用yum安装即可：
引用
# yum install heartbeat*
heartbeat-2.1.3-3.el4.centos.i386.rpm
heartbeat-devel-2.1.3-3.el4.centos.i386.rpm
heartbeat-gui-2.1.3-3.el4.centos.i386.rpm
heartbeat-ldirectord-2.1.3-3.el4.centos.i386.rpm
heartbeat-pils-2.1.3-3.el4.centos.i386.rpm
heartbeat-stonith-2.1.3-3.el4.centos.i386.rpm
perl-Authen-Radius-0.13-1.el4.centos.noarch.rpm
perl-Data-HexDump-0.02-1.el4.centos.noarch.rpm
perl-Mail-POP3Client-2.17-1.c4.noarch.rpm
perl-MailTools-1.77-1.el4.centos.noarch.rpm
perl-Net-IMAP-Simple-1.17-1.el4.centos.noarch.rpm
perl-Net-IMAP-Simple-SSL-1.3-1.c4.noarch.rpm
※ 注意，不知道为什么，我在第一次安装完毕后，配置启动CRM总是失败，后来查看日志才发现原来缺少了/var/run/heartbeat下的多个文件和目录，而这些目录是用于存放运行CRM时的临时执行命令的。所以，请务必确认一下该目录下的内容和用户、组等权限。
引用
# ll /var/run/heartbeat
总用量 12
drwxr-xr-x 2 hacluster haclient 4096 4月 8 12:32 ccm
drwxr-x--- 2 hacluster haclient 4096 4月 8 12:33 crm
srwxrwxrwx 1 root root 0 4月 8 12:32 register
drwxr-xr-t 4 root root 4096 4月 8 12:33 rsctmp
srwxrwxrwx 1 root root 0 4月 8 12:32 stonithd
srwxrwxrwx 1 root root 0 4月 8 12:32 stonithd_callback
※ 另外，heartbeat的运行还需要依赖hacluster用户和haclient组，而红旗在之前安装1.x版本时已经创建了这些用户，这里不需重新创建。如果您对这些用户的uid和gid进行了改动，则务必把对应的目录修改为正确的宿主。
二、1.x和2.x配置文件对比
在下面三个文件上体现了v2版本对比v1的区别：
引用
/etc/ha.d/authkeys 该文件在两个版本作用是完全相同的，都必须设置，并且保证每个节点（node）内容一样；
/etc/ha.d/ha.cf 这个是主要配置文件，由其决定v1或v2 style格式
/etc/ha.d/haresources 这是v1的资源配置文件
/var/lib/heartbeat/crm/cib.xml 这是v2的资源配置文件，两者根据ha.cf的设定只能选其一
正如前面所说的，v2版本使用CRM管理工具，而cib.xml文件可有几种方式来编写：
引用
a）人工编写XML文件；
b）使用admintools工具，其已经包含在heartbeat包中；
c）使用GUI图形工具配置，也包含在heartbeat-gui包里面；
d）使用python脚本转换1.x style的格式配置文件。
这四种方法实质都是相同的，并且以python脚本转换最为简单容易（GUI工具相当难用，今后有时间再详细说明）。为此，我们可以先配置好1.x style的格式。
三、配置1.x style格式
1、准备
为方便配置文件之间的同步，我建议先给主节点做好到下面各个节点的ssh密钥认证，单向即可。
这部分的配置，请参考：http://www.linuxfly.org/post/29/
2、设定authkeys文件
该文件是集群中各节点相互认证的配置文件，允许使用crc（明文）、md5、sha1等不同的验证方式，可以使用heartbeat自带的示例来修改：
# cp /usr/share/doc/heartbeat-2.1.3/authkeys /etc/ha.d/
# cd /etc/ha.d
# chmod 600 authkeys
修改后的内容如下：
引用
# cat authkeys
auth 2
1 crc
2 sha1 HI!
3 md5 Hello!
auth命令定义了使用那种验证方式，需保证每个节点使用相同的验证方式和验证字符串。authkeys的权限也必须是600的。
3、设定ha.cf文件
这是关键的配置文件，同样的，可以先从示例中拷贝过来：
# cp /usr/share/doc/heartbeat-2.1.3/ha.cf /etc/ha.d
1.x的基本配置信息如下：
引用
# more /etc/ha.d/ha.cf
#发送keepalive包的间隔时间
keepalive 2
#定义节点的失效时间
deadtime 30
#定义heartbeat服务启动后，等待外围其他设备（如网卡启动等）的等待时间
initdead 30
#使用udp端口694 进行心跳监测
udpport 694
#定义心跳
bcast eth0 eth1 # Linux
#定义是否使用auto_failback功能
auto_failback off
#定义集群的节点
node hatest3
node hatest4
#使用heartbeat提供的日志服务，若use_logd设置为yes后，下面的三个选项会失效
use_logd yes
#logfile /var/log/ha_log/ha-log.log
#logfacility local7
#debugfile /var/log/ha_log/ha-debug.log
#设定一个监控网关，用于判断心跳是否正常
ping 192.168.228.153
deadping 5
#指定和heartbeat一起启动、关闭的进程
respawn hacluster /usr/local/lib64/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster
该配置文件是比较简单和清晰的，在不适用crm yes的情况下，即为1.x style格式。
4、设定haresources文件
这个是1.x使用的集群资源文件，每行一个组，第一列定义的是优先级服务器，也就是默认资源运行在该服务器上：
引用
hatest3 192.168.228.235 httpd
#hatest3 IPaddr::192.168.228.235 httpd
当ha发现优先节点当掉了，则另一个节点会自动接管192.168.228.235（浮动IP）和服务。第二行的作用是相同的，第一行是简略了IPaddr的写法。如果集群需要实现Active-Active（互备）状态，则可以再写一行，但托管的应用不能冲突。
5、设定hosts文件
这不是一个必须的配置，但为了方便同步各节点的配置，建议设定：
引用
# cat /etc/hosts
hatest3 192.168.228.233
hatest4 192.168.228.234
6、拷贝配置文件到集群各节点上
可以利用v2版本提供的同步配置工具来同步上述的配置文件，但默认只提供同步ha.cf和authkeys，haresources文件还是需要自行拷贝的（v2不使用该文件）：
引用
# /usr/lib/heartbeat/ha_propagate
# /usr/lib/heartbeat/ha_propagate
Propagating HA configuration files to node hatest4.
ha.cf 100% 11KB 10.7KB/s 00:00
authkeys 100% 682 0.7KB/s 00:00
Setting HA startup configuration on node hatest4.
# scp /etc/ha.d/haresources hatest4:/etc/ha.d
haresources 100% 5960 5.8KB/s 00:00
7、测试
在节点上都启动heartbeat服务：
# service heartbeat start
同时监控/var/log/ha-log日志文件，可以发现：
引用
info: Enabling logging daemon
info: logfile and debug file are those specified in logd config file (default /etc/logd.cf)
info: Version 2 support: false
info: **************************
info: Configuration validated. Starting heartbeat 2.1.3
info: heartbeat: version 2.1.3
info: Heartbeat generation: 1239094081
可见，这是没有使用v2 style配置格式的。接着，您可以进行简单的切换测试（例如断开hatest3的网络，关闭hatest3等），看看httpd服务是否可以正常切换到hatest4上。
至此，1.x style的heartbeat已经搭建完成。接下来即可借助1.x style的资源配置文件，转换为2.x style的格式，以构建2.x的HA集群应用。因文章篇幅太长，请转到下一篇日志中继续。
--------------------------------------------------------------------
继续昨天的内容。接下来要做的，就是借助1.x style的集群资源配置文件转换为2.x style的格式，并适当的配置ha.cf文件。与1.x style不同的是，v2.x style会使用CRM来进行整个集群的管理。集群开始时，通过在各节点间选举产生一个节点成为DC（Designated Coordinator），配置应在该DC上进行，并由其分发到下面的各个节点上。另外，使用中发现存在缺少ccm和crm临时目录的问题，暂时从官方的文档中暂时没有找到明确的解析和说明，我是作为一个Bug来理解的。
四、配置2.x style格式
从上面的测试可见，heartbeat 2.1.3确实是支持v1的配置格式的。如果要使用CRM管理，接下来要做的，就是激活v2的支持，并转换集群资源配置文件。
1、修改ha.cf配置文件
首先停止各节点的heartbeat服务：
# service heartbeat stop
然后修改/etc/ha.d/ha.cf文件为：
引用
# more /etc/ha.d/ha.cf
keepalive 2
deadtime 30
initdead 30
udpport 694
bcast eth0 eth1 # Linux
auto_failback off
node hatest3
node hatest4
ping 192.168.228.153
use_logd yes
#下面的配置是关键，也就是激活crm管理，允许使用v2 style格式
#注意，还可以使用crm yes的写法，但这样写的话，如果后面的cib.xml配置有问题
#会导致heartbeat直接重启该服务器，所以，测试时建议使用respawn的写法
crm respawn
#下面是对传输的数据进行压缩，是可选项
compression bz2
compression_threshold 2
※ 注意，v2 style不支持ipfail功能，而应使用pingd代替
请见：http://www.linux-ha.org/ipfail
2、关于Designated Coorinator
v2.x style使用CRM来进行整个集群的管理。即使没有生成下面的cib.xml文件，只要正确配置authorkeys和ha.cf，即可运行集群。
集群开始时，通过在各节点间选举产生一个节点成为DC（Designated Coordinator），日志会显示：
引用
info: update_dc: Set DC to hatest3 (2.0)
今后，配置应在该DC上进行，并由其分发到下面的各个节点上。
※ 注意，我从官方的资料中并没有找到明确指出，如何再多个节点之间选举DC的方法和策略，似乎是与节点的主机名有关。
介绍请见：这里。
暂时，建议首次配置heartbeat的朋友，可以在没有cib.xml文件的情况下，启动所有节点上的heartbeat服务，通过查看日志以判断DC为那台节点机器。
这里，以hatest3为DC进行举例说明。所以，以下的工作都在hatest3节点上进行。
3、转换v1.x为v2.x格式文件
heartbeat提供了一个使用python写的转换工具，可直接转换v1 style的配置文件为v2 style：
# /usr/lib/heartbeat/haresources2cib.py /etc/ha.d/haresources
※ 如果您之前已经启动过使用v2 style的heartbeat，需要先删除原来的文件：
# rm -f /var/lib/heartbeat/crm/*
继续前，可以先校验一下资源文件的格式是否正确：
# crm_verify -x /var/lib/heartbeat/crm/cib.xml
◎ 因/etc/ha.d/haresources文件对于v2 style来说是多余的，所以官方文档中，是创建了一个haresources.tmp的文件，然后直接转换：
# /usr/lib/heartbeat/haresources2cib.py /root/haresources.tmp
4、拷贝配置文件到各节点上
同步各节点的配置文件
引用
# /usr/lib/heartbeat/ha_propagate
Propagating HA configuration files to node hatest4.
ha.cf 100% 11KB 10.7KB/s 00:00
authkeys 100% 682 0.7KB/s 00:00
Setting HA startup configuration on node hatest4.
# scp /var/lib/heartbeat/crm/cib.xml hatest4:/var/lib/heartbeat/crm/
cib.xml 100% 3117 3.0KB/s 00:00
5、重建crm临时目录
※ 这一步非常重要，如果不进行这步操作的话，后面启动hearbeat服务会失败的。
在安装的时候，我们提到，heartbeat v2的允许需要依赖/var/run/heartbeat中的若干文件。但不知道是Bug，还是其他原因，我发现机器重启后，/var/run/heartbeat目录会被清空：
引用
# ll /var/run/heartbeat/
总用量 0
但这目录下的ccm和crm对于heartbeat v2的运行是不可缺少的，对比一下heartbeat包中的内容：
引用
# rpm -ql heartbeat|grep run
/var/run
/var/run/heartbeat
/var/run/heartbeat/ccm
/var/run/heartbeat/crm
如果这时候直接启动heartbeat服务，日志中就会报错：
引用
info: startCib: CIB Initialization completed successfully
info: cib_register_ha: Signing in with Heartbeat
info: cib_register_ha: FSA Hostname: hatest3
ERROR: socket_wait_conn_new: trying to create in /var/run/heartbeat/crm/cib_callback bind:: No such file or directory
ERROR: Can't create wait channel of type uds: Resource temporarily unavailable
通过查看/etc/init.d/heartbeat文件，可以发现其中有：
StartHA() {
EchoNoNl "Starting High-Availability services: "
......
if
[ ! -d $RUNDIR/heartbeat ]
then
mkdir -p $RUNDIR/heartbeat/ccm
mkdir -p $RUNDIR/heartbeat/crm
chown -R hacluster:haclient $RUNDIR/heartbeat
chmod -R 750 $RUNDIR/heartbeat
fi
......
所以，解决办法是，修改该文件为：
引用
StartHA() {
EchoNoNl "Starting High-Availability services: "
......
if
[ ! -d $RUNDIR/heartbeat/ccm -o ! -d $RUNDIR/heartbeat/crm ]
then
mkdir -p $RUNDIR/heartbeat/ccm
mkdir -p $RUNDIR/heartbeat/crm
chown -R hacluster:haclient $RUNDIR/heartbeat
chmod -R 750 $RUNDIR/heartbeat
fi
......
参考办法：
Heartbeat fails to start after Dapper upgrade
6、测试
最后，在各节点上启动heartbeat服务进行测试：
# service heartbeat start
日志会显示：
引用
info: Enabling logging daemon
info: logfile and debug file are those specified in logd config file (default /etc/logd.cf)
info: Version 2 support: respawn
WARN: File /etc/ha.d/haresources exists.
WARN: This file is not used because crm is enabled
info: **************************
info: Configuration validated. Starting heartbeat 2.1.3
info: heartbeat: version 2.1.3
info: Heartbeat generation: 1239088581
可见，已经使用v2 style配置了。接下来，您可以查看hatest3上的服务是否正常，或进行故障切换测试。
7、GUI工具
v2 style的集群正常启动后，会打开5560端口，允许hb_gui访问。
引用
# netstat -ln|grep 5560
tcp 0 0 0.0.0.0:5560 0.0.0.0:* LISTEN
# ps -ef|grep mgmt|grep -v 'grep'
root 3770 3752 2 10:50 ? 00:00:02 /usr/lib/heartbeat/mgmtd -v
使用hb_gui访问CRM管理界面前，还需要给hacluster用户创建一下密码：
# passwd hacluster
接着，就可以进入Xwin界面，运行：
# hb_gui
看到的登陆界面如下：
登陆后可以看到当前的集群情况：
该界面不单可以进行监控，还可以进行配置和管理的操作：
不过，这工具可真的并不是那么好用，待以后有机会再做说明吧。
※ heartbeat还提供了一个CRM管理程序crm_resource，在 这里 说明。
最后确认整个HA集群都可以正常运行、监控、切换后，可以把/etc/ha.d/ha.cf中的crm respawn改为crm yes，并设置为自启动：
# chkconfig --level 35 heartbeat on
五、故障分析
在整个配置和调试过程中，遇到的问题可真是不少，甚至大部分问题在官方的资料中都没有提及，这是开源软件一个典型的问题。软件并不是研发出来就可以了，维护和文档是非常重要的。
1、激活5560端口错误
启动heartbeat时，报错：
引用
ERROR: Duplicate apiauth directive for API client mgmtd: [mgmtd uid=root]
some entries in ha.cf no longer needed
在旧版本heartbeat上，激活5560端口，提供GUI访问支持，需要修改/etc/ha.d/ha.cf文件，在其中增加：
引用
apiauth mgmtd uid=root
respawn root /usr/lib/heartbeat/mgmtd -v
但新版本heartbeat已经不需要再进行该设置了，只需要打开crm yes或crm respawn即可，而重复的定义会导致启动失败的。
官方提供了说明：http://www.linux-ha.org/UpdateExperience
2、缺少临时目录
引用
ERROR: socket_wait_conn_new: trying to create in /var/run/heartbeat/crm/cib_callback bind:: No such file or directory
ERROR: Can't create wait channel of type uds: Resource temporarily unavailable
这问题在前面已经提过了，是因为缺少/var/run/heartbeat下的ccm和crm目录，修改/etc/init.d/heartbeat脚本，或重建这些目录都可以解决。
3、临时目录权限不对
引用
ERROR: socket_wait_conn_new: unlink failure(/var/run/heartbeat/ccm/ccm): Permission denied
ERROR: socket_wait_conn_new: trying to create in /var/run/heartbeat/ccm/ccm bind:: Permission
这问题与上面的问题类似，是因为临时目录创建时给予的权限不对导致的，修改为正确的权限即可。
4、UUID不正确
参与集群的每台服务器都会有一个唯一的UUID值，但可能由于一些特殊原因，例如目录复制、机器拷贝、文件丢失等，导致UUID丢失或重复，会导致集群不能正常启动。
这时，可删除下面的文件，重启heartbeat时会自动重建新的UUID：
# cd /var/lib/heartbeat/
# rm delhostcache hb_generation hb_uuid hostcache
# service heartbeat start
5、宿主和权限问题
红旗上默认安装的heartbeat v1会创建UID为90的hacluster用户和haclient组，若您重新安装hearbeat v2时对这部分进行了修改，请需要确认相关的文件是否正确。同样的，权限也一样，有部分执行文件是设置了setuid等特殊权限的。
下面的命令能协助您找出机器中属于hacluster用户的文件：
# find / -u hacluster -print
