Heartbeat v2 安装和配置原理

1. Information Technologies, IncHang zhou, China
Product Name
Heartbeat V2 安装和配置
Author Name
Pickup.Li
1

2. 2

3. 目 录
目 录 .......................................................................................................................................3
1 修订记录 ................................................................................................................................5
2 文档介绍 ................................................................................................................................6
2.1 文档目的.........................................................................................................................................6
2.2 术语与缩写解释..............................................................................................................................6
3 Heartbeat 安装和简单配置 ....................................................................................................7
3.1 Heartbeat 的安装............................................................................................................................7
3.2 配置 ha.cf.......................................................................................................................................8
3.3 配置 Authkeys...............................................................................................................................10
3.4 配置 haresources..........................................................................................................................11
3.5 配置 cib.xml..................................................................................................................................12
3.6 启动 HeartBeat..............................................................................................................................15
3.7 Heartbeat 管理工具.......................................................................................................................15
4 Heartbeat 基础架构 .............................................................................................................19
5 Heartbeat 各模块分析 .........................................................................................................21
5.1 heartbeat 模块：...........................................................................................................................21
5.2 CRM：cluster resource manager...................................................................................................21
5.3 LRM：local resource manager......................................................................................................21
5.4 PE：CRM Policy Engine...............................................................................................................22
5.5 TE：Transition engine...................................................................................................................22
3

4. 5.6 CIB：cluster information base........................................................................................................22
5.7 CCM：consensus cluster membership..........................................................................................22
5.8 LOGD：logging daemon（non-blocking）.....................................................................................23
5.9 APPHBD：application heartbeat daemon......................................................................................23
5.10 RMD：recovery manager daemon...............................................................................................23
6 Heartbeat 的切换策略 -积分统计方法 .................................................................................24
7 Resource agent 介绍 ...........................................................................................................29
7.1 LSB resource agent.......................................................................................................................29
7.2 Heartbeat resource agent..............................................................................................................29
7.3 OCF resource agent......................................................................................................................30
7.4 小结..............................................................................................................................................30
8 相关文档列表 ......................................................................................................................32
4

5. 修订日期 版本号 描述 修订人
2008-7-29 1.0 create Pickup.Li
1 修订记录
5

6. 2 文档介绍
2.1 文档目的
本文档主要介绍 linux-HA 项目的新版本 v2 的安装和配置及相关算法，为以后架构 linux-HA 增加系统
的可用性，以及基于该项目开发我们自己的监控和 Failover 工具提供指导性意见和建议。
2.2 术语与缩写解释
编号 术语 解释
1. linux-HA 是一个开发用于 linux 操作系统的构建高可用性群集的软件的项目，软件主要是
指 Heartbeat 软件，它同样可用于 FreeBSD, Solaris, 和 OpenBSD 等操作系统。
2. Heartbeat 它既可以指 linux-HA 项目的整个软件，也可以指负责通讯和基础架构的核心软
件包。本文中前者我们用 Heartbeat 表示，后者用 heartbeat 表示。
3. CCM/Consensus 集群节点关系监控模块，用来维护和传递集群节点信息，包括新增节点，排除
Cluster Membership 节点。
4. CRM/Cluster 是 Linux-HA 的“大脑”模块，它维护着配置信息，负责资源的分配，改变资源
Resource 和节点的状态，它和 Linux-HA 的每一个模块都有交互。
Manager
5. LRM/Local 本地资源管理器，它基本上是对 resource agent 的抽象，CRM 主要是通过 LRM
Resource 对资源和节点进行对应操作，比如启动，停止和监控等。
Manager
6. CIB/Cluster 集群基本信息管理器，它包括静态地配置信息和资源定义信息，以及动态的节
Information Base 点和资源状态信息等。
7. transition graph 转化图，它作为 PE 的输出和 TE 的输入，描述了从 CurrentClusterState 转变到
TargetClusterState 的必要操作和依赖关系，以期望集群中的各资源都运行正常。
8. PE/pengine/CRM 协议引擎，用于从当前的状态信息计算得到 transition graph，它会考虑到
policy engine resource 的当前位置和状态，节点的正常与否以及当前的静态配置信息。
9. TE/tengine/CRM 转化引擎，它利用 PE 生成的 transition graph 通过远程节点上的 LRM 发起具体
Transition Engine 的操作（start，stop），以期望达到 TargetClusterState。
10. resource 资源，它是高可用性的基本单位，是集群资源管理器用于高可用性配置的服务
或者相应的工具。 注意：集群资源只能被集群启动和停止，而不能由操作系统的
参与。
11. RA/resource agent 资源代理，它对某种类型的集群资源进行了包裹，就像具体的硬件驱动程序一
样。
12.
6

7. 3 HEARTBEAT 安装和简单配置
3.1 Heartbeat 的安装
Heartbeat V1 的安装和配置比较简单，主要缺点是只能允许两个节点做高可用性配置，并且功能比较单
一。具体的安装和配置可以参见 IBM heartbeat 与 Apache Web 服务器。
Heartbeat V2 的安装基本上和 V1 差不多，同样可以采用 rpm 包安装或者源代码包安装等不同的安装方
式。建议采用源代码安装包安装的时候指定 prefix，这样在安装的时候 Heartbeat 将安装在指定的目录。具体的
安装步骤可以参见 heartbeat installation guide。
2.x 和 1.x 最主要的区别在于：
1) 2.x 支持 CRM 管理,资源文件由原来的 haresources 变为 cib.xml,
2) 支持 OCF 格式的 resource agent,
3) 可以对多资源组进行独立监控
4)支持多节点
当然，HeartbeatV2 也可以配置成 V1 那样的模式（把 CRM 置为 off），但是这个不是我们关注的地方。
Heartbeat V2 的配置文件主要包括三个配置文件：ha.cf，authkey 和 cib.xml。和 V1 的区别主要在于
cib.xml。在 V1 版本中替代 cib.xml 的是 haresources。幸运的是从版本 1 到版本 2 的这个配置文件的过渡可以通
过 haresources2cib.py 来实现，它将 haresources 资源文件转换成 cib.xml。 里编译好后自带有转换脚本,很方便
2.x
假设 haresources 文件如下,
node1 192.168.1.205 runhttpd.sh
node2 runjboss.sh
每一行表示一个资源组,
node1,node2 表示 prefered node,即该资源组优先在该 node 上运行,
192.168.1.205 与 runhttpd.sh 一起属于第一个资源组,为提供 http 服务的 vip,
7

