VMware vSAN stretched clusters across Australian sites
Building a VMware vSAN stretched cluster across two sites creates a single fault-tolerant storage environment for virtual machines hosted in separate data centres. It can preserve access to storage through a complete site failure, but the design depends on WAN behaviour, capacity and application recovery rather than replication alone.
The topology combines two vSAN clusters with site-to-site synchronous replication and a small vSAN Witness appliance in a third failure domain. The witness does not hold user data; it supplies quorum information that helps the surviving site avoid unsafe split-brain decisions. This permits an active-site model with controlled failover instead of merely copying virtual disks between locations.
These distinctions are important across Australia, where carrier coverage, latency and physically diverse fibre routes differ markedly between metropolitan and regional locations. Support teams also work across Australian Eastern and Central time zones, making clear ownership and rehearsed recovery procedures essential parts of the architecture.
Set recovery goals and isolate failure domains
Document recovery point and recovery time objectives before choosing equipment. Synchronous replication protects acknowledged writes from the modelled failure, but transaction state, database quorum and application consistency determine whether services can safely resume. A storage-level recovery claim does not automatically protect every workload from data loss.
Place each vSAN cluster in a genuinely independent location. Separate server rooms in one building share power, cooling and carrier entry points, so they form one infrastructure failure domain. Seek separate utility feeds, physical security, fire protection and diverse network paths rather than relying on a second rack across the corridor.
House the witness in a third failure domain with supported low-latency connectivity to both clusters. A colocation facility in another metropolitan location can qualify when it meets the relevant latency and availability requirements; geographic distance alone neither disqualifies nor validates it. Price the added WAN and operational complexity against the workloads that genuinely need site-level resilience.
Engineer a WAN that preserves storage latency
Provide vSAN traffic with a supported, redundant IP network, preferably separated from user and backup flows. Follow current VMware guidance for vMotion and management traffic, and avoid placing storage replication on an uncontracted consumer connection. Test packet loss, congestion and path reconvergence because carrier failover can disrupt vSAN even when the link returns quickly.
Measure round-trip latency, jitter, packet loss and busy-hour behaviour against the limits published for your specific vSAN release. Record 95th and 99th-percentile results, not averages alone. A Sydney–Melbourne fibre route may fit the supported envelope, while a Perth-to-eastern-Australia path needs separate testing and might not. Cross-check those assumptions against the Chumacraju technical resource.
Regional carrier choices and physically diverse fibre routes can be limited, so map shared trenches, exchanges, power feeds and repair arrangements. Consumer NBN plans are not substitutes for an enterprise interconnect with explicit service levels. If a route cannot maintain the supported latency envelope, use a clustered design with replication rather than labelling it a stretched cluster.
Configure policy, capacity and management paths
Select a vSAN storage policy containing the supported stretched-cluster rule set. Confirm the required copy and failure-tolerance behaviour, then verify the effective policy on every protected virtual disk. Do not assume a generic or default policy protects data across sites; unsupported combinations can leave replication or accessibility incomplete.
Provision each cluster for the full workload it must serve during failover, plus rebuild and resynchronisation headroom. Account for thin provisioning, snapshots, swap and log growth. Capacity at the remote site must support the protected data set without relying on space that the surviving site still requires.
Check host connectivity to local and remote storage networks, supported routes to the witness, and consistent DNS, certificates, NTP and identity services. vCenter manages configuration but does not carry the vSAN data path. A management-plane outage can therefore delay recovery even when storage remains available.
Exercise failure scenarios and runbooks
Test one host, one storage-network path, one disk or controller, the witness, the WAN and then an entire site. Keep failures isolated so each result has a clear cause. Record whether storage stays accessible, whether the surviving cluster assumes the expected role and which virtual machines resume automatically.
Test applications separately from vSAN. Quorum-based databases, clustered services and licence-dependent systems can fail or require arbitration even when storage is healthy. Include directory services, DNS, time synchronisation and backup catalogues in the runbook. If replicated data includes personal information, map access and support procedures to the Australian Privacy Principles and Notifiable Data Breaches scheme under the Privacy Act 1988.
Monitor latency, jitter, loss, route changes, vSAN congestion and rebuild progress, with alerts tied to service impact. Repeat site-loss exercises and give duty officers clear failover authority. For teams handing work between Australian Eastern and Central offices, record events in UTC while displaying local time, and name the accountable operator in every handover.
Validate the model in a home lab
A home lab can rehearse the failure model without reproducing a carrier-grade WAN. The IT Diversified home lab provides a practical base for hosts, virtualisation and storage practice. Model two sites and the witness as separate network segments, then use routing policy or traffic shaping to introduce latency, jitter, loss and link loss.
Treat the exercise as procedure validation, not proof of production support. Test application dependencies, monitoring, recovery steps and operator communications, and record how routing and storage behave when one site disappears. Keep virtual-machine boot order and database recovery separate from storage tests so they do not imitate or conceal a vSAN fault. Production approval still needs representative hardware, supported versions and a design that has survived the failure tests.