用CRM命令行工具配置集群资源
以下为转帖,原帖网址为:http://club.topsage.com/thread-530660-1-1.html
1. 创建群集资源
可以创建以下类型的资源：
原始资源:原始资源是最基本的资源类型。
资源组:资源组包含一系列需要放置在一起、按顺序启动和以反序停止的资源。
克隆资源:克隆资源是可以在多个主机上处于活动状态的资源。如果各个资源代理支持，则任何资源均可克隆。
主资源:主资源是一种特殊的克隆资源，主资源可以具有多种模式。主资源必须只能包含一个组或一个常规资源。
资源选项:
您可以为添加的每个资源定义选项。群集使用这些选项来决定资源的行为方式，它们会告知 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 资源代理类型：资源代理的提供程序：资源代理名称 实例属性 操作 元属性
例如：
primitive Virtual-IP-Tomcat ocf:heartbeat:IPaddr2
params lvs_support="true" ip="192.168.1.100" cidr_netmask="24" broadcast="192.168.1.255" \
op monitor interval="1m" timeout="10s" \
meta migration-threshold="10"
primitive ldirectord ocf:heartbeat:ldirectord \
params configfile="/etc/ha.d/ldirectord.cf" \
op monitor interval="2m" timeout="20s" \
meta migration-threshold="10" target-role="Started"
primitive tomcat lsb:tomcat \
op monitor interval="30s" timeout="10s" \
meta migration-threshold="10" target-role="Started"
primitive mysql ocf:heartbeat:mysql \
params binary="/usr/bin/mysqld_safe" config="/etc/my.cnf" datadir="/var/lib/mysql" user="mysql" pid="/var/lib/mysql/mysql.pid" socket="/var/lib/mysql/mysql.sock" test_passwd="password" test_table="ldirectord.connectioncheck" test_user="slave_user" \
op monitor interval="20s" timeout="10s" \
meta migration-threshold="10" target-role="Started"
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 检查资源状态的频率。
# crm
crm(live)# configure
crm(live)configure# monitor mysql monitor interval="20s" timeout="10s"
2. 配置资源约束：
配置好所有资源只是完成了该作业的一部分。即便群集熟悉所有必需资源,它可能还无法进行正确处理。资源约束允许您指定在哪些群集节点上运行资源、以何种顺序装载资源,以及特定资源依赖于哪些其他资源。
三种不同的约束:
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 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 的分数来定义必须始终或决不能在同一节点上运行的资源。例如,要始终在同一个主机上运行 ID 为filesystem_resource 和 nfs_group 的两个资源,可使用以下约束:
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
3. 配置群集资源组：
某些群集资源与其他组件或资源相关,要求每个组件或资源以特定的顺序启动并在相同的服务器上运行。为了简化配置,引入资源组的概念。
资源组具有以下属性:
启动和停止资源：资源以显示顺序启动,以相反顺序停止。
相关性：如果组中某个资源在某处无法运行,则该组中位于其之后的任何资源都不允许运行。
组内容：组可能仅包含一些原始群集资源。要引用组资源的子代,请使用子代的 ID代替组的 ID。
限制：尽管在约束中可以引用组的子代,但通常倾向于使用组的名称。
黏性：黏性在组中可以累加。每个活动的组成员可以将其黏性值累加到组的总分中。因此,如果默认的 resource-stickiness 值为 100,而组中有七个成员,其中五个成员是活动的,则组总分为 500,更喜欢其当前位置。
定义资源组：group 唯一ID 资源列表
例如：
group Load-Balancing Virtual-IP-Tomcat ldirectord
4. 配置克隆资源：
可能希望某些资源在群集的多个节点上同时运行。为此,必须将资源配置为克隆资源。可以配置为克隆资源的资源示例包括 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"
5. 设置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"
6. 迁移群集资源:
crm(live)# resource
crm(live)resource# migrate VIP node2
7. 启动/停止资源:
crm resource start resource-ID
crm resource stop resource-ID
8. 在特定节点上执行：
使节点变成备份节点
crm node standby
使节点变成活动节点
crm node online
1. 创建群集资源
可以创建以下类型的资源：
原始资源:原始资源是最基本的资源类型。
资源组:资源组包含一系列需要放置在一起、按顺序启动和以反序停止的资源。
克隆资源:克隆资源是可以在多个主机上处于活动状态的资源。如果各个资源代理支持，则任何资源均可克隆。
主资源:主资源是一种特殊的克隆资源，主资源可以具有多种模式。主资源必须只能包含一个组或一个常规资源。
资源选项:
您可以为添加的每个资源定义选项。群集使用这些选项来决定资源的行为方式，它们会告知 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 资源代理类型：资源代理的提供程序：资源代理名称 实例属性 操作 元属性
例如：
primitive Virtual-IP-Tomcat ocf:heartbeat:IPaddr2
params lvs_support="true" ip="192.168.1.100" cidr_netmask="24" broadcast="192.168.1.255" \
op monitor interval="1m" timeout="10s" \
meta migration-threshold="10"
primitive ldirectord ocf:heartbeat:ldirectord \
params configfile="/etc/ha.d/ldirectord.cf" \
op monitor interval="2m" timeout="20s" \
meta migration-threshold="10" target-role="Started"
primitive tomcat lsb:tomcat \
op monitor interval="30s" timeout="10s" \
meta migration-threshold="10" target-role="Started"
primitive mysql ocf:heartbeat:mysql \
params binary="/usr/bin/mysqld_safe" config="/etc/my.cnf" datadir="/var/lib/mysql" user="mysql" pid="/var/lib/mysql/mysql.pid" socket="/var/lib/mysql/mysql.sock" test_passwd="password" test_table="ldirectord.connectioncheck" test_user="slave_user" \
op monitor interval="20s" timeout="10s" \
meta migration-threshold="10" target-role="Started"
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 检查资源状态的频率。
# crm
crm(live)# configure
crm(live)configure# monitor mysql monitor interval="20s" timeout="10s"
2. 配置资源约束：
配置好所有资源只是完成了该作业的一部分。即便群集熟悉所有必需资源,它可能还无法进行正确处理。资源约束允许您指定在哪些群集节点上运行资源、以何种顺序装载资源,以及特定资源依赖于哪些其他资源。
三种不同的约束:
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 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 的分数来定义必须始终或决不能在同一节点上运行的资源。例如,要始终在同一个主机上运行 ID 为filesystem_resource 和 nfs_group 的两个资源,可使用以下约束:
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
3. 配置群集资源组：
某些群集资源与其他组件或资源相关,要求每个组件或资源以特定的顺序启动并在相同的服务器上运行。为了简化配置,引入资源组的概念。
资源组具有以下属性:
启动和停止资源：资源以显示顺序启动,以相反顺序停止。
相关性：如果组中某个资源在某处无法运行,则该组中位于其之后的任何资源都不允许运行。
组内容：组可能仅包含一些原始群集资源。要引用组资源的子代,请使用子代的 ID代替组的 ID。
限制：尽管在约束中可以引用组的子代,但通常倾向于使用组的名称。
黏性：黏性在组中可以累加。每个活动的组成员可以将其黏性值累加到组的总分中。因此,如果默认的 resource-stickiness 值为 100,而组中有七个成员,其中五个成员是活动的,则组总分为 500,更喜欢其当前位置。
定义资源组：group 唯一ID 资源列表
例如：
group Load-Balancing Virtual-IP-Tomcat ldirectord
4. 配置克隆资源：
可能希望某些资源在群集的多个节点上同时运行。为此,必须将资源配置为克隆资源。可以配置为克隆资源的资源示例包括 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"
5. 设置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"
6. 迁移群集资源:
crm(live)# resource
crm(live)resource# migrate VIP node2
7. 启动/停止资源:
crm resource start resource-ID
crm resource stop resource-ID
8. 在特定节点上执行：
使节点变成备份节点
crm node standby
使节点变成活动节点
crm node online