一个配置heartbeat 2.x的小技巧

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
非常方便!

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

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

一、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

/etc/init.d/nginx (lsb style)

这几天学习了一下heartbeat的资料,想参照 Two Apache Web Servers in an Active/Active Configuration    做个Two Nginx Web Services in Active/Active HA。研究发现,heartbeat所管理的资源代理(Resource Agent),有OCF、LSB等几种 。LSB这种shell脚本我还能依葫芦画瓢的写一点,参考linux系统中的原有脚本和网上资料,写了一个很简单的:

C代码 复制代码

  1. #!/bin/bash  
  2. #  
  3. # nginx:        Control the nginx Daemon  
  4. #  
  5. # Version:       @(#) /etc/init.d/nginx 0.1  
  6. #  
  7. # description: This is a init.d script for nginx. Tested on CentOS4.   
  8. #               Change DAEMON and PIDFILE if neccessary.  
  9. #  
  10.   
  11. #Location of nginx binary. Change path as neccessary  
  12. DAEMON=/usr/local/nginx/sbin/nginx  
  13. NAME=`basename $DAEMON`  
  14.   
  15. #Pid file of nginx, should be matched with pid directive in nginx config file.  
  16. PIDFILE=/var/run/$NAME.pid  
  17.   
  18. #this file location  
  19. SCRIPTNAME=/etc/init.d/$NAME  
  20.   
  21. #only run if binary can be found  
  22. test -x $DAEMON || exit 0  
  23.   
  24. RETVAL=0  
  25.   
  26. start() {  
  27.      echo $"Starting $NAME"  
  28.      $DAEMON  
  29.      RETVAL=0  
  30. }  
  31.   
  32. stop() {  
  33.      echo $"Graceful stopping $NAME"  
  34.      [ -s "$PIDFILE" ] && kill -QUIT `cat $PIDFILE`  
  35.      RETVAL=0  
  36. }  
  37.   
  38. forcestop() {  
  39.      echo $"Quick stopping $NAME"  
  40.      [ -s "$PIDFILE" ] && kill -TERM `cat $PIDFILE`  
  41.      RETVAL=$?  
  42. }  
  43.   
  44. reload() {  
  45.      echo $"Graceful reloading $NAME configuration"  
  46.      [ -s "$PIDFILE" ] && kill -HUP `cat $PIDFILE`  
  47.      RETVAL=$?  
  48. }  
  49.   
  50. status() {  
  51.     if [ -s $PIDFILE ]; then  
  52.          echo $"$NAME is running."  
  53.          RETVAL=0  
  54.     else  
  55.          echo $"$NAME stopped."  
  56.          RETVAL=3  
  57.      fi  
  58. }  
  59. # See how we were called.  
  60. case "$1" in  
  61.      start)  
  62.          start  
  63.          ;;  
  64.      stop)  
  65.          stop  
  66.          ;;  
  67.      force-stop)  
  68.          forcestop  
  69.          ;;  
  70.      restart)  
  71.          stop  
  72.          start  
  73.          ;;  
  74.      reload)  
  75.          reload  
  76.          ;;  
  77.      status)  
  78.          status  
  79.          ;;  
  80.      *)  
  81.          echo $"Usage: $0 {start|stop|force-stop|restart|reload|status}"  
  82.          exit 1  
  83. esac  
  84.   
  85. exit $RETVAL  

#!/bin/bash # # nginx: Control the nginx Daemon # # Version: @(#) /etc/init.d/nginx 0.1 # # description: This is a init.d script for nginx. Tested on CentOS4. # Change DAEMON and PIDFILE if neccessary. # #Location of nginx binary. Change path as neccessary DAEMON=/usr/local/nginx/sbin/nginx NAME=`basename $DAEMON` #Pid file of nginx, should be matched with pid directive in nginx config file. PIDFILE=/var/run/$NAME.pid #this file location SCRIPTNAME=/etc/init.d/$NAME #only run if binary can be found test -x $DAEMON || exit 0 RETVAL=0 start() { echo $"Starting $NAME" $DAEMON RETVAL=0 } stop() { echo $"Graceful stopping $NAME" [ -s "$PIDFILE" ] && kill -QUIT `cat $PIDFILE` RETVAL=0 } forcestop() { echo $"Quick stopping $NAME" [ -s "$PIDFILE" ] && kill -TERM `cat $PIDFILE` RETVAL=$? } reload() { echo $"Graceful reloading $NAME configuration" [ -s "$PIDFILE" ] && kill -HUP `cat $PIDFILE` RETVAL=$? } status() { if [ -s $PIDFILE ]; then echo $"$NAME is running." RETVAL=0 else echo $"$NAME stopped." RETVAL=3 fi } # See how we were called. case "$1" in start) start ;; stop) stop ;; force-stop) forcestop ;; restart) stop start ;; reload) reload ;; status) status ;; *) echo $"Usage: $0 {start|stop|force-stop|restart|reload|status}" exit 1 esac exit $RETVAL

