A two-node Windows Server Failover Cluster is achievable on VPS infrastructure, but the constraints are different from a datacenter build. Shared storage usually does not exist, quorum is a design decision rather than an afterthought, and network latency between nodes sets the practical ceiling for what can fail over cleanly. This is the design reference for a two-node cluster on commodity VPS.
Validated Two-Node Configurations
Microsoft validates these topologies for two nodes; anything else needs a support waiver.
- Storage Spaces Direct (S2D): local disks on each node pooled and replicated. Works without shared storage, but requires low inter-node latency and enough local disk on each VM.
- Shared storage in a third location: iSCSI target or a SAN presented to both nodes. Rare on cheap VPS plans but possible with iSCSI over a private network.
- Witness-based options (no shared storage): cloud witness, file share witness, or a disk witness on a shared volume.
Quorum: The Part People Get Wrong
With only two nodes, losing the network link between them means both think the other failed. Quorum breaks the tie. Opinions on which witness to use:
- Cloud witness is the cheapest and most VPS-friendly: an Azure Storage account key, no third machine. It requires outbound HTTPS from both nodes.
- File share witness needs a third host with a share both nodes can reach, and the share must be on a machine outside the cluster.
- Disk witness requires shared storage, which defeats the purpose if you chose S2D.
- For a 2-node cluster, set one node to Node Majority (default) and configure the witness. Do not run dynamic quorum tuning until you understand it.
| Witness type | Third machine? | Best for |
|---|---|---|
| Cloud witness | No (Azure Storage) | VPS nodes, minimal cost |
| File share witness | Yes | On-prem or hybrid with a file server |
| Disk witness | No but needs shared disk | SAN-backed clusters |
Networking Requirements
- Two networks minimum: a public/management path and a private cluster heartbeat path. Put the heartbeat on a private VLAN between the two VPS instances.
- Fixed IP addresses on the cluster network; DHCP on a heartbeat interface is a support nightmare.
- Latency is the real limit. S2D and live migration both degrade badly above single-digit milliseconds of inter-node latency; check it with
Test-NetConnectionand continuous ping before committing.
Building It
- Install the Failover Clustering feature on both nodes:
Install-WindowsFeature Failover-Clustering -IncludeManagementTools. - Validate first:
Test-Cluster -Node node1,node2and read every warning; fix storage and network issues before creating the cluster. - Create:
New-Cluster -Name vpsclu -Node node1,node2 -StaticAddress 10.0.0.50. - Add the witness:
Set-ClusterQuorum -CloudWitness -AccountName acct -AccessKey key.
Cost and Provider Reality
A cluster doubles your compute cost before you add storage. Two equal instances, a private network between them, and an Azure Storage account for the witness are the minimum. Confirm your provider supports a private LAN between instances and static IPs on it; some budget plans do not. If the provider cannot give you a low-latency private network, a cluster will flap. When you are sizing the two nodes, keep memory and disk identical and compare Windows VPS plans on the private-network and snapshot features rather than raw core count, since those features decide whether clustering is viable at all.
When Not to Cluster
If your workload is IIS or a database that already has its own replication, DNS round-robin plus health checks can deliver most of the availability for a fraction of the complexity. Cluster when you need automatic failover of a stateful role with a single network identity; otherwise the operational overhead usually outweighs the benefit.
