vSAN stretched cluster requirements: witness, latency, bandwidth and what happens when a site fails

vSAN stretched cluster requirements at a glance

A vSAN stretched cluster needs two data sites, normally with the same number of hosts, and a witness host at a third site. Broadcom’s VCF 9.1 documentation, updated on 5 October 2026, says the data sites “must have a network latency of no more than five milliseconds (5 ms) round trip (RTT)”, and the vSAN 8.0 pages give the same limit. The witness must be less than 200 ms RTT from the data sites. Broadcom’s vSAN Stretched Cluster Guide for 9.1, dated 5 May 2026, adds the bandwidth figures and a size range from 1+1+1 to 20+20+1 hosts.

Broadcom TechDocs for VCF 9.1 (2 September to 5 October 2026) and vSAN 8.0 (9 September 2026); vSAN Stretched Cluster Guide for 9.1, which focuses on ESA (5 May 2026).

The witness host and the vSAN witness appliance

A stretched cluster has three fault domains: the preferred site, the secondary site and the witness. The witness stores “only metadata such as witness components” and acts as tie-breaker when the network between the data sites is partitioned. It can be a physical host or an ESX host in a VM, runs no virtual machines and serves one stretched cluster only, while two-node clusters can share a witness. The appliance belongs on “a third site independent of the two sites”, sharing no physical resources with either, and comes in separate versions for ESA and OSA (9.1 documentation).

Broadcom TechDocs, “Deploying a vSAN Witness Appliance” for VCF 9.1 (10 September 2026) and vSAN 8.0 (9 September 2026); one set of component limits per size, listed above both tables and estimated for standard VM configurations; the OSA table calls the medium size Normal.

Do not snapshot or back up the witness host, and replace it if it fails (vSAN 8.0 design considerations). In 9.x a physical host that is the witness, or runs the witness appliance, must be tagged with esxcli vsan witness license set and the option --enable true, then rebooted, before it joins the vCenter inventory, also after an upgrade from 8.x; otherwise it does not receive the witness licence (KB 401072).

Latency, bandwidth and network design between the sites

With site mirroring, each object’s data is written to both sites synchronously, so every write waits for the other data site. The stretched cluster guide calls 10 Gbps between the data sites “the supported minimum”. With site read locality enabled, as the guide asks, “read operations will always come from the site of the VM instance requesting the read”, so size the link from the peak write rate of the mirrored VMs, plus resynchronisation after a failure. Towards the witness, about 2 Mbps per 1,000 components comes to some 44 Mbps for a witness at the medium size’s 21,833 components, by our arithmetic.

Broadcom’s 9.1 network design supports stretched Layer 2 or routed Layer 3 between the data sites and recommends Layer 3 “for fault isolation and easier troubleshooting”. How far apart 5 ms lets the sites be, and which regional risks they still share, is in our guide to how far a DR site should be from the primary data centre.

Storage policies, site affinity and raw capacity

Site protection is set per VM in the storage policy. Site disaster tolerance offers Site mirroring - stretched cluster, which replicates object data to both sites, or None - keep data on Preferred or on Secondary, which keeps an object in one site; Failures to tolerate then sets “the number of failures to tolerate within each site”. When VCF stretches a cluster, SDDC Manager switches its policy to Site mirroring - stretched cluster.

For ESA with the Auto-RAID rule of 9.1, Broadcom’s design guide of 5 May 2026 describes a mirror between the sites plus RAID-5 in each site with 3 to 5 hosts per site, or RAID-6 with 6 or more, both at 3.0 times the object size in raw capacity. Below three hosts per site there is no protection inside a site (2.0 times), so one failed host leaves the affected objects with only the copy in the other site. Auto-RAID is documented for ESA only; on OSA you set Failures to tolerate yourself, and the 9.1 stretched cluster guide refers OSA users to its earlier editions. The space efficiency paper of 11 May 2026 says stretched clusters “cut the effective capacity in half” against a single-site cluster, and global deduplication in 9.1 does not support them. RAID rules by architecture are in our vSAN ESA vs OSA comparison.

DRS “must” rules hold a VM on one site, and the guide names them for VMs that “do not need site-level resilience or use their own application-level replication for resilience”, which is where keep-data policies fit, for example domain controllers with one in each site.

vSphere HA and DRS settings for a stretched cluster

Broadcom’s stretched cluster guide and vSAN 8.0 design considerations give these settings:

1. Enable vSphere HA and set admission control to 50% for CPU and memory, so the surviving site can restart every VM of the failed one.
2. Set the response for host isolation to Power off and restart VMs.
3. Point das.isolationaddress0 and das.isolationaddress1 to an IP address on the vSAN network in each site, and set das.usedefaultisolationaddress to false.
4. Disable HA datastore heartbeats unless a datastore outside vSAN is available.
5. Enable DRS with a host group and a VM group per site, linked by VM-Host “should” rules.
6. Keep site read locality enabled.

