Building a vSAN Stretched Cluster for Cross-Site Redundancy

A vSAN stretched cluster links two sites into one storage and availability domain. Synchronous replication keeps protected data current on both sides, while vSphere HA can restart workloads after a site loss. For Australian teams, that can turn a data centre outage into a controlled failover.

Geography makes this less straightforward than drawing a line between two racks. Sydney and Melbourne may host primary and recovery sites, yet the 900-kilometre route can exceed the latency envelope for synchronous storage. Two Sydney sites with diverse carrier paths may suit synchronous replication better. Measure the actual path; suburb distance is not fibre latency.

Local procurement also shapes the brief. Australian organisations and managed service providers often require recovery data to remain in Australia, and cloud choices include Australian and New Zealand regions rather than overseas capacity. A stretched private connection must preserve residency while identity, security and backups receive their own recovery design.

The cluster does not make every application cross-site capable. This guide covers the architecture, network, quorum, sizing and tests needed for a defensible vSAN stretched cluster, with emphasis on realities faced by local IT teams and the engineers supporting them.

Set the failure model

Start by naming the events the design must survive: host loss, storage-path loss, WAN-circuit loss and an entire site. Set separate RPO and RTO targets for each. A stretched cluster can offer near-zero storage RPO, but application recovery may take longer.

vSAN provides storage resilience and vSphere HA restarts workloads. It does not automatically protect DNS, directory services, application secrets, licences or database logic. Include management planes, network virtualisation and backup catalogues in the failure model.

The fair dinkum test is whether the result is measured, repeatable and owned by operations. Define which site declares failure, who authorises failover, and how normal service returns without another outage.

Engineer sites and WAN paths

Choose sites by latency and diversity. Two facilities in one metro can suit synchronous storage better than a Sydney-to-Melbourne span, but separation alone does not guarantee isolation. Confirm that power, cooling, carrier handoffs and upstream routers do not share a failure domain.

Use redundant routed paths, tested failover, QoS and an end-to-end MTU that matches the design. Sustained loss, jitter and congestion matter as much as average round-trip time. Keep inter-site RTT within the supported limit for your release, commonly around 5 ms, and test under busy conditions.

Regional Australian sites add environmental constraints. Brisbane and Darwin bring heat and humidity, while remote power and cooling dependencies can be harder to monitor. Use metered capacity, environmental alerts and a documented support path.

Size hosts, storage and witness

Calculate storage per site. Each stretched disk group maintains a remote synchronous copy, so usable capacity must reflect both sites, rebuild headroom and performance reserve. A 50 per cent efficiency factor is a starting point, not a sizing answer.

Balance CPU, memory and network headroom because vSAN traffic, HA restart and maintenance can coincide. Validate disk-group, cache and policy combinations with IOPS, latency and queue-depth tests. Keep spare capacity so host loss does not trigger a long rebuild.

The witness supplies quorum, not user data. Place it in an independent failure domain according to the supported topology, and avoid making it depend on the same WAN path as one site. The witness, vCenter, identity and time services must remain reachable in the promised failure sequence.

Compare resilience patterns

The practical choice is between local resilience, replicated independent clusters and a stretched storage domain:

Design	Local performance	Site-loss recovery	WAN profile	Main trade-off
Single-site vSAN with backups	Strong while the site is healthy	Restore or rebuild from backups	Low steady traffic	Recovery depends on backup speed and application
Independent clusters with replication	Strong in each site	Depends on replicated data and application	Replication traffic only	Two stacks and consistency work
vSAN stretched cluster	One stretched storage domain	Protected VMs fail over with current storage	Continuous synchronous traffic	WAN tuning, quorum and shared dependencies

A stretched cluster suits workloads that need VM-level restart with current storage, provided they tolerate WAN-sensitive IO. Independent clusters suit systems with deliberate application replication, such as a database with its own standby. Test both against the same RTO and data-loss budget before committing to links.

Deploy the cluster and dependencies

Build the foundation first. Confirm supported ESXi, vCenter and vSAN versions, configure vSAN and vSphere networks, and establish the witness using the release’s supported design. If NSX is used, stretch or replicate its control plane and traffic path deliberately.

Time, naming and access must survive the same event. Use resilient DNS and NTP, synchronise identity, and keep vCenter reachable from both sites. Logs and automated maintenance windows need authoritative time rather than manually adjusted offsets.

Protect the platform with encryption, role-based access, off-site backups and management-configuration backup. For the operator’s perspective and experience behind this approach, Jonathan Frappier’s professional background adds context on infrastructure and automation.

Test failure and recovery

Validation starts with a baseline. Record vSAN health, device latency, resource pressure, replication state and application performance. Exercise host loss, storage-path loss, WAN-circuit loss and site loss. Planned maintenance-mode tests are useful, but abrupt traffic removal exposes behaviour that orderly shutdown can hide.

Measure service recovery, not merely cluster convergence. Start protected applications, reconnect dependencies, verify DNS and identity, and time each transaction path. Database consistency, licence servers and backup catalogues can dominate RTO even when storage remains healthy.

Repeat tests after fabric, firmware or policy changes and schedule exercises through the year. Australian managed service providers can run this operationally, but clients must define priorities and acceptance criteria. Rerun after significant expansion.

Put the plan into practice

Turn the design into an evidence pack. Download the free PowerCLI tools, run them against representative sites, and retain latency, packet-loss, capacity and recovery results alongside the architecture.

Start with a measured path test and clear RPO/RTO, then build the witness, storage policy and failover runbook from that evidence. Run the site-loss rehearsal until recovery is repeatable under realistic load.