Windows Server Failover Clustering Concepts, Quorum, Nodes, Networks, and Storage

Learning outcomes

ServiceHub now has tested backups, but recovery time is still measured in restore steps. High availability (HA) tries to keep a service reachable through selected infrastructure failures. SQL Server does not solve that problem alone. On Windows, both Failover Cluster Instances (FCIs) and traditional Availability Groups (AGs) rely on Windows Server Failover Clustering (WSFC) for node membership, health and quorum. The Database Engine contributes SQL-specific health and replica state; the cluster decides whether the infrastructure still has authority to keep resources online.

1. The first HA layer is authority, not data replication

A cluster must answer a dangerous question during a partition: which side is allowed to own the service? WSFC uses voting members and optional witnesses to maintain a majority. If a valid majority cannot be established, the cluster takes clustered workloads offline rather than allow competing owners. This is why quorum is part of correctness, not merely uptime tuning.

SELECT SERVERPROPERTY('ProductVersion') AS product_version,       SERVERPROPERTY('ProductUpdateLevel') AS update_level,       SERVERPROPERTY('Edition') AS edition,       SERVERPROPERTY('EngineEdition') AS engine_edition,       SERVERPROPERTY('IsClustered') AS is_fci,       SERVERPROPERTY('IsHadrEnabled') AS hadr_enabled,       SERVERPROPERTY('MachineName') AS machine_name,       SERVERPROPERTY('ServerName') AS server_name;GOSELECT name, compatibility_level, recovery_model_descFROM sys.databasesWHERE name = N'ServiceHubLab';GO

2. Model the votes before installing SQL Server

USE ServiceHubLab;GOIF SCHEMA_ID(N'lab16') IS NULL EXEC(N'CREATE SCHEMA lab16 AUTHORIZATION dbo;');GODROP TABLE IF EXISTS lab16.FailoverDrill;DROP TABLE IF EXISTS lab16.ReplicaModel;DROP TABLE IF EXISTS lab16.ClusterVote;GOCREATE TABLE lab16.ClusterVote(  member_name sysname NOT NULL PRIMARY KEY,  member_type varchar(12) NOT NULL CHECK (member_type IN ('NODE','WITNESS')),  site_name varchar(30) NOT NULL,  has_vote bit NOT NULL,  is_reachable bit NOT NULL);CREATE TABLE lab16.ReplicaModel(  replica_name sysname NOT NULL PRIMARY KEY,  site_name varchar(30) NOT NULL,  availability_mode varchar(30) NOT NULL,  failover_mode varchar(20) NOT NULL,  role_desc varchar(12) NOT NULL,  synchronization_state varchar(30) NOT NULL,  log_send_queue_kb bigint NOT NULL DEFAULT 0,  redo_queue_kb bigint NOT NULL DEFAULT 0);CREATE TABLE lab16.FailoverDrill(  drill_id bigint IDENTITY PRIMARY KEY,  scenario varchar(80) NOT NULL,  started_at datetime2(3) NOT NULL DEFAULT SYSUTCDATETIME(),  expected_primary sysname NULL,  observed_primary sysname NULL,  data_loss_possible bit NOT NULL,  client_reconnect_required bit NOT NULL,  outcome nvarchar(300) NULL);GO

INSERT lab16.ClusterVote(member_name,member_type,site_name,has_vote,is_reachable)VALUES (N'NODE-A','NODE','Primary',1,1),       (N'NODE-B','NODE','Secondary',1,1),       (N'WITNESS','WITNESS','ThirdSite',1,1);GOSELECT member_name,member_type,site_name,has_vote,is_reachableFROM lab16.ClusterVote;SELECT SUM(CASE WHEN has_vote=1 THEN 1 ELSE 0 END) AS configured_votes,       SUM(CASE WHEN has_vote=1 AND is_reachable=1 THEN 1 ELSE 0 END) AS reachable_votesFROM lab16.ClusterVote;GO

With three configured votes, two reachable votes form a majority. Now simulate loss of one node. The remaining node plus witness can still establish authority. Simulate loss of the witness instead: both nodes together still have two of three. The lesson is not “three is magic.” The lesson is that each vote must live in a failure domain that behaves the way your outage model assumes.

UPDATE lab16.ClusterVote SET is_reachable=0 WHERE member_name=N'NODE-B';WITH q AS( SELECT SUM(CASE WHEN has_vote=1 THEN 1 ELSE 0 END) AS configured,        SUM(CASE WHEN has_vote=1 AND is_reachable=1 THEN 1 ELSE 0 END) AS reachable FROM lab16.ClusterVote)SELECT configured,reachable,       FLOOR(configured/2.0)+1 AS votes_required,       CASE WHEN reachable >= FLOOR(configured/2.0)+1 THEN 'QUORUM' ELSE 'NO QUORUM' END AS decisionFROM q;GO

3. Quorum arithmetic is only as good as the failure-domain model

A file-share witness located on the same power circuit and switch as NODE-A is not independent merely because it has a different hostname. A cloud witness introduces internet/Azure-storage dependencies. A disk witness is natural for shared-storage clusters but is usually the wrong model for a multisite AG with no shared data disk. WSFC supports dynamic quorum and witness behavior; do not freeze a simplistic “odd number of nodes” rule into an operational standard.

# Optional Windows Server / WSFC topology only.Get-ClusterGet-ClusterNode | Format-Table Name, State, NodeWeight, DynamicWeightGet-ClusterQuorumGet-ClusterGroupGet-ClusterNetwork# Run Test-Cluster before production deployment/change according to Microsoft guidance.

4. Linux changes the cluster manager, not the need for authority

SQL Server availability groups on Linux can use Pacemaker for cluster-managed failover. SQL Server uses CLUSTER_TYPE = EXTERNAL for an external cluster manager, while CLUSTER_TYPE = NONE supports read-scale configurations with no cluster-managed failover. Neither model turns the Database Engine into a consensus system. Pacemaker requires its own quorum/fencing design; clusterless AGs require manual orchestration.

SELECT SERVERPROPERTY('IsHadrEnabled') AS is_hadr_enabled;SELECT cluster_name,quorum_type_desc,quorum_state_descFROM sys.dm_hadr_cluster;SELECT member_name,member_type_desc,member_state_desc,number_of_quorum_votesFROM sys.dm_hadr_cluster_members;GO-- Zero rows on a standalone/non-AG lab are expected evidence, not an error.

5. Production judgment

Quorum configuration is an infrastructure safety mechanism. Record the cluster version, Windows Server or Linux distribution, node/vote/witness placement, network and storage failure domains, cluster validation status, fencing design, and administrative ownership. Windows Server licensing/infrastructure is required for a real WSFC; Pacemaker deployments require supported Linux and cluster tooling. A single SQL Server Developer/Express instance can teach the reasoning but cannot prove cluster failover.

The next lesson places an actual SQL Server instance under cluster ownership and shows why FCI protects the instance through node failure while still retaining a single shared copy of its database storage.

Authoritative references

• Windows Server Failover Clustering with SQL Server — WSFC role in SQL Server HA
• WSFC quorum modes and voting configuration — SQL Server quorum guidance
• What is a quorum witness? — Windows Server 2025 witness and dynamic-quorum concepts
• Create and configure an availability group on Linux — Pacemaker/external and clusterless concepts