corosync pacemaker 配置高可用集群（二）

在上一篇《corosync pacemaker 配置高可用集群（一）》配置corosync+pacemaker 可以正常运行了，下面将用crm sh接着进行corosync+pacemaker +NFS共享存储的WEB高可用集群的余下相关配置。

1、认识crm sh

相比heartbeat v2，pacemaker配置接口更强大：CLI：crm sh、pcs和GUI：hawk(WEB-GUI)、LCMC、pacemaker-mgmt、pcs等,下面将会用crm sh来配置。

crm（sh）命令行模式的资源管理器配置接口，从pacemaker 1.1.8开始，crm sh 发展成一个独立项目，pacemaker中不再提供，得另外下载安装，而我们安装pacemaker为1.0.7版本，直接可以使用即可。

1-1、crm sh使用方法

crm sh两种使用模式：交互式和批处理，批处理配置立即生效使，交互式配置执行commit命令以后才生效，交互式支持自动补全。交互式用方法如下：

[root@node1 ~]# crm     #输入crm命令，进入crm sh 模式

crm(live)# help     #输入help查看一下，会出下很多子命令

crm(live)# configure     #输入configure就会进入，configure模式下，

crm(live)configure#         #敲两下tab键就会显示configure下全部命令

crm(live)configure# help node     #输入help加你想了解的任意命令，就会显示该命令的使用帮助与案例

crm(live)configure# cd ../        #返回上一级

1-2、crm sh常用操作

1、查看一下集群状态，这和使用crm_mon是一样的，如下：

crm(live)# status

2、查看一下CIB配置：

crm(live)# configure

crm(live)configure# show

crm(live)configure# show xml #查xml格式文件

3、检测一下配置文件是否有错，可以看到刚开始默认STONITH配置错误，因为没有STONITH设备（下面再解决）：

crm(live)configure# verify

4、查看当前集群系统所支持的资源代理类型，可以看到支持我们前面文章据说的几种资源代理类型：

crm(live)ra# classes

5、查看某种类别下的所用资源代理的列表，分别查看了所有lsb类型资源、heartbeat资源代理和pacemaker资源代理：

crm(live)ra# list lsb

crm(live)ra# list ocf heartbeat

crm(live)ra# list ocf pacemaker

6、查看某个资源代理的配置方法，下面查看了heartbeat的ip资源的配置方法：

crm(live)ra# info ocf:heartbeat:IPaddr

好了，简单说明就到这，其实就是一句话，不会的命令help一下。下面我们开始配置高可用的Web集群。

2、配置集群资源组

集群中拥有三个资源VIP、NFS存储和httpd，如果只是把各个资源配置进去就启动集群，各资源可能会被分摊到各节点上，而且它们的启动、停止顺序也不明确，所以我们要根据需要配置资源组或资源约束，具体的概念在前文《高可用集群》有讲述，这里不多讲。

下面先尝试比较简单的方式，把VIP、NFS存储和httpd三个资源配置到资源组group_webservice里，按顺序启动，注意配置的参数，配置过程如下：

1、先解决上面发现的刚开始默认STONITH配置错误，因为没有STONITH设备，修改默认属性配置，如下：

crm(live)configure# property stonith-enabled=false

2、创建IP地址资源，IP资源是主资源，可以查看一下怎么定义一个主资源，配置验证后，记得提交，提交立即生效，可以看到VIP配置到node1上，过程如下：

crm(live)configure# primitive

crm(live)configure# primitive vip ocf:heartbeat:IPaddr params ip=192.168.18.240 nic=eth0 cidr_netmask=24

crm(live)configure# verify

crm(live)configure# commit

3、接着配置NFS共享存储和httpd服务，配置生效后，看到三个资源不在同一节点上，如下：

crm(live)configure# primitive nfs ocf:heartbeat:Filesystem params device=192.168.18.243:/web/hahtml directory=/var/www/html fstype=nfs

crm(live)configure# primitive httpd lsb:httpd

crm(live)configure# verify

crm(live)configure# commit

4、创建资源组，把三个资源加到里面，使三个资源在同一节点上运行，如下：

crm(live)configure# group group_webservice webvip nfs httpd

crm(live)configure# verify

crm(live)configure# commit

3、启动资源组测试

1、上面三个资源VIP、NFS存储和httpd放到同一个资源组后，三个资源就会在同一节点上运行，但测试时发现httpd怎么都无法运行，原来是有节点主机上的SELINUX没关闭，无法访问到NFS共享存储目录，setenforce 0关闭后，需要在crm sh中清理资源状态，才能正常启动，过程如下：

2、正常运行后，查看VIP配置在node1的eth0的别名上，再通过浏览器访问VIP，返回的是NFS服务器上的测试页面：

