pacemaker-schedulerd - Man Page

Pacemaker scheduler options

Synopsis

[no-quorum-policy=select] [shutdown-lock=boolean] [shutdown-lock-limit=time] [symmetric-cluster=boolean] [maintenance-mode=boolean] [start-failure-is-fatal=boolean] [enable-startup-probes=boolean] [stonith-enabled=boolean] [stonith-action=select] [stonith-timeout=time] [have-watchdog=boolean] [concurrent-fencing=boolean] [startup-fencing=boolean] [priority-fencing-delay=time] [node-pending-timeout=time] [cluster-delay=time] [batch-limit=integer] [migration-limit=integer] [stop-all-resources=boolean] [stop-orphan-resources=boolean] [stop-orphan-actions=boolean] [remove-after-stop=boolean] [pe-error-series-max=integer] [pe-warn-series-max=integer] [pe-input-series-max=integer] [node-health-strategy=select] [node-health-base=integer] [node-health-green=integer] [node-health-yellow=integer] [node-health-red=integer] [placement-strategy=select]

Description

Cluster options used by Pacemaker's scheduler

Supported Parameters

no-quorum-policy = select [stop]

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, fence, suicide

shutdown-lock = boolean [false]

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 promoted role of promotable clones are currently never locked, though support could be added in a future release.

shutdown-lock-limit = time [0]

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.

symmetric-cluster = boolean [true]

Whether resources can run on any node by default

maintenance-mode = boolean [false]

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

start-failure-is-fatal = boolean [true]

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.

enable-startup-probes = boolean [true]

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

stonith-enabled = boolean [true]

*** 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.

stonith-action = select [reboot]

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

stonith-timeout = time [60s]

How long to wait for on, off, and reboot fence actions to complete by default

have-watchdog = boolean [false]

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.

concurrent-fencing = boolean [false]

Allow performing fencing operations in parallel

startup-fencing = boolean [true]

*** 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.

priority-fencing-delay = time [0]

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.

node-pending-timeout = time [0]

How long to wait for a node that has joined the cluster to join the controller process group

Fence nodes that do not join the controller process group within this much time after joining the cluster, to allow the cluster to continue managing resources. A value of 0 means never fence pending nodes. Setting the value to 2h means fence nodes after 2 hours.

cluster-delay = time [60s]

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.

batch-limit = integer [0]

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.

migration-limit = integer [-1]

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

stop-all-resources = boolean [false]

Whether the cluster should stop all active resources

stop-orphan-resources = boolean [true]

Whether to stop resources that were removed from the configuration

stop-orphan-actions = boolean [true]

Whether to cancel recurring actions removed from the configuration

remove-after-stop = boolean [false]

*** Deprecated *** Whether to remove stopped resources from the executor

Values other than default are poorly tested and potentially dangerous.

pe-error-series-max = integer [-1]

The number of scheduler inputs resulting in errors to save

Zero to disable, -1 to store unlimited.

pe-warn-series-max = integer [5000]

The number of scheduler inputs resulting in warnings to save

Zero to disable, -1 to store unlimited.

pe-input-series-max = integer [4000]

The number of scheduler inputs without errors or warnings to save

Zero to disable, -1 to store unlimited.

node-health-strategy = select [none]

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

node-health-base = integer [0]