2.7. Considerations for Using Quorum Disk
qdiskd, that provides supplemental heuristics to determine node fitness. With heuristics you can determine factors that are important to the operation of the node in the event of a network partition. For example, in a four-node cluster with a 3:1 split, ordinarily, the three nodes automatically "win" because of the three-to-one majority. Under those circumstances, the one node is fenced. With
qdiskdhowever, you can set up heuristics that allow the one node to win based on access to a critical resource (for example, a critical network path). If your cluster requires additional methods of determining node health, then you should configure
qdiskdto meet those needs.
qdiskdis not required unless you have special requirements for node health. An example of a special requirement is an "all-but-one" configuration. In an all-but-one configuration,
qdiskdis configured to provide enough quorum votes to maintain quorum even though only one node is working.
qdiskdparameters for your Red Hat Cluster depend on the site environment and special requirements needed. To understand the use of heuristics and other
qdiskdparameters, refer to the qdisk(5) man page. If you require assistance understanding and using
qdiskdfor your site, contact an authorized Red Hat support representative.
qdiskd, you should take into account the following considerations:
- Cluster node votes
- Each cluster node should have the same number of votes.
- CMAN membership timeout value
- The CMAN membership timeout value (the time a node needs to be unresponsive before CMAN considers that node to be dead, and not a member) should be at least two times that of the
qdiskdmembership timeout value. The reason is because the quorum daemon must detect failed nodes on its own, and can take much longer to do so than CMAN. The default value for CMAN membership timeout is 10 seconds. Other site-specific conditions may affect the relationship between the membership timeout values of CMAN and
qdiskd. For assistance with adjusting the CMAN membership timeout value, contact an authorized Red Hat support representative.
- To ensure reliable fencing when using
qdiskd, use power fencing. While other types of fencing (such as watchdog timers and software-based solutions to reboot a node internally) can be reliable for clusters not configured with
qdiskd, they are not reliable for a cluster configured with
- Maximum nodes
- A cluster configured with
qdiskdsupports a maximum of 16 nodes. The reason for the limit is because of scalability; increasing the node count increases the amount of synchronous I/O contention on the shared quorum disk device.
- Quorum disk device
- A quorum disk device should be a shared block device with concurrent read/write access by all nodes in a cluster. The minimum size of the block device is 10 Megabytes. Examples of shared block devices that can be used by
qdiskdare a multi-port SCSI RAID array, a Fibre Channel RAID SAN, or a RAID-configured iSCSI target. You can create a quorum disk device with
mkqdisk, the Cluster Quorum Disk Utility. For information about using the utility refer to the mkqdisk(8) man page.
NoteUsing JBOD as a quorum disk is not recommended. A JBOD cannot provide dependable performance and therefore may not allow a node to write to it quickly enough. If a node is unable to write to a quorum disk device quickly enough, the node is falsely evicted from a cluster.