Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

9.2. Multistate Resources: Resources That Have Multiple Modes

Multistate resources are a specialization of Clone resources. They allow the instances to be in one of two operating modes; these are called Master and Slave. The names of the modes do not have specific meanings, except for the limitation that when an instance is started, it must come up in the Slave state.
You can create a resource as a master/slave clone with the following single command.
pcs resource create resource_id standard:provider:type|type [resource options] master [master_options]
The name of the master/slave clone will be resource_id-master.

Note

For Red Hat Enterprise Linux release 7.3 and earlier, use the following format to create a master/slave clone.
pcs resource create resource_id standard:provider:type|type [resource options] --master [meta master_options]
Alternately, you can create a master/slave resource from a previously-created resource or resource group with the following command: When you use this command, you can specify a name for the master/slave clone. If you do not specify a name, the name of the master/slave clone will be resource_id-master or group_name-master.
pcs resource master master/slave_name resource_id|group_name [master_options]
For information on resource options, see Section 6.1, “Resource Creation”.
Table 9.2, “Properties of a Multistate Resource” describes the options you can specify for a multistate resource.

Table 9.2. Properties of a Multistate Resource

FieldDescription
id
Your name for the multistate resource
priority, target-role, is-managed
clone-max, clone-node-max, notify, globally-unique, ordered, interleave
master-max
How many copies of the resource can be promoted to master status; default 1.
master-node-max
How many copies of the resource can be promoted to master status on a single node; default 1.

9.2.1. Monitoring Multi-State Resources

To add a monitoring operation for the master resource only, you can add an additional monitor operation to the resource. Note, however, that every monitor operation on a resource must have a different interval.
The following example configures a monitor operation with an interval of 11 seconds on the master resource for ms_resource. This monitor operation is in addition to the default monitor operation with the default monitor interval of 10 seconds.
# pcs resource op add ms_resource interval=11s role=Master

9.2.2. Multistate Constraints

In most cases, a multistate resources will have a single copy on each active cluster node. If this is not the case, you can indicate which nodes the cluster should preferentially assign copies to with resource location constraints. These constraints are written no differently than those for regular resources.
For information on resource location constraints, see Section 7.1, “Location Constraints”.
You can create a colocation constraint which specifies whether the resources are master or slave resources. The following command creates a resource colocation constraint.
pcs constraint colocation add [master|slave] source_resource with [master|slave] target_resource [score] [options]
For information on colocation constraints, see Section 7.3, “Colocation of Resources”.
When configuring an ordering constraint that includes multistate resources, one of the actions that you can specify for the resources is promote, indicating that the resource be promoted from slave to master. Additionally, you can specify an action of demote, indicated that the resource be demoted from master to slave.
The command for configuring an order constraint is as follows.
pcs constraint order [action] resource_id then [action] resource_id [options]
For information on resource order constraints, see Section 7.2, “Order Constraints”.

9.2.3. Multistate Stickiness

To achieve a stable allocation pattern, multistate resources are slightly sticky by default. If no value for resource-stickiness is provided, the multistate resource will use a value of 1. Being a small value, it causes minimal disturbance to the score calculations of other resources but is enough to prevent Pacemaker from needlessly moving copies around the cluster.