2.x开始使用cib.xml作为配置文件，当heartbeat启用的时候，无法手工修改cib.xml，即使修改保存了也无效，因为会被 cib.xml.last覆盖掉，这个时候您需要停掉heartbeat，删除/var/lib/heartbeat/crm中的cib.xml.sig cib.xml.last cib.xml.last.sig，然后修改保存，再启动heartbeat，单单启动heartbeat就要花费5分钟（如果你的ha.cf的配置是默 认的话），所以排错的时候非常麻烦。
昨天我在ha的mail-list中看到一则小技巧，在heartbeat运行的时候，可以将cib倒出来，然后修改，再导回去，可以立即生效！
cibadmin -Q > tmp.xml
vim tmp.xml
<do what you want>
cibadmin -R -x tmp.xml
非常方便！

     在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分。

     除了可以通过给每个资源单独设置两项的分数之外，也可以将所有的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>
         <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

         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>
        …
     </primitive>
      …
    </group>

     …

     这样，在该资源组中任何一个资源出现问题之后，都会被认为该资源组有问题，当分数低于其他节点出现切换的时候就是整个资源组的切换。

     另外，对于INFINITY和-INFINITY这两个值，实际上主要用途就是为了控制永远不切换和只要失败必须切换用的。因为代表的意思就是拥有正无穷大的分数和失败就到负无穷大，主要用来满足极端规则的简单配置项。

     总的来说，一项资源（或者资源组）在一个节点运行迁移到另一个节点之前，可以失败的次数的计算公式可以如下表示：

     (nodeA score – nodeB score + stickiness)/abs(failure stickiness)，即为A节点分数减去B节点分数，再加上资源运行分数后得到的总分数，除以资源失败分数的绝对值。

一、heartbeat模块：

     整个Heartbeat软件的通信模块，各个节点之间的任何通信都是通过这个模块完成。这个模块会根据不同类型的通信启动不同的事件 handler，当监听到不同类型的通信请求后会分给不同的handler来处理。这个从整个Heartbeat的启动日志中看出来。

二、CRM：cluster resource manager

     从这个名字就可以看出这个模块基本上就是v2的heartbeat的一个只会中心，整个系统的一个大脑了，他主要负责整个系统的各种资源的 当前配置信息，以及各个资源的调度。也就是根据各资源的配置信息，以及当前的运行状况来决定每一个资源（或者资源组）到底该在哪个节点运行。不过这些事情 并不是他直接去做的，而是通过调度其他的一些模块来进行。

     他通过heartbeat模块来进行节点之间的通信，调度节点之间的工作协调。随时将通过heartbeat模块收集到的各个成员节点的基 本信息转交给CCM某块来更新整个集群的membership信息。他指挥LRM（local resource manager）对当前节点的各资源执行各种相应的操作（如start、stop、restart和monitor等等），同时也接收LRM在进行各种操 作的反馈信息并作出相应的决策再指挥后续工作。另外CRM模块还负责将各个模块反馈回来的各种信息通过调用设定的日志记录程序记录到日志文件中。

三、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/

     LRM就是通过调用以上路径下面的各种脚本来实现对资源的各种操作。每一种类型的脚本都可以由用户自定义，只要支持各类型的标准即可。实际 上这里的标准就是接受一个标准的调用命令和参数格式，同时返回符合标准的值即可。至于脚本中的各种操作时如何的LRM并不care。

四、PE：CRM Policy Engine

     他主要负责将CRM发过来的一些信息按照配置文件中的各种设置来进行计算，分析。然后将结果信息按照某种固定的格式通过CRM提交给 TE（Transition engine）去分析出后续需要采取的相应的action。PE需要计算分析的信息主要是当前有哪些节点，各节点的状况，当前管理有哪些资源，各资源当前 在哪一个节点，在各个节点的状态如何等等。

五、TE：Transition engine

     主要工作是分析PE的计算结果，然后根据配置信息转换成后续所需的相应操作。个人感觉PE和TE组合成一个类似于规则引擎实现的功能，而且 PE和TE这两个模块只有在处于active的节点被启动。另外PE和TE并不直接通信，而都是通过Heartbeat的指挥中心CRM来传达信息的。