8. 启动的时候从左到右依次运行脚本,关闭的时候从右到左依次关闭.
a):转换命令
/usr/local/lib/heartbeat/haresources2cib.py --stout -c /usr/local/etc/ha.d/ha.cf /usr/local/etc/ha.d/haresources
b):这一步可选
清空/usr/local/etc/ha.d/haresources
echo "" > /usr/local/etc/ha.d/haresources
3.2 配置 ha.cf
在启用 Heartbeat 之前，需要配置三个文件。第一个是 ha.cf，该文件位于在安装后创建的/etc/ha.d 目录中。
该文件中包括为 Heartbeat 使用何种介质通路和如何配置他们的信息。在源代码目录中的 ha.cf 文件包含了您可
以使用的全部选项，下面列出了部分选项，详细描述见 linux-HA 的 ha.cf 页：
serial /dev/ttyS0
使用串口 heartbeat－如果不使用串口 heartbeat，则必须使用其他的介质，如 bcast（以太网）heartbeat。用
适当的设备文件代替/dev/ttyS0。
watchdog /dev/watchdog
可选。通过 Watchdog 功能可以获得提供最少功能的系统，该系统不提供 heartbeat，可以在持续一份钟的
不正常状态后重新启动。该功能有助于避免一台机器在被认定已经死亡之后恢复 heartbeat 的情况。如果这种情
况发生并且磁盘挂载因故障而迁移（fail over），便有可能有两个节点同时挂载一块磁盘。如果要使用这项功
能，则除了这行之外，也需要加载“softdog”内核模块，并创建相应的设备文件。方法是使用命令“insmod
softdog”加载模块。然后输入“grep misc /proc/devices”并记住得到的数字（应该是 10）。然后输入”cat
/proc/misc | grep watchdog”并记住输出的数字（应该是 130）。根据以上得到的信息可以创建设备文件，
“mknod /dev/watchdog c 10 130”。
bcast eth1
表示在 eth1 接口上使用广播 heartbeat（将 eth1 替换为 eth0，eth2，或者您使用的任何接口）。
keepalive 2
设定 heartbeat 之间的时间间隔为 2 秒。
8

9. warntime 10
在日志中发出“late heartbeat“警告之前等待的时间，单位为秒。
deadtime 30
在 30 秒后宣布节点死亡。
initdead 120
在某些配置下，重启后网络需要一些时间才能正常工作。这个单独的”deadtime”选项可以处理这种情况。
它的取值至少应该为通常 deadtime 的两倍。
baud 19200
波特率，串口通信的速度。
udpport 694
使用端口 694 进行 bcast 和 ucast 通信。这是默认的，并且在 IANA 官方注册的端口号。udpport 必须在
bcast 和 ucast 之前指定，否则 udpport 指定的端口无效，bcast 和 ucast 将采用默认的 694 端口
auto_failback on
必须的。对于那些熟悉 Tru64 Unix 的人来说，heartbeat 的工作方式类似于“favored member“模式。在
failover 之前，haresources 文件中列出的主节点掌握所有的资源，之后从节点接管这些资源。 auto_failback 设
当
置为 on 时，一旦主节点重新恢复联机，将从从节点取回所有资源。若该选项设置为 off，主节点便不能重新获
得资源。该选项与废弃的 nice_failback 选项类似。如果要从一个 nice_failback 设置为 off 的集群升级到这个或更
新的版本，需要特别注意一些事项以防止 flash cut。请参阅 FAQ 中关于如何处理这类情况的章节。在 V2 中如
果 crm 开启了，那么它是无效的，被 cib.xml 中的 default_resource_stickiness 取代了。
node linuxha1.linux-ha.org
必须的。集群中机器的主机名，与“uname –n”的输出相同。
respawn <userid> <cmd>
可选的：列出将要执行和监控的命令。例如：要执行 ccm 守护进程，则要添加如下的内容：
respawn hacluster /usr/lib/heartbeat/ccm
使得 Heartbeat 以 userid（在本例中为 hacluster）的身份来执行该进程并监视该进程的执行情况，如果其
死亡便重启之。对于 ipfail，则应该是：
9

10. respawn hacluster /usr/lib/heartbeat/ipfail
注意：如果结束进程的退出代码为 100，则不会重启该进程。
ping ping1.linux-ha.org ping2.linux-ha.org ....
可选：列出 ping 节点。这些节点不是集群节点。他们是用来为 ipfail 等模块检查网络连接情况的。
ping_group <name> ping1.linux-ha.org ping2.linux-ha.org ....
可选：指定一个 ping 节点组。 ping 节点类似，但只要节点组中的任何一个节点可用，便认为该节点组
与
可用。组的名字可以是任意字符串，用来唯一标识该组。每个组必须出现在单独的行上。 ping 节点类似，节
与
点组也不是集群节点。他们与 ping 节点的功能相同，也是用来检查网络连接情况的。
3.3 配置 Authkeys
需要配置的第二个文件 authkeys 决定了您的认证密钥。共有三种认证方式：crc，md5，和 sha1。您可能会
问：“我应该用哪个方法呢？”简而言之：
如果您的 Heartbeat 运行于安全网络之上，如本例中的交叉线，可以使用 crc，从资源的角度来看，这是
代价最低的方法。如果网络并不安全，但您也希望降低 CPU 使用，则使用 md5。最后，如果您想得到最好的认
证，而不考虑 CPU 使用情况，则使用 sha1，它在三者之中最难破解。
文件格式如下：
auth <number>
<number> <authmethod> [<authkey>]
因此，对于 sha1，示例的/etc/ha.d/authkeys 可能是
auth 1
1 sha1 key-for-sha1-any-text-you-want
对于 md5，只要将上面内容中的 sha1 换成 md5 就可以了。 对于 crc，可作如下配置：
auth 2
2 crc
10