注意对应的Nginx配置的PID指令。

参考资料:

LSBResourceAgent

Running and Controlling Nginx

Boot Script for Nginx on Ubuntu, Debian etc.

heartbeat 2.x style的配置(使用cib.xml)

一) 前言:

网上关于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 CRM模式

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

VRRP安装配置实做笔记

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这个地址接管过来。

使用 Nginx 提升网站访问速度

Nginx 简介

Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器,也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的,它已经在该站点运行超过两年半了。 Igor 将源代码以类 BSD 许可证的形式发布。尽管还是测试版,但是,Nginx 已经因为它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名了。

根据最新一期(08 年 6 月份)的 NetCraft 调查报告显示,已经有超过两百万的主机使用了 Nginx,这个数字超过了另外一个轻量级的 HTTP 服务器 lighttpd, 排名第四,并且发展迅速。下面是这份报告的前几名的报表:

产品 网站数 Apache 84,309,103 IIS 60,987,087 Google GFE 10,465,178 Unknown 4,903,174 nginx 2,125,160 Oversee 1,953,848 lighttpd 1,532,952

关于这期调查报告的更详细信息请看下面链接:

http://survey.netcraft.com/Reports/200806/

下图是最近几个月使用 Nginx 和 lighttpd 的网站数比较

图 1. 最近几个月使用 Nginx 和 lighttpd 的网站数比较
图 1. 最近几个月使用 Nginx 和 lighttpd 的网站数比较

使用 Nginx 前必须了解的事项

  1. 目前官方 Nginx 并不支持 Windows,您只能在包括 Linux、UNIX、BSD 系统下安装和使用;
  2. Nginx 本身只是一个 HTTP 和反向代理服务器,它无法像 Apache 一样通过安装各种模块来支持不同的页面脚本,例如 PHP、CGI 等;
  3. Nginx 支持简单的负载均衡和容错;
  4. 支持作为基本 HTTP 服务器的功能,例如日志、压缩、Byte ranges、Chunked responses、SSL、虚拟主机等等,应有尽有。

在 Linux 下安装 Nginx

为了确保能在 Nginx 中使用正则表达式进行更灵活的配置,安装之前需要确定系统是否安装有 PCRE(Perl Compatible Regular Expressions)包。您可以到 下载最新的 PCRE 源码包,使用下面命令下载编译和安装 PCRE 包:

# wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-7.7.tar.gz
# tar zxvf pcre-7.7.tar.gz
# cd pcre-7.7
# ./configure
# make
# make install

接下来安装 Nginx,Nginx 一般有两个版本,分别是稳定版和开发版,您可以根据您的目的来选择这两个版本的其中一个,下面是把 Nginx 安装到 /opt/nginx 目录下的详细步骤:

# wget http://sysoev.ru/nginx/nginx-0.6.31.tar.gz
# tar zxvf nginx-0.6.31.tar.gz
# cd nginx-0.6.31
# ./configure –with-http_stub_status_module –prefix=/opt/nginx
# make
# make install

其中参数 --with-http_stub_status_module 是为了启用 nginx 的 NginxStatus 功能,用来监控 Nginx 的当前状态。

安 装成功后 /opt/nginx 目录下有四个子目录分别是:conf、html、logs、sbin 。其中 Nginx 的配置文件存放于 conf/nginx.conf,Nginx 只有一个程序文件位于 sbin 目录下的 nginx 文件。确保系统的 80 端口没被其他程序占用,运行 sbin/nginx 命令来启动 Nginx,打开浏览器访问此机器的 IP,如果浏览器出现 Welcome to nginx! 则表示 Nginx 已经安装并运行成功。

常用的 Nginx 参数和控制

程序运行参数

Nginx 安装后只有一个程序文件,本身并不提供各种管理程序,它是使用参数和系统信号机制对 Nginx 进程本身进行控制的。 Nginx 的参数包括有如下几个:

-c <path_to_config>:使用指定的配置文件而不是 conf 目录下的 nginx.conf 。

-t:测试配置文件是否正确,在运行时需要重新加载配置的时候,此命令非常重要,用来检测所修改的配置文件是否有语法错误。

-v:显示 nginx 版本号。

-V:显示 nginx 的版本号以及编译环境信息以及编译时的参数。

例如我们要测试某个配置文件是否书写正确,我们可以使用以下命令

sbin/nginx – t – c conf/nginx2.conf

通过信号对 Nginx 进行控制

Nginx 支持下表中的信号:

信号名 作用描述 TERM, INT 快速关闭程序,中止当前正在处理的请求 QUIT 处理完当前请求后,关闭程序 HUP 重新加载配置,并开启新的工作进程,关闭就的进程,此操作不会中断请求 USR1 重新打开日志文件,用于切换日志,例如每天生成一个新的日志文件 USR2 平滑升级可执行程序 WINCH 从容关闭工作进程

有两种方式来通过这些信号去控制 Nginx,第一是通过 logs 目录下的 nginx.pid 查看当前运行的 Nginx 的进程 ID,通过 kill – XXX <pid> 来控制 Nginx,其中 XXX 就是上表中列出的信号名。如果您的系统中只有一个 Nginx 进程,那您也可以通过 killall 命令来完成,例如运行 killall – s HUP nginx 来让 Nginx 重新加载配置。

配置 Nginx

先来看一个实际的配置文件:

user nobody;# 工作进程的属主
worker_processes 4;# 工作进程数,一般与 CPU 核数等同

#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;

#pid logs/nginx.pid;

events {
use epoll;#Linux 下性能最好的 event 模式
worker_connections 2048;# 每个工作进程允许最大的同时连接数
}

http {
include mime.types;
default_type application/octet-stream;

#log_format main ‘$remote_addr – $remote_user [$time_local] $request ‘
# ‘"$status" $body_bytes_sent "$http_referer" ‘
# ‘"$http_user_agent" "$http_x_forwarded_for"’;

#access_log off;
access_log logs/access.log;# 日志文件名

sendfile on;
#tcp_nopush on;
tcp_nodelay on;

keepalive_timeout 65;

include gzip.conf;

# 集群中的所有后台服务器的配置信息
upstream tomcats {
server 192.168.0.11:8080 weight=10;
server 192.168.0.11:8081 weight=10;
server 192.168.0.12:8080 weight=10;
server 192.168.0.12:8081 weight=10;
server 192.168.0.13:8080 weight=10;
server 192.168.0.13:8081 weight=10;
}

server {
listen 80;#HTTP 的端口
server_name localhost;

charset utf-8;

#access_log logs/host.access.log main;

location ~ ^/NginxStatus/ {
stub_status on; #Nginx 状态监控配置
access_log off;
}

location ~ ^/(WEB-INF)/ {
deny all;
}

location ~ .(htm|html|asp|php|gif|jpg|jpeg|png|bmp|ico|rar|css|js|
zip|java|jar|txt|flv|swf|mid|doc|ppt|xls|pdf|txt|mp3|wma)$ {
root /opt/webapp;
expires 24h;
}

location / {
proxy_pass http://tomcats;# 反向代理
include proxy.conf;
}

error_page 404 /html/404.html;

# redirect server error pages to the static page /50x.html
#
error_page 502 503 /html/502.html;
error_page 500 504 /50x.html;
location = /50x.html {
root html;
}
}
}

Nginx 监控

上 面是一个实际网站的配置实例,其中灰色文字为配置说明。上述配置中,首先我们定义了一个 location ~ ^/NginxStatus/,这样通过 http://localhost/NginxStatus/ 就可以监控到 Nginx 的运行信息,显示的内容如下:

Active connections: 70
server accepts handled requests
14553819 14553819 19239266
Reading: 0 Writing: 3 Waiting: 67

NginxStatus 显示的内容意思如下:

  • active connections – 当前 Nginx 正处理的活动连接数。
  • server accepts handled requests — 总共处理了 14553819 个连接 , 成功创建 14553819 次握手 ( 证明中间没有失败的 ), 总共处理了 19239266 个请求 ( 平均每次握手处理了 1.3 个数据请求 )。
  • reading — nginx 读取到客户端的 Header 信息数。
  • writing — nginx 返回给客户端的 Header 信息数。
  • waiting — 开启 keep-alive 的情况下,这个值等于 active – (reading + writing),意思就是 Nginx 已经处理完正在等候下一次请求指令的驻留连接。

静态文件处理

通过正则表达式,我们可让 Nginx 识别出各种静态文件,例如 images 路径下的所有请求可以写为:

location ~ ^/images/ {
root /opt/webapp/images;
}

而下面的配置则定义了几种文件类型的请求处理方式。

location ~ .(htm|html|gif|jpg|jpeg|png|bmp|ico|css|js|txt)$ {
root /opt/webapp;
expires 24h;
}

对于例如图片、静态 HTML 文件、js 脚本文件和 css 样式文件等,我们希望 Nginx 直接处理并返回给浏览器,这样可以大大的加快网页浏览时的速度。因此对于这类文件我们需要通过 root 指令来指定文件的存放路径,同时因为这类文件并不常修改,通过 expires 指令来控制其在浏览器的缓存,以减少不必要的请求。 expires 指令可以控制 HTTP 应答中的“ Expires ”和“ Cache-Control ”的头标(起到控制页面缓存的作用)。您可以使用例如以下的格式来书写 Expires:

