[ClusterLabs] ban node or disable (all) resources upon node addition to the cluster - how?

Ken Gaillot kgaillot at redhat.com
Wed Aug 1 14:09:52 UTC 2018


On Wed, 2018-08-01 at 15:26 +0200, Jan Pokorný wrote:
> Hello,
> 
> On 01/08/18 13:46 +0100, lejeczek wrote:
> > is it possible to tell the cluster to exclude or ban resources to
> > run on a node which I'd like to add the cluster? (as one command?)
> > 
> > (or any other way that would assure that no resources would be
> > moved to that
> > node, in case cluster would decide for some reason that was a good
> > idea)
> 
> With pacemaker 1.1.17+, your best bet is to start pacemakerd on that
> particular node in standby mode, which can be achieved with either:
> 
>   - running pacemakerd with "-s" (--standby) switch
>   
>   - modifying /etc/(default|sysconfig)/pacemaker
>     (or another file like this per conventions in your
>     OS/distribution) so that it effectively declares
>     "PCMK_node_start_state=standby" (i.e. such line
>     must not be commented out)
> 
> Note that the second option is more handy (and likely your only
> choice) when you are using higher-level management tool (crm/pcs).
> 
> Of course, this needs to be done ahead of time at each such node
> to be added.  It may also be wise to comment that line again once
> those nodes are ready to start serving right away with subsequent
> starts incl. upon reboots.

The standby method above is probably easiest.

Another approach is more than one command to set up initially, but then
is zero commands per node added. You can make the cluster asymmetric,
meaning that resources can run only on nodes where they have been
enabled via location constraints. Add location constraints for each
resource on the existing nodes (even a score of 0 is sufficient), then
set symmetric-cluster to false, then add any number of new nodes; to
allow a resource on one of the new nodes, add a location constraint
enabling it.

Another approach would be to set resource-stickiness to INFINITY, so
when you add the node, nothing moves.
-- 
Ken Gaillot <kgaillot at redhat.com>


More information about the Users mailing list