Corosync+Pacemaker集群资源被异常删除问题分析及解决

问题现象

在两节点Corosync+Pacemaker集群中，master在node0节点上，当关机node1节点后，给集群中添加某资源（本文中“资源”以xx_mysql为例）且能正常运行。但当node1节点开机加入集群后，先前在node0节点上添加的集群资源却被异常删除，导致相关资源应用无法正常承担业务。
其中，Linux、Pacemaker和Corosync的版本号信息如下：

Linux 3.10.0-693.el7.x86_64、pacemaker-1.1.23-1.el7_9.1.x86_64、corosync-2.4.5-7.el7.x86_64

查看corosync.log日志，关键打印信息如下：

Mar 29 11:57:57 [4875] xx pengine: info: rsc_action_digest_cmp: Parameters to xx_mysql_monitor_0 on node0 changed: was 8b36ac1527c6ce34f76bb21fb642d3cb vs. now f2317cad3d54cec5d7d7aa7d0bf35cf8 (reload:3.0.14) 0:0;8:3:7:c9bb2393-efb3-4248-a9a3-cc175b05e92a
Mar 29 11:57:57 [4875] xx pengine: notice: pe__clear_failcount: Clearing failure of xx_mysql on node0 because resource parameters have changed | xx_mysql_clear_failcount_0
Mar 29 11:57:57 xx pengine[4875]: notice: Clearing failure of xx_mysql on node0 because resource parameters have changed
Mar 29 11:57:57 xx pengine[4875]: warning: Detected active orphan xx_mysql running on node0

问题分析

通过对日志信息和现象的分析，不难发现，当关机的节点node1加入集群后，集群内部会比较各个节点上的cib.xml文件，当发现node0上存在孤立资源xx_mysql时，于是将node0上该孤立资源删除，进而保持各节点上cib.xml文件的一致性。既然知道了原因，但如何解决或者规避该问题呢？
在集群配置中，将停止的孤立资源属性设置为flase，当关机的node1节点加入集群后，发现新添加的xx_mysql资源并不会删除掉，但该资源只能起在node0节点上，此时集群状态如下：

Online: [ node0 node1 ]
Full list of resources:
xx_mysql (ocf::heartbeat:mysql): ORPHANED Started node0 (unmanaged)

显然，这并不是预期结果，因为一旦集群发生切换，这种“ORPHANED Started node0 (unmanaged)”的情况将导致该资源无法在其他节点上起来，也相当于集群切换后发生了资源丢失，得不偿失。
通过进一步的调研分析和测试发现，由于应用系统中配置了Stonith设备（也称为Fence设备）。关机节点刚发生开机和加入集群过程中，应用系统会设置stonith属性更新，该更新发生在刚加入的节点自动同步cib.xml文件之前，与此同时，该更新会触发stonith_device_remove、update_cib_stonith_devices_v2、 cib_devices_update这三个集群事件，用于检查和比较cib.xml文件，然后删除孤立的资源进而导致了该问题现象。

解决方案

1、避免更新stonith属性操作。关机、重启等异常节点刚加入集群过程中避免去更新stonith属性（主要指设置为true或false属性),靠集群内部的cib同步机制自动同步各节点上的cib配置文件，并保持一致性。
2、调整stonith属性更新位置。当关机、重启等异常节点加入集群且已完成cib配置自动同步后，再进行stonith属性更新设置，因为这个时候集群中各个节点上cib配置已自动完成同步且一致。