Red Hat SummitChapter 18. Creating cluster resources that are active on multiple nodes (cloned resources)
You can clone a cluster resource so that the resource can be active on multiple nodes. For example, you can use cloned resources to configure multiple instances of an IP resource to distribute throughout a cluster for node balancing. You can clone any resource provided the resource agent supports it. A clone consists of one resource or one resource group.
Only resources that can be active on multiple nodes at the same time are suitable for cloning. For example, a Filesystem resource mounting a non-clustered file system such as ext4 from a shared memory device should not be cloned. Since the ext4 partition is not cluster aware, this file system is not suitable for read/write operations occurring from multiple nodes at the same time.
18.1. Creating and removing a cloned resource
You can create a resource and a clone of that resource at the same time. Create a resource and clone of the resource with the following single command.
pcs resource create resource_id [standard:[provider:]]type [resource options] [meta resource meta options] clone [clone_id] [clone options]
pcs resource create resource_id [standard:[provider:]]type [resource options] [meta resource meta options] clone [clone_id] [clone options]You can create a clone of a previously-created resource or resource group with the following command.
pcs resource clone resource_id | group_id [clone_id][clone options]...
pcs resource clone resource_id | group_id [clone_id][clone options]...
By default, the name of the clone will be resource_id-clone. You can set a custom name for the clone by specifying a value for the clone_id option.
You cannot create a resource group and a clone of that resource group in a single command.
When you create a resource or resource group clone that will be ordered after another clone, you should almost always set the interleave=true option. This ensures that copies of the dependent clone can stop or start when the clone it depends on has stopped or started on the same node. If you do not set this option, if a cloned resource B depends on a cloned resource A and a node leaves the cluster, when the node returns to the cluster and resource A starts on that node, then all of the copies of resource B on all of the nodes will restart. This is because when a dependent cloned resource does not have the interleave option set, all instances of that resource depend on any running instance of the resource it depends on.
Use the following command to remove a clone of a resource or a resource group. This does not remove the resource or resource group itself.
pcs resource unclone resource_id | clone_id | group_name
pcs resource unclone resource_id | clone_id | group_nameResource Clone Options
The following table describes the options you can specify for a cloned resource.
| Field | Description |
|---|---|
|
| Options inherited from resource that is being cloned, as described in the "Resource Meta Options" table in Configuring resource meta options. |
|
| How many copies of the resource to start. Defaults to the number of nodes in the cluster. |
|
|
How many copies of the resource can be started on a single node; the default value is |
|
|
When stopping or starting a copy of the clone, tell all the other copies beforehand and when the action was successful. Allowed values: |
|
|
Does each copy of the clone perform a different function? Allowed values:
If the value of this option is
If the value of this option is |
|
|
Should the copies be started in series (instead of in parallel). Allowed values: |
|
|
Changes the behavior of ordering constraints (between clones) so that copies of the first clone can start or stop as soon as the copy on the same node of the second clone has started or stopped (rather than waiting until every instance of the second clone has started or stopped). Allowed values: |
|
|
If a value is specified, any clones which are ordered after this clone will not be able to start until the specified number of instances of the original clone are running, even if the |
To achieve a stable allocation pattern, clones are slightly sticky by default, which indicates that they have a slight preference for staying on the node where they are running. If no value for resource-stickiness is provided, the clone 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. For information about setting the resource-stickiness resource meta-option, see Configuring resource meta options.
Procedure
The following procedure creates and removes a resource clone.
On one node of the cluster, create the resource clone.
When you create a clone of a resource, by default the clone takes on the name of the resource with
-cloneappended to the name. The following command creates a resource of typeapachenamedwebfarmand a clone of that resource namedwebfarm-clone.pcs resource create webfarm apache clone
# pcs resource create webfarm apache cloneCopy to Clipboard Copied! Remove the clone of a resource or a resource group. This does not remove the resource or resource group itself.
pcs resource unclone webfarm
# pcs resource unclone webfarmCopy to Clipboard Copied!
18.2. Configuring clone resource constraints
You can determine the behavior of a clone resource in a cluster by configuring constraints for that resourse. These constraints are written no differently than those for regular resources except that you must specify the clone’s ID. For information about resource constraints, see Configuring cluster resources.
Clone resource location constraints
In most cases, a clone will have a single copy on each active cluster node. You can, however, set clone-max for the resource clone to a value that is less than the total number of nodes in the cluster. If this is the case, you can indicate which nodes the cluster should preferentially assign copies to with resource location constraints. For general information about location constraints, see Determining which node a resource can run on.
The following command creates a location constraint for the cluster to preferentially assign resource clone webfarm-clone to node1.
pcs constraint location webfarm-clone prefers node1
# pcs constraint location webfarm-clone prefers node1Clone resource ordering constraints
Ordering constraints behave slightly differently for clones. In the example below, because the interleave clone option is left to default as false, no instance of webfarm-stats will start until all instances of webfarm-clone that need to be started have done so. Only if no copies of webfarm-clone can be started then webfarm-stats will be prevented from being active. Additionally, webfarm-clone will wait for webfarm-stats to be stopped before stopping itself.
pcs constraint order start webfarm-clone then webfarm-stats
# pcs constraint order start webfarm-clone then webfarm-statsFor general information about resource ordering constraints, see Determining the order in which cluster resources are run.
Clone resource colocation constraints
Colocation of a regular (or group) resource with a clone means that the resource can run on any machine with an active copy of the clone. The cluster will choose a copy based on where the clone is running and the resource’s own location preferences. For information about colocation constraints, see xref colocating-cluster-resources[Colocating cluster resources].
Colocation between clones is also possible. In such cases, the set of allowed locations for the clone is limited to nodes on which the clone is (or will be) active. Allocation is then performed as normally.
The following command creates a colocation constraint to ensure that the resource webfarm-stats runs on the same node as an active copy of webfarm-clone.
pcs constraint colocation add webfarm-stats with webfarm-clone
# pcs constraint colocation add webfarm-stats with webfarm-clone18.3. Promotable clone resources
Promotable clone resources are clone resources with the promotable meta attribute set to true. They allow the instances to be in one of two operating modes; these are called promoted and unpromoted. 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 Unpromoted state.
The Promoted and Unpromoted role names are the functional equivalent of the Master and Slave Pacemaker roles in previous RHEL releases.
18.3.1. Creating a promotable clone resource
You can create a resource as a promotable clone with the following single command.
pcs resource create resource_id [standard:[provider:]]type [resource options] promotable [clone_id] [clone options]
pcs resource create resource_id [standard:[provider:]]type [resource options] promotable [clone_id] [clone options]
By default, the name of the promotable clone is resource_id-clone. You can set a custom name for the clone by specifying a value for the clone_id option.
Alternately, you can create a promotable resource from a previously-created resource or resource group with the following command.
pcs resource promotable resource_id [clone_id] [clone options]
pcs resource promotable resource_id [clone_id] [clone options]
By default, the name of the promotable clone is resource_id-clone or group_name-clone. You can set a custom name for the clone by specifying a value for the clone_id option.
The following table describes the extra clone options you can specify for a promotable resource.
| Field | Description |
|---|---|
|
| How many copies of the resource can be promoted; default 1. |
|
| How many copies of the resource can be promoted on a single node; default 1. |
18.3.2. Configuring promotable resource constraints
You can determine the behavior of a promotable resource in a cluster by configuring constraints for that resource. For general information about resource constraints, see Configuring cluster resources.
Promotable resource location constraints
In most cases, a promotable resource 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 about location constraints, see Determining which node a resource can run on.
Promotable resource colocation constraints
You can create a colocation constraint which specifies whether the resources are operating in a promoted or unpromoted role. The following command creates a resource colocation constraint.
pcs constraint colocation add [promoted|unpromoted] source_resource with [promoted|unpromoted] target_resource [score] [options]
pcs constraint colocation add [promoted|unpromoted] source_resource with [promoted|unpromoted] target_resource [score] [options]For information about colocation constraints, see Colocating cluster resources.
Promotable resource ordering constraints
When configuring an ordering constraint that includes promotable resources, one of the actions that you can specify for the resources is promote, indicating that the resource be promoted from unpromoted role to promoted role. Additionally, you can specify an action of demote, indicated that the resource be demoted from promoted role to unpromoted role.
The command for configuring an order constraint is as follows.
pcs constraint order [action] resource_id then [action] resource_id [options]
pcs constraint order [action] resource_id then [action] resource_id [options]For information about resource order constraints, see Determining the order in which cluster resources are run.
18.3.3. Demoting a promoted resource on failure
You can configure a promotable resource so that when a promote or monitor action fails for that resource, or the partition in which the resource is running loses quorum, the resource will be demoted but will not be fully stopped. This can prevent the need for manual intervention in situations where fully stopping the resource would require it.
To configure a promotable resource to be demoted when a
promoteaction fails, set theon-failoperation meta option todemote, as in the following example.pcs resource op add my-rsc promote on-fail="demote"
# pcs resource op add my-rsc promote on-fail="demote"Copy to Clipboard Copied! To configure a promotable resource to be demoted when a
monitoraction fails, setintervalto a nonzero value, set theon-failoperation meta option todemote, and setroletoPromoted, as in the following example.pcs resource op add my-rsc monitor interval="10s" on-fail="demote" role="Promoted"
# pcs resource op add my-rsc monitor interval="10s" on-fail="demote" role="Promoted"Copy to Clipboard Copied! -
To configure a cluster so that when a cluster partition loses quorum any promoted resources will be demoted but left running and all other resources will be stopped, set the
no-quorum-policycluster property todemote
Setting the on-fail meta-attribute to demote for an operation does not affect how promotion of a resource is determined. If the affected node still has the highest promotion score, it will be selected to be promoted again.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}