Windows Server Failover Clustering (WSFC) has been the backbone of high-availability (HA) for Microsoft workloads since Windows 2003. Despite the shift towards cloud-native resilience patterns, WSFC remains highly relevant for on-premises SQL Server Always On Availability Groups, Hyper-V high availability, Scale-Out File Servers (SOFS), and Storage Spaces Direct (S2D) clusters.

This article covers the architecture decisions and configuration details that matter most in production deployments.

Cluster Components and Architecture

A WSFC consists of:

  • Nodes — Windows Server instances (physical or virtual) that are members of the cluster. Minimum: 2 nodes. Supported up to 64 nodes.
  • Cluster network — a dedicated private network used for heartbeat traffic and cluster communication. Must be separate from the client-access network.
  • Shared storage or direct replication — either shared SAS/iSCSI/FC storage (traditional) or Storage Spaces Direct with local NVMe/SSD (hyperconverged). SQL Server AG with synchronous replication does not require shared storage.
  • Cluster IP address — a virtual IP hosted by whichever node currently owns the cluster core resource group, used for cluster management access.
  • Roles — workloads configured to run on the cluster: SQL Server AG, Hyper-V VMs, File Server, generic services.

Quorum: The Critical Concept

Quorum is the mechanism WSFC uses to determine when it's safe to continue operating after a partial failure. It prevents "split-brain" — a scenario where two halves of a cluster both believe they own a resource simultaneously, leading to data corruption.

The cluster maintains a vote count. Nodes and optionally a witness each hold one vote. The cluster continues operating as long as the majority of votes are present (quorum majority).

Quorum Witness Options

  • Disk witness — a small shared disk (1 GB is sufficient) that holds a vote. Reliable for traditional SAN-attached clusters. Not applicable for S2D clusters.
  • File share witness (FSW) — a UNC file share on an independent server. Common for two-node clusters without shared storage. The witness server must be outside the cluster and ideally in a third site/subnet.
  • Cloud witness — an Azure Blob Storage account acts as the witness. Requires internet access from all nodes. Ideal for clusters that already use Azure services; eliminates the need for a third on-premises server.

For a two-node cluster: use Node Majority + Witness (total 3 votes — quorum requires 2). This allows one node to fail and the cluster to remain operational. Without a witness, a two-node cluster loses quorum when one node fails — which defeats the purpose.

Networking Requirements

Network misconfiguration is the most common cause of cluster problems in production. Requirements:

  • Dedicated cluster network — heartbeat traffic must use a dedicated NIC and subnet, not shared with client traffic. Minimum 1 GbE; 10 GbE recommended for live migration and storage traffic.
  • Static IP addressing on all cluster networks — DHCP-assigned cluster NICs are unsupported and cause intermittent problems.
  • Consistent DNS — all nodes must resolve each other's names correctly. DNS scavenging that removes cluster name records causes access failures.
  • Firewall rules — WSFC uses TCP/UDP port 3343 for cluster communication. SQL Server AG uses port 5022 for replication endpoints. These must be open between all nodes.
  • Same-subnet or route-based failover — nodes in different subnets (stretch cluster, multi-site) require appropriate routing and DNS TTL considerations to ensure clients reconnect quickly after failover.

SQL Server Always On Availability Groups on WSFC

WSFC is the dependency for SQL Server Always On AG (synchronous or asynchronous mode). Key design decisions:

  • AG listener — the listener IP must be in the same subnet as the primary replica (or use multi-subnet AG with OR-dependency on the IP resources)
  • Synchronous vs asynchronous replicas — synchronous replication guarantees zero data loss on failover but adds latency to every commit. Use synchronous only for replicas with sub-10ms RTT to the primary. Asynchronous is appropriate for DR replicas in remote sites.
  • Automatic vs manual failover — only synchronous replicas are eligible for automatic failover. Maximum two automatic failover replicas per AG in SQL Server 2019 and earlier; expanded in SQL Server 2022.
  • Readable secondaries — offload read workloads (reporting, backups) to synchronous or asynchronous secondaries using the AG listener with ApplicationIntent=ReadOnly connection string parameter.

Storage Spaces Direct (S2D) Clustering

S2D eliminates the need for external shared storage by pooling local drives across nodes. Key requirements:

  • Minimum 2 nodes (for Hyper-V HA); minimum 4 nodes for S2D with three-way mirror resiliency
  • All nodes must have identical drive configurations
  • NVMe or SAS SSDs for cache tier; SAS HDDs or SAS SSDs for capacity tier
  • RDMA-capable NICs (RoCE v2 or iWARP) strongly recommended for storage traffic — reduces CPU overhead and improves latency significantly vs standard TCP
  • Switch-embedded teaming (SET) for the converged network (storage + cluster + management on same NICs)
"The most dangerous WSFC configuration is a two-node cluster with no witness. One node fails, quorum is lost, and the cluster takes down the second node too — turning a hardware failure into a complete outage."

Sripadatech designs, deploys, and supports WSFC environments for SQL Server, Hyper-V, and file services. Contact us if you're planning a HA deployment or reviewing an existing cluster configuration.