Disabling fencing during maintenance

The cluster uses STONITH fencing to power off a node that stops responding, which prevents a split-brain condition. If your maintenance takes the node down, either by powering it off or by rebooting it, the surviving node can see the node as failed and attempt to fence it.

Determining whether to disable fencing

The rule of thumb is that if the node will stop answering Corosync heartbeats at any point during the work, disable STONITH before you begin. In practice that means the following.

• Hardware maintenance. Disable STONITH. The node is powered off or rebooted, so it stops answering Corosync heartbeats and drops out of cluster membership, and the surviving node would fence it in response. Disabling STONITH suppresses that fencing action only. It has no effect on the node's membership, which is governed by Corosync.
• Software maintenance. Usually you do not need to. The node stays powered on and keeps answering heartbeats, so the surviving node never sees it as failed. Disable STONITH anyway if the update installs a new kernel, requires a reboot, or restarts Corosync or Pacemaker. See Updating the cluster software, DRBD, and the kernel.

Maintenance mode is not a substitute for disabling STONITH. It suspends resource management, but fencing is triggered by membership loss and unclean node state rather than by resource state, so a node that stops answering Corosync can still be fenced while the cluster is in maintenance mode. Treat the two controls as separate decisions. The node maintenance procedures run with maintenance mode turned off so that standby is able to migrate resources off the node.

Disabling and enabling STONITH

STONITH is a cluster-wide property, so both of the following commands can be run from either node over SSH.

1. Check whether STONITH is currently enabled for the cluster. In the CLI response, look for Stonith in the Option column. The value is Enabled or Disabled, not true or false. If you are calling the cluster.info method directly, the field is stonith_enabled.

rvc cluster info

2. Disable STONITH for the cluster. The command produces no output when it succeeds.

sudo crm configure property stonith-enabled=false

Enabling STONITH again is a step in both the primary and secondary node procedures in Performing maintenance on a node, so that it is not missed. Run it once the node is back in service, from whichever node you are connected to.

sudo crm configure property stonith-enabled=true

For an example of this sequence as part of a larger operation, see Shutting down and restarting a cluster.

To confirm fencing is back on after the maintenance, see Verifying a node after maintenance.

Related documentation

• Pacemaker and Corosync (high availability): the cluster software, STONITH, and the failover process.
• Performing maintenance on a node: the standby procedure that this step is part of.
• Operating the cluster: maintenance mode, standby, and how the two controls interact.