11. 不论您在关键字 auth 后面指定的是什么索引值，在后面必须要作为键值再次出现。如果您指定“auth
4”，则在后面一定要有一行的内容为“4 <signaturetype>”。
确保该文件的访问权限是安全的，如 600。其实也并不是“any text you want” 都可以，可以使用的字母个
数是有限制的。
3.4 配置 haresources
这里我们先介绍一下 haresources 的配置，因为 cib.xml 很容易有它生成。该文件列出集群所提供的服务以
及服务的默认所有者。 注意：两个集群节点上的该文件必须相同，否则会发生一些莫名其妙的事情。
在本文中我们假设要配置的 HA 服务为 Apache 和 Samba。集群的 IP 地址是必须的，并一定不能在
haresources 文件以外配置该地址！在 haresources 文件中需要如下内容：
linuxha1.linux-ha.org 192.168.85.3 httpd smb
该行指定在启动时，节点 linuxha1 得到 IP 地址 192.168.85.3，并启动 Apache 和 Samba。在停止时，
Heartbeat 将首先停止 smb，然后停止 Apache，最后释放 IP 地址 192.168.85.3。这里假设命令“uname –n”的输
出为“linuxha1.linux-ha.org”－如果输出为“linuxha1”，便应使用“linuxha1”。
注意：httpd 和 smb 分别是 Apache 和 Samba 的启动脚本。Heartbeat 会在以下路径中寻找有相同名字的启
动脚本：
/etc/ha.d/resource.d
/etc/init.d
这些脚本必须通过<scriptname> start 来启动服务，以及<scriptname> stop 来停止服务。您可以使用任何符
合这个标准的脚本来作为服务。
若要向教本传递参数，则格式应该为： <scriptname>::<argument> 因此若我们添加了一个服务“maid”，
他需要参数“vacuum”，则 haresources 文件中的该行需要修改为：
linuxha1 192.168.85.3 httpd smb maid::vacuum
这种方式为我们将 IP 地址作为服务提供了灵活性。在上面我们用的其实是简化的符号。该行实际应该是
（省略了 maid 服务）：
linuxha1 IPaddr::192.168.85.3 httpd smb
这里 IPaddr 是服务脚本的名字，其参数为 192.168.85.3。当然，您可以在目录/etc/ha.d/resource.d 中找到名
11

12. 为 IPaddr 的脚本。该脚本也允许您操作 IP 服务的子网掩码，广播地址和基本接口等参数。要指定有 32 个地址
的子网，您可以定义该服务为（不显式指定 IPaddr 因为这样不会有问题）：
linuxha1 192.168.85.3/27 httpd smb
这里指定 IP 地址为 192.168.85.3，子网掩码为 255.255.255.224，广播地址将取默认值为 192.168.85.31
（即该子网上的最高地址）。您可以指定的最后一个参数为广播地址。若要以 192.168.85.16 覆盖默认的广播地
址，可以这样写：
linuxha1 192.168.85.3/27/192.168.85.16 httpd smb
您可能想要知道是否需要指定上面的某个参数，这要视情况而定。如果您已经为服务的 IP 地址建立了一
条合适的路由（独立于 Heartbeat），并设置了正确的子网掩码和广播地址，那么您便不需要。然而情况并不
总是这样的，这便是这些选项存在的原因。另外，您可能有不止一个网络接口用于 IP 服务。下面将会讲述
Heartbeat 如何处理这种情况…
3.5 配置 cib.xml
Cluster Information Base (CIB)主要存储了两类集群的相关信息。一类主要是静态的配置信息以及该集群中
resource, cluster nodes 和 constraints 的定义。另一类信息是集群的当前状态信息。从这里我们可以看到：cib.xml
是一个动态的在运行过程中会改变的文件。也就是说当 heartbeat 启用的时候，无法手工修改 cib.xml，即使修
改保存了也无效。这里有个小技巧利用 cibadmin 工具在 Heartbeat 运行时修改某些配置信息。
下面是一个空 CIB 文件。
<cib>
<configuration>
<crm_config/>
<nodes/>
<resources/>
<constraints/>
</configuration>
12

13. <status/>
</cib>
它展示了 CIB 文件可能包含的一些主要元素。其中 crm_config 可能包含一些集群的配置信息，下面有一
个示例：
<crm_config>
<nvpair id="require_quorum" name="require_quorum" value="true"/>
<nvpair id="symmetric_cluster" name="symetric_cluster" value="true"/>
<nvpair id="suppress_cib_writes" name="suppress_cib_writes" value="true"/>
</crm_config>
而 node 项一般不用用户来填充，Heartbeat 将自己进行填充，填充以后的示例如下：
<node id="de937e3d-0309-4b5d-b85c-f96edc1ed8e3" uname="c001n01" type="member"/>
resources 项定义集群的各个资源和资源组，下面是一个简单的示例，Heartbeat 将每 2 分钟检测资源运行
情况（interval="120s"），如果发现资源不在，则尝试启动资源；如果 60s 后还未启动成功
（timeout="60s"），则资源切换向另节点。这里的时间都可以由用户修改。
<primitive class="heartbeat" id="runhttpd.sh_2" provider="heartbeat" type="runhttpd.sh">
<operations>
<op id="runhttpd.sh_2_mon" interval="120s" name="monitor" timeout="60s"/>
</operations>
</primitive>
另外一个例子是对 VIP 的监控,每 5S 监控一次，若 vip 失效，则尝试重启 vip,timeout 时间为 5s,若 5s 后
启动不成功，则切换向另节点。
<primitive class="ocf" id="IPaddr_192_168_1_205" provider="heartbeat" type="IPaddr">
13