六、CIB：cluster information base

     CIB在系统中充当的是当前集群中各资源原始配置以及之后动态变化了的状态，统计信息收集分发中心，是一个不断更新的信息库。当他收集到任 何资源的变化，以及节点统计信息的变化后，都会集成整合到一起组成当前集群最新的信息，并分发到集群各个节点。分发动作并不是自己和各个节点通信，同样也 是通过heartbeat模块来做的。

     CIB收集整理并汇总出来的信息是以一个xml格式保存起来的。实际上Heartbeat v2的资源配置文件也就是从haresources迁移到了一个叫cib.xml文件里面。该文件实际上就是CIB的信息库文件。在运行过程中，CIB可 能会常读取并修改该文件的内容，以保证信息的更新。

七、CCM：consensus cluster membership

     CCM的最主要工作就是管理集群中各个节点的成员以及各成员之间的关系。他让集群中各个节点有效的组织称一个整体，保持着稳定的连接。heartbeat模块所担当的只是一个通信工具，而CCM是通过这个通信工具来将各个成员连接到一起成为一个整体。

八、LOGD：logging daemon（non-blocking）

     一个无阻塞的日志记录程序，主要负责接收CRM从各个其他模块所收集的相关信息，然后记录到指定额度日志文件中。当logd接收到日志信息后会立刻返回给CRM反馈。并不是一定要等到将所有信息记录到文件后再返回，日志信息的记录实际上是一个异步的操作。

九、APPHBD：application heartbeat daemon

     apphbd模块实际上是给各个模块中可能需要用到的计时用的服务，是通过watchdog来实现的。这个模块具体的细节我还不是太清楚。

十、RMD：recovery manager daemon

     主要功能是进程恢复管理，接受从apphbd所通知的某个（或者某些）进程异常退出或者失败或者hang住后的恢复请求。RMD在接受到请求后会作出restart（如果需要可能会有kill）操作。

这篇 【Heartbeat V2 模块分析】来自 alidba.net By sky

一) 前言:

网上关于heartbeat的文章很多,但大部分是基于1.x style的,

我把我配置的2.x style的heartbeat 过程发出来,

希望对大家能有一点用,

2.x和1.x最主要的区别在于,

1) 2.x支持CRM管理,资源文件由原来的haresources变为cib.xml,

2) 支持OCF格式的resource agent,

3) 可以对多资源组进行独立监控(这点我不确定在1.x里是否可以,没试过)

4)支持多节点

二) 配置

本文假设原有的heartbeat 已经配置好且能正常工作,
如和配置heartbeat不属于本文讨论范围.

我这里以两节点为例:
node1 和node2,
有两个资源作HA,apache和jboss,
其中apache使用vip :192.168.1.205,
jboss无vip,

1)在ha.cf里面增加
       crm yes
       apiauth cibmon uid=hacluster
       respawn hacluster /usr/local/lib/heartbeat/cibmon -d

2)将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,
       启动的时候从左到右依次运行脚本,关闭的时候从右到左依次关闭.
       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)
       修改heartbeat目录权限，可以用以下命令：
       find / -type d -name "heartbeat" -exec chown -R hacluster {} ;
       find / -type d -name "heartbeat" -exec chgrp -R haclient {} ;

4)LSB格式的resource agent script中必须支持status功能
                   所谓的resource agent就是服务的启动脚本,这我这里叫runhttpd.sh,runjboss等,
                   必须能接收start,stop,status,三个参数,如果是OCF格式agent,则必须支持
                   start,stop,monitor三个参数.其中status和monitor参数是用来监控资源的,非常重要.
       例如LSB风格的脚本,运行./runhttpd.sh status时候，
       返回值包含OK或则running则表示资源正常
       返回值包含stopped或者No则表示资源不正常。

       假如是OCF风格的脚本,运行./runhttpd.sh monitor时候,
       返回0表示资源是正常的,
       返回7表示资源出现问题.

三) 与1.x相比的区别

与1.x风格相比，功能变化：

1）保留原有所有功能
       如，网络,heartbeat ,机器down了时候均可以切换资源。

