Stretched Cluster With No Third Site
Acme Health is planning a VxRail stretched cluster between two data centers 10 km apart. The customer has ordered four VxRail E560 nodes-two per site-and no additional hardware. Round-trip latency between sites is 1.2 ms; each site has a 10 GbE L3 link with 8 Gbps available. The customer wants vSAN storage to survive a full site failure and insists that no third site is available. They also require the witness to be as local as possible and ask whether one of the two data centers can host it. The VxRail version is 7.0.240. The network team has allocated separate management, vSAN, and vMotion VLANs, but the vSAN VLAN is stretched L2 across sites. The project manager wants to know if the design is approvable and what must change before ordering switches.
1. Is a 2+2 stretched cluster without a witness acceptable? What is the minimum viable topology?
Read the worked answer
No. A vSAN stretched cluster is a 2+2+1 design: two nodes in each data site plus a witness in a third fault domain. The four data nodes alone cannot provide quorum after a full site failure, because the surviving site still needs the witness to establish majority. The 1.2 ms RTT is within the usual 5 ms RTT limit, so latency is not the blocker; topology is.
Placing the witness in site A or site B creates a correlated failure. If that site fails, the witness is lost along with half the data nodes, and the remaining site may not have quorum. VMware permits a witness in one of the two data sites only as a non-preferred workaround; it is not the design to approve for a VxRail production stretched cluster. Minimum viable topology: 2+2 VxRail data nodes plus a witness host/appliance in a third location, with the witness reachable over L3 from both sites. If no third location exists, do not approve stretched cluster; propose a single-site cluster with backup/replication instead.
2. What network changes are required before deployment?
Read the worked answer
Keep the vSAN VLAN stretched L2 between the two data sites, because the data nodes must share the vSAN fault-domain network. Put the witness on an L3-reachable network and confirm firewall rules for witness-to-site traffic. The inter-site link must carry vSAN and witness traffic with enough bandwidth for resync and rebuild; 8 Gbps is workable but must be monitored.
Set MTU 9000 end-to-end for vSAN and vMotion, including the inter-site path; a 1500 MTU on one side will break jumbo vmkping and can fail deployment validation. Keep management at 1500 unless the customer standardizes jumbo everywhere. Do not rely on a simple ping: validate with vmkping -s 8972 -d from each vSAN VMkernel to the remote site and to the witness. Confirm that the L2 stretched vSAN VLAN does not create unexpected ARP or broadcast issues, and that the witness network is not accidentally stretched into the same fault domain.
3. The customer proposes a virtual witness VM in the management cluster at site A. What is your risk assessment?
Read the worked answer
Reject it for a production stretched cluster. A witness VM in the site A management cluster is inside the same failure domain as the site A data nodes. If site A loses power, cooling, or management network, the witness is lost at the same time as the site A vSAN nodes. The surviving site B may lose quorum even though its data nodes are healthy, which defeats the purpose of stretched clustering.
A witness must be in a third fault domain with independent power, network, and management. It also should not depend on the production vCenter or management cluster it is protecting. If the customer cannot provide a third site, document the risk and propose a non-stretched design. Do not accept the argument that the witness is only metadata and therefore can be local; quorum is exactly what makes the surviving site usable.