14. <operations>
<op id="IPaddr_192_168_1_205_mon" interval="5s" name="monitor" timeout="5s"/>
</operations>
<instance_attributes id="IPaddr_192_168_1_205_inst_attr">
<attributes>
<nvpair id="IPaddr_192_168_1_205_attr_0" name="ip" value="192.168.1.205"/>
</attributes>
</instance_attributes>
</primitive>
由于 Heartbeat V2 和 V1 不同，它可以运行在多个节点上，所以它引入了 constraints 项来定义各节点和各
个资源之间的关系。有三种不同种类的 constraints，它们分别为：Locational，Co-Locational 和 Ordering 约束条
件。Co-Locational 用于指定两个资源是否必须或者不能运行在同一个节点上；Locational 规则使用 rules and
expressions 来指明资源可以运行在哪个节点上以及优先度；而 Ordering 规则指定资源启动的先后顺序。详细的
信息和示例可以查看 ClusterInformationBase/SimpleExamples。
所有的 constraints 都有一个 score 分值，它用来调整某个资源在某个符合条件的节点上的优先程度。score
分值有正有负，资源不会被分配到 score 为负的节点上。另外，Heartbeat 还定义了两个特殊的值：INFINITY
和-INFINITY，分别表示正无穷大和负无穷大。它们的运算关系如下。
INFINITY +/- -INFINITY : ERROR
INFINITY +/- int : INFINITY
-INFINITY +/- int : -INFINITY
另外，在使用某些 resource 时，constraints 包含了一些缺省的或者说是不言自明的规则。比如：对一个资
源组 resource group 来说，我们就没有必要特地在 constraints 中指明资源组中的 resource 必须允许在同一个节
点，并且它们应该按照列出来的顺序启动和按照逆序停止了。
跟 node 项一样，用户也不应该配置 status 项，它是 Heartbeat 用来记录和修改集群节点的地方。
14

15. 3.6 启动 HeartBeat
配置好了 HeartBeat 相关的配置文件以后，如果要启动 HeartBeatV2，还有一些小的步骤需要做。我们需
要把某些文件的属主和属组修改为特定的用户和组（一般是 hacluster 和 haclient），我们可以通过修改
heartbeat 目录权限的命令：find / -type d -name "heartbeat" -exec chown -R hacluster:haclient {} ;来实现。另外，
authkey 文件还需要 chmod 为 600。这样直接用 service heartbeat start 就可以启动 Heartbeat 了。Heartbeat 首先会和
其他的节点通讯，并且选出指定的协调仲裁者（Designated Coordinator）分配资源，协调集群的各节点。过一
段时间 Heartbeat 就会启动配置的资源了。用户可以通过查看对应的日志文件（如果没有修改的话应该是：
/var/log/ha-log）来查看 Heartbeat 启动的信息，如果启动不成功的话，具体的错误信息也会记录到这里，
Heartbeat 默认的日志记录级别比较低，所以该日志记录的信息也比较丰富。
你有可能会看到 warning 报错，说没有启动 Logiing deamon，形如：
heartbeat[22522]: 2008/07/25_09:52:32 WARN: Logging daemon is disabled --enabling logging daemon is
recommended。
其实这个是 Heartbeat 提醒你使用它的异步日志记录程序 logd，你可以在 ha.cf 中指定：“use_logd yes”来
使用这个程序，并配置 logd 的相关配置文件，这样可以避免日志记录的 I/O 操作阻塞 Heartbeat，影响性能。
你可以根据自己的需求调整 Heartbeat，不断实验，配置一个适合你的系统和要求的高性能，高可靠性的
Heartbeat 集群。
3.7 Heartbeat 管理工具
Heartbeat 提供了一系列的管理工具，包括 GUI 工具和 crm_*命令工具等，Heartbeat GUI Guide 能够实时
的监控节点和资源的运行情况，并且还能修改配置文件，比较方便使用。不过它主要用于 Linux 的 X server 环
境下。其他的 crm_*命令工具主要包括：crm_attribute, crm_failcount, crm_mon, crm_sh, crm_uuid, crm_diff,
crm_master, crm_resource , crm_standby, crm_verify 等。
另外 Heartbeat 软件包还附带了 hb_standby，hb_takeover 和
cl_status 等一些其他的工具。大部分工具都可以在 prefix/sbin 目录中找到（prefix 是指你在安装 Heartbeat 时
configure 的—prefix 指定的目录）。我们这里仅仅介绍一下用户查看和管理资源的 crm_resource 工具，其他的
工具可以在 Linux-HA 官方网页上找到相关的用法。
CRM 管理程序 crm_resource 功能示例:
Examples
1)查看所有资源
15

16. crm_resource -L
2)查看资源跑在哪个节点上
crm_resource -W -r runhttpd.sh_2
resource runhttpd.sh_2 is running on: server1
crm_resource -W -r runhttpd.sh_2
resource runhttpd.sh_2 is NOT running
4)启动/停止资源
crm_resource -r runhttpd.sh_2 -p target_role -v started
crm_resource -r runhttpd.sh_2 -p target_role -v stopped
5)查看资源在 cib.xml 中的定义
crm_resource -x -r runhttpd.sh_2
6)将资源从当前节点移动向另个节点
crm_resource -M -r runhttpd.sh_2
7)将资源移向指定节点
crm_resource -M -r runhttpd.sh_2 -H c001n02
8)允许资源回到正常的节点
crm_resource -U -r runhttpd.sh_2
NOTE: the values of resource_stickiness and default_resource_stickiness may mean that it doesnt move back. In
such cases, you should use -M to move it back and then run this command.
9)将资源从 CRM 中删除
crm_resource -D -r runhttpd.sh_2 -t primitive
10)将资源组从 CRM 中删除
crm_resource -D -r my_first_group -t group
16

