Building a Two-Node vSAN Cluster for High Availability

A two-node vSAN cluster can deliver resilient compute and storage without the cost or rack space of a traditional three-node design. It is well suited to branch offices, small data centres, test environments and home labs where virtual machines need protection from a single host failure.

The design does require careful planning. A two-node configuration uses a separate vSAN witness, so availability depends on host hardware, network paths, witness placement and sensible operational procedures. For Australian organisations, that might mean supporting a Brisbane office from Sydney, working around regional bandwidth limits, or fitting infrastructure into a compact Melbourne colocation rack.

Design Goals And Constraints

Begin by defining the failure you need to survive. A correctly configured two-node vSAN cluster can continue running workloads when one ESXi host fails, while vSphere HA restarts affected virtual machines on the surviving host. It does not protect against every event, including a shared power failure, a faulty switch or a misconfigured storage policy.

The witness appliance supplies quorum metadata and should be placed independently from the two data nodes. It can run at another site, in a suitable cloud environment or on a separate management host, provided latency and connectivity meet VMware’s documented requirements. Avoid placing the witness on either physical host because that removes an important layer of failure isolation.

Capacity planning also matters. Reserve enough CPU, memory and storage for one host to carry critical workloads after a failure. A cluster that is full during normal operation may remain technically available but perform poorly when it is degraded.

Choose Compatible Hardware

Use two closely matched servers with hardware listed on the VMware Compatibility Guide. Check the exact controller, drive, firmware, network adapter and ESXi version rather than relying on a similar model number. Consistency makes lifecycle management and troubleshooting considerably easier.

For most new deployments, all-flash storage and 10 GbE networking provide a sensible baseline. Enterprise SSDs should be selected for endurance as well as capacity, and the storage controller must support the required vSAN mode. Do not assume a controller suitable for conventional RAID is automatically appropriate for vSAN.

Include dual power supplies, separate power circuits and redundant network connections where the site allows it. In a Sydney or Perth facility, confirm rack power and remote-hands arrangements before delivery. A small regional site may have fewer options, making tested spare disks, transceivers and power supplies especially valuable.

Plan The Network

Create separate, documented networks for management, vMotion, vSAN and virtual machine traffic. Physical separation is ideal, although VLAN-based separation can work when the switching platform is properly designed. Every relevant port group should use consistent MTU settings, VLAN tagging and security policies across both hosts.

Use redundant switches or switch stacks when practical, with each ESXi host connected to both paths. Validate DNS, NTP, routing and forward and reverse name resolution before deploying vSAN. Time drift and unreliable name resolution often create confusing symptoms that look like storage or HA faults.

The witness network deserves specific attention. A witness hosted across an Australia-wide WAN may experience congestion or variable latency, particularly on business-grade links serving regional locations. Monitor packet loss and latency continuously, and document the routing path so an outage can be diagnosed quickly rather than treated as a mysterious vSAN health warning.

Deploy vSAN And Witness

Install the same supported ESXi release and patch level on both hosts, then add them to vCenter. Create a cluster with vSAN enabled, select the two-node configuration, and deploy the witness appliance separately. The witness should use reliable management connectivity and have adequate resources for the number of objects it serves.

Claim the storage devices according to the selected vSAN architecture and assign the appropriate disk groups. Confirm that every capacity device is recognised, healthy and contributing as expected. In a two-node cluster, vSAN commonly uses mirrored protection, so usable capacity is lower than raw capacity.

Set storage policies deliberately. A policy with failures to tolerate set to one generally provides a mirror across the two data hosts, while the witness records placement metadata. Review object compliance after provisioning workloads, and remember that snapshots, replicas and thin-provisioned disks can consume capacity faster than initial estimates suggest.

Configure vSphere HA

Enable vSphere HA after the hosts, networking and vSAN health checks are clean. Configure admission control so the cluster reserves enough capacity to restart important workloads after losing one host. In a two-node environment, capacity reservations can appear conservative, but relaxing them may leave the surviving host unable to provide meaningful service.

Set VM restart priorities according to business impact. Domain controllers, DNS, monitoring and management services may need to start before application servers. Use VM-Host affinity rules carefully; an overly strict rule can prevent HA from restarting a workload on the only available host.

Test isolation response settings and understand how the hosts behave when management traffic is interrupted. vSAN health, HA status and host isolation alarms should be integrated with the organisation’s monitoring platform. Role-based administration can also reduce accidental changes, with guidance available in this custom vCenter roles guide.

Operate And Test The Cluster

A high-availability design is valuable only when its failure behaviour is known. Test a controlled host shutdown, vMotion, a vSAN disk failure and loss of a single network path during a maintenance window. Record recovery times and verify that application owners see the expected service behaviour.

Before placing a host into maintenance mode, select the appropriate vSAN data migration option and confirm available capacity. Full data migration provides stronger protection but can take longer and generate substantial network traffic. Ensure backups are current, because replication within vSAN is not a replacement for independent backup.

Use the vSAN Skyline Health checks, vCenter events, hardware management tools and capacity reports as a combined operational view. Keep firmware, drivers and ESXi updates aligned with the supported vSAN release. The site disclaimer also explains the basis on which technical material and tools should be evaluated in a production environment.

Practical Build Checklist

A short checklist helps turn a design into a repeatable deployment. It is particularly useful when work is shared between an internal team, an MSP and a data-centre provider in different Australian states.

Keep the final configuration in Git or another controlled repository, including VLAN identifiers, IP assignments, firmware versions and storage policies. Automation can reduce drift, and free PowerCLI tools can help with inventory, validation and repeatable administration.

A well-planned two-node vSAN cluster offers a practical balance between resilience, cost and operational simplicity. Document the design, test the failure scenarios and monitor the witness as seriously as the data hosts. Start with a small validated workload, confirm recovery behaviour, and then expand the platform with confidence.