关于Pacemaker集群配置的版本

关于Pacemaker集群配置的版本

Pacemaker中CIB有一个由admin_epoch, epoch, num_updates组合而成的版本，当有节点加入集群时，根据版本号的大小，取其中版本最大的作为整个集群的统一配置。

admin_epoch, epoch, num_updates这3者中，admin_epoch通常是不会变的，epoch在每次"配置"变更时累加并把num_updates置0，num_updates在每次"状态"变更时累加。"配置"指持久的CIB中configuration节点下的内容，包括cluster属性，node的forever属性，资源属性等。"状态"指node的reboot属性，node死活，资源是否启动等动态的东西。

"状态"通常是可以通过monitor重新获取的（除非RA脚本设计的有问题），但"配置"出错可能会导致集群的故障，所以我们更需要关心epoch的变更以及节点加入后对集群配置的影响。尤其一些支持主从架构的RA脚本会动态修改配置(比如mysql的mysql_REPL_INFO
和pgsql的pgsql-data-status)，一旦配置处于不一致状态可能会导致集群故障。

1. 手册说明

http://clusterlabs.org/doc/en-US/Pacemaker/1.1-plugin/html-single/Pacemaker_Explained/index.html#idm140225199219024

3.2.Configuration Version When a node joins the cluster, the cluster will perform a check to see who has the best configuration based on the fields below. It then asks the node with the highest (admin_epoch,epoch,num_updates) tuple to replace the configuration on all the nodes - which makes setting them, and setting them correctly, very important.

Table3.1.Configuration Version Properties

Field	Description
admin_epoch	Never modified by the cluster. Use this to make the configurations on any inactive nodes obsolete.Never set this value to zero, in such cases the cluster cannot tell the difference between your configuration and the "empty" one used when nothing is found on disk.
epoch	Incremented every time the configuration is updated (usually by the admin)
num_updates	Incremented every time the configuration or status is updated (usually by the cluster)

2.实际验证

2.1 环境

3台机器，srdsdevapp69，srdsdevapp71和srdsdevapp73
OS: CentOS 6.3
Pacemaker: 1.1.14-1.el6 (Build: 70404b0)
Corosync: 1.4.1-7.el6

2.2 基本验证

0. 初始时epoch="48304"，num_updates="4"

1. [root@srdsdevapp69 mysql_ha]# cibadmin -Q |grep epoch
   

1. 更新集群配置导致epoch加1并将num_updates清0

1. [root@srdsdevapp69 mysql_ha]# crm_attribute --type crm_config -s set1 --name foo1 -v "1"
   
2. [root@srdsdevapp69 mysql_ha]# cibadmin -Q |grep epoch
   

2. 更新值如果和现有值相同epoch不变

1. [root@srdsdevapp69 mysql_ha]# crm_attribute --type crm_config -s set1 --name foo1 -v "1"
   
2. [root@srdsdevapp69 mysql_ha]# cibadmin -Q |grep epoch
   

3. 更新生命周期为forever的节点属性也导致epoch加1

1. [root@srdsdevapp69 mysql_ha]# crm_attribute -N `hostname` -l forever -n foo2 -v 2
   
2. [root@srdsdevapp69 mysql_ha]# cibadmin -Q |grep epoch
   

4. 更新生命周期为reboot的节点属性导致num_updates加1

1. [root@srdsdevapp69 mysql_ha]# crm_attribute -N `hostname` -l reboot -n foo3 -v 2
   
2. [root@srdsdevapp69 mysql_ha]# cibadmin -Q |grep epoch
   

2.3 分区验证

1. 人为造成srdsdevapp69和其它两个节点的网络隔离形成分区,分区前的DC(Designated Controller)为srdsdevapp73

1. [root@srdsdevapp69 mysql_ha]# iptables -A INPUT -j DROP -s srdsdevapp71
   
2. [root@srdsdevapp69 mysql_ha]# iptables -A OUTPUT -j DROP -s srdsdevapp71
   
3. [root@srdsdevapp69 mysql_ha]# iptables -A INPUT -j DROP -s srdsdevapp73
   
4. [root@srdsdevapp69 mysql_ha]# iptables -A OUTPUT -j DROP -s srdsdevapp73

两个分区上的epoch都没有变，仍是48306,但srdsdevapp69将自己作为了自己分区的DC 。

分区1(srdsdevapp69) : 未取得QUORUM

1. [root@srdsdevapp69 mysql_ha]# cibadmin -Q |grep epoch
   

分区2(srdsdevapp71,srdsdevapp73) : 取得QUORUM

1. [root@srdsdevapp71 ~]# cibadmin -Q |grep epoch
   

2. 在srdsdevapp69上做2次配置更新，使其epoch增加2