[ClusterLabs] Moving resources and implicit bans - please explain?

[Ken Gaillot]

On 03/16/2016 02:38 PM, Matthew Mucker wrote:
> I have set up my first three-node Pacemaker cluster and was doing some testing by using "crm resource move" commands. I found that once I moved a resource off a particular node, it would not come back up on that node. I spent a while troubleshooting and eventually gave up and rebuilt the node.
> 
> After rebuild, the same thing happened. I then found in the documentation for the crm_resource command under the move command "NOTE: This may prevent the resource from running on the previous location node until the implicit constraints expire or are removed with −−unban"
> 
> This is a regrettably vague note. What dictates the conditions for "may prevent?" How do I determine what implicit constraints are present on my resources and when they'll expire?
> 
> I did find that explicitly removing bans with crm_resource -U solved my problem. However, I'd like to understand this further. Any explanation would be appreciated. A Google search on "pacemaker move resource ban" didn't find me anything that was obviously authoritative.
> 
> I'd appreciate any expertise the community could share with me!
> 
> Thanks,
> 
> -Matthew

Hi Matthew,

Sorry for that unpleasant detour. It catches a lot of people (at least
once ...).

Pacemaker dynamically chooses what node to run a resource on based on
many factors in the configuration and current state of the cluster. For
example, you can specify utilization values for each resource (RAM, CPU,
whatever) and a placement-strategy to balance them across nodes. You can
configure rules to change cluster behavior based on the time of day. You
can specify location constraints to say a resource prefers to run on or
not to run on a particular node, and colocation constraints to say a
resource prefers to run with another particular resource.

Given that dynamism, there is really no concept of "moving" a resource
in pacemaker. The ideal location is recalculated constantly based on
changing conditions.

To get around that, the various cluster tools emulate "moving" by
creating location constraints -- either a constraint pinning a resource
to a particular destination node, or a constraint banning the resource
from the original node. That forces pacemaker to accept a certain idea
of "best" location.

Those constraints stay in place permanently until you explicitly remove
them. Only you know why the resource needed to be moved, so only you
will know when it's safe to let it float again. The various tools all
offer an option to do this (like crm_resource -U, or pcs resource clear,
etc.).

What happens when you clear the constraints? Pacemaker recalculates the
ideal location without the constraint. Maybe the ideal location is where
it already is, in which case nothing happens, or maybe the ideal
location is now somewhere else, in which case it will move again.
"Stickiness" is a resource option that allows you to tell pacemaker to
give a preference to a resource's current location, to make it less
likely to move.

Hope that saves you some more detours ...