There are primarily two occasions when you would want to move a resource from its current location: when the whole node is under maintenance, and when a single resource needs to be moved.
Since everything eventually comes down to a score, you could create constraints for every resource to prevent them from running on one node. While pacemaker configuration can seem convoluted at times, not even we would require this of administrators.
Instead, one can set a special node attribute which tells the cluster "don’t let anything run here". There is even a helpful tool to help query and set it, called crm_standby. To check the standby status of the current machine, run:
# crm_standby -G
A value of on indicates that the node is not able to host any resources, while a value of off says that it can.
You can also check the status of other nodes in the cluster by specifying the --node option:
# crm_standby -G --node sles-2
To change the current node’s standby status, use -v instead of -G:
# crm_standby -v on
Again, you can change another host’s value by supplying a hostname with --node.
A cluster node in standby mode will not run resources, but still contributes to quorum, and may fence or be fenced by nodes.
9.3.1.2. Moving One Resource
When only one resource is required to move, we could do this by creating location constraints. However, once again we provide a user-friendly shortcut as part of the crm_resource command, which creates and modifies the extra constraints for you. If Email were running on sles-1 and you wanted it moved to a specific location, the command would look something like:
# crm_resource -M -r Email -H sles-2
Behind the scenes, the tool will create the following location constraint:
<rsc_location rsc="Email" node="sles-2" score="INFINITY"/>
It is important to note that subsequent invocations of crm_resource -M are not cumulative. So, if you ran these commands
# crm_resource -M -r Email -H sles-2
# crm_resource -M -r Email -H sles-3
then it is as if you had never performed the first command.
To allow the resource to move back again, use:
# crm_resource -U -r Email
Note the use of the word allow. The resource can move back to its original location but, depending on resource-stickiness, it might stay where it is. To be absolutely certain that it moves back to sles-1, move it there before issuing the call to crm_resource -U:
# crm_resource -M -r Email -H sles-1
# crm_resource -U -r Email
Alternatively, if you only care that the resource should be moved from its current location, try:
# crm_resource -B -r Email
Which will instead create a negative constraint, like
<rsc_location rsc="Email" node="sles-1" score="-INFINITY"/>
This will achieve the desired effect, but will also have long-term consequences. As the tool will warn you, the creation of a -INFINITY constraint will prevent the resource from running on that node until crm_resource -U is used. This includes the situation where every other cluster node is no longer available!
In some cases, such as when
resource-stickiness is set to
INFINITY, it is possible that you will end up with the problem described in
Section 5.2.4, “What if Two Nodes Have the Same Score”. The tool can detect some of these cases and deals with them by creating both positive and negative constraints. E.g.
Email prefers sles-1 with a score of -INFINITY
Email prefers sles-2 with a score of INFINITY
which has the same long-term consequences as discussed earlier.