2）自动监控资源
       每2分钟检测资源运行情况，如果发现资源不在，则尝试启动资源，
       如果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">
          <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>

3)可以对各资源组实现独立监控.
       比如jboss运行在node1上,apache运行在node2上,

4）同时监控系统负载
       可以自动将资源切换到负载低的node上

四) CRM管理程序crm_resource功能示例:

Examples
1)查看所有资源

   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

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)设置资源的某个属性

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

写的比较匆忙,有错误的地方请指正.

欢迎转载,修改,不需要标明作者,不过最好请标明来自CU.

heartbeat默认模式是没法监控资源的，也就是说其中某个资源要是crash掉了，也不会发生任何动作，它只有当它认为对方机器dead后才会发生动作。也就是机器crashed，网络断掉了之类。这显然没法达到我们的目标。

为了达到我们的目标就要采用crm(cluster resource management)模式了。

首先，先按默认模式配置heartbeat(详见heartbeat新手上路)。

默认模式配置成功后，再按下面的步骤操作：

1)在ha.cf里面增加

crm on

2)将haresources资源文件转换成cib.xml文件,2.1.3自带有转换脚本

/usr/local/lib64/heartbeat/haresources2cib.py haresources

输出文件在/usr/local/var/lib/heartbeat/crm/cib.xml

3)如果hacluster和haclient用户和用户组是在安装heartbeat之后创建的话，则需要执行下面命令修改权限

修改heartbeat目录权限，可以用以下命令：

find / -type d -name "heartbeat" -exec chown -R hacluster {} ;

find / -type d -name "heartbeat" -exec chgrp -R haclient {} ;

4)在2.0的版本中ipfail与crm 模式有冲突，所以在ha.cf中不可打开ipfail。

5) cib.xml文件的修改

如果在IPaddr中有下面两行，则删除：

<nvpair id="IPaddr_172_18_57_83_attr_1" name="nic" value="24"/>

<nvpair id="IPaddr_172_18_57_83_attr_2" name="cidr_netmask" value="bond0"/>

2.1.3版本生成的cib.xml文件中,mysql资源是ocf格式的，而它自带的mysql角本是无法启动mysql的，所以需要修改，有两种方法。在修改前先介绍一下ocf和lsb格式的区别：

LSB格式的角本必须支持status功能，必须能接收start,stop,status,三个参数；而如果是OCF格式,则必须支持start,stop,monitor三个参数.其中status和monitor参数是用来监控资源的,非常重要.

例如LSB风格的脚本,运行./mysql status时候，

返回值包含OK或则running则表示资源正常

返回值包含stopped或者No则表示资源不正常。

假如是OCF风格的脚本,运行./mysql monitor时候,

返回0表示资源是正常的,

返回7表示资源出现问题.

ocf格式的启动角本在/usr/lib/ocf/resource.d/heartbeat(也许你的机器上目录不是这个，可以搜索ocf来查找)

lsb格式的启动角本在/usr/lib/lsb/resource.d/heartbeat目录下。

两种修改方法

1.修改cib.xml，将mysql的ocf改成lsb。然后在/usr/lib/lsb/resource.d/heartbeat(如果该目录不存在，则手工创建，并将权限赋给hacluster:haclient)下面执行ln -s /etc/init.d/mysql mysql。

注意，如果修改过cib.xml文件后，需要将同目录下面其他文件均删除！

2.修改/usr/lib/ocf/resource.d/heartbeat下面的mysql的角本，使之能正常工作。或者将/etc/init.d/mysql拷过来，修改使它支持monitor操作

6) 然后启动heartbeat即可。Service heartbeat start.

7)如果mysql采用双master的话，则在stop资源后，记的将mysql手动起来。

Heartbeat CRM模式管理

1)查看所有资源

[root@alssme_probe3 sbin]# crm_resource -L

Resource Group: group_1

IPaddr_172_18_158_111 (heartbeat::ocf:IPaddr)

mysql_2 (lsb:mysql)

2)查看资源跑在哪个节点上

[root@alssme_probe3 sbin]# crm_resource -W -r mysql_2

