What to do when the cluster does not have quorum

What to do when the cluster does not have quorum Allowed values: stop, freeze, ignore, demote, suicide

Whether resources can run on any node by default

Whether the cluster should refrain from monitoring, starting, and stopping resources

Whether a start failure should prevent a resource from being recovered on the same node

When true, the cluster will immediately ban a resource from a node if it fails to start there. When false, the cluster will instead check the resource's fail count against its migration-threshold.

Whether the cluster should check for active resources during start-up

Whether to lock resources to a cleanly shut down node

When true, resources active on a node when it is cleanly shut down are kept "locked" to that node (not allowed to run elsewhere) until they start again on that node after it rejoins (or for at most shutdown-lock-limit, if set). Stonith resources and Pacemaker Remote connections are never locked. Clone and bundle instances and the master role of promotable clones are currently never locked, though support could be added in a future release.

Do not lock resources to a cleanly shut down node longer than this

If shutdown-lock is true and this is set to a nonzero time duration, shutdown locks will expire after this much time has passed since the shutdown was initiated, even if the node has not rejoined.

*** Advanced Use Only *** Whether nodes may be fenced as part of recovery

If false, unresponsive nodes are immediately assumed to be harmless, and resources that were active on them may be recovered elsewhere. This can result in a "split-brain" situation, potentially leading to data loss and/or service unavailability.

Action to send to fence device when a node needs to be fenced ("poweroff" is a deprecated alias for "off")

Action to send to fence device when a node needs to be fenced ("poweroff" is a deprecated alias for "off") Allowed values: reboot, off, poweroff

*** Advanced Use Only *** Unused by Pacemaker

This value is not used by Pacemaker, but is kept for backward compatibility, and certain legacy fence agents might use it.

Whether watchdog integration is enabled

This is set automatically by the cluster according to whether SBD is detected to be in use. User-configured values are ignored. The value `true` is meaningful if diskless SBD is used and `stonith-watchdog-timeout` is nonzero. In that case, if fencing is required, watchdog-based self-fencing will be performed via SBD without requiring a fencing resource explicitly configured.

Allow performing fencing operations in parallel

*** Advanced Use Only *** Whether to fence unseen nodes at start-up

Setting this to false may lead to a "split-brain" situation,potentially leading to data loss and/or service unavailability.

Apply fencing delay targeting the lost nodes with the highest total resource priority

Apply specified delay for the fencings that are targeting the lost nodes with the highest total resource priority in case we don't have the majority of the nodes in our cluster partition, so that the more significant nodes potentially win any fencing match, which is especially meaningful under split-brain of 2-node cluster. A promoted resource instance takes the base priority + 1 on calculation if the base priority is not 0. Any static/random delays that are introduced by `pcmk_delay_base/max` configured for the corresponding fencing resources will be added to this delay. This delay should be significantly greater than, safely twice, the maximum `pcmk_delay_base/max`. By default, priority fencing delay is disabled.

Maximum time for node-to-node communication

The node elected Designated Controller (DC) will consider an action failed if it does not get a response from the node executing the action within this time (after considering the action's own timeout). The "correct" value will depend on the speed and load of your network and cluster nodes.

Maximum number of jobs that the cluster may execute in parallel across all nodes

The "correct" value will depend on the speed and load of your network and cluster nodes. If set to 0, the cluster will impose a dynamically calculated limit when any node has a high load.

The number of live migration actions that the cluster is allowed to execute in parallel on a node (-1 means no limit)

Whether the cluster should stop all active resources

Whether to stop resources that were removed from the configuration

Whether to cancel recurring actions removed from the configuration

*** Advanced Use Only *** Whether to remove stopped resources from the executor

Values other than default are poorly tested and potentially dangerous.

The number of scheduler inputs resulting in errors to save

Zero to disable, -1 to store unlimited.

The number of scheduler inputs resulting in warnings to save

Zero to disable, -1 to store unlimited.

The number of scheduler inputs without errors or warnings to save

Zero to disable, -1 to store unlimited.

How cluster should react to node health attributes

Requires external entities to create node attributes (named with the prefix "#health") with values "red", "yellow" or "green". Allowed values: none, migrate-on-red, only-green, progressive, custom

Base health score assigned to a node

Only used when node-health-strategy is set to progressive.

The score to use for a node health attribute whose value is "green"

Only used when node-health-strategy is set to custom or progressive.

The score to use for a node health attribute whose value is "yellow"

Only used when node-health-strategy is set to custom or progressive.

The score to use for a node health attribute whose value is "red"

Only used when node-health-strategy is set to custom or progressive.

How the cluster should allocate resources to nodes

How the cluster should allocate resources to nodes Allowed values: default, utilization, minimal, balanced

Author.