Linux高可用性方案之Heartbeat的CRM配置

yanfangsheng123

　　本文转载至http://czmmiao.iteye.com/blog/1179225
　　heartbeat默认模式是没法监控资源的，也就是说其中某个资源要是crash掉了，也不会发生任何动作，它只有当它认为对方机器dead后才会发生动作,也就是机器crashed，网络断掉了之类。这显然没法达到我们的目标。为了达到我们的目标就要采用crm(cluster resource management)模式了。
　　本文需要实现的目标，让ha自动监控资源的运行状态。启动服务ip为192.168.0.222,自动运行脚本echo.sh
　　echo.sh脚本内容如下
　　#!/bin/bash
　　echo "ii" >> /var/lib/heartbeat/crm/1.txt
　　exit 0
　　配置crm
　　首先，先按默认模式安装、配置Heartbeat读者可参见
　　http://czmmiao.iteye.com/blog/1174010
　　默认模式配置成功后在ha.cf里面增加
　　crm on
　　将haresources资源文件转换成 cib.xml文件,2.1.3自带有转换脚本
　　#/usr/lib/heartbeat/haresources2cib.py haresources
　　输出文件在/var/lib /heartbeat/crm/cib.xml
　　如果hacluster和haclient用户和用户组是在安装heartbeat之后创建的话，则需要执行下面命令修改权限
　　修改heartbeat目录权限，可以用以下命令：
　　#find / -type d -name "heartbeat" -exec chown -R hacluster {} ;
　　#find / -type d -name "heartbeat" -exec chgrp -R haclient {} ;
　　在2.0的版本中ipfail与crm 模式有冲突，所以在ha.cf中不可打开ipfail。
　　cib.xml文件的修改
　　Heartbeat的cib.xml文件资源有两种配置风格分别是ocf和lsb在修改前先介绍一下ocf和lsb格式的区别：
　　LSB格式的角本必须支持status功能，必须能接收start,stop,status,三个参数。lsb格式的启动角本在 /usr/lib/lsb/resource.d/heartbeat目录下。
　　例如LSB风格的脚本,运行./mysql status时候，
　　返回值包含OK或则running则表示资源正常
　　返回值包含stopped或者No则表示资源不正常。
　　OCF格式,则必须支持start,stop,monitor三个参数.其中status和monitor参数是用来监控资源的。ocf格式的启动脚本在/usr/lib/ocf/resource.d/heartbeat(也许你的机器上目录不是这个，可以搜索ocf来查找)
　　假如是OCF风格的脚本,运行./mysql monitor时候,
　　返回0表示资源是正常的,
　　返回7表示资源出现问题.
　　在Heartbeat2.1.3中默认的资源配置风格为ocf，如果需要将资源的配置风格聪ocf修改为lsb有两种修改方法
　　1.修改cib.xml，将资源的ocf改成lsb。将脚本文件拷贝至/usr/lib/lsb/resource.d/heartbeat(如果该目录不存在，则手工创建，并将权限赋给hacluster:haclient)
　　2.修改/usr /lib/ocf/resource.d/heartbeat下面的脚本，使之能正常工作。或者将/etc/init.d/下的脚本拷过来，修改使它支持monitor操作
　　配置完成后启动heartbeat服务
　　#/etc/init.d/heartbeat start
　　创建群集资源
　　可以创建以下类型的资源
　　原始资源:原始资源是最基本的资源类型。
　　资源组:资源组包含一系列需要放置在一起、按顺序启动和以反序停止的资源。
　　克隆资源:克隆资源是可以在多个主机上处于活动状态的资源。如果各个资源代理支持，则任何资源均可克隆。
　　主资源:主资源是一种特殊的克隆资源，主资源可以具有多种模式。主资源必须只能包含一个组或一个常规资源。
　　资源选项
　　您可以为添加的每个资源定义选项。群集使用这些选项来决定资源的行为方式，它们会告知 CRM 如何对待特定的资源。可使用 crm_resource –meta 命令或 GUI 来设置资源选项。
　　原始资源选项
　　priority 如果不允许所有的资源都处于活动状态，群集会停止优先级较低的资源以便保持较高优先级资源处于活动状态。
　　target-role 群集应试图将此资源保持在何种状态，允许的值：Stopped 和 Started。
　　is-managed 是否允许群集启动和停止资源，允许的值：true和 false。
　　resource-stickiness 资源留在所处位置的自愿程度如何，默认为default- resource-stickiness 的值。
　　migration-threshold 节点上的此资源应发生多少故障后才能确定该节点没有资格主管此资源,默认值：none。
　　multiple-active 如果发现资源在多个节点上活动，群集该如何操作，允许的值：block（将资源标记为未受管）、stop_only 和 stop_start。
　　failure-timeout 在恢复为如同未发生故障一样正常工作（并允许资源返回它发生故障的节点）之前，需要等待几秒钟,默认值：never。
　　资源操作
　　默认情况下，群集将不会确保您的资源一直正常。要指示群集如此操作，需要向资源的定义中添加一个监视操作。可为所有类或资源代理添加监视操作。
　　ID ：您的操作名称。必须是唯一的。
　　name ：要执行的操作。常见值：monitor、start 和 stop。
　　interval ：执行操作的频率。单位：秒。
　　timeout ： 需要等待多久才能声明操作失败。
　　requires ：需要满足什么条件才能发生此操作。允许的值：nothing、quorum 和 fencing。默认值取决于是否启用屏障和资源的类是否为 stonith。对于 STONITH 资源，默认值为 nothing。
　　on-fail ：此操作失败时执行的操作。允许的值：
　　ignore：假装资源没有失败。
　　block：不对资源执行任何进一步操作。
　　stop：停止资源并且不在其他位置启动该资源。
　　restart：停止资源并（可能在不同的节点上）重启动。
　　fence：关闭资源失败的节点 (STONITH)。
　　standby：将所有资源从资源失败的节点上移走。
　　enabled 如果值为 false，将操作视为不存在。允许的值：true、false。
　　原始资源包含的参数
　　元属性：元属性是可以为资源添加的选项。它们告诉 CRM 如何处理特定资源。
　　实例属性：实例属性是特定资源类的参数,用于确定资源类的行为方式及其控制的服务实例。
　　操作：可以为资源添加监视操作。监视操作指示群集确保资源状况依然正常。所有资源代理类都可以添加监视操作。您还可以设置特定参数,如为 start 或stop 操作设置 timeout值。
　　定义原始资源：primitive   唯一ID   资源代理类型：资源代理的提供程序：资源代理名称  实例属性   操作  元属性
　　migration-threshold用来定义资源的故障次数，假设已经为资源配制了一个首选在节点上运行的位置约束。如果那里失败了,系统会检查 migration-threshold 并与故障计数进行比较。如果故障计数 >= migration-threshold,会将资源迁移到下一个自选节点。
　　默认情况下,一旦达到阈值,就只有在管理员手动重置资源的故障计数后(在修复故障原因后),才允许在该节点上运行有故障的资源。
　　但是,可以通过设置资源的 failure-timeout 选项使故障计数失效。如果设置migration-threshold=2 和 failure-timeout=60s ，将会导致资源在两次故障后迁移到新的节点,并且可能允许在一分钟后移回(取决于黏性和约束分数)。
　　迁移阈值概念有两个例外,在资源启动失败或停止失败时出现:启动故障会使故障计数设置为 INFINITY,因此总是导致立即迁移。停止故障会导致屏障(stonith-enabled 设置为 true 时,这是默认设置)。如果不定义 STONITH资源(或 stonith-enabled 设置为 false),则该资源根本不会迁移。
　　重置资源的故障计数：对指定节点上的指定资源执行 crm_resource -C 和 crm_failcount -D 命令。
　　如果在创建时将资源的初始状态设置为 stopped(target-role 元属性的值为 stopped),则资源在创建后不会自动启动。要想启动资源使用命令：crm resource start 资源ID
　　配置资源监视（可以在定义资源时用op monitor命令定义）
　　虽然 High Availability Extension 可以检测节点故障，但也能够检测节点上的各个资源何时发生故障。如果希望确保资源运行，则必须为该资源配置资源监视。资源监视包括指定超时和/或启动延迟值以及间隔。间隔告诉 CRM 检查资源状态的频率。
　　配置资源约束
　　配置好所有资源只是完成了该作业的一部分。即便群集熟悉所有必需资源,它可能还无法进行正确处理。资源约束允许您指定在哪些群集节点上运行资源、以何种顺序装载资源,以及特定资源依赖于哪些其他资源。
　　三种不同的约束:
　　Resource Location(资源位置)： 位置约束定义资源可以、不可以或首选在哪些节点上运行。
　　Resource Collocation(资源排列)： 排列约束告诉群集资源可以或不可以在某个节点上一起运行。
　　Resource Order(资源顺序)：排序约束定义操作的顺序。
　　定义约束时，还需要指定分数。各种分数是群集工作方式的重要组成部分。其实，从迁移资源到决定在已降级群集中停止哪些资源的整个过程是通过以某种方式操纵分数来实现的。分数按每个资源来计算，资源分数为负的任何节点都无法运行该资源。在计算出资源分数后，群集选择分数最高的节点。INFINITY（无穷大）目前定义为 1,000,000。加减无穷大遵循以下 3 个基本规则：
　　任何值 + 无穷大 = 无穷大
　　任何值 – 无穷大 = -无穷大
　　无穷大 – 无穷大 = -无穷大
　　定义资源约束时，也可以指定每个约束的分数。分数表示您指派给此资源约束的值。分数较高的约束先应用，分数较低的约束后应用。通过使用不同的分数为既定资源创建更多位置约束，可以指定资源要故障转移至的目标节点的顺序。
　　指定资源故障转移节点
　　资源在出现故障时会自动重启动。如果在当前节点上无法实现重启动，或如果在当前节点上发生 N 次故障，则资源会试图故障转移到其他节点。您可以多次定义资源的故障次数（migration-threshold），在该值之后资源会迁移到新节点。
　　指定资源故障回复节点（资源黏性）
　　当原始节点恢复联机并位于群集中时，资源可能会故障回复到该节点。如果希望阻止资源故障回复到故障转移前运行的节点上，或如果希望指定其他的节点让资源进行故障回复，则必须更改资源黏性值。在创建资源时或在创建资源后，都可以指定指定资源黏性。
　　在指定资源黏性值时，请考虑以下情况：
　　值为 0：这是默认选项。资源放置在系统中的最适合位置。这意味着当负载能力“较好”或较差的节点变得可用时才转移资源。此选项的作用几乎等同于自动故障回复，只是资源可能会转移到非之前活动的节点上。
　　值大于 0：资源更愿意留在当前位置，但是如果有更合适的节点可用时会移动。值越高表示资源越愿意留在当前位置。
　　值小于 0：资源更愿意移离当前位置。绝对值越高表示资源越愿意离开当前位置。
　　值为 INFINITY：如果不是因节点不适合运行资源（节点关机、节点待机、达到migration-threshold 或配置更改）而强制资源转移，资源总是留在当前位置。此选项的作用几乎等同于完全禁用自动故障回复。
　　值为 -INFINITY：资源总是移离当前位置。
　　定义位置约束：location  唯一ID  资源ID  规则
　　定义位置约束：location  唯一ID  资源ID  规则
　　location Prefer-Node1 ldirectord
　　rule $id="prefer-node1-rule" 100: #uname eq NODE1
　　资源排列约束
　　colocation 命令用于定义哪些资源应在相同主机上运行,哪些资源应在不同主机上运行。通常情况下使用以下顺序:
　　crm(live)configure# order rsc1 rsc2
　　crm(live)configure# colocation rsc2 rsc1