expires 1 January, 1970, 00:00:01 GMT;
expires 60s;
expires 30m;
expires 24h;
expires 1d;
expires max;
expires off;

动态页面请求处理

Nginx 本身并不支持现在流行的 JSP、ASP、PHP、PERL 等动态页面,但是它可以通过反向代理将请求发送到后端的服务器,例如 Tomcat、Apache、IIS 等来完成动态页面的请求处理。前面的配置示例中,我们首先定义了由 Nginx 直接处理的一些静态文件请求后,其他所有的请求通过 proxy_pass 指令传送给后端的服务器(在上述例子中是 Tomcat)。最简单的 proxy_pass 用法如下:

location / {
proxy_pass http://localhost:8080;
proxy_set_header X-Real-IP $remote_addr;
}

这里我们没有使用到集群,而是将请求直接送到运行在 8080 端口的 Tomcat 服务上来完成类似 JSP 和 Servlet 的请求处理。

当页面的访问量非常大的时候,往往需要多个应用服务器来共同承担动态页面的执行操作,这时我们就需要使用集群的架构。 Nginx 通过 upstream 指令来定义一个服务器的集群,最前面那个完整的例子中我们定义了一个名为 tomcats 的集群,这个集群中包括了三台服务器共 6 个 Tomcat 服务。而 proxy_pass 指令的写法变成了:

location / {
proxy_pass http://tomcats;
proxy_set_header X-Real-IP $remote_addr;
}

在 Nginx 的集群配置中,Nginx 使用最简单的平均分配规则给集群中的每个节点分配请求。一旦某个节点失效时,或者重新起效时,Nginx 都会非常及时的处理状态的变化,以保证不会影响到用户的访问。

总结

尽 管整个程序包只有五百多 K,但麻雀虽小、五脏俱全。 Nginx 官方提供的各种功能模块应有尽有,结合这些模块可以完整各种各样的配置要求,例如:压缩、防盗链、集群、FastCGI、流媒体服务器、 Memcached 支持、URL 重写等等,更关键的是 Nginx 拥有 Apache 和其他 HTTP 服务器无法比拟的高性能。您甚至可以在不改变原有网站的架构上,通过在前端引入 Nginx 来提升网站的访问速度。

本文只是简单介绍了 Nginx 的安装以及常见的基本的配置和使用,更多关于 Nginx 的信息请阅读文章后面的参考资源。在这里要非常感谢我的朋友——陈磊(chanix@msn.com),他一直在做 Nginx 的中文 WIKI(http://wiki.codemongers.com/NginxChs),同时也是他介绍给我这么好的一款软件。

如果您的网站是运行在 Linux 下,如果您并没有使用一些非常复杂的而且确定 Nginx 无法完成的功能,那您应该试试 Nginx 。

nginx –upstream iphash

一般做负载均衡,都需要后端多台web服务器之间实现session共享,否则用户登录可能就有问题了。

今天看nginx文档时候,发现nginx可以根据客户端IP进行负载均衡,在upstream里设置ip_hash,就可以针对同一个C类地址段中的客户端选择同一个后端服务器,除非那个后端服务器宕了才会换一个。

原文如下:
The key for the hash is the class-C network address of the client. This method guarantees that the client request will always be forwarded to the same server. But if this server is considered inoperative, then the request of this client will be transferred to another server. This gives a high probability clients will always connect to the same server.

也 就是说我可以在两台服务器上跑两个论坛,但共享一个后台数据库,而不用去关心session共享的问题,前面启用ip_hash,正常情况下,客户端上网 获得IP,登录浏览发帖等都会被转到固定的后端服务器上,这样就不会出问题了。应该说来访IP分布越广,负载均衡就越平均。嘿嘿,如果都是同一个C来的用 户,那就没用了。

虚拟机上搭了个环境测试了一下:

装了三个nginx,分别在80,81,82端口上。

80端口上的nginx做负载均衡前端,配置到后面两个nginx:

upstream test{
            ip_hash;
            server 127.0.0.1:81 ;
            server 127.0.0.1:82 ;
        }

在81端口的nginx上写个简单的html,内容为1;在82端口的nginx上写个内容为2的html,两个文件同名。

在有ip_hash的时候,刷新页面http://192.168.1.33/index.html,始终显示为1,没有ip_hash的时候,则为轮流的1和2

nginx的upstream目前支持4种方式的分配

1、轮询(默认)

每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。

2、weight

指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。  

2、ip_hash

每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决的问题。

3、fair(第三方)

按后端服务器的响应时间来分配请求,响应时间短的优先分配。

4、url_hash(第三方)

按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效