resource mysql_2 is running on: alssme_probe3

4)启动/停止资源(cluster不会发生切换，手工停mysql，将会重新启动或者发生切换)

[root@alssme_probe4 crm]# crm_resource -r mysql_2 -p target_role -v started

[root@alssme_probe3 sbin]# crm_resource -r mysql_2 -p target_role -v stopped

5)查看资源在cib.xml中的定义

[root@alssme_probe3 sbin]# crm_resource -x -r mysql_2

mysql_2 (lsb:mysql): Started alssme_probe3

raw xml:

<primitive class="lsb" provider="heartbeat" type="mysql" id="mysql_2">

<operations>

<op id="mysql_2_mon" interval="60s" name="monitor" timeout="30s"/>

</operations>

<instance_attributes id="mysql_2">

<attributes>

<nvpair name="target_role" id="mysql_2-target_role" value="started"/>

</attributes>

</instance_attributes>

</primitive>

即每60秒检测资源运行情况，如果发现资源不在，则尝试启动资源，如果30s后还未启动成功，则资源切换向另节点。时间可以修改( mysql一般建议采用这个时间值)。

6)将资源移向指定节点

crm_resource -M -r mysql_2 -H alssme_probe4

7)允许资源回到正常的节点

crm_resource -U -r mysql_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 mysql -t primitive

10)将资源组从CRM中删除

crm_resource -D -r my_first_group -t group

1.下载keepalived的源码 官方网站http://www.keepalived.org
直接链接：http://www.keepalived.org/software/keepalived-1.1.12.tar.gz
2.将下载的源码复制到/usr/src,解压缩
cp keepalived-1.1.12.tar.gz /usr/src
cd /usr/src
tar xvzf keepalived-1.1.12.tar.gz
cd keepalived-1.1.12
3.生成编译配置文件

./configure (默认安装到/usr/local，可以使用–prefix=参数指定安装目录)
make
make install

安装程序会复制下列文件和配置：
* keepalived : keepalived守护程序
* genhash :    MD5生成器
* /etc/keepalived/keepalived.conf keepalived配置文件

=====================================
注意在Redhat 9中会报下面的错误：

> checking openssl/ssl.h usability… no
> checking openssl/ssl.h presence… no
> checking for openssl/ssl.h… no
> configure: error:
>   !!! OpenSSL is not properly installed on your system. !!!
>   !!! Can not include OpenSSL headers files.            !!!

其实这个问题与openssl没有关系，是因为Kerberos include文件的位置的问题。
使用以下方法解决：

在/etc/profile文件中增加 : export CPPFLAGS=-I/usr/kerberos/include
然后:

1.) export CPPFLAGS=-I/usr/kerberos/include
2.) make clean(或者删掉整个源码目录，重新解压)
3.) 重新编译
=====================================
4.编辑master的配置文件,/usr/local/etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
state MASTER             #(主机为MASTER，备用机为BACKUP)
interface eth0           #(HA监测网络接口)
track_interface {        #其他要监测状态的接口
eth1
}
virtual_router_id 51     #(主、备机的virtual_router_id必须相同)
priority 500             #(主、备机取不同的优先级，主机值较大，备份机值较小,值越大优先级越高)
advert_int 1             #(VRRP Multicast广播周期秒数)
authentication {
auth_type PASS           #(VRRP认证方式)
auth_pass 1111           #(VRRP口令字)
}
virtual_ipaddress {
192.168.3.3              #(VRRP HA虚拟地址)
}
}

6.编辑backup上的配置文件,/usr/local/etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
state BACKUP
interface eth0
track_interface { # Interfaces state we monitor
eth1
}
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.3.3
}
}
track_interface的意思是将Linux中你想监控的网络接口卡监控起来，当其中的一块出现故障是keepalived都将视为路由器出现故障。

7. 分别在两台机器上启用Multicast路由，注意这步很重要！！！

route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

8.在master和backup上启动keepalived

/usr/local/keepalived/sbin/keepalived –D –f /usr/local/keepalived/etc/keepalived/keepalived.conf