17. 11)将资源从 CRM 中禁用
crm_resource -p is_managed -r runhttpd.sh_2 -t primitive -v off
12)将资源从新从 CRM 中启用
crm_resource -p is_managed -r runhttpd.sh_2 -t primitive -v on
13)Resetting a failed resource after having been manually cleaned up
crm_resource -C -H c001n02 -r runhttpd.sh_2
14)检查所有节点上未在 CRM 中的资源
crm_resource -P
15)检查指定节点上未在 CRM 中的资源
crm_resource -P -H c001n02
Querying a parameter of a resource. Say the resource is the following:
<primitive id="example_mail" class="ocf" type="MailTo" provider="heartbeat">
<instance_attributes id="example_mail_inst">
<attributes>
<nvpair id="example_mail_inst_attr0" name="email" value="root"/>
<nvpair id="example_mail_inst_attr1" name="subject" value="Example Failover"/>
</attributes>
</instance_attributes>
</primitive>
You could query the email address using the following:
crm_resource -r example_mail -g email
16)设置资源的某个属性
17

18. crm_resource -r example_mail -p email -v "myemailaddress@somedomain.com"
18

19. 4 HEARTBEAT 基础架构
Heartbeat 基本上可以分为三层：heartbeat 层，CCM 层和 CRM 层。
heartbeat 层主要负责底层信息交互和基础构架；CCM 层比 heartbeat 更加抽象一点，主要负责节点之间
的通信和它们之间的关系的维护；CRM 层则更加抽象，它是整个 Heartbeat 的“大脑”，它不区分各个
resource 的不同点，只是负责各 resource 的在各节点之间的分配，当某节点崩溃时，将该节点的资源转移到其
他节点。
图 1、HeartBeat 的基础架构图
19

20. 下面的两节（5，6 节）主要摘录于 Alibaba DBA Team 中的两篇文章，主要介绍了 Heartbeat 的各个模块
以及资源转移时选择哪个节点。
20

21. 5 HEARTBEAT 各模块分析
5.1 heartbeat 模块：
整个 Heartbeat 软件的通信模块，各个节点之间的任何通信都是通过这个模块完成。这个模块会根据
不同类型的通信启动不同的事件 handler，当监听到不同类型的通信请求后会分给不同的 handler 来处
理。这个从整个 Heartbeat 的启动日志中看出来。
5.2 CRM： cluster resource manager
从这个名字就可以看出这个模块基本上就是 v2 的 heartbeat 的一个集群中心，整个系统的一个大脑
了，他主要负责整个系统的各种资源的当前配置信息，以及各个资源的调度。也就是根据各资源的配
置信息，以及当前的运行状况来决定每一个资源（或者资源组）到底该在哪个节点运行。不过这些事
情并不是他直接去做的，而是通过调度其他的一些模块来进行。
他通过 heartbeat 模块来进行节点之间的通信，调度节点之间的工作协调。随时将通过 heartbeat 模块
收集到的各个成员节点的基本信息转交给 CCM 某块来更新整个集群的 membership 信息。他指挥
LRM（local resource manager）对当前节点的各资源执行各种相应的操作（如 start、stop、restart 和
monitor 等等），同时也接收 LRM 在进行各种操作的反馈信息并作出相应的决策再指挥后续工作。另
外 CRM 模块还负责将各个模块反馈回来的各种信息通过调用设定的日志记录程序记录到日志文件中。
5.3 LRM： local resource manager
LRM 是整个 Heartbeat 系统中直接操作所管理的各个资源的一个模块，负责对资源的监控，启动，
停止或者重启等操作。这个模块目前好像支持有四种类型的资源代理（resource agent）：heartbeat 自身
的，ocf（open cluster framework），lsb（linux standard base，其实就是 linux 下标准的 init 脚本），还有
一种就是 stonith。stonith 这种我还不是太清楚是一个什么类型的。
四种类型的 resource agent 中的前三种所调用的脚本分别存如下路径：
heartbeat：/etc/ha.d/resource.d/
ocf:/usr/lib/resource.d/heartbeat/
lsb:/etc/init.d/
21

22. LRM 就是通过调用以上路径下面的各种脚本来实现对资源的各种操作。每一种类型的脚本都可以由
用户自定义，只要支持各类型的标准即可。实际上这里的标准就是接受一个标准的调用命令和参数格
式，同时返回符合标准的值即可。至于脚本中的各种操作时如何的 LRM 并不 care。
5.4 PE： CRM Policy Engine
他主要负责将 CRM 发过来的一些信息按照配置文件中的各种设置来进行计算，分析。然后将结果信
息按照某种固定的格式通过 CRM 提交给 TE（Transition engine）去分析出后续需要采取的相应的
action。 需要计算分析的信息主要是当前有哪些节点，各节点的状况，当前管理有哪些资源，各资源
PE
当前在哪一个节点，在各个节点的状态如何等等。
5.5 TE： Transition engine
主要工作是分析 PE 的计算结果，然后根据配置信息转换成后续所需的相应操作。个人感觉 PE 和 TE
组合成一个类似于规则引擎实现的功能，而且 PE 和 TE 这两个模块只有在处于 active 的节点被启动。
另外 PE 和 TE 并不直接通信，而都是通过 Heartbeat 的指挥中心 CRM 来传达信息的。
5.6 CIB： cluster information base
CIB 在系统中充当的是当前集群中各资源原始配置以及之后动态变化了的状态，统计信息收集分发
中心，是一个不断更新的信息库。当他收集到任何资源的变化，以及节点统计信息的变化后，都会集
成整合到一起组成当前集群最新的信息，并分发到集群各个节点。分发动作并不是自己和各个节点通
信，同样也是通过 heartbeat 模块来做的。
CIB 收集整理并汇总出来的信息是以一个 xml 格式保存起来的。实际上 Heartbeat v2 的资源配置文件
也就是从 haresources 迁移到了一个叫 cib.xml 文件里面。该文件实际上就是 CIB 的信息库文件。在运行
过程中，CIB 可能会常读取并修改该文件的内容，以保证信息的更新。
5.7 CCM： consensus cluster membership
CCM 的最主要工作就是管理集群中各个节点的成员以及各成员之间的关系。他让集群中各个节点有
效的组织称一个整体，保持着稳定的连接。heartbeat 模块所担当的只是一个通信工具，而 CCM 是通过
22

