[ClusterLabs] Trying to Understanding crm-fence-peer.sh
Bryan K. Walton
bwalton+1546953805 at leepfrog.com
Wed Jan 16 11:49:21 EST 2019
On Wed, Jan 16, 2019 at 04:53:32PM +0100, Lars Ellenberg wrote:
> To clarify: crm-fence-peer.sh is an *example implementation*
> (even though an elaborate one) of a DRBD fencing policy handler,
> which uses pacemaker location constraints on the Master role
> if DRBD is not sure about the up-to-date-ness of that instance,
> to ban nodes from taking over the Master role.
> It does NOT trigger node level fencing.
> But it has to wait for, and rely on, pacemaker node level fencing.
Thanks Lars. Between these comments, and the man page for drbd.conf, I
think I understand what is going on here. Is it correct to say, that in
the case I provided, that DRBD successfully issued a "drbdadm outdate
res" on the other node, and therefore it didn't need to STONITH the
peer? (Looking at the crm-fence-peer code, I see that exit code 4 is
node fenced, but there is an exit code 7 which means STONITHED. In my
case, I got an exit code 4, and not a 7.)
Also you mentioned that "Other implementations of drbd fencing policy
handlers may directly escalate to node level fencing."
Are these "other implementations" third-party handlers? Or are they
available from within the DRBD software? Can you point to any of these?
More information about the Users