On Fri, 2017-11-24 at 11:32 +0000, Alan Birtles wrote: > Is it possible to setup pacemaker with a resource which will only run > on the same machine as another resource but that will not trigger a > failover of the second resource if the first resource becomes > unrunnable? > e.g. > I have 2 resources A and B. Resource A is the main resource and B is > some monitoring resource which should only be run on the same machine > as A but if B fails to run on a machine it shouldn't trigger a > movement of A to another machine. If A fails on a machine it should > move to another machine and then B should also move to that machine. > I've tried setting a low score on the colocation constraint which > does stop A from moving when B fails but this then allows B to start > on a machine which isn't running A.
Pacemaker will place A on a node first, but it will take B's preferences into account due to the colocation. If B becomes unrunnable, its resulting aversion to the current node can cause A to move. There's no direct way to say what you want, but I can think of a few ways to make it happen: * If you set A's stickiness to INFINITY, that should override any preference from B. I'd set A's priority meta-attribute higher than B's as well. * If you set on-fail=stop for B's monitor, the cluster will stop B rather than try to restart and/or move it if it fails. * The ocf:pacemaker:attribute agent, which sets an arbitrary node attribute to a particular value depending on whether it is started or stopped, was added for cases like this. You can create a group of A plus the attribute, then create a location constraint with a rule allowing B to run only where the attribute is set as started. This way, A is unaware of the relationship and ignores B's preferences. -- Ken Gaillot <kgail...@redhat.com> _______________________________________________ Users mailing list: Users@clusterlabs.org http://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