Network Load Balancing vs Failover Clustering

What Is Network Load Balancing?

Network Load Balancing (NLB) is a Windows Server feature that combines two or more servers, called hosts, into a single virtual cluster addressed by one shared IP address. Each host runs its own independent copy of the application, and NLB spreads incoming client requests across all of them using the TCP/IP stack itself — no dedicated load-balancer hardware is required.

Think of NLB as a row of identical toll booths on the same highway: any car can use any booth, none of them need to know what the others are doing, and losing one booth just means the remaining booths absorb its traffic. There is no shared record between booths — each one operates entirely on its own.

NLB supports up to 32 hosts in a single cluster, detects a failed or offline host and redistributes its load automatically, and typically completes that redistribution within about ten seconds. Hosts can be added or removed from a running cluster without taking the whole service down.

What Is Failover Clustering?

Failover Clustering is a different Windows Server feature entirely: a group of independent servers, also called nodes, that work together to increase the availability of a single set of clustered roles — a file share, a SQL Server instance, a virtual machine. Unlike NLB, only one node owns and runs a given clustered role at a time. If that node fails, the cluster moves ownership of the role to another node, and clients reconnect to the same identity on its new host.

The full mechanics — quorum, witnesses, and how a failover actually happens — are covered in depth in the Failover Clustering post. The short version: each node gets a vote, a quorum witness can hold a tie-breaking vote, and the cluster only keeps running while more than half the votes are present, specifically to avoid a split-brain scenario where two halves of a partitioned cluster both think they own the workload.

The Core Distinction

The question that actually decides which technology fits is not “how available does this need to be” — it’s does this workload keep state that only one node can own at a time?

A web front end serving static content or stateless API responses has no such state: any node can answer any request, so NLB fits naturally. A SQL Server database, a file share backed by a single volume, or a DHCP scope has exactly one authoritative copy of its data at any moment — running it “active-active” across multiple independent nodes would let two nodes each think they own writes, which corrupts data rather than protecting it. That is what Failover Clustering’s single-owner model exists to prevent.

When to Use Which

The two are not mutually exclusive. A common pattern puts an NLB cluster of stateless web or application servers in front of a backend that itself runs on a Failover Cluster — the web tier scales out and tolerates node loss with NLB, while the database behind it stays consistent because only one node ever owns it at a time.

Installing and Configuring

Both features install the same way, through Server Manager’s Add Roles and Features wizard or PowerShell, and neither requires a restart to complete installation.

# Install NLB with its management tools
Install-WindowsFeature NLB -IncludeManagementTools

# Install Failover Clustering with its management tools
Install-WindowsFeature Failover-Clustering -IncludeManagementTools

Creating an NLB cluster from PowerShell needs an interface name and a primary cluster IP address at minimum:

# Create a new NLB cluster on the specified network adapter
New-NlbCluster -InterfaceName "Ethernet" -ClusterPrimaryIP 10.20.4.50 -ClusterName "WebCluster01"

# Add a second host to the existing cluster
Add-NlbClusterNode -InterfaceName "Ethernet" -NewNodeName "WEB02" -NewNodeInterface "Ethernet"

# Add a port rule with Single affinity so a client always lands on the same host
Add-NlbClusterPortRule -StartPort 443 -EndPort 443 -Affinity Single

# Check the status of every node in the cluster
Get-NlbClusterNode

Creating a failover cluster starts with validation, not creation — skipping this step is the single most common cause of a cluster that looks fine until the first real failover:

# Validate that the proposed nodes and storage meet clustering requirements
Test-Cluster -Node "FS01","FS02"

# Create the cluster once validation passes
New-Cluster -Name "FileCluster01" -Node "FS01","FS02" -StaticAddress 10.20.4.60

# Check quorum configuration on the new cluster
Get-ClusterQuorum

# List the nodes and their current state
Get-ClusterNode

Common Pitfalls

Final Thoughts

NLB and Failover Clustering get lumped together as “Windows high availability” often enough that it is easy to reach for whichever one is more familiar rather than the one that actually fits the workload. The decision is not about which technology is more robust — it comes down entirely to whether the workload can safely run on more than one node at once.

Stateless, horizontally scalable services belong on NLB. Anything with a single authoritative copy of its own data belongs on Failover Clustering. Get that one distinction right and the rest of the configuration — port rules and affinity on one side, quorum and shared storage on the other — follows naturally from it.