Azure_ARM fence agent - pcmk_delay_max and priority-fencing-delay

[db6thomas]

To avoid a fence race, it is possible to use above parameters to address this issue. References can be found here:

https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap/high-availability-guide-rhel-pacemaker
https://www.suse.com/support/kb/doc/?id=000019110
https://access.redhat.com/solutions/5110521

The options do not work for the Azure_ARM fence agent 4.7.1 and 4.9.1.
Both gets ignored and fencing race happens.

Is this for purpose or just missing yet?

[oalbrigt]

These parameters depend on which version of pacemaker you're running.

Can you post your output of rpm -qa | grep pacemaker?

[db6thomas]

Hello,

azr-sd01:~ # rpm -qa |grep pacemaker
libpacemaker3-2.0.4+20200616.2deceaa3a-1.2.db2pcmk.x86_64
pacemaker-remote-2.0.4+20200616.2deceaa3a-1.2.db2pcmk.x86_64
pacemaker-cli-2.0.4+20200616.2deceaa3a-1.2.db2pcmk.x86_64
libpacemaker-devel-2.0.4+20200616.2deceaa3a-1.2.db2pcmk.x86_64
pacemaker-cts-2.0.4+20200616.2deceaa3a-1.2.db2pcmk.noarch
pacemaker-2.0.4+20200616.2deceaa3a-1.2.db2pcmk.x86_64

This the Pacemaker, that comes integrated with Db2 - therefore you see db2pcmk.x86_64. In Pacemaker and Corosync, no changes where made beside new packaging.
With the same pacemaker version, we tested on AWS and there the parameters works and fencing race can be avoided.

[oalbrigt]

pcmk_delay_max, pcmk_delay_base, priority-fencing-delay are being executed by pacemaker (fenced) prior to execute the action on the fence-agent while other delay-parameters are passed to the fence-agent.

The reason why fence_azure_arm is behaving differently might be due to code in fence_aws to avoid race conditions:
https://github.com/ClusterLabs/fence-agents/pull/323/files

Maybe you should use pcmk_delay_base instead? That's used for base+random value.

[oalbrigt]

If you have further issues you can try mailing: http://oss.clusterlabs.org/mailman/listinfo/users where users/devs of all the ClusterLabs projects can answer.