pacemaker配置一个三节点主备集群并配置vip资源

接着上一章来讲，http://blog.csdn.net/minxihou/article/details/72862715
本章中会讲述一些集群简单配置命令，法定人数概念，配置一个VIP服务并且如何防止资源在节点恢复后移动。

接着搭建继续来写在搭建完pacemaker之后如果不在里面配置任何服务其实这个东西是完全没有什么用的。那么我们从最简单的一个配置来说起，那就是配置VIP。我们通过配置一个VIP，下连三台服务器来对这个IP提供服务，这个在网站的基础架构中是非常重要的。在网站中为了解决单点故障一般在一个公网ip中下连至少有两台http服务器来防止单点故障。这样做的好处显而易见就是为了保障服务的可用性。那么设置VIP就是其中要做的第一步。

架构图如下：

这里依旧沿用了我们上篇文章中搭建好的pacemaker服务集群。这里我打算将这三个节点都启用，两个节点作为standby一个节点作为active，当active节点发生单点故障时，剩下两个节点则会接管该服务保证服务不受中断。

Part1.浏览现有集群配置

当pacemaker启动的时候，他会自动记录节点的数量和详细信息，以及基层软件和Pacemaker的版本。
最初始配置文件的模样：

[root@node-1 ~]# crm
crm(live)# configure
crm(live)configure# show
node 1: node-1
node 2: node-2
node 3: node-3
property cib-bootstrap-options: \
    have-watchdog=false \
    dc-version=1.1.15-11.el7_3.4-e174ec8 \
    cluster-infrastructure=corosync \
    cluster-name=my_cluste

如果想看xml格式，可以添加xml选项来看到原始的配置文件。

在我们做出任何改变之前，最好检查配置文件。

[root@node-1 ~]# crm_verify -L
Errors found during check: config not valid
  -V may provide more details
[root@node-1 ~]# crm_verify -L -V
   error: unpack_resources:    Resource start-up disabled since no STONITH resources have been defined
   error: unpack_resources:    Either configure some or disable STONITH with the stonith-enabled option
   error: unpack_resources:    NOTE: Clusters with shared data need STONITH to ensure data integrity
Errors found during check: config not valid

为了确保数据的安全性，请使用配置STONITH的pacemaker。但是当没有配置STONITH的时候也会报这个错误（因为当集群中某个节点需要被隔离的时候，集群就无法工作了）。目前实验环境下我们禁用这个特性，然后在配置STONISH章节再来配置。这里要指出，使用STONITH是非常有必要的。关闭这个特性就是告诉集群：假装故障的节点已经安全的关机了。一些供应商甚至不允许这个特性被关闭。

关闭STONITH的特性命令如下：

#crm configure property stonith-enabled=false
#crm_verify -L

这里给出pcs命令的参考：
禁用STONITH：

pcs property set stonith-enabled=false

无法仲裁的时候，选择忽略：

pcs property set no-quorum-policy=ignore

Part2.添加资源

首先要做的是配置一个IP地址，不管集群服务在哪运行，我们要一个固定的地址来提供服务。在这里我们选择一个IP作为浮动IP（10.100.109.157，这个IP根据你实际情况来决定），给它取一个好记的名字ClusterIP并且告诉集群每30秒检查一次。

note：
所选择的IP地址不能被节点所占用
这里我们使用的是ocf标准资源heartbeat下的IPaddr2。

[root@node-1 ~]# crm
crm(live)# configure
crm(live)configure# primitive ClusterIP ocf:heartbeat:IPaddr2\
   > params ip=10.100.109.151 cider_netmask=32 \
   > op monitor interval=30s

直接添加的话会报错如下：

ERROR: ClusterIP: parameter cider_netmask does not exist
Do you still want to commit (y/n)? n

这个时候去找到相应的脚本查看这个cider_netmask参数。

我们可以看到注视中给出了参数，但是在初始化的时候没有使用，这里需要在初始化的时候使用：

然后在编辑资源的时候通过检查不会报错。定义这个资源时这样几个重要信息，第一个是ocf:heartbeat:IPaddr2。这告诉Pacemaker三件事情，第一个部分，ocf，指明了这个资源采用的标准（类型）以及在哪能找到它。第二个部分表明这个资源脚本在OCF中的名字空间，在这个例子中是hearbeat。最后一个部分指明了资源脚本的名称。

可以运行下面的命令来获得可用的资源类

# crm ra classes
[root@node-1 ~]# crm ra classes
lsb
ocf / .isolation heartbeat openstack pacemaker
service
stonith
systemd

找到OCF中Pacemaker和Heartbeat提供的资源脚本，运行下面的命令。

如果直接在linux的shell界面的话你需要直接执行如下命令，不过pacemaker提供了crm的命令工具，笔者觉的键入crm之后在做操作这样会好一些。

#crm ra list ocf heartbeat

现在检查下IP资源是不是已经添加了，并且看看是否处在可用状态：

#crm_mon

查看当前集群的配置情况：

#crm configure show

part3.做一次失效备援

作为一个高可用的集群，我们在继续之后的配置操作之前首先先要测试一下我们当前配置的资源是否正常被集群纳管可用。简单的来说我们希望看到在主节点离线的情况下我们的VIP仍然可以访问。首先，找到IP资源现在在那个节点上运行。

#crm resource status ClusterIP

关闭那个节点上面的Corosync服务

# systemctl stop corosync

当corosync停止运行以后，我们到另外一个节点用crm_mon来检查集群状态：

part4.防止资源在节点恢复后移动

一些环境中会要求尽量避免资源在节点之间移动。移动资源通常一位置一段时间内无法提供服务，某些负载的服务，比如Oracle数据库，这个时间可能会很长。为了达到这个效果，pacemaker有一个叫做资源粘性值的概念，它能够控制一个服务（资源）有多想待在它正在运行的节点上。你可以把它认为是无法提供服务的“代价”。pacemaker为了达到最优分部各个资源的目的，默认设置这个值为0.我们可以为每个资源定义不同的粘性值，但一般来说更改默认粘性值就够了。

设置粘性值：crm configure rsc_defaults resource-stickiness=100

[root@node-1 ~]# crm configure show
node 1: node-1
node 2: node-2
node 3: node-3
primitive ClusterIP IPaddr2 \
    params ip=10.100.109.151 cidr_netmask=32 \
    op monitor interval=30s
location cli-prefer-ClusterIP ClusterIP role=Started inf: node-3
property cib-bootstrap-options: \
    have-watchdog=false \
    dc-version=1.1.15-11.el7_3.4-e174ec8 \
    cluster-infrastructure=corosync \
    cluster-name=my_cluster \
    stonith-enabled=false \
    no-quorum-policy=ignore
rsc_defaults rsc-options: \
    resource-stickiness=100

做个实验，现在资源在node-3上，通过停止node-3的pacemaker服务，然后在启动来查看变动情况：

停掉node-3上的pacemaker服务：

重新开启node-3上的服务：

启停corosync服务：
在node-3上停掉服务

在node-3上开启服务发现资源没有切换：

这里就可以说明corosync是心跳层服务。如果corosync集群会认为该节点不可达而立马将节点置成offline状态。

part5.法定人数和双节点集群

这是因为集群已经达不到“法定人数”了，就像我们看到的“partition WITHOUT quorum”。为了避免数据遭到破坏，当pacemaker发现集群达不到法定人数时，就会停止所有的资源。当有半数以上的节点在线时，这个集群就认为自己拥有法定人数了，是“合法”的，换而言之就是下面的公式：
总结点数-1<2*可用节点数

因此在双节点的集群中，只有当两者都在线时才是合法的。这个规则会让双节点的集群毫无意义，但是我们可以控制pacemaker发现集群达不到法定人数时候的行为。简单来说，我们告诉集群忽略它。

配置如下：

#crm configure property no-quorum-policy=ignore
#crm configure show
 crm(live)configure# show
node 1: node-1
node 2: node-2
node 3: node-3
primitive ClusterIP IPaddr2 \
    params ip=10.100.109.151 cidr_netmask=32 \
    op monitor interval=30s
location cli-prefer-ClusterIP ClusterIP role=Started inf: node-3
property cib-bootstrap-options: \
    have-watchdog=false \
    dc-version=1.1.15-11.el7_3.4-e174ec8 \
    cluster-infrastructure=corosync \
    cluster-name=my_cluster \
    stonith-enabled=false \
    no-quorum-policy=ignore

这样可以让双节点的HA集群在服务故障的时候能够顺利的把资源切换到其他的节点上。
当我们再三节点的环境中停掉了两个节点的corosync，在停掉corosync的时候pacemaker也会对应停止，应为我们是通过corosync来启动pacemaker的。当忽略了法定人数的行为后还是保证了服务正常。