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.
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=Master9.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.
