配置pacemaker有2种途径，一是命令行工具包括crm和pcs，二是图形工具包括：pygui(mgmt),Hawk,LCMC,pcsd. mgmt出道时间较早，很多文章有介绍；LCMC是Java编写的图形管理工具；Hawk则是官方推荐的代替mgmt的web界面配置工具；pcsd则是pcs的图形界面。具体可参考http://clusterlabs.org/#addons
本文主要介绍命令行工具crm, 而pcs和crm相似，语法稍有不同，掌握crm后使用pcs不成问题。
注：从Pacemaker 1.1.8开始，crmsh发展成一个独立项目，Pacemaker中不再提供。我们安装好Pacemaker后，是没有crm这个命令行管理器的，需另行下载安装。（https://savannah.nongnu.org/projects/crmsh/）
1.1.8之前版本已含crm,无需另行下载。
crm有两种工作方式，
a.批处理模式就是在命令行中直接输入命令（如执行crm status）
b.交互式模式：运行crm，进入crm(live)# , 按2次Tab键可显示该层级所有指令
1.CRM交互模式基本指令介绍：
help,? #查看当前区域可用命令
end,cd,up,back #返回上一级
quit,bye,exit #退出crm（live）交互模式
例：crm(live)# ？configure #查看configure指令的帮助信息
crm采用分层设计，拥有多层命令，输入某命令表示进入该命令层，命令可输头几个字母按Tab补全
例：crm(live)# configure #进入configure命令层
crm中常用一级命令：
configure 用于设置具体参数
resource 对已定义资源进行各种操作
ra resource agents center, 可查看哪些resource agent可供使用
cib 类似于configure，只是操作的是cib shadow
node 对节点进行各类操作
status 显示集群状态信息
2.configure 具体使用
2.1常用指令列表：
crm(live)configure# show #查看当前配置
crm(live)configure# verify #检查当前配置是否正确, 相当于crm_verify -L
crm(live)configure# commit #提交配置使配置生效，修改后没提交系统不会保存更改的信息
crm(live)configure# delete <id> #删除某项配置, id为该项的名称
crm(live)configure# edit <id> #编辑某项配置，id为该项的名称
crm(live)configure# primitive #定义资源
crm(live)configure# monitor #资源检视
crm(live)configure# group #创建组资源，将几项资源编成一组
crm(live)configure# clone #克隆已建的资源
crm(live)configure# ms/master #定义master/slave资源
2.2 定义资源
在configure中定义默认资源属性
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。
例：crm(live)configure# rsc_defaults resource-stickiness=100
#指定资源指定默认黏性值
2.2.1 primitive中参数说明
primitive 唯一ID 资源代理类型：资源代理的提供程序：资源代理名称
params attr_list
meta attr_list
op op_type [<attribute>=<value>...] ...]
资源代理类型： lsb, ocf, stonith, service
资源代理的提供程序： heartbeat , pacemaker
资源代理名称：即resource agent， 如：IPaddr2,httpd, mysql
meta--元属性， 是可以为资源添加的选项。它们告诉 CRM 如何处理特定资源。
params--实例属性，是特定资源类的参数,用于确定资源类的行为方式及其控制的服务实例。
op--操作，默认情况下，群集不会确保您的资源一直正常。要指示群集确保资源状况依然正常，需要向资源的定义中添加一个监视操作monitor。可为所有类或资源代理添加monitor。
op_type ：包括 start，stop，monitor
interval ：执行操作的频率。单位：秒。
timeout ： 需要等待多久才声明操作失败。
requires ：需要满足什么条件才能发生此操作。允许的值：nothing、quorum 和 fencing。默认值取决于是否启用屏障和资源的类是否为 stonith。对于 STONITH 资源，默认值为 nothing。
on-fail ：此操作失败时执行的操作。允许的值：
ignore：假装资源没有失败。
block：不对资源执行任何进一步操作。
stop：停止资源并且不在其他位置启动该资源。
restart：停止资源并（可能在不同的节点上）重启动。
fence：关闭资源失败的节点 (STONITH)。
standby：将所有资源从资源失败的节点上移走。
enabled 如果值为 false，将操作视为不存在。允许的值：true、false。
例：
primitive r0 ocf:linbit:drbd \
params drbd_resource=r0 \
op monitor role=Master interval=60s \
op monitor role=Slave interval=300s
meta元属性参数说明
priority：如果不允许所有的资源都处于活动状态，群集会停止优先级较低的资源以便保持较高优先级资源处于活动状态。
target-role： 此资源试图保持的状态，包括started和stopped
is-managed：是否允许群集启动和停止资源，包括true和 false。
migration-threshold：用来定义资源的故障次数，假设已经为资源配制了一个首选在节点上运行的位置约束。如果那里失败了,系统会检查 migration-threshold 并与故障计数进行比较。如果故障计数 >= migration-threshold,会将资源迁移到下一个自选节点。
默认情况下,一旦达到阈值,就只有在管理员手动重置资源的故障计数后(在修复故障原因后),才允许在该节点上运行有故障的资源。
但是,可以通过设置资源的 failure-timeout 选项使故障计数失效。如果设置migration-threshold=2 和 failure-timeout=60s ，将会导致资源在两次故障后迁移到新的节点,并且可能允许在一分钟后移回(取决于黏性和约束分数)。
迁移阈值概念有两个例外,在资源启动失败或停止失败时出现:启动故障会使故障计数设置为 INFINITY,因此总是导致立即迁移。停止故障会导致屏障(stonith-enabled 设置为 true 时,这是默认设置)。如果不定义 STONITH资源(或 stonith-enabled 设置为 false),则该资源根本不会迁移。
failure-timeout：在恢复为如同未发生故障一样正常工作（并允许资源返回它发生故障的节点）之前，需要等待几秒钟,，默认值0 (disabled)
resource-stickiness：资源留在所处位置的自愿程度如何，即黏性，默认为0。
multiple-active：如果发现资源在多个节点上活动，群集该如何操作，包括：
block（将资源标记为未受管），stop_only（停止所有活动实例），stop_start（默认值，停止所有活动实例，并在某个节点启动资源）
requires：定义某种条件下资源会被启动。默认资源会被fencing，为以下这几种值时除外
* nothing - 集群总能启动资源；
* quorum - 集群只有在大多数节点在线时能启动资源，当stonith-enabled为false 或资源为stonith时，其为默认值；
* fencing - 集群只有在大多数节点在线，或在任何失败或未知节点被关闭电源时，才能启动资源；
* unfencing - 集群只有在大多数节点在线，或在任何失败或未知节点被关闭电源时并且只有当节点没被fencing时，才能启动资源。当为某一fencing设备，而将stonith的meta参数设置为provides=unfencing时，其为默认值；
例：
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"
重置资源的故障计数：对指定节点上的指定资源执行 crm_resource -C 和 crm_failcount -D 命令。
如果在创建时将资源的初始状态设置为 stopped(target-role 元属性的值为 stopped),则资源在创建后不会自动启动。要想启动资源使用命令：crm resource start 资源ID
2.3 资源3种约束：
crm(live)configure# colocation #排列约束，指定哪些资源捆绑一起，在同一节点上运行
crm(live)configure# order #指定排列约束中的资源启动顺序，该顺序和colocation顺序相反
crm(live)configure# location #位置约束，指定资源首选在哪些节点上运行
定义约束的顺序也是由上到下
排列约束-------》顺序约束-----》位置约束
只有在一起了，才有先后，然后将两者一起放到一个节点上。
colocation资源排列约束:
colocation 命令用于定义哪些资源应在相同主机上运行,哪些资源应在不同主机上运行。
通常情况下colocation和order成对出现，而colocation中资源的顺序和order中的相反。Active/Passive模式和Active/Active模式均可使用colocation和order
crm(live)configure# order rsc1 rsc2
crm(live)configure# colocation rsc2 rsc1
colocation语法:
colocation <id> <score>: <rsc>[:<role>] <with-rsc>[:<role>]
[node-attribute=<node_attr>]
colocation <id> <score>: <rsc>[:<role>] <rsc>[:<role>] ...
[node-attribute=<node_attr>]
<score>中，只能设置 +INFINITY 或 -INFINITY 的分数来定义必须始终或决不能在同一节点上运行的资源。
例：始终在同一节点上运行ID为filesystem_resource 和 nfs_group 的两个资源
crm(live)configure# colocation nfs_on_filesystem inf: nfs_group filesystem_resource
例：ID为apache和dummy两个资源始终不在同一节点上运行
colocation never_put_apache_with_dummy -inf: apache dummy
对于主从属配置,除在本地运行资源以外,还有必要了解当前节点是否为主节点。这可以通过附加 to_role 或 from_role 属性来检查。
定义约束时，可指定分数。各种分数是群集工作方式的重要组成部分。其实，从迁移资源到决定在已降级群集中停止哪些资源的整个过程是通过以某种方式操纵分数来实现的。分数按每个资源来计算，资源分数为负的任何节点都无法运行该资源。在计算出资源分数后，群集选择分数最高的节点。、
查看节点的分值/黏性：# crm_simulate -sL
INFINITY（无穷大）目前定义为 1,000,000。
SCORE加减无穷大遵循以下规则：
number > INFINITY = INFINITY
number < -INFINITY = - INFINITY
number + INFINITY = INFINITY
number - INFINITY = - INFINITY
INFINITY - INFINITY = - INFINITY
定义资源约束时，也可以指定每个约束的分数。分数表示您指派给此资源约束的值。分数较高的约束先应用，分数较低的约束后应用。通过使用不同的分数为既定资源创建更多位置约束，可以指定资源要故障转移至的目标节点的顺序。
order排序约束：
使用排序约束可在另一个资源满足某个特殊条件之前或之后启动或停止某项服务,如已启动、已停止或已升级到主资源。
order <id> {kind|<score>}: <rsc>[:<action>] <rsc>[:<action>] ...
[symmetrical=<bool>]
kind包括： Mandatory | Optional | Serialize
Mandatory 默认值，表示强制约束，所有Mandatory资源的状态必定相同，其他资源状态跟随第1个资源的状态变化而变化。有Mandatory关系的两个资源，当第1个资源stop后，第2个资源也必须stop。启动/停止顺序按从左到右。
Optional表示选择性约束，当第1个资源状态发生变化时，第2个资源不会受影响，不会跟随变化。只有当多个资源同时启动或停止时才发生order作用。
Serialize表示顺序约束，资源按顺序启动/停止，不可同时启动/停止。
可使用 crm 中的以下命令来配置排序约束:
crm(live)configure# order nfs_after_filesystem mandatory: filesystem_resource nfs_group
location位置约束：定义资源可在哪个节点上运行
location 唯一ID 资源ID 规则
location <id> <rsc> {node_pref|rules}
node_pref格式为: <score>: <node> [role=<role>]
rules格式为: rule [id_spec] [$role=<role>] <score>: <expression>
例：在名为 earth 的节点上运行 ID为fs1的资源的可能性增加到 100
location fs1-loc fs1 100: earth
例：
location Prefer-Node1 ldirectord
rule $id="prefer-node1-rule" 100: #uname eq NODE1
示例配置约束:
如果没有附加约束，示例将不能按预期工作。其中最基本的就是让所有资源在同一台计算机上作为 drbd 资源的主资源运行。另一个关键点就是在任何其他资源启动之前，drbd 资源必须是主资源。在 drbd 不是主资源时尝试装入 drbd 设备只能失败。必须满足的约束如下所示：
文件系统必须始终与 drbd 资源的主资源位于相同的节点上。
crm(live)configure# colocation filesystem_on_master inf: \
filesystem_resource drbd_resource:Master
NFS 服务器及 IP 地址必须与文件系统位于相同的节点上。
crm(live)configure# colocation nfs_with_fs inf: \
nfs_group filesystem_resource
NFS 服务器及 IP 地址在装入文件系统后启动：
crm(live)configure# order nfs_second mandatory: \
filesystem_resource nfs_group
必须在 drbd 资源升级为节点上的主资源之后将文件系统装入此节点上。
crm(live)configure# order drbd_first inf: \
drbd_resource:promote filesystem_resource
2.4 配置群集资源组：
某些群集资源与其他组件或资源相关,要求每个组件或资源以特定的顺序启动并在相同的服务器上运行。为了简化配置,引入资源组的概念。
资源组具有以下属性:
启动和停止资源：资源以显示顺序启动,以相反顺序停止。
相关性：如果组中某个资源在某处无法运行,则该组中位于其之后的任何资源都不允许运行。
组内容：组可能仅包含一些原始群集资源。要引用组资源的子代,请使用子代的 ID代替组的 ID。
限制：尽管在约束中可以引用组的子代,但通常倾向于使用组的名称。
黏性：黏性在组中可以累加。每个活动的组成员可以将其黏性值累加到组的总分中。因此,如果默认的 resource-stickiness 值为 100,而组中有七个成员,其中五个成员是活动的,则组总分为 500,更喜欢其当前位置。
定义资源组：group 唯一ID 资源列表
例：group Load-Balancing Virtual-IP-Tomcat ldirectord
group在Active/Passive模式中使用，资源启动顺序从左至右，其作用相当于colocation+order
但在Active/Active模式中，通常有clone语句，而group语句对clone定义的资源无效，这时应使用colocation和order.
2.5 配置克隆资源：
在一个Active/Active模式中，某些资源在群集的多个节点上同时运行。为此,必须将资源配置为克隆资源。可以配置为克隆资源的资源包括 STONITH 和群集文件系统(如OCFS2)。如有resource agent支持,则可以克隆任何资源。克隆资源的配置甚至也有不同,具体取决于资源驻留的节点。
资源克隆有三种类型:
匿名克隆：参数globally-unique=false。这是最简单的克隆类型。这种克隆类型在所有位置上的运行方式都相同。因此,每台计算机上只能有一个匿名克隆实例是活动的。
全局唯一克隆：参数globally-unique=true。这些资源各不相同。一个节点上运行的克隆实例与另一个节点上运行的实例不同,同一个节点上运行的任何两个实例也不同。
状态克隆：作为参数出现在ms/master中。这些资源的活动实例分为两种状态:主动和被动，也称主和从。状态克隆可以是匿名克隆也可以是全局唯一克隆。
定义克隆资源：clone 唯一ID 资源ID
参数：
clone-max：克隆副本的最大值，默认是集群节点数
clone-node-max：单个节点可启动克隆副本的最大个数，默认为1
notify：某个克隆停止或启动时通知其他克隆，可选true 或 false
globally-unique：
定义每个克隆副本是否全局唯一，为false时副本在每一处的作用相同，但每个节点只能有1个副本是active的；为true时每个副本和其他副本都不相同，无论是在同一个节点或是在不同的节点，当clone-node-max>1时，默认值为true。
ordered：副本按顺序启动/停止，代替并发启动。包括true和false，默认为false。
interleave：副本交错启动/停止，改变master/clone间的order约束，每个实例像其他克隆实例一样可快速启动/停止，无需等待其他克隆实例。
priority, target-role, is-managed的定义参考meta说明。
例如：
clone cl-mysql mysql
clone cl_fence apc_1 \
meta clone-node-max=1 globally-unique=false
状态克隆：
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"
注：每个节点克隆数大于1时（clone-node-max>1），需指定globally-unique=true，clone-node-max默认值为1
2.6 定义主从资源
ms或master指令定义主从资源（master/slave），如drbd
ms <name> <rsc>
[description=<description>]
[meta attr_list]
[params attr_list]
attr_list :: [$id=<id>] <attr>=<val> [<attr>=<val>...] | $id-ref=<id>
例:
ms disk1 drbd1 \
meta notify=true globally-unique=false
2.7 配置资源监视monitor
如果希望确保资源运行，则必须为该资源配置资源监视。
有两种方法可以监视资源：使用 op 关键字定义监视操作或使用 monitor 命令。资源监视包括指定超时，启动延迟值以及间隔。间隔告诉 CRM 检查资源状态的频率。
以下示例配置了一个 Apache 资源并使用 op 关键字每 30 分钟对它进行监视一次：
crm(live)configure# primitive apache apache \
params ... \
op monitor interval=60s timeout=30s
同样也可以使用以下方式来实现：
crm(live)configure# primitive apache apache \
params ...
crm(live)configure# monitor apache 60s:30s
2.8. 设置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"
3.RA(resource agents)使用
3.1查看RA类型：
crm(live)configure ra# classes
lsb：linux标准库，一般位于/etc/rc.d/init.d/目录下的支持start|stop|status等参数的服务脚本都是lsb
ocf / heartbeat pacemaker #ocf（Open cluster Framework）开放集群架构，包括heartbeat和pacemaker
service：
stonith：专为配置stonith设备而用
lsb和ocf使用得较多，其中ocf格式脚本调用较复杂，可使用meta指令查看其参数具体使用。
例：查看Filesystem的资源选项参数
crm(live)configure ra# classes
crm(live)configure ra# list ocf #列出所有ocf脚本，其中有Filesystem
crm(live)configure ra# providers Filesystem #查看Filesystem属于哪个类别
heartbeat #结果显示Filesystem属于heartbeat
crm(live)configure ra# meta ocf:heartbeat:Filesystem #查看Filesystem资源选项参数
Manages filesystem mounts (ocf:heartbeat:Filesystem)
......................................................
Parameters (* denotes required, [] the default):
device* (string): block device
The name of block device for the filesystem, or -U, -L options for mount, or NFS mount specification.
directory* (string): mount point
The mount point for the filesystem.
fstype* (string): filesystem type
The type of filesystem to be mounted.
......................................................
其中带有*表示必填参数，群集使用这些参数选项来决定资源的行为方式，它们会告知 CRM 如何对待特定的资源。除了在crm交互模式中定义资源选项参数外，还可使用 crm_resource –meta 命令或 GUI 来设置资源选项。
例：
crm(live)configure# primitive webnfs ocf:heartbeat:Filesystem \
params device="192.168.1.110:/share" directory="/var/www/html" fstype="nfs" \
op monitor interval=60s timeout=60s op start timeout=60s op stop timeout=60s
4.resource的使用
未完，待续....................