Deploying VMware vSAN stretched cluster for disaster recovery
A VMware vSAN stretched cluster places virtual machine storage across two data sites while using a third location as a witness. Each site contributes hosts and local disks, and vSAN maintains object availability according to storage policies. This design can keep workloads running when an entire site loses power, connectivity, or access.
The architecture is useful for Australian organisations that need resilient infrastructure without maintaining a fully separate disaster recovery platform. It suits metro deployments such as Sydney–Canberra or Melbourne–Geelong, provided the sites have suitable latency, independent utilities, and reliable carrier connectivity.
Why use a stretched vSAN design
Traditional vSphere High Availability protects against host failure, but it cannot restart workloads if the entire facility is unavailable. A stretched cluster adds site-level protection by placing storage components in separate fault domains. If one data site fails, the surviving site can continue operating with the witness providing quorum.
This approach can reduce recovery time objectives because virtual machines do not need to be restored from backup before starting. It also avoids maintaining an idle duplicate cluster, although backups remain essential for recovering from ransomware, accidental deletion, and logical corruption. A stretched cluster is availability infrastructure, not a replacement for a backup strategy.
Plan the sites and witness
The two data sites should have genuinely independent failure characteristics. Separate buildings, power feeds, cooling systems, network paths, and physical access are preferable. Placing both sites in the same basement or within the same flood-prone precinct defeats much of the design. In Brisbane, flood exposure may deserve as much attention as distance; in parts of New South Wales and Victoria, bushfire risk can affect both facilities and access routes.
The witness should be deployed at a third failure domain, such as a small office, colocation facility, or cloud-connected site. It should not run inside either data site. A witness appliance contains metadata and quorum information rather than a full copy of virtual machine data, so its capacity requirements are modest, but it still needs dependable connectivity and power.
Validate networking and hardware
The inter-site network must meet the latency, bandwidth, MTU, and packet-loss requirements for the vSAN release in use. VMware and Broadcom documentation should be treated as authoritative because limits and supported configurations can change between versions. In general, low and predictable round-trip latency between data sites is critical, while the witness can be farther away within supported limits.
Use redundant links and confirm that the network can carry vSAN, vMotion, management, and virtual machine traffic without congestion. Test jumbo frames end to end if they are part of the design; a single interface or carrier device using a smaller MTU can cause difficult-to-diagnose failures. Australian organisations often use Telstra, Optus, Vocus, or specialist carriers for private Ethernet and SD-WAN services, but the provider name matters less than documented service levels and measured performance.
Hosts, controllers, flash devices, capacity devices, firmware, and drivers must appear on the VMware compatibility lists. Keep hosts symmetrical between sites where possible. Confirm that the selected vSAN architecture, whether Original Storage Architecture or Express Storage Architecture, is supported for the hardware, vSphere version, and intended storage policy.
Configure fault domains and policies
Create a vSAN cluster in vCenter and define the two data-site fault domains before placing production workloads. Assign each ESXi host to the correct site, then configure the witness host or witness appliance separately. The cluster must have accurate DNS, time synchronisation, certificates, routing, and host naming before storage configuration begins.
Storage policies determine how objects are protected. For a stretched design, select a site-level failure tolerance policy and define the required number of failures to tolerate. Consider RAID-1, RAID-5, or RAID-6 based on capacity, performance, rebuild behaviour, and licensing. A policy that protects against a host failure may not protect against a complete site failure, so validate the resulting object layout in the vSAN health and capacity views.
Use site affinity deliberately. Critical workloads may be configured to run primarily at the preferred site, while selected services remain available at the secondary site. Keep management, identity, DNS, monitoring, and backup services available after a site loss. An Australian business with offices in Perth and Sydney should also account for the significant WAN distance and operating cost before attempting a stretched topology.
Deploy and test the cluster
Before production, run vSAN health checks, storage performance tests, and controlled failure tests. Disconnect a host, fail an uplink, stop a vSAN service, and simulate loss of the inter-site path while observing quorum and object compliance. Test both data-site failures independently. Do not assume that a successful host failure test proves site resilience.
Document the recovery sequence for network teams, application owners, and service desk staff. Include who can declare a site failure, how DNS or load-balancer traffic is redirected, and how the failed site is isolated before it returns. Radware appliances, firewalls, and external routing may require separate changes even when vSphere automatically restarts workloads.
Schedule maintenance around local operating conditions. Melbourne and Sydney teams may work across different daylight-saving rules from Queensland, while Perth operations often span a large time-zone gap. Record times in UTC in change tickets, and confirm carrier maintenance windows rather than relying on informal local times.
Operate, monitor, and recover safely
Monitor vSAN health, capacity consumption, resynchronisation traffic, latency, witness connectivity, and policy compliance. Alert on reduced redundancy before another failure occurs. Keep sufficient free capacity for repairs and resync operations; a cluster that is full may remain online but become difficult to heal safely.
Backups should be stored outside both data sites, with at least one protected or offline copy. Test file recovery, full virtual machine recovery, and application-consistent recovery at planned intervals. Australian privacy and data-residency requirements may influence whether backup copies are held in Sydney, Melbourne, or an overseas region, so involve legal and compliance teams before selecting a provider.
| Architecture | Site failure protection | Recovery method | Operational burden | Typical fit |
|---|---|---|---|---|
| Standard vSphere cluster | Host failure within one site | HA restart and shared storage recovery | Lower | Single data centre |
| Separate DR cluster | Full site failure | Replication, orchestration, or backup restore | Medium to high | Larger recovery distance |
| vSAN stretched cluster | Full failure of one data site | Workloads continue or restart in the surviving site | Medium | Metro or low-latency sites |
| Backup-only recovery | Data loss and site loss | Restore from backup | Lower infrastructure cost, longer outage | Small environments or archival services |
A successful stretched deployment depends on disciplined design more than on the cluster wizard. Validate distances, carrier performance, hardware compatibility, application dependencies, and failure procedures before production workloads are placed on the platform. When those controls are maintained, vSAN can provide a practical disaster recovery layer for hybrid infrastructure across Australia.