Introduction to Failover Clustering on Windows Server 2019

Failover Clustering in Windows Server 2019 provides high availability for workloads by grouping multiple servers into a cluster so that if one node fails, another node automatically takes over the workload. Failover Clustering is commonly used to protect Hyper-V virtual machines, SQL Server databases, file servers, and any role that supports clustering. Windows Server 2019 adds improvements including cluster sets for super-clusters, Azure-aware quorum for hybrid scenarios, storage bus layer enhancements, and improvements to the cluster health service.

A Failover Cluster requires shared storage (or Storage Spaces Direct), a stable network, and nodes running Windows Server 2019 that are domain-joined. Before you begin, ensure all nodes are joined to the same Active Directory domain and have matching Windows Server editions (Standard or Datacenter).

Prerequisites and Preparation

All cluster nodes must be domain-joined and have the same Windows Server 2019 edition. Ensure name resolution works for all node names. Configure at minimum two network adapters on each node: one for client traffic and one dedicated to cluster heartbeat traffic. Assign static IP addresses to all adapters. Install any required role features before creating the cluster — for example, Hyper-V if the cluster will host VMs.

Install the Failover Clustering feature on all nodes:

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Repeat this on every node that will participate in the cluster.

Running Cluster Validation

Cluster validation is a required step before creating a cluster. Run it from one of the nodes:

Test-Cluster -Node "Node1","Node2" -Include "Inventory","Network","Storage","System Configuration","Hyper-V Configuration"

Review the HTML report saved to C:UsersPublicDocuments. All failures in the “critical” category must be resolved before proceeding. Common issues include mismatched NIC driver versions, storage bus errors, or network adapter settings that differ between nodes.

Creating the Failover Cluster

After validation passes, create the cluster:

New-Cluster -Name "ProdCluster01" -Node "Node1","Node2" -StaticAddress 192.168.1.50

If you have shared SAN storage, omit -NoStorage to let Windows automatically add discovered shared disks. If using Storage Spaces Direct, use -NoStorage:

New-Cluster -Name "ProdCluster01" -Node "Node1","Node2" -StaticAddress 192.168.1.50 -NoStorage

Verify the cluster was created successfully:

Get-Cluster -Name "ProdCluster01"

Configuring Cluster Quorum

Quorum determines how many votes are needed for the cluster to remain online. For a two-node cluster, configure a witness to provide a tiebreaker vote. A cloud witness (Azure Blob Storage) is recommended for modern deployments:

Set-ClusterQuorum -Cluster "ProdCluster01" -CloudWitness -AccountName "mystorageaccount" -AccessKey "base64accesskeyhere=="

Alternatively, use a file share witness on a file server that is not part of the cluster:

Set-ClusterQuorum -Cluster "ProdCluster01" -FileShareWitness "\FileServerClusterWitness"

View the current quorum configuration:

Get-ClusterQuorum -Cluster "ProdCluster01"

Adding Cluster Shared Volumes

For Hyper-V clusters, Cluster Shared Volumes (CSVs) allow multiple nodes to simultaneously access the same volume. Add a shared disk to the cluster and then enable CSV:

Add-ClusterDisk -InputObject (Get-Disk -Number 1)
Add-ClusterSharedVolume -Name "Cluster Disk 1"

CSVs mount at C:ClusterStorageVolume1 on all nodes. View all CSVs:

Get-ClusterSharedVolume -Cluster "ProdCluster01"

Configuring Cluster Networks

View all networks detected by the cluster:

Get-ClusterNetwork -Cluster "ProdCluster01" | Select Name, Address, Role

The Role property indicates how the network is used: 0 = not used, 1 = cluster only (internal heartbeat), 3 = all (client and cluster). Set the heartbeat network to cluster-only traffic:

Get-ClusterNetwork -Cluster "ProdCluster01" -Name "Heartbeat" | Set-ClusterNetwork -Role 1

Configure preferred failover networks for cluster IP resources:

(Get-ClusterNetwork -Cluster "ProdCluster01" -Name "Production").Metric = 100

Testing Failover

Test that failover works correctly by moving cluster resources from one node to another:

Move-ClusterGroup -Cluster "ProdCluster01" -Name "Available Storage" -Node "Node2"

Monitor cluster events in real time:

Get-ClusterLog -Cluster "ProdCluster01" -Destination "C:ClusterLogs" -TimeSpan 60

View cluster resource health:

Get-ClusterResource -Cluster "ProdCluster01" | Select Name, State, OwnerNode, ResourceType

Windows Server 2019 Failover Clustering provides the foundation for all high-availability workloads including Hyper-V, SQL Server, Scale-Out File Servers, and Storage Spaces Direct. Proper planning of network, storage, and quorum configuration is essential for a resilient production cluster.