[ClusterLabs] What am I Doing Wrong with Constraints?

[Eric Robinson]

I don't understand why a problem with a resource causes other resources above it in the dependency stack (or on the same level with it) to fail over.

My dependency stack is:

drbd -> filesystem -> floating_ip -> Azure virtual IP
			|
			-> MySQL_instance_1
			-> MySQL_instance_2

Note that the MySQL instances are dependent on the floating IP, but not on each other. However, if one of the MySQL instances has a problem that causes it to go into a FAIL status, the whole cluster fails over. Or if the Azure virtual IP resource has a problem and I need to run a cleanup, the whole cluster fails over. 

Here's what my resources look like...

[root at 001db01b mysql]# pcs status
Cluster name: 001db01ab
Stack: corosync
Current DC: 001db01b (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Mon Aug  6 12:52:44 2018
Last change: Mon Aug  6 12:18:38 2018 by root via cibadmin on 001db01a

2 nodes configured
11 resources configured

Online: [ 001db01a 001db01b ]

Full list of resources:

 p_vip_clust01  (ocf::heartbeat:IPaddr2):       Started 001db01b
 p_azip_clust01 (ocf::heartbeat:AZaddr2):       Started 001db01b
 Master/Slave Set: ms_drbd0 [p_drbd0]
     Masters: [ 001db01b ]
     Slaves: [ 001db01a ]
 Master/Slave Set: ms_drbd1 [p_drbd1]
     Masters: [ 001db01a ]
     Slaves: [ 001db01b ]
 p_fs_clust01   (ocf::heartbeat:Filesystem):    Started 001db01b
 p_fs_clust02   (ocf::heartbeat:Filesystem):    Started 001db01a
 p_vip_clust02  (ocf::heartbeat:IPaddr2):       Started 001db01a
 p_azip_clust02 (ocf::heartbeat:AZaddr2):       Started 001db01a
 p_mysql_001    (lsb:mysql_001):        Started 001db01b

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled

Here's what my constraints look like...

[root at 001db01b mysql]# pcs constraint --full
Location Constraints:
Ordering Constraints:
  promote ms_drbd0 then start p_fs_clust01 (kind:Mandatory) (id:order-ms_drbd0-p_fs_clust01-mandatory)
  promote ms_drbd1 then start p_fs_clust02 (kind:Mandatory) (id:order-ms_drbd1-p_fs_clust02-mandatory)
  start p_fs_clust01 then start p_vip_clust01 (kind:Mandatory) (id:order-p_fs_clust01-p_vip_clust01-mandatory)
  start p_vip_clust01 then start p_azip_clust01 (kind:Mandatory) (id:order-p_vip_clust01-p_azip_clust01-mandatory)
  start p_fs_clust02 then start p_vip_clust02 (kind:Mandatory) (id:order-p_fs_clust02-p_vip_clust02-mandatory)
  start p_vip_clust02 then start p_azip_clust02 (kind:Mandatory) (id:order-p_vip_clust02-p_azip_clust02-mandatory)
  start p_vip_clust01 then start p_mysql_001 (kind:Mandatory) (id:order-p_vip_clust01-p_mysql_001-mandatory)
Colocation Constraints:
  p_azip_clust01 with p_vip_clust01 (score:INFINITY) (id:colocation-p_azip_clust01-p_vip_clust01-INFINITY)
  p_fs_clust01 with ms_drbd0 (score:INFINITY) (with-rsc-role:Master) (id:colocation-p_fs_clust01-ms_drbd0-INFINITY)
  p_fs_clust02 with ms_drbd1 (score:INFINITY) (with-rsc-role:Master) (id:colocation-p_fs_clust02-ms_drbd1-INFINITY)
  p_vip_clust01 with p_fs_clust01 (score:INFINITY) (id:colocation-p_vip_clust01-p_fs_clust01-INFINITY)
  p_vip_clust02 with p_fs_clust02 (score:INFINITY) (id:colocation-p_vip_clust02-p_fs_clust02-INFINITY)
  p_azip_clust02 with p_vip_clust02 (score:INFINITY) (id:colocation-p_azip_clust02-p_vip_clust02-INFINITY)
  p_mysql_001 with p_vip_clust01 (score:INFINITY) (id:colocation-p_mysql_001-p_vip_clust01-INFINITY)
Ticket Constraints: