Windows · Failover Clustering

Failover Clustering

Failover Clustering keeps a workload running when a server fails by moving it to another node automatically, and almost every design decision in it – node counts, witness type, dynamic quorum – exists to answer one question: which side of a split network is allowed to keep running.

By K Shankar R Karanth Windows

Quick idea: A failover cluster is a group of servers that work together to keep a workload available – if one node fails, another takes over. The mechanism that decides whether the surviving nodes are allowed to keep running, rather than shutting down to avoid corruption, is called quorum, and understanding quorum is most of what there is to understand about clustering.

Node

A server that is a member of the cluster and can host clustered roles.

Quorum

The voting mechanism that decides how many failures the cluster can survive before it must stop.

Witness

An extra vote – disk, file share, or cloud blob – used to break ties when node votes alone aren’t enough.

What Is Failover Clustering?

Failover Clustering is a Windows Server feature that groups multiple physical or virtual servers – nodes – into a single fault-tolerant unit. If the node hosting a clustered role fails, or loses connectivity, the cluster automatically starts that role on a surviving node instead of waiting for someone to notice and intervene.

Think of a cluster as a relay team rather than a single runner: the baton (the workload – a file share, a SQL Server instance, a virtual machine) keeps moving even if one runner drops out, because the team was built with that possibility in mind. What makes this hard in practice isn’t handing off the baton – it’s making sure two runners don’t both think they’re carrying it at once.

That second problem is called split-brain: if a network partition splits the cluster in two and both halves keep running independently, both can try to own the same storage or the same workload at the same time, corrupting data. Quorum exists specifically to prevent this.

How Quorum Works

Every node gets one vote. For the cluster to keep running, more than half of the total votes must be present and reachable – a simple majority. If a partition or set of failures drops the surviving vote count to half or fewer, the cluster stops itself on the minority side rather than risk two halves acting independently.

A quorum witness – disk, file share, or cloud – can hold one additional vote. Its job is purely to break ties: in a cluster with an even number of nodes, a network partition could otherwise split the votes exactly 50/50 with neither side holding a majority. A witness vote resolves that tie in favour of whichever side can still reach it.

Quorum Mode	How Quorum Is Decided
Node majority	Only node votes count. No witness configured.
Node majority with witness	Node votes plus one witness vote (disk or file share).
No majority (disk witness only)	Only the disk witness has a vote. Not recommended – the disk becomes a single point of failure.

Key rule: Configure an odd number of total voting elements. If the cluster has an even number of nodes, add a disk or file share witness so a network partition can never produce an exact 50/50 tie with no side holding a majority.

Witness Types

Microsoft’s current guidance is to always configure a witness on Windows Server 2012 R2 and later – later Windows Server versions manage the witness vote and node votes automatically through dynamic quorum, so a witness costs nothing when it isn’t needed and helps when it is.

Disk Witness

A small shared disk, NTFS or ReFS, accessible by every node. Requires shared storage such as a SAN.

File Share Witness

An SMB 2+ share on a separate server. No shared disk needed – the standard choice for clusters without shared storage, such as SQL Server Always On or Storage Spaces Direct.

Cloud Witness

An Azure Blob Storage container reached over HTTPS (port 443). No third site or extra server to maintain – useful for stretched or branch-office clusters.

A file share witness must be dedicated to a single cluster – never used to store user or application data – and the hosting device needs only 5 MB of free space. If the cluster runs Windows Server 2019 or later, the file share can live on a non-domain-joined device, such as a NAS or a workgroup server; on earlier versions it must be a domain-joined Windows server in the same forest as the cluster.

Important: A cloud witness needs a Standard general-purpose V2 storage account specifically – other account types aren’t supported. Use the primary access key the first time you configure it, and switch to the secondary key when rotating the primary, updating every cluster that shares that storage account.

Dynamic Quorum and Node Votes

Dynamic quorum management, enabled by default since Windows Server 2012 R2, lets the cluster adjust vote counts as nodes leave, rather than using a fixed majority calculated once at cluster creation. As nodes shut down one at a time in a planned sequence, the cluster recalculates what a majority means for the votes still present – which is how a cluster can end up running on a single surviving node (“last man standing”) instead of losing quorum the moment it drops below its original majority threshold.

This does not mean a cluster can survive several nodes failing at the exact same instant – dynamic quorum adjusts as nodes leave one after another, but at the moment of any given failure the cluster still needs a majority of the votes that existed just before it.

# Check whether dynamic quorum and dynamic witness weighting are enabled
Get-Cluster | Format-List Name, DynamicQuorum, WitnessDynamicWeight

# Check whether a specific node currently holds a quorum vote
# (DynamicWeight: 1 = has a vote, 0 = vote currently withdrawn)
Get-ClusterNode | Format-Table Name, State, DynamicWeight

# Disable dynamic quorum management (rarely necessary)
(Get-Cluster).DynamicQuorum = 0

Practical rule: Don’t remove a node’s vote manually just to force an odd number of voting elements – Microsoft’s own guidance is to use a witness for that instead. Manually removing votes is for specific disaster-recovery scenarios, such as excluding a backup site’s nodes from quorum calculations during planned manual failover.

Installing the Feature and Creating a Cluster

Failover Clustering is a Windows feature, not a role – install it on every server that will become a node before validation or cluster creation.

# Install the feature and its management tools (MMC snap-in + PowerShell module)
# Run on every server that will join the cluster
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

# Validate hardware, network, and storage before creating the cluster -
# do not skip this step even for a "simple" two-node cluster
Test-Cluster -Node "node01","node02"

# Create the cluster once validation passes
New-Cluster -Name "ProdCluster01" -Node "node01","node02" -StaticAddress 10.10.0.50

# Confirm the current quorum configuration
Get-ClusterQuorum

Practical rule: Run Test-Cluster before creating the cluster and again after any change to nodes or storage. It’s also how you catch a suboptimal quorum configuration – the report explicitly flags when the current setup isn’t the recommended one for the node count and storage present.

Configuring the Quorum

# Disk witness - list available shared disks, then assign one
Get-ClusterAvailableDisk
Set-ClusterQuorum -DiskWitness "Cluster Disk 1"

# File share witness - path must be dedicated to this cluster only
Set-ClusterQuorum -FileShareWitness "\\fileserver01\ProdCluster01-Witness"

# File share witness on a non-domain-joined device - prompts for
# the local account credential configured on that device
Set-ClusterQuorum -FileShareWitness "\\nas01\ClusterWitness" -Credential (Get-Credential)

# Cloud witness - Azure Storage account name and its access key
Set-ClusterQuorum -CloudWitness -AccountName "clusterwitnessstore" -AccessKey ""

# Confirm whichever witness type is now active
Get-ClusterQuorum | Format-List *

Production note: A disk witness needs shared storage every node can reach – it’s not an option for clusters without shared disks, such as SQL Server Always On Availability Groups or Storage Spaces Direct. Use a file share or cloud witness for those instead.

Gotchas and Best Practices

DFS Replication is not supported for a file share witness or any cluster storage. Replicated storage can produce a partition-in-time where nodes see different, independently-changing copies of the same data – exactly the split-brain condition quorum exists to prevent.

Restart the cluster service on the last active node before planned maintenance. File share and cloud witnesses don’t store a copy of the cluster configuration database themselves – only nodes do. If every node is shut down without this step, the cluster can come back up with a stale configuration and refuse to start (event 1561, below) until forced.

Key rule: After creating or reconfiguring a cluster, run the Validate Quorum Configuration test (part of Test-Cluster) rather than assuming the automatic defaults are optimal for your storage and node count. Once in production, avoid changing the quorum configuration except for a deliberate reason – adding or evicting nodes, adding storage, or recovering from a long-term witness failure.

Troubleshooting Cheat Sheet

Symptom	Likely Cause	Fix
Event 1177 – Cluster service shutting down, quorum lost	Network connectivity lost between nodes, or the witness became unreachable at the same time as a node failure.	Run the Validate a Configuration wizard against networking; check adapters, switches, and the witness’s availability.
Event 1135 – Node removed from cluster membership	The Cluster service stopped on that node, or it lost communication with the other active nodes.	Check the node’s Cluster service state and network adapters; confirm it can reach the other nodes and the witness.
Event 1069 – Cluster resource failed	The resource itself failed on the node currently hosting it – not necessarily a clustering problem.	Check resource and group state with `Get-ClusterResource`; investigate the underlying application or storage, not the cluster service.
Event 1561 – Cluster service won’t start, stale configuration detected	All nodes were shut down without restarting the cluster service on the last active node first; this node’s copy of the configuration is out of date.	Start the cluster service on other nodes first if possible. If none have a current copy, run `Start-ClusterNode -FQ` to force this node’s database authoritative – accepting that changes made while it was out of membership may be lost.
Cluster splits into two halves, neither functions	Even number of voting nodes with no witness configured, and a network partition produced an exact tie.	Add a disk, file share, or cloud witness so the total number of voting elements is odd.
`Set-ClusterQuorum -DiskWitness` fails or the disk isn’t listed	The disk isn’t visible to every node, or it’s a dynamic disk rather than basic.	Confirm the disk is shared storage, basic (not dynamic), and formatted NTFS or ReFS; re-run `Get-ClusterAvailableDisk`.

Final Thoughts

Most of what looks complicated about Failover Clustering is really one question asked repeatedly in different forms: if the cluster splits, which side gets to keep running? Node votes, witness type, and dynamic quorum are all answers to that same question, tuned for different failure scenarios and storage topologies.

Get the quorum configuration right for the node count and storage available, keep a witness for the odd-vote guarantee, and the failover mechanics underneath – moving a role from a failed node to a healthy one – mostly take care of themselves.

Key takeaway: Run Get-ClusterQuorum and confirm a witness is configured whenever the cluster has an even number of nodes. If quorum is ever lost, check event 1177 and 1135 first to tell a real network partition apart from a single node simply going down.

Next in this series

Storage Spaces and Storage Spaces Direct build directly on the clustering concepts here – a natural next stop is how pooled storage and resiliency types work underneath a clustered role.