　　只能设置 +INFINITY 或 -INFINITY 的分数来定义必须始终或决不能在同一节点上运行的资源。例如,要始终在同一个主机上运行>　　crm(live)configure# colocation nfs_on_filesystem inf: nfs_group filesystem_resource
　　对于主从属配置,除在本地运行资源以外,还有必要了解当前节点是否为主节点。这可以通过附加 to_role 或 from_role 属性来检查。
　　排序约束：
　　有时提供启动资源的顺序是必要的。例如,在设备可用于系统之前,您不能装入文件系统。使用排序约束可在另一个资源满足某个特殊条件之前或之后启动或停止某项服务,如已启动、已停止或已升级到主资源。可使用 crm 中的以下命令来配置排序约束:
　　crm(live)configure# order nfs_after_filesystem mandatory: filesystem_resource nfs_group
　　配置群集资源组
　　某些群集资源与其他组件或资源相关,要求每个组件或资源以特定的顺序启动并在相同的服务器上运行。为了简化配置,引入资源组的概念。
　　资源组具有以下属性:
　　启动和停止资源：资源以显示顺序启动,以相反顺序停止。
　　相关性：如果组中某个资源在某处无法运行,则该组中位于其之后的任何资源都不允许运行。

　　组内容：组可能仅包含一些原始群集资源。要引用组资源的子代,请使用子代的>　　限制：尽管在约束中可以引用组的子代,但通常倾向于使用组的名称。
　　黏性：黏性在组中可以累加。每个活动的组成员可以将其黏性值累加到组的总分中。因此,如果默认的 resource-stickiness 值为 100,而组中有七个成员,其中五个成员是活动的,则组总分为 500,更喜欢其当前位置。
　　定义资源组：group  唯一ID  资源列表
　　例如：
　　group Load-Balancing Virtual-IP-Tomcat ldirectord
　　配置克隆资源：
　　可能希望某些资源在群集的多个节点上同时运行。为此,必须将资源配置为克隆资源。可以配置为克隆资源的资源示例包括 STONITH 和群集文件系统(如OCFS2)。如果受资源的资源代理支持,则可以克隆任何资源。克隆资源的配置甚至也有不同,具体取决于资源驻留的节点。
　　资源克隆有三种类型:
　　匿名克隆：这是最简单的克隆类型。这种克隆类型在所有位置上的运行方式都相同。因此,每台计算机上只能有一个匿名克隆实例是活动的。
　　全局唯一克隆：这些资源各不相同。一个节点上运行的克隆实例与另一个节点上运行的实例不同,同一个节点上运行的任何两个实例也不同。
　　状态克隆：这些资源的活动实例分为两种状态:主动和被动。有时也称为主要和辅助,或主和从。状态克隆可以是匿名克隆也可以是全局唯一克隆。
　　定义克隆资源：clone  唯一ID  资源ID
　　例如：
　　clone cl-tomcat tomcat
　　clone cl-mysql mysql
　　状态克隆：
　　primitive drbd_mysql ocf:linbit:drbd \
　　params drbd_resource="mysql" \
　　op monitor interval="15s"
　　ms ms_drbd_mysql drbd_mysql \
　　meta master-max="1" master-node-max="1" \
　　clone-max="2" clone-node-max="1" \
　　notify="true"
　　设置CRM其他属性
　　如果是两个节点的集群，应该设置no-quorum-policy为ignore，如果一个节点down掉，另一个节点仍能正常运行。设置start- failure-is-fatal 为false 允许你为每一个资源设置migration-threshold属性。如果没有定义stonith资源则必须设置stonith-enabled为 false。
　　property no-quorum-policy="ignore" \
　　start-failure-is-fatal="false" \
　　stonith-enabled="false"
　　迁移群集资源
　　crm(live)# resource
　　crm(live)resource# migrate VIP node2
　　启动/停止资源:
　　crm resource start resource-ID
　　crm resource stop resource-ID
　　在特定节点上执行：
　　使节点变成备份节点
　　crm node standby
　　使节点变成活动节点
　　crm node online
　　cib.xml
　　
　　
　　
　　
　　               #配置资源元属性
　　
　　
　　                      #将默认得分设为0
　　               #将默认失分设为0
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　               #配置资源组属性
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　               #配置ip得分
　　               #配置ip失分
　　
　　
　　
　　
　　
　　
　　
　　               #去掉interval值避免不断执行echo.sh脚本
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　           #配置资源约束
　　
　　               #为ha1上的ip资源配置默认分数值，注意，在rsc里配置了资源组的限制如group_1的情况下,如果只设置资源的得分，没有配置默认资源的情况下，则该限制无效。笔者无法成功测试配置资源组的得分，如果有成功的读者望与笔者分享下配置心得
　　
　　
　　
　　         #为ha1上的脚本资源配置默认分数值
　　
　　
　　
　　
　　
　　           #为ha2上的ip资源配置默认分数值
　　
　　
　　
　　
　　         #为ha2上的脚本资源配置默认分数值
　　
　　
　　
　　         #限制ip资源和echo.sh资源跑在一起
　　
　　
　　
　　参考至：http://club.topsage.com/thread-530660-1-1.html
　　http://www.jfox.info/xtgl/a/dl/2984f.html
　　http://zhouchunyan500.blog.163.com/blog/static/132443720112134554891/
　　http://tech.ddvip.com/2009-12/1262248972142506_3.html
　　http://bbs.chinaunix.net/thread-2208623-1-1.html
　　http://doc.chinaunix.net/linux/200902/239743.shtml
　　http://www.novell.com/documentation/sles10/heartbeat/?page=/documentation//sles10/heartbeat/data/sec_hb_manual_config_constraints.html