What is the Linux High Availabi
简介：
高可用性群集的出现是为了使群集的整体服务尽可能可用，以便考虑计算硬件和软件的易错性。如果高可用性群集中的主节点发生了故障，那么这段时间内将由次节 点代替它。次节点通常是主节点的镜像，所以当它代替主节点时，它可以完全接管其身份，并且因此使系统环境对于用户是一致的。
什么叫心跳：就是将多台服务器用网络连接起来，而后每一台服务器都不停的将自己依然在线的信息很简短很小的通告给同一个网络中的备用服务器的主机，告诉其实主机自己依然在线，其它服务器收到这个心跳信息就认为本机是在线的，尤其是主服务器。
心跳信息怎么发送，由谁来收，其实就是进程中的通信两台主机是没法通信的，只能利用网络功能，通过进程监听在某一套接字上，实现数据发送，数据请求，所以多台服务器就得运行同
等的进程，这两个进程不停的进行通信，主节点(主服务器)不停的向对方同等的节点发送自己的心跳信息，那这个软件就叫高可用的集群的基准层次，也叫心跳信
息传递层以及事物信息的传递层，这是运行在集群中的各节点上的进程，这个进程是个服务软件，关机后需要将其启动起来，主机间才可以传递信息的，一般是主节
点传给备节点。在每个节点上，CRM维护群集信息库 (CIB)，包含所有群集选项、节点、资源及其关系和当前状态的定义。如果选择群集中的CRM为指定协调 程序(DC)，则意味着它具有主CIB。群集中的所有其他CIB是此主CIB的 复本。对CIB的常规读写操作通过主CIB进行排序。DC是群集中唯一可以 决定需要在整个群集执行更改（例如节点屏障或资源移动)的实体。
群集信息库(CIB)
群集信息库是整个群集配置和当前状态在内存中的XML表示。它包含所有 群集选项、节点、资源、约束及其之间的关系的定义。CIB还将更新同步到 所有群集节点。群集中有一个主CIB，由DC维护。所有其他节点包含一个CIB副本.
策略引擎(PE)
每当指定协调程序需呀进行整个鮮集的更改（对新CIB做出反应），策略引擎就会根据群集的当前状态和配置计算集群的下一个状态，PE还生成个转換图，包含用于达到下一个群集状态的（资源）操作和依赖性的列表，PE在每个节点上都运行以加速DC故障转移。
本地资源管理器(LRM)
LRM
代表CRM调用本地资源代理.因此它可以执行启动/停止/监视操作并将结果报告给CRM。它还隐藏资源代理支持的脚本标准（OCF、LSB、Heartbeat VI)之间的区别。LRM是其本地节点上所有资源相关信息的权威来源.
资源层
最高层是资源层。资源层包括一个或多个资源代理(RA)。资源代理是为启动、 停止和监视某种服务(资源) 而编写的程序，通常是服务控制脚本。资源代理仅由LRM调用。第三方可将他们自己的代理放在文件系统中定义的位皆，这样就为各自的软件提供了现成群集集成.所谓的资源：以web为例，vip是资源，web服务也是资源，还有网页面也是资源，一个服务包括多个资源，而像web的共享存储也是资源等等，不同的服务所需要的资源也是不同的，而共享存储是高可用集群中最难解决的问题。如是主节点挂了，多个备节点怎么样来选择一个备节点来做为提供服务的一个节点呢，而这种应该选择哪个备用节点来做为提供服务的机制就叫做集群事物决策的过程。ha_aware：如果一个应用程序自己能够利用底层心跳信息传递层的功能完成集群事物决策的过程的软件就叫ha_aware。 DC：Designated Coordinator选定的协调员，当DC所在的主机挂了就会先选出一个DC，再由DC做出事物的决策。注意：在高可用集群中最核心的、最底层的管理的单位叫资源，把资源组合在一起来组合成一个服务。高可用集群中任何资源都不应该自行启动，而是由CRM管理启动启动的；CRM：Cluster Resources Manager集群资源管理，真正做出决策的是CRM。
heartbeat v1版时就有了资源管理的概念，而v1版的资源就是heartbeat自带的，叫haresources，这个文件是个配置文件；而这个配置文件接口就叫haresources；
heartbeat v2第二版的时候，heartbeat被做了很大的改进，自己可以做为一个独立进程来运行，并而可以通过它接收用户请求，它就叫crm，在运行时它需要在各节点上运行
一个叫crmd的进程，这个进程通常要监听在一个套接字上，端口就是5560，所以服务器端叫crmd，而客户端叫crm(可以称为crm
shell)，是个命令行接口，通过这个命令行接口就可以跟服务器端的crm通信了，heartbeat也有它的图形化界面工具，就叫
heartbeat-GUI工具，通过这个界面就可以配置进行。
第三版heartbeat v3，被独立成三个项目heartbeat、pacemaker(心脏起博器)、cluster-glue(集群的贴合器)，架构分离开来了，可以结合其它的组件工作了。
RA：resource agent资源代理，其
实就是能够接收CRM的调度用于实现在节点上对某一个资源完成管理的工具，这个管理的工具通常是脚本，所以我们通常称为资源代理。任何资源代理都要使用同
一种风格，接收四个参数：{start|stop|restart|status}，包括配置IP地址的也是。每个种资源的代理都要完成这四个参数据的输
出。
当某一个节点出现故障时，其上面的资源被自动转移到其它正常的备用节点上并启动的这个过程叫故障转移，也称为失效转移(failover)。
如果出现故障的节点又回来的，那我们就要把这个节点添加回来，那这个添加回来的过程我们就叫失效转回，也称故障转回(failback)。
资源争用、资源隔离：
万一集群发生分裂时，为了避免不再成为集群上的节点继续使用资源而发生资源争用情况，导致有挂载文件系统的系统文件发生崩溃，成为新的集群的就会给不再成为集群的节点补一枪，让不是集群节点的服务死透，不再接收请求，这就叫stonith(shoot the other node in the head)，而这种功能就叫资源隔离。争用共享存储的后果是非常严重的，轻则共享存储崩溃，重则整个文件系统都崩溃，数据全部丢失。
资源隔离有两种级别：
节点级别：这种就叫STONITH，这种就是不管怎么样直接把对方的电源给切断，一般这种主机都是连接到电源交换机上的。
资源级别：这种需要依赖一些硬件设备来完成，比如连接到共享存储的光纤交换机，把需要踢除出去的节点的光纤接口屏蔽了，这种就叫资源级别的隔离。
对于服务器左右分隔的这种情况通常称为脑裂(brain-split)，左右不协调了，在高可以用集群中避免资源争用完成资源隔离是我们在设计高可用集群中必须要考滤的问题。
两个节点的模式下，一旦发生集群分隔以后，其中一个节点发生故障，在我们无法判定哪个节点不正常的时候，而正常的节点一定是可以连到互联网上去的，这样的话就说明正常的节点是可以跟前端路由通信的，所以我们就把前端路由当成第三个节点，这里我们称为ping节点，当每个节点联系到对方之后先去ping前端的节点，如果可以ping通，那就说明自己是正常的，就说明该节点是有多票法定票数的节点，而前端的ping节点就叫仲裁设备，帮助节点判断哪个节点是优胜一方的，偶数节点数时就会借助于仲裁设备。
RHCS不是使用ping节点来判断的，他是使用了一个共享存储的设备，偶数个节点处于活动的节点不断的往磁盘中写数据，按照心跳信息频率每隔一个信息频率就往磁盘里写一个数据位，只要这个设备每隔一个心跳时间间隔就更新一次数据位，就说明这个设备处于活动状态的，如果发现节点多次没有写数据位了就认为节点挂了，这种也叫仲裁设备(qdisk)。仲裁设备又有两种：分别为ping node和qdisk；
那心跳是怎么传递的呢，在多台主机之机又是怎么互相工作良好呢，如图：高可用主从的两个节点；
信息层(Messaging Layer)：主从两个节点的心跳信息都要基于信息层来实现，也叫底层基础架构层，用于传递心跳信息的，而能够实现这种功能的有Corosync和heartbeat，corosync是openAIS的一个组件，
资源分配层(Resource Allocation)：也叫资源管理器层，这层的核心组件叫CRM(Cluster Resourcce Manager集群资源管理器)，CRM上必须有一个资源被推举成为管理者的，叫Leader，它的工作是决策集群中的所有事物的，这里称为DC(Designated Coordinator指定协调员)，任何DC上会额外运行两个进程，一个叫PE(Policy Engine策略引擎)，所谓策略引擎就是将底层信息层收集整个集群中所有节点上的信息在本地生成一个大图big pic来策略节点运行在哪个节点上，并通知其实节点上的资源管理器来实现资源的启动和关闭等操作；一个叫TE(Transition Engine 传输引擎)，它主要是把PE做出的决策通告给对应节点的CRM；
集群资源管理器必须借助于Messageing Layer通告给每一个节点，自动的广播或组播给每一个节点，这样就保证了每一个节点上的信息都是一样的，而这些数据在计算机中又怎么样来交互数据的呢，这里就要基于扩展标记语言来实现数据的格式传递的，这种叫半结构化数据基于XML的，所以在各节点之间实现配置信息保存都是通过XML文件保存的，而要能够理解这个XML文件保存的信息使用到一个工具叫CIB(Cluster Information Base集群信息库)；只要能连接到CRM上都可以去配置这个XML文件，首先它会先保存到DC的XML中，然后再由DC同步支每个节点上的XML文件中去的；
Resources层：而
PE(策略引擎)就是根据XML这个库来获取资源的配置信息的，并通过Messaging
Layer不获取当前节点的活动信息，而后做出决策，一旦做得决策就要启动资源了；所以PE借助于本地的Messaging
Layer通知给其实节点的集群信息库来实现对某些资源信息的传递，比如说通告其它CRM要启动某一资源了，收到信息后CRM并不负责启动，转由
LRM(Local Resource Manager本地资源管理)启动，每个节点上都运行在这个LRM，而并发资源又借助于RA(Resource
Agent资源代理)实现资源管理，这就是它的工作原理；CRM负责收集信息，推举为DC的由PE运行，PE负责整合整个集群中的所有资源，并确保某些资
源在合适的节点上运行起来，一旦做出决策就会通告给其它节点上的CRM，对应节点上的CRM收到通告以后会调用自己的LRM，由LRM指挥RA完成相关的操作；
处理流程：
linux 高可用 使用 Pacemaker作为CRM, CRM作为守护程序执行(crmd)，它在每个集群节点上都有一个实例。Pacemaker 通过将某个crmd实例选为主实例，从而集中了所有的群集决策制定。如果选定的crmd进程（或它所在的节点)出现故障，则将建立一个新的进程。
在每个节点上保留了一个CIB，它反映了群集的配置和群集中所有资源的当前状态。CIB的内容会在整个群集的同步过程中自动保留下来。
群集中执行的许多操作都将导致整个群集的更改。这些操作包括添加或删除群集资源、更改资源约束等。了解执行这样的操作时群集中会发生的状况是很重要。
例如，假设您要添加一个群集IP地址资源。为此，您可以使用一种命令行工具， 或GUI修改CIB您不必在DC上执行此操作，可以使用群集中任何节点上的任何工具，此操作会被传送到DC上。然后DC将把此CIB更改复制到所有群集节点。
根据CIB中的信息，PE便计算群集的理想状态及如何达到此状态，并将指令列表传递给DC.DC通过消息交换/基础结构层发出命令，其他节点上的crmd同
级将收到此命令《每个lrmd使用它的LRM (作为Irmd实观）执行资源修改.lrmd不是群集感知的，它直接与资源代理（脚本)交互
所有同级节点将操作的结果报告给DC。一旦DC做出所有必需操作已在群集中成功执行的结论，群集将返回至空闲状态并等待进一步亊件。如果有操作末按计划执行，则会再次调用PE，CIB中将记录新信息。
在某系情况下，可能需要关闭节点以保护共享数据或完成资源恢复。为此，pacemaker附带了一个屏障子系统，stonithd。STONITH
是"shoot the other node in the
head"(关闭其他节点)"的首字母缩写，通常通过一个远程电源开关实施。在pacemaker中将STONITH设备构造成资源(并在CIB中配置)
以便它们监视故障；然而，stonithd负责了解STONITH拓扑，这样它的客户端只需请求屏障节点，余下的工作由它来完成。
Linux High Availabi 资源类型：
original
原始资源是最基本的资源类型。
group
组包含一系列需要放置在一起的资源、按顺序启动和以反序停止的资源。
组具有以下属性：
启动和停止资源
资源以显示顺序启动，以相反顺序停止。
相关性
如果组中某个资源在某处无法运行，则该组中位于其之后的任何资源都不允 许运行。
组内容
组可能仅包含一些原始群集资源。要引用组资源的子代，请使用子代的ID 代替组的ID。
限制
尽管在约束中可以引用组的子代，但通常倾向于使用组的名称。
黏性
黏性在组中可以累加。每个活动的组成员可以将其黏性值累加到组的总分 中。因此，如果默认的resource-stickiness值为100，而组中有七个 成员，其中五个成员是活动的，则组总分为500，更喜欢其当前位置。
资源监控
要为组启用资源监视，必须为组中每个要监视的资源分配监视。
注意： 组必须包含至少一个资源，否则无效.
Web 服务器的资源组
资源组示例是需要IP地址和文件系统的Web服务器。在这种情况下，每个组件 都是一个会合并到群集资源组中的独立群集资源。资源组在一台或多台服务器 上运行，如果软件或硬件有故障，故障转移至群集中的另一台服务器上，这与 单个群集资源相同。
如下图所示：
clone
克隆是可以在多个主机上处于活动状态的资源。如果各个资源代理支持，则任何资源均可克隆。(集群文件系统,文件共享服务器)
您可能希望某些资源在群集的多个节点上同时运行。为此，必须将资源配置为 克隆资源。可以配置为克隆资源的资源示例包括STOMTH和群集文件系统（如
0CFS2)。如果受资源的资源代理支持，则可以克隆任何资源。克隆资源的配 置甚至也有不同，具体取决于资源驻留的节点。
资源克隆有三种类型：
匿名克隆
这是最简单的克隆类型。这种克隆类型在所有位置上的运行方式都相同。因 此，每台计算机上只能有一个匿名克隆实例是活动的。
全局唯一克隆
这些资源各不相同。一个节点上运行的克隆实例与另一个节点上运行的实例 不同，同一个节点上运行的任何两个实例也不同。
状态克隆
这些资源的活动实例分为两种状态：主动和被动。有时也称为主要和辅助， 或主和从。状态克隆可以是匿名克隆也可以是全局唯一克隆。
master
主资源是一种特殊的克隆资源，主资源可以具有多种模式。主资源必须只能包含一个组或一个常规资源。
master/slave
主从资源主的能读能写，从的不能读也不能写
Linux High Availabi 配置资源约束：
配置好所有资源只是完成了该作业的一部分。即便群集熟悉所有必需资源，它 可能还无法进行正确处理。资源约束允许您指定在哪些群集节点上运行资源、 以何种顺序装载资源，以及特定资源依赖于哪些其他资源。
提供三种不同的约束：
Resource Location (资源位置）
位置约束定义资源可以、不可以或首选在哪些节点上运行。 优先级(inf：无穷大、- inf： 负无穷大 n：指定优先级大小 -n ：负优先级大小)
Resource Collocation (资源排列)
排列约束告诉群集资源可以或不可以在某个节点上一起运行。 inf：排列约束：资源无论如何都要在一起 -inf： 资源老死不相往来 (在某台服务器上)
Resource Order (资源顺序）
排序约束定义操作的顺序。 资源启动次序及关闭次序(比如 在启动web服务器的时候是先启动IP，还是先启动web服务进程呀！)
定义约束时，还需要指定分数。各种分数是群集工作方式的重要组成部分。其 实，从迁移资源到决定在已降级群集中停止哪些资源的整个过程是通过以某种
方式操纵分数来实现的。分数按每个资源来计算，资源分数为负的任何节点都
无法运行该资源。在计算出资源分数后，群集选择分数最高的节点。INFINITY (无穷大）目前定义为1, 000,
000。加减无穷大遵循以下3个基本规则：
◆任何值+无穷大=无穷大
◆任何值-无穷大=-无穷大
◆无穷大-无穷大=-无穷大
定义资源约束时，也可以指定每个约束的分数。分数表示您指派给此资源约束 的值。分数较高的约束先应用，分数较低的约束后应用。通过使用不同的分数 为既定资源创建更多位置约束，可以指定资源要故障转移至的目标节点的顺序
指定资源故障回复节点(资源黏性)
当原始节点恢复联机并位于群集中时，资源可能会故障回复到该节点。如果希望阻止资源故障回复到故障转移前运行的节点上，或如果希望指定其他的节点让资源进行故障回复，则必须更改资源黏性值。在创建资源时或在创建资源后， 都可以指定指定资源黏性。
在指定资源黏性值时，请考虑以下情况：
值为0:
这是默认选项。资源放置在系统中的最适合位置。这意味着当负载能力“较好”或较差的节点变得可用时才转移资源。此选项的作用几乎等同于自动故障回复，只是资源可能会转移到非之前活动的节点上。
值大于0:
资源更愿意留在当前位置，但是如果有更合适的节点可用时会移动。值越高表示资源越愿意留在当前位置。
值小于0:
资源更愿意移离当前位置。绝对值越高表示资源越愿意离开当前位置。
值为 INFINITY:
如果不是因节点不适合运行资源（节点关机、节点待机、达到migration-threshold或配置更改）而强制资源转移资源转移，资源总是留在当前位置。此选项的作用几乎等同于完全禁用自动故障回复.
值为-INFINITY:
资源总是移离当前位置。
那下面我们来实现heartbeat v1版本的工作过程：
安装配置高可用集群：实现heartbeat v1版的过程
1、节点名称很关键，集群每个节的名称都得能互相解析；
用hosts文件，/etc/hosts：hosts中主机名的正反解析结果必须跟”uname -n”的结果保持一致；
2、时间必须得同步，使用网络时间服务器同步时间；
3、各节点间能基于ssh密钥互相认证通信；
1)配置主机名、
第一台节点的主机名为node1.tanxw.com，第二台节点的主机名为node2.tanxw.com
# vim /etc/hosts 改主机名，注意，两个节点都要添加，我几个节点就加几条解析
172.16.249.61 node1.tanxw.com
172.16.249.62 node2.tanxw.com
# uname -n
# hostname node1.tanxw.com
# hostname node2.tanxw.com
# cat /etc/sysconfig/network 如果这个与node1或2不一致就改一下，这个改配置文件保证下次系统重启时主机名依然有效，
# 如果改好了没有生效就ctrl+d注销一下再登录就OK了。
2)两台主机或多台主机基于ssh无密钥通信
# ssh-keygen -t rsa -P ‘’ 这个生成一个密码为空的公钥和一个密钥，把公钥复制到对方节点上即可
# ssh-copy-id -i .ssh/id_rsa.pub [email protected] 对方主机名用登录用户名
两台主机都要互相可以通信，所以两台主机都得互相生成密钥和复制公钥，相互的节点上的hosts文件是都要解析对方的主机名，172.16.249.61 node1.tanxw.com
172.16.249.62 node2.tanxw.com
# ssh node2.tanxw.com ‘date’;date 测试一下是否已经互信
3)安装heartbeat v1版本的程序，两个节点都要安装上heartbeat的相关程序包
# 安装这几个包，但是存在依赖关系，需要解决：
heartbeat-2.1.-.el6.x86_64.rpm、heartbeat-pils-2.1.-.el6.x86_64.rpm、
heartbeat-stonith-2.1.-.el6.x86_64.rpm
# 解决依赖关系：
# yum -y install perl-TimeDate net-snmp-libs libnet PyXML
# rpm -ivh heartbeat-pils-2.1.-.el6.x86_64.rpm heartbeat-stonith-2.1.-.el6.x86_64.rpm heartbeat-2.1.-.el6.x86_64.rpm
一个高可用集群得依赖：1、信息层； 2、资源管理器；3、资源代理
我们配置的过程就按这种层次去配置就可以了；
这里要注意的是：如
何在网络中我们期望的节点集群成为我们所需要的节点，在集群中信息不能随便传递，而心跳节点是基于组播地址传递的，如果别人也装了heartbeat也连
接到这个组播地址上来，这都不安全，基于这种情况，我们各节点这间信息传递是需要认证的，这种认证基于HMAC(消息认证码)，消息认证码是使用单向加密
算动法来实现的，而单向加密一般有三类：crc(循环冗余校验码)、md5(信息摘要算法)、sha1。heartbeat基于udp协议，监听在694
端口上；
4)配置heartbeat，它的配置文件在/etc/ha.d/的目录下，但是安装完程序之后这个目录下没有这个配置文件，只有/usr/share
/doc/heartbeat-2.1.4/目录下有ha.cf的主配置文件样本，复制到/etc下修改配置文件即可使用；还有一个authkeys的认
证文件，这个文件就是我们各节点认证时所保存的认证密码和认证机制，所以这个文件的权限至关重要，必须是600，否则启动不了服务；第三个
haresources，定义资源时需要资源管理器来读取这个文件，所以这个也得有；
# cp /usr/share/doc/heartbeat-2.1./{ha.cf,authkeys,haresources} /etc/ha.d/
# cd /etc/ha.d/
# openssl rand -hex 生成16位随机数
ee869d3d86e1556f
# vim /etc/ha.d/authkeys
auth 这里的2与下面选项的数只要一致就可以了，没有什么限定
sha1 ee869d3d86e1556f
# chmod authkeys
# vim /etc/ha.d/ha.cf 启用以下参数及功能
logfile /var/log/ha-log #日志文件，正常日志信息记录到哪去的
keepalive 1000ms #每隔多长时间发送一次心跳信息的，单位是秒，毫秒用ms
deadtime #隔多长时间探测到对方不在线就kill掉的时间间隔
warntime #警告时间
udpport
mcast eth0 225.0.0.1 #定义组播地址
auto_failback on #开启故障转回功能
node node2.tanxw.com #定义两个节点
node node1.tanxw.com
crm on #启用crm功能
ping 172.16.0.1 #ping节点
compression bz2 #压缩格式
compression_threshold #表示小于2K时不压缩传输
ha.cf配置文件部分参数详解：
autojoin none
#集群中的节点不会自动加入
logfile /var/log/ha-log
#指名heartbaet的日志存放位置
keepalive
#指定心跳使用间隔时间为2秒（即每两秒钟在eth1上发送一次广播）
deadtime
#指定备用节点在30秒内没有收到主节点的心跳信号后，则立即接管主节点的服务资源
warntime
#指定心跳延迟的时间为十秒。当10秒钟内备份节点不能接收到主节点的心跳信号时，就会往日志中写入一个警告日志，但此时不会切换服务
initdead
#在某些系统上，系统启动或重启之后需要经过一段时间网络才能正常工作，该选项用于解决这种情况产生的时间间隔。取值至少为deadtime的两倍。
udpport
#设置广播通信使用的端口，694为默认使用的端口号。
baud
#设置串行通信的波特率
bcast eth0
# Linux 指明心跳使用以太网广播方式，并且是在eth0接口上进行广播。
#mcast eth0 225.0.0.1
#采用网卡eth0的Udp多播来组织心跳，一般在备用节点不止一台时使用。Bcast、ucast和mcast分别代表广播、单播和多播，是组织心跳的三种方式，任选其一即可。
#ucast eth0 192.168.1.2
#采用网卡eth0的udp单播来组织心跳，后面跟的IP地址应为双机对方的IP地址
auto_failback on
# 用来定义当主节点恢复后，是否将服务自动切回，heartbeat的两台主机分别为主节点和备份节点。主节点在正常情况下占用资源并运行所有的服务，遇到 故障时把资源交给备份节点并由备份节点运行服务。在该选项设为on的情况下，一旦主节点恢复运行，则自动获取资源并取代备份节点，如果该选项设置为 off，那么当主节点恢复后，将变为备份节点，而原来的备份节点成为主节点
#stonith baytech /etc/ha.d/conf/stonith.baytech
# stonith的主要作用是使出现问题的节点从集群环境中脱离，进而释放集群资源，避免两个节点争用一个资源的情形发生。保证共享数据的安全性和完整性。
#watchdog /dev/watchdog
# 该选项是可选配置，是通过Heartbeat来监控系统的运行状态。使用该特性，需要在内核中载入"softdog"内核模块，用来生成实际的设备文件， 如果系统中没有这个内核模块，就需要指定此模块，重新编译内核。编译完成输入"insmod softdog"加载该模块。然后输入"grep misc /proc/devices"(应为10)，输入"cat /proc/misc |grep watchdog"(应为130)。最后，生成设备文件："mknod /dev/watchdog c 10 130" 。即可使用此功能
node node1.magedu.com
#主节点主机名，可以通过命令“uanme –n”查看。
node node2.magedu.com
#备用节点主机名
ping 192.168.12.237
#选择ping的节点，ping 节点选择的越好，HA集群就越强壮，可以选择固定的路由器作为ping节点，但是最好不要选择集群中的成员作为ping节点，ping节点仅仅用来测试网络连接
ping_group group1 192.168.12.120 192.168.12.237
#类似于ping ping一组ip地址
apiauth pingd gid=haclient uid=hacluster
respawn hacluster /usr/local/ha/lib/heartbeat/pingd -m -d 5s
# 该选项是可选配置，列出与heartbeat一起启动和关闭的进程，该进程一般是和heartbeat集成的插件，这些进程遇到故障可以自动重新启动。最 常用的进程是pingd，此进程用于检测和监控网卡状态，需要配合ping语句指定的ping node来检测网络的连通性。其中hacluster表示启动pingd进程的身份。
定义资源：在资源管理器的配置文件中定义；/etc/ha.d/haresources，在/etc/ha.d/resource.d下有各种资源类型，当在资源配置文件中定义时就会调用这里的资源类型来运行相应的程序；
# vim /etc/ha.d/haresources
node1.tanxw.com 172.16.249.66 httpd # 172.16..66这个是浮动地址
注：node1.tanxw.com：说明哪台主机是主节点，更倾向于谁上面
[node1.tanxw.com 172.16.249.61//eth0/172.16.255.255 httpd 也可以这样定义
node2.tanxw.com 172.16.249.62 httpd httpd是怎么被调用的呢:首先会找/etc/ha.d/resource.d目录下，如果没有就去/etc/init.d/目录下找httpd，找到就start。]
# scp -p authkeys haresources ha.cf node1.tanxw.com:/etc/ha.d/
# service heartbeat start
在主节点上使用下面的命令仅仅停止 heartbeat 来模拟故障转移（failover）：
/etc/rc.d/init.d/heartbeat stop
您应该会看到，在一分钟之内，第二个节点上的所有 Web 服务器进程都会启动。如果不是那样，那么去查看
/var/log/messages 来确定问题所在并改正它。