From Disktatorship to Diskmocracy: Quorums in Failover Clustering
As an IT professional, it is my job to ensure the services and roles my clients need to access are actually available. One technology I can use to make sure that the storage or application that the client needs is nearly constantly accessible is failover clustering. It allows me to place the same role or storage share onto up to 64 physical servers, or nodes, and configure all of them to seamlessly take the place of one another in case of a single server failure. This allows me to keep all essential services running no matter what happens, making me look super competent even if some of the servers in my care are actually on fire.
Without failover clustering, each computer running the roles that my users and clients need would fail independently. Any hiccup in service would be immediately noticeable, and I would not look super competent.
Systems Administrators who are working in large environments might find this information useful. Clients who have the need for and resources to support multiple servers to carry out complex tasks will rely on this technology, and will need sys admins who are familiar with it. You will need to use the Failover Cluster feature to create a cluster, installed via the Add Roles and Features option in the Server Manager, and controlled with the Failover Cluster Manager. Here’s what the Failover Cluster Manager looks like:
The system that regulates whether a group of independent computers acting as nodes can function as a cluster is called quorum. A quorum is defined as the number of elements required to be online for a cluster to continue running. Here is how to access the quorum configuration options:
Like a legislative body convening to vote on regulatory bills and amendments, servers can vote on whether enough nodes are present to function as a cluster. The voting occurs automatically, with no direct interference from a systems administrator necessary. But I can set the terms of the legislative session. Choosing different quorum modes, or configurations, allows me to configure who gets a vote within the cluster, and how the votes are tabulated. A node can get a vote and configuring the quorums allows for a file share to be assigned a vote too.
There are four different quorum modes, each offering a different voting configuration for a different cluster setup. The first, and least used, would be the Disk Only Quorum Mode. In a Disk Only mode, the only part of the cluster that has a vote is a single node that is online and connected to a shared disk.
This mode is not recommended for use by me or Microsoft or anyone; it effectively turns your clustering setup into a disktatorship. If the node is online, it keeps the cluster online even if all other nodes fail. You could end up without a “cluster” and only a single computer performing a role that was supposed to be carried out by a collection of machines.
A node majority is the mode you might want to use if you have an odd number of nodes. This allows for a simple majority of nodes to keep the cluster going. For clusters with even numbers of nodes, consider the node and disk or node and file share modes. These allow the cluster to keep running with half the nodes online plus either a disk witness or file share online, respectively.
The voting among nodes and disks occurs automatically based on their availability. Choose which configuration mode is right for your setup, and become a stalwart defender of diskmocracy.
Thanks to my instructor, Thomas Titanski, for his assistance and patience. for more information and failover clusters and quorums, check out these articles from Altaro.com and TechNet.