在启动Master上的keepalived之前，我们先看一下Master上eth0的情况：
————————————————————–
# ip add show eth0

8: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:e0:4c:3a:d7:25 brd ff:ff:ff:ff:ff:ff
inet 192.168.3.1/24 brd 192.168.3.255 scope global eth1
inet6 fe80::2e0:4cff:fe3a:d725/64 scope link
————————————————————–
我们看到只有一个IP地址：192.168.3.1/24，现在我们启动Master上的keepalived
#/usr/local/keepalived/sbin/keepalived –D –f /usr/local/keepalived/etc/keepalived/keepalived.conf

现在我们再看一下Master上eth0的情况：
————————————————————–
# ip add show eth0
8: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:e0:4c:3a:d7:25 brd ff:ff:ff:ff:ff:ff
inet 192.168.3.1/24 brd 192.168.3.255 scope global eth1
inet 192.168.3.3/32 scope global eth1
inet6 fe80::2e0:4cff:fe3a:d725/64 scope link
—————————————————————
我们看到有两个IP地址，其中一个就是V-Gate:192.168.3.3/32

用同样的方法启动Backup上的keepalived
#/usr/local/keepalived/sbin/keepalived –D –f /usr/local/keepalived/etc/keepalived/keepalived.conf

这样，当Master失效时，Backup就会通过MultiCast地址：224.0.0.18这个组播地址，获得这个消息，并将192.168.3.3这个地址接管过来。

1. 至http://httpd.apache.org/download.cgi下載Apache HTTP Server (以2.2.4版為例).
2. 安裝Apache HTTP Server.
3. 修改Apache2.2confhttpd.conf, 將以下的#刪除, 使其在啟動後運作.
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
#引用Apache的Virtual Hosts設定
Include conf/extra/httpd-vhosts.conf
4. 編輯Apache2.2confextrahttpd-vhosts.conf, 如下:
NameVirtualHost *
<VirtualHost *>
ServerName www.example.com
ServerAlias example.com
DocumentRoot C:JavaApache2.2conf
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
#Proxy的Pattern, 以下將把"/", 交由"balancer://iiscluster/"處理
#詳細說明可至:http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
ProxyPass / balancer://iiscluster/ stickysession=MYCOOKIE nofailover=On
ProxyPassReverse / balancer://iiscluster
<Proxy balancer://iiscluster>
#load balance的主機URL
　　#route是load balance的worker name, 及後續要在IIS設定Session ID的參數
　　#loadfactor是數字1-100的權重, 數字越大loading將越重
BalancerMember http://192.168.1.2 route=node1 loadfactor=1
BalancerMember http://192.168.1.3 route=node2 loadfactor=1
#load balance的方式(byrequests, bytraffic)
ProxySet lbmethod=byrequests
</Proxy>
#加入此設定, 將來可至http://…../balancer-manager/下, 監視load balance的狀態
<Location /balancer-manager>
SetHandler balancer-manager
Order deny,allow
Allow from all
</Location>
</VirtualHost>
5. 設定IIS的Header:
5.1 開啟IIS管理畫面, 在[網站]或其下的[WebApplication]點選[內容].
5.2 在[HTTP標頭]頁籤中, 按下[自訂HTTP標頭]的[新增]按鈕.
5.3 [自訂標頭名稱]輸入:"Set-Cookie"
5.4 [自訂標頭值]輸入:"MYCOOKIE=iiscluster.node1; path=/;"
＊請對照第4步ProxyPass的stickysession=MYCOOKIE, 以及<Proxy>中的
route=node1, route=node2分別設定192.168.1.2與192.168.1.3的IIS
6.重新啟動IIS與Apache即可.
7.若要Debug, 可在<VirtualHost *> 中加入:
LogLevel debug

三）双机lvs-ha

主服务器+真实的web服务器 ：192.168.2.28
备服务器+ 真实的web服务器：192.168.2.20
Lvs director 配置在主服务器上,根据源地址分配服务器。
集群的虚拟ip为60.*.165，初始分配在主服务器的eth0, 主服务器宕机后，ip由备份服务器接管，分配在备份服务器的eth0.