3、使活动节点node1成为备节点，可以看到node2成为主节点，查看VIP配置在node2的eth0的别名上，再通过浏览器访问VIP，返回的还是NFS服务器上的测试页面：

4、使活动节点node1重新上线，可以看到资源重回转到node1（这是个问题，下面分析）：

以上测试说明crm sh配置的corosync+pacemaker集群提供了高可用功能，同时使用了NFS共享存储WEB文件。

4、其他关注点

4-1、资源回转的问题（资源黏性）

上面启动资源组测试第三步：node2为拥有资源的活动节点，现使得node1重新上线也成功为活动节点，可以看到资源重回转到node1（但也可能不回去）。

资源的这种在节点间每一次的来回流动都会造成那段时间内其无法正常被访问，所以，我们有时候需要在资源因为节点故障转移到其它节点后，即便原来的节点恢复正常也禁止资源再次流转回来。这可以通过定义资源的黏性(stickiness)来实现（具体的概念在前文《高可用集群》有讲述，这里不多讲）。

而设置提交后，重复上面的测试过程，可以看到node2上的资源不再回转到node1,继续留在node2上

crm(live)configure# rsc_defaults resource-stickiness=100

crm(live)configure# commit

4-2、不满足合法票数的问题

在前文《高可用集群》有讲述高可用集群的合法票数（quorum）的问题，而现在配置的集群只有两个节点，也没有引入第三方仲裁设备，当其中一个节点突然宕机时，另一个会因为获得不足法定票数而无法启动资源。

例如，当node2在运行资源时，停止node2上的corosync服务，发现node1无法启动获得资源：

因为此时的集群状态为"WITHOUT quorum"（上图DC状态标识），即已经失去了quorum，此时集群服务本身已经不满足正常运行的条件，这对于只有两节点的集群来讲是不合理的。因此，我们可以通过如下的命令来修改忽略quorum不能满足的集群状态检查：

crm(live)configure# property no-quorum-policy=ignore #开始配置成no_quorum_policy导致有警告

crm(live)configure# verify

crm(live)configure# commit

提交生效后，再重复上面的测试过程，可以看到node2停止服务，node1立即获取资源：

5、配置单个集群资源及资源约束

前面提到，如果没有资源组或资源约束的话，存在三个资源可能会运行在不同节点，或者它们的启动、停止顺序不明确等问题，下面通过配置资源约束来解决。

5-1、认识资源约束

资源约束在《高可用集群》有说明，如下：

A、资源粘性：资源对节点倾向程度，资源是否倾向于当前节点。score，正值倾向于当前节点（还要和位置约束结合）。

B、资源约束（Constraint）：资源和资源之间的关系

a、排列约束（colocation）：资源间的依赖/互斥性，定义资源是否运行在同一节点上。score，正值表示要运行在同一节点上，负值则不可。

b、位置约束（location）：每个节点都有一个score值，正值则倾向于本节点，负值倾向于其他节点，所有节点score比较，倾向于最大值的节点。

c、顺序约束（order）：定义资源执行动作的次序，例如vip应先配置，httpd服务后配置。特殊的score值，-inf 负无穷，inf 正无穷。

也就是说资源粘性定义资源对资源当前所在节点的倾向性，而位置约束定义资源对集群中所有节点的倾向性。如webvip的资源粘性为100，位置约束对node1为200，当webvip在node2上时，node1上线资源会转移到node1，因为当前节点node2粘性100小于对node1的位置约束200；如webvip的资源粘性为200，位置约束对node1为100，当webvip在node2上时，node1上线资源不会转移到node1，继续留在node2上，因为当前节点node2粘性200大于对node1的位置约束100。

5-2、恢复三个单独资源状态

先让两个节点都上线，再停止运行中的资源组，并清理状态，然后再删除资源组，这样VIP、NFS存储和httpd就恢复为了三个单独资源状态，过程如下：

crm(live)# resource

crm(live)resource# stop group_webservice

crm(live)resource# cleanup group_webservice

crm(live)resource# cd ..

crm(live)# configure

crm(live)configure# delete group_webservice

crm(live)configure# commit

5-3、配置排列（协同）约束

httpd服务依赖于nfs共享存储，而nfs共享存储依赖于VIP配置，配置好后show xml可以查看具体的CIB信息，配置如下：

crm(live)# configure

crm(live)configure# colocation nfs-with-vip inf: nfs webvip

crm(live)configure# colocation httpd-with-nfs inf: httpd nfs

crm(live)configure# show xml

5-4、配置顺序约束

httpd服务在启动nfs共享存储后启动，而nfs共享存储在VIP之后配置，配置如下：

crm(live)configure# order httpd-after-nfs mandatory: nfs httpd

crm(live)configure# order nfs-after-vip mandatory: webvip nfs

crm(live)configure# verify