Chapter 16. Managing cluster resources
This section describes various commands you can use to manage cluster resources.
16.1. Displaying configured resources
To display a list of all configured resources, use the following command.
pcs resource status
For example, if your system is configured with a resource named VirtualIP
and a resource named WebSite
, the pcs resource show
command yields the following output.
# pcs resource status
VirtualIP (ocf::heartbeat:IPaddr2): Started
WebSite (ocf::heartbeat:apache): Started
To display a list of all configured resources and the parameters configured for those resources, use the --full
option of the pcs resource config
command, as in the following example.
# pcs resource config
Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
Attributes: ip=192.168.0.120 cidr_netmask=24
Operations: monitor interval=30s
Resource: WebSite (type=apache class=ocf provider=heartbeat)
Attributes: statusurl=http://localhost/server-status configfile=/etc/httpd/conf/httpd.conf
Operations: monitor interval=1min
To display the configured parameters for a resource, use the following command.
pcs resource config resource_id
For example, the following command displays the currently configured parameters for resource VirtualIP
.
# pcs resource config VirtualIP
Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
Attributes: ip=192.168.0.120 cidr_netmask=24
Operations: monitor interval=30s
16.2. Modifying resource parameters
To modify the parameters of a configured resource, use the following command.
pcs resource update resource_id [resource_options]
The following sequence of commands show the initial values of the configured parameters for resource VirtualIP
, the command to change the value of the ip
parameter, and the values following the update command.
#pcs resource config VirtualIP
Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat) Attributes: ip=192.168.0.120 cidr_netmask=24 Operations: monitor interval=30s #pcs resource update VirtualIP ip=192.169.0.120
#pcs resource config VirtualIP
Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat) Attributes: ip=192.169.0.120 cidr_netmask=24 Operations: monitor interval=30s
When you update a resource’s operation with the pcs resource update
command, any options you do not specifically call out are reset to their default values.
16.3. Clearing failure status of cluster resources
If a resource has failed, a failure message appears when you display the cluster status. If you resolve that resource, you can clear that failure status with the pcs resource cleanup
command. This command resets the resource status and failcount
, telling the cluster to forget the operation history of a resource and re-detect its current state.
The following command cleans up the resource specified by resource_id.
pcs resource cleanup resource_id
If you do not specify a resource_id, this command resets the resource status and failcount
for all resources.
The pcs resource cleanup
command probes only the resources that display as a failed action. To probe all resources on all nodes you can enter the following command:
pcs resource refresh
By default, the pcs resource refresh
command probes only the nodes where a resource’s state is known. To probe all resources even if the state is not known, enter the following command:
pcs resource refresh --full
16.4. Moving resources in a cluster
Pacemaker provides a variety of mechanisms for configuring a resource to move from one node to another and to manually move a resource when needed.
You can manually move resources in a cluster with the pcs resource move
and pcs resource relocate
commands, as described in Manually moving cluster resources.
In addition to these commands, you can also control the behavior of cluster resources by enabling, disabling, and banning resources, as described in Enabling, disabling, and banning cluster resources.
You can configure a resource so that it will move to a new node after a defined number of failures, and you can configure a cluster to move resources when external connectivity is lost.
16.4.1. Moving resources due to failure
When you create a resource, you can configure the resource so that it will move to a new node after a defined number of failures by setting the migration-threshold
option for that resource. Once the threshold has been reached, this node will no longer be allowed to run the failed resource until:
-
The administrator manually resets the resource’s
failcount
using thepcs resource cleanup
command. -
The resource’s
failure-timeout
value is reached.
The value of migration-threshold
is set to INFINITY
by default. INFINITY
is defined internally as a very large but finite number. A value of 0 disables the migration-threshold
feature.
Setting a migration-threshold
for a resource is not the same as configuring a resource for migration, in which the resource moves to another location without loss of state.
The following example adds a migration threshold of 10 to the resource named dummy_resource
, which indicates that the resource will move to a new node after 10 failures.
# pcs resource meta dummy_resource migration-threshold=10
You can add a migration threshold to the defaults for the whole cluster with the following command.
# pcs resource defaults migration-threshold=10
To determine the resource’s current failure status and limits, use the pcs resource failcount show
command.
There are two exceptions to the migration threshold concept; they occur when a resource either fails to start or fails to stop. If the cluster property start-failure-is-fatal
is set to true
(which is the default), start failures cause the failcount
to be set to INFINITY
and thus always cause the resource to move immediately.
Stop failures are slightly different and crucial. If a resource fails to stop and STONITH is enabled, then the cluster will fence the node in order to be able to start the resource elsewhere. If STONITH is not enabled, then the cluster has no way to continue and will not try to start the resource elsewhere, but will try to stop it again after the failure timeout.
16.4.2. Moving resources due to connectivity changes
Setting up the cluster to move resources when external connectivity is lost is a two step process.
-
Add a
ping
resource to the cluster. Theping
resource uses the system utility of the same name to test if a list of machines (specified by DNS host name or IPv4/IPv6 address) are reachable and uses the results to maintain a node attribute calledpingd
. - Configure a location constraint for the resource that will move the resource to a different node when connectivity is lost.
Table 10.1, “Resource Agent Identifiers” describes the properties you can set for a ping
resource.
Table 16.1. Properties of a ping resources
Field | Description |
---|---|
| The time to wait (dampening) for further changes to occur. This prevents a resource from bouncing around the cluster when cluster nodes notice the loss of connectivity at slightly different times. |
| The number of connected ping nodes gets multiplied by this value to get a score. Useful when there are multiple ping nodes configured. |
| The machines to contact in order to determine the current connectivity status. Allowed values include resolvable DNS host names, IPv4 and IPv6 addresses. The entries in the host list are space separated. |
The following example command creates a ping
resource that verifies connectivity to gateway.example.com
. In practice, you would verify connectivity to your network gateway/router. You configure the ping
resource as a clone so that the resource will run on all cluster nodes.
# pcs resource create ping ocf:pacemaker:ping dampen=5s multiplier=1000 host_list=gateway.example.com clone
The following example configures a location constraint rule for the existing resource named Webserver
. This will cause the Webserver
resource to move to a host that is able to ping gateway.example.com
if the host that it is currently running on cannot ping gateway.example.com
.
# pcs constraint location Webserver rule score=-INFINITY pingd lt 1 or not_defined pingd
Module included in the following assemblies: // // <List assemblies here, each on a new line> // rhel-8-docs/enterprise/assemblies/assembly_managing-cluster-resources.adoc
16.5. Disabling a monitor operation
The easiest way to stop a recurring monitor is to delete it. However, there can be times when you only want to disable it temporarily. In such cases, add enabled="false"
to the operation’s definition. When you want to reinstate the monitoring operation, set enabled="true"
to the operation’s definition.
When you update a resource’s operation with the pcs resource update
command, any options you do not specifically call out are reset to their default values. For example, if you have configured a monitoring operation with a custom timeout value of 600, running the following commands will reset the timeout value to the default value of 20 (or whatever you have set the default value to with the pcs resource ops default
command).
#pcs resource update resourceXZY op monitor enabled=false
#pcs resource update resourceXZY op monitor enabled=true
In order to maintain the original value of 600 for this option, when you reinstate the monitoring operation you must specify that value, as in the following example.
# pcs resource update resourceXZY op monitor timeout=600 enabled=true
16.6. Configuring and managing cluster resource tags (RHEL 8.3 and later)
As of Red Hat Enterprise Linux 8.3, you can use the pcs
command to tag cluster resources. This allows you to enable, disable, manage, or unmanage a specified set of resources with a single command.
16.6.1. Tagging cluster resources for administration by category
The following procedure tags two resources with a resource tag and disables the tagged resources. In this example, the existing resources to be tagged are named d-01
and d-02
.
Create a tag named
special-resources
for resourcesd-01
andd-02
.[root@node-01]#
pcs tag create special-resources d-01 d-02
Display the resource tag configuration.
[root@node-01]#
pcs tag config
special-resources d-01 d-02Disable all resources that are tagged with the
special-resources
tag.[root@node-01]#
pcs resource disable special-resources
Display the status of the resources to confirm that resources
d-01
andd-02
are disabled.[root@node-01]#
pcs resource
* d-01 (ocf::pacemaker:Dummy): Stopped (disabled) * d-02 (ocf::pacemaker:Dummy): Stopped (disabled)
In addition to the pcs resource disable
command, the pcs resource enable
, pcs resource manage
, and pcs resource unmanage
commands support the administration of tagged resources.
After you have created a resource tag:
-
You can delete a resource tag with the
pcs tag delete
command. -
You can modify resource tag configuration for an existing resource tag with the
pcs tag update
command.
16.6.2. Deleting a tagged cluster resource
You cannot delete a tagged cluster resource with the pcs
command. To delete a tagged resource, use the following procedure.
Remove the resource tag.
The following command removes the resource tag
special-resources
from all resources with that tag,[root@node-01]#
pcs tag remove special-resources
[root@node-01]#pcs tag
No tags definedThe following command removes the resource tag
special-resources
from the resourced-01
only.[root@node-01]#
pcs tag update special-resources remove d-01
Delete the resource.
[root@node-01]#
pcs resource delete d-01
Attempting to stop: d-01... Stopped