“Should” rules keep VMs on their site in normal operation and allow them “to run in the other site in the event of an HA event like a site outage”. Since vSAN 7.0 Update 2, DRS can run fully automated, and after a failed site returns it waits until a VM’s data is fully resynchronised before moving it back. Per the vSAN 8.0 design considerations, vSphere Fault Tolerance works in a stretched cluster only for VMs whose policy keeps data on one site.

What happens when a site, the link or the witness fails

Broadcom TechDocs for VCF 9.1 and vSAN 8.0 (September and October 2026); vSAN Stretched Cluster Guide for 9.1 (5 May 2026).

VMs of a failed site restart on the other site as after a power loss, and no write acknowledged on a mirrored object is lost. Adaptive Quorum Control, from vSAN 7 Update 3, recalculates the votes after a site outage within “a few seconds to a few minutes”, and “will not protect against a simultaneous double failure of a data site and a witness”.

Site maintenance mode and site takeover in VCF 9.1

VCF 9.1 adds site maintenance mode for ESA and OSA stretched clusters, with vCenter and ESX hosts on 9.1 or later. A VCF blog post of 1 August 2025 had announced it and manual site takeover for VCF 9.0, takeover first in limited availability through a Technical Qualification Request. The 9.1 release notes list site maintenance as new, and Broadcom’s availability paper of 23 September 2026 calls both new in 9.1. Broadcom warns that moving all hosts of a site into maintenance one at a time “can cause inaccessibility of objects, if the active site fails”. The site operation brings the site’s components to one point in time, powers off VMs whose data is local to it and migrates workloads to the active site. If the active site then fails beyond repair, site takeover recovers the objects “to an older point in time”, by our reading the start of the maintenance, so later writes are lost. Broadcom’s guide makes manual site takeover available for all stretched clusters in 9.1, while the 9.1 documentation excludes vSAN storage clusters.

Our VMware optimisation service covers version and architecture updates of vSphere, vSAN, NSX and VCF in agreed maintenance windows with a rollback plan. Send us your hosts per site, the measured RTT and your vSAN version through the form below.

Setting up the cluster, and what VVF and VCF include

Without SDDC Manager, the vSphere Client sets it up under Configure, vSAN, Fault Domains, Configure Stretched Cluster, with a witness host outside the cluster. In VCF, the SDDC Manager API stretches clusters with the same number of hosts in both availability zones, and the default management domain cluster must be stretched before any workload domain cluster. VCF cannot stretch clusters that share a vSAN storage policy, contain DPU-backed hosts, mix subnets within an availability zone or, on ESA, use global deduplication. ESA stretched clusters have been fully supported in VCF since 5.2, per the vSAN 8.0 Update 3 release notes (June 2024).

Broadcom’s feature comparison for 9.1.1 (30 September 2026) marks stretched clusters for vSphere Foundation (VVF), VCF Edge and VMware Cloud Foundation (VCF). The programme documents of June 2026 include 0.25 TiB of vSAN per VVF core and 1 TiB per VCF core, with add-on TiB above that. The vSAN programme document of May 2026 counts “all raw physical storage that is claimed by Software on all the Servers in the vSAN Cluster”, which in a stretched cluster includes both sites. At the ESA Auto-RAID factor of 3.0, 10 TiB of VM data needs 30 TiB of licensed raw capacity before compression and spare capacity, by our arithmetic. Other differences between the products are in our VVF vs VCF comparison.

When a stretched cluster fits and when asynchronous DR is enough

A stretched cluster suits systems that must lose no acknowledged write when a site fails and must run again within minutes, through an HA restart. Our disaster recovery page lists an RPO of about zero and an RTO of minutes as typical figures for an active-active synchronous cluster and notes that it doubles infrastructure and budget. Sites within 5 ms of each other can share regional risks, and mirroring copies a corrupted or encrypted block at once, so backups and a distant asynchronous copy remain necessary. Systems that tolerate minutes of data loss and an hour or two of recovery are served by asynchronous replication; how to tier them is in our guide on how to choose RPO and RTO.

Our disaster recovery service replicates virtual machines with Veeam from a 15-minute interval to a recovery site in Baltneta’s Tier-3 data centres in Lithuania. Tell us which systems need a recovery point of zero and which can wait.

What we do

Eurokommerz holds the contract and supplies the hardware and VMware / Broadcom licensing, with engineering by our partner Vixen.UNO under one European contract. Under VMware optimisation, Vixen.UNO audits the estate and its licences and delivers version and architecture updates of vSphere, vSAN, NSX and VCF in agreed maintenance windows with a rollback plan at every stage, then support under an agreed SLA. Our disaster recovery service is built for critical systems without the budget for a second data centre, with RPO and RTO fixed in the SLA; if a system needs zero RPO, that is active-active synchronous clustering, a different class of solution and budget, and we say so on the first call. The first call is free of charge; the price of the technical assessment is fixed before work begins.

FAQ