What’s the issue?
SQL Server Always On Availability Groups and Failover Cluster Instances rely on Windows Server Failover Clustering (WSFC) for high availability coordination. The cluster maintains a list of members (nodes) and tracks their current state, and it uses a quorum model to determine whether enough of the cluster is online to safely make decisions about resource ownership and failover.
Quorum is calculated from votes assigned to cluster members and, depending on the quorum model, a witness (file share, disk, or cloud witness). The cluster must have a majority of votes online and reachable to maintain quorum and continue operating; if quorum is lost, the cluster shuts down its resources to prevent split brain scenarios.
This finding identifies clusters where one or more members are currently offline, where vote configuration is out of balance, or where the remaining online members do not constitute a healthy quorum margin.
Why is this a problem?
A cluster running with reduced membership has reduced resilience to additional failures. A two-node cluster with one node offline has no remaining redundancy: the loss of the surviving node takes the cluster fully offline, which means any AG or FCI hosted on the cluster also goes offline, taking applications with it.
Quorum problems can also cause unexpected behavior even when the visible members appear healthy. If the vote configuration is misaligned (for example, two votes online and two offline with no witness to break ties), a brief network partition can split the cluster into two halves that each believe they should host resources, producing the split brain condition that quorum exists to prevent.
The SQL Server side experience of quorum loss is often confusing. AGs and FCIs become unavailable suddenly, sometimes with limited error messaging at the SQL Server level, and the actual cause sits at the Windows clustering layer rather than in SQL Server itself. Diagnosing the issue requires looking at cluster events, which may be unfamiliar territory for teams focused on the database engine.
The condition often persists because clusters are designed to keep running even with reduced membership, so the immediate symptoms of an offline node are limited until additional failures occur. Without monitoring specifically focused on cluster health, an offline node can remain undetected for days or longer, leaving the cluster in a fragile state that no one knows about.
What should you do about this?
Review the current cluster state through Failover Cluster Manager, the Get-ClusterNode PowerShell command, or the cluster log. Identify which members are offline, the reason for the offline state, and the current vote configuration including any configured witness.
Bring offline nodes back online by addressing whatever caused the outage, whether that is a hardware issue, operating system problem, network connectivity loss, or a planned maintenance task that was not completed. Confirm that the cluster service starts cleanly and that the node rejoins the cluster as an active voting member.
If a node cannot be returned to service quickly and the remaining nodes are running with reduced quorum margin, consider adjusting the vote configuration temporarily so the surviving cluster members maintain a healthy majority. Use the dynamic quorum and witness settings appropriate to your cluster model, and document any temporary changes so they are reversed once the offline node is restored.
Verify the witness configuration is appropriate for the cluster size and topology. Two node clusters in particular benefit from a file share witness or cloud witness, since without one the loss of either node can result in immediate quorum loss. Larger clusters benefit from witnesses to handle even node count scenarios.
Read more…
Understanding Quorum in a Failover Cluster | Microsoft Community Hub