The Stretched Cluster That Cannot Stretch
A retailer asks you to sanity-check a disaster-recovery design before it goes to their board. Two sites are 40 km apart, joined by a 1 Gbps link with a measured 12 ms round-trip time. Tier 1 is 120 VMs with 4 TB of daily change, RPO 15 minutes, RTO 2 hours. Tier 2 is 300 VMs with 12 TB of daily change, RPO 24 hours, RTO 48 hours. The proposal: one stretched cluster spanning both sites with vSAN, so that "everything is protected and there is no failover at all." The storage arrays at the two sites come from different vendors. The inter-site link is shared with core banking replication that already consumes about 200 Mbps. The board meets tomorrow morning.
1. Is the Tier 1 replication requirement feasible on this link as described? Show the bandwidth reasoning and name the figure you would demand before answering yes.
Read the worked answer
Start with steady-state arithmetic:
- 4 TB per day = 4,194,304 MB / 86,400 s = 48.5 MB/s, about 388 Mbps of average change.
- Usable link: 1 Gbps minus 200 Mbps of banking traffic minus protocol overhead leaves roughly 700-800 Mbps on average.
So the average fits at about half the available headroom. That is not the answer to the question, though, because replication must satisfy the RPO in the worst window, not the average. A 15-minute RPO means 15 minutes of change must land within about 15 minutes; at 100 MB/s achievable, roughly 41 GB of change takes about 7 minutes, so the design survives peak change up to about twice the daily average.
The figure to demand before signing off: peak change rate measured in 15-minute windows across at least one week, including month-end batch and backup windows. Also size the initial full sync separately, and check whether throttling rules or network I/O control can protect the banking traffic when a sync is running.
2. Evaluate the stretched-cluster proposal against these facts. What specifically disqualifies it?
Read the worked answer
Three independent problems, any one of which is enough:
- Round-trip latency. 12 ms RTT substantially exceeds the roughly 5 ms site-to-site guidance for stretched clusters. Every write on the surviving side pays inter-site latency for metadata coordination, so the failure mode is not "no failover" - it is slow writes and stalled operations all day, every day.
- Witness site. A two-site stretched cluster needs a third independent site for the witness to break ties. The design names two sites and no third location, so a link partition leaves both sites unable to decide which one should survive.
- The premise itself. "No failover at all" is a claim about mechanism, not about outcomes. Tier 2 has an RPO of 24 hours and an RTO of 48 hours. Paying stretched-cluster latency to protect workloads with those tolerances is over-engineering applied to the wrong tier.
The different array vendors are irrelevant to a vSAN stretched cluster but very relevant to the array-replication alternative, which is a point worth making because it tells you the proposal was assembled without comparing options.
3. Propose an architecture for each tier and outline how you would present it to the board in one slide.
Read the worked answer
Tier 1 (RPO 15 min, RTO 2 h): asynchronous replication every 15 minutes, either array-based if the vendors can be aligned or per-VM with vSphere Replication, plus a documented, tested failover runbook. Orchestrated recovery with defined priority groups, because 120 VMs will not restart usefully in an arbitrary order. Verify that dependent services (directory, DNS, database) come up in sequence.
Tier 2 (RPO 24 h, RTO 48 h): nightly replication or backup and restore to the secondary site, with the restore path exercised at least quarterly. Cheaper by an order of magnitude and entirely adequate.
One-slide framing for the board: two rows, one per tier, each with RPO, RTO, mechanism, annual cost, and the residual risk in plain language. Then the headline: the stretched-cluster option buys failure tolerance the business did not ask for, at the cost of application latency and a witness site they do not own. Offer the honest trade: if they want near-zero RPO for Tier 1, the decision is about application redesign and synchronous-capable storage, not about buying a stretched cluster.