Quorum devices support on Pacemaker
A quorum device helps a cluster manager make cluster management decisions when the cluster manager's normal decision process does not produce a clear choice.
To select an action to take, a cluster manager counts the number of cluster domain nodes that support each of the potential actions. The cluster manager then selects the action that is supported by most of the cluster domain nodes. If the same number of cluster domain nodes supports more than one choice, then the cluster manager refers to a quorum device to make the choice.
- Two-node quorum
- QDevice quorum
- Majority quorum
The two-node quorum is the default mechanism. Because no tie-breaker mechanism exists, the two-node quorum is prone to the split-brain scenario. It is not intended for production environments.
QDevice is similar to a Network IP tiebreaker in the sense that it requires an external resource accessible by all hosts in the current Pacemaker cluster. But they differ immensely in terms of reliability. QDevice is much more reliable because the quorum decision logic is more robust than a simple TCP/IP ping to the external IP address. QDevice requires that the resource is placed on a separate host, similar to a majority quorum requirement. However, setup is simplified, as the host with the QDevice does not need to be part of the Pacemaker quorum. The QDevice is the best blended quorum solution that combines reliability and simplicity.
A quorum device acts as the third-party arbitration device for the cluster. Its primary use is to allow a cluster to sustain more node failures than standard quorum rules allow.
As seen in Figure 1, it is a Corosync daemon process, QDevice daemon (corosync-qdevice), running on each node in the cluster. The QDevice daemon provides a configured number of votes to the quorum subsystem, based on a third-party arbitrator's decision. This third-party arbitrator is a separate Corosync QNet daemon (corosync-qnetd) running on a separate host (not part of the cluster). The third-party arbitrator contributes to the deciding vote of the corosync-qdevice logic that ultimately decides the surviving side in a split-brain scenario.
Both the QDevice daemon and the QNet daemon are provided with different software packages and must be installed separately. The QDevice daemon must be installed on each host in the cluster (Host1 and Host2 in Figure 1). The QNet daemon is needed only on a separate host that is not part of the cluster (Host3 in Figure 1).
The QNet daemon can be used as the arbitrator for another cluster (in Figure 1, two clusters share the same host with qnetd process), given that all clusters have a unique name.
|Link Failures||Host1 instance state||Host1 Quorum status||Host2 instance state||Host 2 Quroum status||Host3 state||Scenario description|
|1||Up||Acq||Down||Lost||Up||Quorum device picks the node with the lowest node ID value to survive, which is Host 1. Host 2 loses quorum and the instance is taken down.|
|2||Up||Acq||Up||Acq||Up||Host 1 still has quorum and continues to work.|
|3||Up||Acq||Up||Acq||Up||Host 2 still has quorum and continues to work.|
|1 and 2||Down||Acq||Up||Acq||Up||Host 1 loses quorum and the instance is taken down.|
|2 and 3||Up||Acq||Up||Acq||Down||Host 1 and host 2 maintain quorum but are without the quorum service.|
|1 and 3||Up||Acq||Down||Lost||Up||Host 2 loses quorum and the instance is taken down.|
|All||Down||Lost||Down||Lost||Down||Both hosts lose quorum and the instances are taken down. The quorum service is also down.|
The Majority Quorum avoids split-brain scenarios by adding a third node to the cluster for arbitration. In a split-brain scenario, the side that successfully acquires the third node is the surviving side. The difference between QDevice and Majority Quorum is that the third node is fully integrated into the cluster.
Quorum consideration on public cloud vendors
For more information, refer to Public cloud vendors supported with Db2 Pacemaker.