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? Thanks! Bryan _______________________________________________ Users mailing list: [email protected] https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