23. 这个通信工具来将各个成员连接到一起成为一个整体。
5.8 LOGD： logging daemon（ non-blocking）
一个无阻塞的日志记录程序，主要负责接收 CRM 从各个其他模块所收集的相关信息，然后记录到
指定额度日志文件中。 logd 接收到日志信息后会立刻返回给 CRM 反馈。
当 并不是一定要等到将所有信
息记录到文件后再返回，日志信息的记录实际上是一个异步的操作。
5.9 APPHBD： application heartbeat daemon
apphbd 模块实际上是给各个模块中可能需要用到的计时用的服务，是通过 watchdog 来实现的。这个
模块具体的细节我还不是太清楚。
5.10 RMD： recovery manager daemon
主要功能是进程恢复管理，接受从 apphbd 所通知的某个（或者某些）进程异常退出或者失败或者
hang 住后的恢复请求。RMD 在接受到请求后会作出 restart（如果需要可能会有 kill）操作。
23

24. 6 HEARTBEAT 的切换策略 -积分统计方法
在 V2 的 Heartbeat 中，为了将资源的监控和切换结合起来，同时支持多节点集群，Heartbeat 提供了
一种积分策略来控制各个资源在集群中各节点之间的切换策略。通过该积分机制，计算出各节点的的
总分数，得分最高者将成为 active 状态来管理某个（或某组）资源。
如果在 CIB 的配置文件中不做出任何配置的话，那么每一个资源的初始分数（resource-stickiness）
都会是默认的 0，而且每一个资源在每次失败之后所减掉的分数（resource-failure-stickiness）也是 0。如
此的话，一个资源不论他失败多少次，heartbeat 都只是执行 restart 操作，不会进行节点切换。一般来说，
resource-stickiness 的值都是正数，resource-failure-stickiness 的值都是负数。另外还有一个特殊值那就是
正无穷大（INFINITY）和负无穷大（-INFINITY）。如果节点的分数为负分，那么不管什么情况发生，
该节点都不会接管资源（冷备节点）。随着资源的各种状态的发生，在各节点上面的分数就会发生变
化，随着分数的变化，一旦某节点的分数大于当前运行该资源的节点的分数之后，heartbeat 就会做出
切换动作，现在运行该资源的节点将释放资源，分数高出的节点将接管该资源。
在 CIB 的配置中，可以给每个资源定义一个分数，通过 resource-stickiness 来设置，同样也可以设置
一个失败后丢失的分数，通过 resource-failure-stickiness 来设置。如下：
<primitive id=”mysql_db” class=”ocf” type=”mysql” provider=”heartbeat”>
<meta_attributes id=”mysql_db_meta_attr”>
<attributes>
<nvpair name=”resource_stickiness” id=”mysql_db_meta_attr_1″ value=”100″/>
<nvpair name=”resource_failure_stickiness” id=”mysql_db_meta_attr_2″ value=”-100″/>
</attributes>
</meta_attributes>
…
<primitive />
上面的配置就是给 mysql_db 这个 resource 配置了两个分数，成功运行的时候所得到的分数
（resource_stickiness）和运行失败会丢失的分数（resource_failure_stickiness），两项分数值一样多，成
功则得 100 分，失败则-100 分。
24

25. 除了可以通过给每个资源单独设置两项的分数之外，也可以将所有的 resource 设置成相同的分数，
如下：
<configuration>
<crm_config>
<cluster_property_set id=”cib-bootstrap-options”>
<attributes>
…
<nvpair id=”default-resource-failure-stickiness” name=”default-resource-failure-stickiness” value=”-100″/>
<nvpair id=”default-resource-stickiness” name=”default-resource-stickiness” value=”100″/>
…
</attributes>
</cluster_property_set>
</crm_config>
…
在这个配置中，就是给所有资源设置了两个默认的分数，省去单独每个资源都设置的麻烦。当然，
如果在设置了这个 default 分数之后，同时也给部分或者全部资源也设置了这两个分数的话，将取单独
设置的各个资源设置的分数而不取默认分数。
除了资源的分数之外，节点自身同样也有分数。节点分数可以如下设置：
…
<constraints>
<rsc_location id=”rsc_location_group_mysql” rsc=”group_mysql”>
<rule id=”mysql1_group_mysql” score=”200″>
<expression id=”mysql1_group_mysql_expr” attribute=”#uname” operation=”eq” value=”mysql1″/>
</rule>
25

26. <rule id=”mysql2_group_mysql” score=”150″>
<expression id=”mysql2_group_mysql_expr” attribute=”#uname” operation=”eq” value=”mysql2″/>
</rule>
</rsc_location>
</constraints>
…
注意这里节点分数的设置是放在 configuration 配置项里面的 constraints 配置项下的，通过 rule 来设置。
这里是通过节点主机名来匹配的（实际上 heartbeat 的很多配置中对主机名都是很敏感的）。这里的
value 值就是节点的主机名，rule 里面的 score 就是一个节点的分数。
通过上面的配置，我们可以作出如下计算：
a、在最开始，两边同时启动 heartbeat 的话，两边都没有开始运行这个 resource，resource 本身没有分
数，那么仅仅计算节点的分数：
mysql1 的分数：node+resource+failcount*failure=200+0+(0*(-100))=200
mysql2 的分数：node+resource+failcount*failure=150+0+(0*(-100))=150
heartbeat 会做出选择在 mysql1 上面运行 mysql_db 这个资源，然后 mysql1 的分数发生变化了，因
为有资源自身的分数加入了：
mysql1 的分数：node+resource+failcount*failure=200+100+(0*(-100))=300
mysql2 的分数：node+resource+failcount*failure=150+0+(0*(-100))=150
b、过了一段时间，heartbeat 的 monitor 发现 mysql_db 这个资源 crash（或者其他问题）了，分数马上
会发生变化，如下：
mysql1 的分数：node+resource+failcount*failure=200+100+(1*(-100))=200
mysql2 的分数：node+resource+failcount*failure=150+0+(0*(-100))=150
heartbeat 发现 mysql1 节点的分数还是比 mysql2 的高，那么资源不发生迁移，将执行 restart 类操作。
c、继续运行一段时间发现又有问题（或者是 b 后面 restart 没有起来）了，分数又发生变化了：
mysql1 的分数：node+resource+failcount*failure=200+100+(2*(-100))=100
26

27. mysql2 的分数：node+resource+failcount*failure=150+0+(0*(-100))=150
这时候 heartbeat 发现 mysql2 节点比 mysql1 节点的分数高了，资源将发生迁移切换，mysql1 释
mysql_db 相关资源，mysql2 接管相关资源，并在 mysql2 上运行 mysql_db 这个资源。这时候，节点的分
数又会发生变化如下：
mysql1 的分数：node+resource+failcount*failure=200+0+(2*(-100))=0
mysql2 的分数：node+resource+failcount*failure=150+100+(0*(-100))=250
这时候如果在 mysql2 上面三次出现问题，那么 mysql2 的分数将变成-50，又比 mysql1 少了，资源将
迁移回 mysql1，mysql1 的分数将变成 100，而 mysql2 的分数将变成-150，因为又少了资源所有者的
那 100 分。到这里，mysql2 节点的分数已经是负数了。heartbeat 还有一个规则，就是资源永远都不会迁
移到一个分数分数是负数的节点上面去。也就是说从这以后，mysql1 节点上面不管 mysql_db 这个资源
失败多少次，不管这个资源出现什么问题，都不会迁移回 mysql2 节点了。一个节点的分数会在该节点
的 heartbeat 重启之后被重置为初始状态。或者通过相关命令来对集群中某个节点的某个资源或者资源
组来重置或者查看其 failcount，如下：
crm_failcount -G -U mysql1 -r mysql_db #将查看 mysql1 节点上面的 mysql_db 这个资源的 failcount
crm_failcount -D -U mysql1 -r mysql_db #将重置 mysql1 节点上面的 mysql_db 这个资源的 failcount
当然，在实际应用中，我们一般都是将某一些互相关联的资源放到一起组成一个资源组，一旦资源
组中某资源有问题的时候，需要迁移整个资源组的资源。这个和上面针对单个资源的情况实际上没有
太多区别，只需要将上面 mysql_db 的设置换到资源组即可，如下：
…
<group id=”group-mysql”>
<meta_attributes id=”group-mysql_meta_attr”>
<attributes>
<nvpair id=”group-mysql_meta_attr-1″ name=”resource_stickiness” value=”100″/>
<nvpair id=”group-mysql_meta_attr-1″ name=”resource_failure_stickiness” value=”-100″/>
</attributes>
</meta_attributes>
<primitive>
27

28. …
</primitive>
…
</group>
…
这样，在该资源组中任何一个资源出现问题之后，都会被认为该资源组有问题，当分数低于其他节
点出现切换的时候就是整个资源组的切换。
另外，对于 INFINITY 和-INFINITY 这两个值，实际上主要用途就是为了控制永远不切换和只要失
败必须切换用的。因为代表的意思就是拥有正无穷大的分数和失败就到负无穷大，主要用来满足极端
规则的简单配置项。
总的来说，一项资源（或者资源组）在一个节点运行迁移到另一个节点之前，可以失败的次数的计
算公式可以如下表示：
(nodeA score - nodeB score + stickiness)/abs(failure stickiness)，即为 A 节点分数减去 B 节点分数，再加
上资源运行分数后得到的总分数，除以资源失败分数的绝对值。
28

29. 7 RESOURCE AGENT 介绍
CRM 可以忽略各 resource 之间的区别的诀窍在于 resource agent。resource agent 就像是硬件驱动程序一样，
把底层的 resource 包裹在自己内部，而提供给 CRM 的是统一的操作接口。resource agent 在 Heartbeat 中主要分
为三类，按照 Heartbeat 推荐度从大到小排列分别为：OCF，LSB 和 Heartbeat 自身定义的 resource agent。按照
复杂度和健壮性而言，它们也是按照从大到小的顺序排列的。
7.1 LSB resource agent
LSB resource agent 一般是由操作系统或者软件发行者定义的 shell 脚本，但是为了能够应用于 Heartbeat
V2，它们必须符合 LSB Spec 的限制。它必须实现的三种操作分别是：start, stop, status。注意：LSB resource
agent 不能附带参数和选项值。对于 start 操作来说，在节点中启动已存在 resource 时，不应该返回错误信息，
而应该返回 0 以表示成功（非 0 表示失败）。同样的，stop 一个已经停止的 resource 也是允许的，并应该返回
0 以表示成功。status 操作用来确定 resource 的运行状态。 resource 正确运行的节点上进行 status 操作，应该返
在
回 0 以及其他正常的打印输出，在 resource 已经停止的节点上进行 status 操作应该返回 3 以及其他正常的打印
输出。另外，你可以通过某些操作检查提供的初始化脚本是否符合 Heartbeat 对 LSB resource agent 的要求。
7.2 Heartbeat resource agent
Heartbeat resource agent 基本上和 LSB resource agent 差不多，但是在状态信息操作（status）上和 LSB
resource agent 存在差异。
它要求定义三种必须的操作，分别是 start, stop, status。 LSB 一样，Heartbeat resource
和
agent 的 start 操作将仅仅在 status 显示某个 resource 没有被启动时，才开启某个节点的 resource；并且在一个
集群中，Heartbeat 不会在同一时间在不同的节点上开启同一个 resource。stop 操作保证节点上的 resource 不再
运行，在 stop 某个 resource 时，Heartbeat resource agent 会去查看它是否已经被停止了，但是对于那些它不知
道是否停止的 resource，Heartbeat 将采取强制措施，来保证 resource 被明确的停止掉了。比如，Heartbeat 有可
能在 stop 失败以后重启某个节点以清除错误。status 操作用来确定 resource 的运行状态。对于 Heartbeat resource
agent 来说，它应该正确的报告它的运行状况：在 resource 运行正常的时候打印 OK 或者 running，否则就不
应该打印这样的信息。注意：Heartbeat resource agent 不检查 status 的返回值（它是为了兼容早期的 Linux 脚本，
这些脚本 status 操作并不返回正确的返回值，但是会正确的打印 OK 或 running 值）。status 操作可以发生在
start 操作之前以检查 resource 是否已经在运行了，它也可以用于释放资源。在 V1 版本中，如果 stop 后的
status 操作表明该资源仍然在运行，那么机器将被重启以保证 resource 确实被停止，但是在开启了 CRM 的
V2 版本中并不这么做，它使用 stonith。Heartbeat 和 LSB 另外的一个不同点在于，它可以接受参数。这些参数
将被置于操作名称之前，如下所示：
如果在 haresources 行中 IPaddr 脚本（Heartbeat resource agent）的参数为 10.10.10.1，表示为：
IPaddr::10.10.10.1
那么实际上 Heartbeat 调用真正的 IPaddr 脚本的 start 操作时对应为：
29