二、集群软件安装
主服务器安装:
yum -y install ipvsadm # ipvs管理器
yum -y install libnet    # 库文件
yum -y install e2fsprogs   # 库文件
yum -y install heartbeat # linux-ha
yum –y install heartbeat-ldirectord   # connector of linux-ha and lvs 【备份服务器不用安装】

2- 拷贝配置文件
cp /usr/share/doc/heartbeat-2.1.*/ha.cf /etc/ha.d/
cp /usr/share/doc/heartbeat-2.1.*/authkeys /etc/ha.d/
cp /usr/share/doc/heartbeat-2.1.*/haresources /etc/ha.d/
cp /usr/share/doc/heartbeat-ldirectord-2.1.*/ldirectord.cf /etc/ha.d/【备份服务器不用】

三、集群配置
主服务器配置：　
1- 修改/etc/hosts文件
192.168.2.28           name1
192.168.2.20           name2

2- 修改haresources文件
liuyuxi IPaddr::60.*.165 lvsdr-basic ldirectord
3- 修改authkeys文件   修改权限 chmod 600 authkeys
auth 1
1 crc
4- 修改ha.cf
   debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility     local0
deadtime 20
initdead 20
ucast 192.168.2.20
auto_failback on
node name1
node name2
ping_group group1 192.168.2.28 192.168.2.20
respawn root /usr/lib/heartbeat/ipfail    
apiauth ipfail gid=root uid=root

5- ldirectord.cf
   checktimeout=3
checkinterval=1
autoreload=no
logfile="/var/log/ldirectord.log"
quiescent=no
virtual=60.*.165:80
       real=60.*.171:80 gate
       real=60.*.164:80 gate
       service=http
       request="test.html"
       receive="Test"       
       scheduler=sh
       protocol=tcp

6- lvsdr-basic
/etc/init.d/lvsdr-basic
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don’t
# want to do the full Sys V style init stuff.

VIP=60.*.165
RIP1=60.*.171
RIP2=60.*.164
###########################
# ifconfig a
#
#/sbin/ifconfig eth0:0 $VIP broadcast $VIP netmask 255.255.255.255 up
#
############################

/sbin/route add -host $VIP dev eth0:0
echo "1" > /proc/sys/net/ipv4/ip_forward

备份服务器配置： 　
1- 修改/etc/hosts文件   同主服务器
2- 修改haresources文件
liuyuxi switchdr IPaddr::60.*.165
虚拟ip地址是 60.*.165
备份服务器在接管主服务器前，执行switchdr start
备份服务器在移交主服务器前，执行switchdr stop
switchdr 见备份服务器配置第5条.

3- 修改authkeys文件   同服务器
4- 修改ha.cf 同主服务器 注意ucast
5- switchdr 脚本
/etc/init.d/switchdr
#!/bin/sh
# description: close lo0 and arp_ignore
VIP=60.*.165

./etc/rc.d/init.d/functions

case "$1" in
start)
       echo "************* start director server and close tunl ***********"
       ifconfig lo:0 down
       echo 0>/proc/sys/net/ipv4/conf/all/arp_announce //允许arp解析虚ip
       ;;
stop)
       echo "start Real Server"
//       —————————————————禁止arp 解析虚ip
       ifconfig eth0:0 down
       ifconfig lo:0   $VIP netmask 255.255.255.255 broadcast $VIP up
       /sbin/route add -host $VIP dev lo:0

       echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
       echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
       echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
       echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce
       sysctl -p
       ;;
*)
       echo "Usage: switchdr {start|stop}"
       exit 1
esac

主服务器上：
/usr/local/apache/bin/apachectl start
/etc/init.d/heartbeat start
备服务器上：
/etc/init.d/httpd start
/etc/init.d/switchdr stop
/etc/init.d/heartbeat start

到此ok，如果有问题就是配置问题，好好检查你的log，所有的信息都在log上显示的。Ipvsadm可显示lvs连接，ipvsadm –l –c 命令查看当前响应。

最后感谢刘俊，ghbspecial 等同志 ，我是参照他们的文档作出的，
有问题请联系我   xu_pj#hotmail.com (#替代@)