30. IPaddr 10.10.10.1 start
7.3 OCF resource agent
OCF specification 实际上是对 LSB 的扩展，它的一些 resource agent 脚本文件可以在/usr/lib/ocf/resource.d/
中找到，/usr/lib/ocf/resource.d/heartbeat 中的那些都是随 Heartbeat 软件包附带的 OCF resource agent 脚本。
{provider}表示提供者，你可以在/usr/lib/ocf/resource.d/增加你自己的目录，然后把 OCF resource agent 脚本放
在这个目录中。为了方便编写 OCF resource agent，很多返回码和通用的 OCF 函数被放在/usr/lib/heartbeat/ocf-
shellfuncs（实际上在最新的版本中（V2.1.3），现在这个文件只是引用了
$OCF_ROOT/resource.d//heartbeat/.ocf-shellfuncs），你可以方便的把它 include 进来。注意：Heartbeat 实现的
OCF Spec 和标准本身并不完全一致，但是，这些改变并没有违反 OCF specification。另外，Heartbeat 提供了
一个 ocf-tester 的脚本用于方便用户编写和测试 OCF resource agent。
普通的 OCF resource agent 必须包括以下四个操作：start, stop, monitor, meta-data。start 操作启动 resource。
如果 resouce 被正确启动了，那么返回 0，否则返回除 7 以外的任何错误值。 操作停止 resource。 resouce
stop 当
被正确启动时，返回 0，否则返回除 7 以外的任何错误值。monitor 操作监控 resource 的健康状况，返回 0 表
示 resource 正常运行，7 表示它已经被停止，其他任何值表示错误。meta-data 操作以 xml 摘要（xml snippet）
的形式提供这个 resource 的信息。OCF Spec 实际上严格定义了每个操作的返回值。我们必须遵守这些规定，
如果返回了错误的返回值，Heartbeat 将会出现一些莫名其妙的错误。特别要注意的是，Heartbeat 必须区分
resource 的完全停止状态和有错误的，不确定的状态。另外，OCF resource agent 应该支持 validate-all 操作，该
操作用于验证环境中的配置 paremeters。如果这些参数有效的的，返回 0；如果无效返回 2；如果 resource 未
配置返回 6；如果找不到了那个被 resource agent 认为正常运行的软件返回 5。对于 cloned 和 multi-state
resources 来说应该支持其他的操作：promote, demote 和 notify。promote 操作把本地的 resource 提升为
master/primary 状态，应该返回为 0；demote 操作把本地的 resource 降级为 slave/secondary 状态，应该返回为
0；notify 被 heartbeat 程序用来给 agent 发送 pre 和 post 通知事件，通知 resource 正在发生或者已经发生的事
情，必须返回 0。另外还有两个 OCF 指定的但是 Heartbeat 目前不支持的操作：reload 和 recover。reload 操作在
不影响服务的情况下 resource 的配置信息。recover 操作是 start 操作的一个变体，它尝试着在本地恢复一个
resource。
另外，OCF 也能够接受参数，这些参数可以告诉它要控制的是 resource 的哪一个实例，或者告诉它对
这个实例应该怎么做。OCF 的参数和 Heartbeat resource agent 不同。OCF 参数通过环境变量传递参数，这些参
数都以：OCF_RESKEY_开头。比如，以 ip 作为参数传递给脚本将设置环境变量：OCF_RESKEY_ip。
另外，linux-HA 列举了一些用户在编写 OCF 脚本中经常容易犯的错误。我们应该要注意避免。详细的
OCF resource agent 信息可以查看 OCF Spec。
7.4 小结
下面的列表详细列出的三类 resource agent 的一些特性：
30

31. 必须支持的操作 支持 存放目录 定义标准
parameters
OCF start,stop,monitor,meta_dat 支持 /usr/lib/ocf/resource.d/{provider} OCF Spec
a
LSB start,stop,status 不支持 /etc/init.d LSB Spec
HeartBeat start,stop,status 支持 /etc/ha.d/resource.d 和 /etc/init.d Heartbeat
表 1、三类 resource agent 的一些特性
31

32. 8 相关文档列表
Linux-HA 入门指南
heartbeat installation guide
Heartbeat V2 模块分析
Heartbeat 的切换策略-积分统计方法
heartbeat 2.x style 的配置(使用 cib.xml)
Linux Standard Base (LSB) Specifications
Open Clustering Framework Resource Agent API
mon - Service Monitoring Daemon
Heartbeat GUI Guide
Getting Started with Linux-HA (Heartbeat 2)
32