Five-Minute RPO on a Twelve-Millisecond Link
Two sites 400 km apart are linked by a 1 Gbps fiber path with 12 ms round-trip latency and 35% peak utilization. Site A runs a 12-node AHV cluster hosting 300 VMs; site B holds an identical idle cluster for disaster recovery. For 40 tier-1 VMs the business requires RPO of 5 minutes or less and RTO of 30 minutes or less. At peak those VMs generate roughly 1.8 TB of changed data per hour. Today they are protected by an hourly async protection domain, and the last DR test took four hours to bring up the VMs because of manual runbook steps and DNS changes. The architect proposes switching the 40 VMs to Nutanix NearSync to reach the 5-minute RPO, arguing the link is 'mostly idle' and that compression will shrink the change rate. The database team confirms the 1.8 TB figure already excludes backup traffic.
1. Is NearSync a viable choice for these 40 VMs? Justify the conclusion against the stated constraints.
Read the worked answer
No - it fails on latency before bandwidth even matters.
Nutanix NearSync schedules frequent snapshots and replicates the deltas, but it is a synchronous-adjacent technology: it is designed for links with round-trip latency in the low single-digit milliseconds, with the supported limit around 5 ms RTT. Metro Availability carries a similar latency limit. A 12 ms RTT path is roughly double that ceiling, so NearSync would either be rejected in design review or would deliver erratic RPOs as replication falls behind.
Secondary problems with the proposal:
- The link is not idle. 35% utilized at peak leaves about 65% of 1 Gbps, roughly 80 MB/s or ~290 GB per hour of headroom. The workload changes 1.8 TB per hour (about 500 MB/s sustained), so it needs roughly 4 Gbps just to keep up with change rate.
- Compression is not a plan. It may reduce bytes on the wire, but assuming a specific ratio for unknown data is exactly how DR designs fail in production.
The architect has chosen the feature that matches the stated RPO without checking whether the WAN can carry it. That is the error the exam wants you to catch.
2. Assuming async replication remains the mechanism, what RPO is realistically achievable today, and show the arithmetic.
Read the worked answer
Arithmetic first.
- Change rate: 1.8 TB/hour = 1800 GB / 3600 s = 0.5 GB/s = 500 MB/s ≈ 4 Gbps.
- Available WAN: 1 Gbps × 65% headroom ≈ 650 Mbps ≈ 81 MB/s ≈ 290 GB/hour.
Conclusion: the link can absorb roughly 290 GB per hour against 1.8 TB produced per hour - about 16% of the change rate. Snapshots will queue, each replication run will take far longer than the interval, and any RPO you advertise will be missed under load.
A realistic calculation for a candidate interval is: bytes changed in the interval must fit inside the available hourly throughput. Even a 15-minute schedule implies ~450 GB per interval, which needs about 1.5 hours to ship at 81 MB/s. Nothing at minute-scale RPO survives that.
The practical RPO today is therefore hours, not minutes, and even that depends on the database remaining quiesced long enough for a consistent snapshot. The current hourly schedule is already nominal rather than achieved; the DR test result supports that reading.
3. What would you recommend to close the gap between the business requirement and what the infrastructure can actually deliver? Address RPO and RTO separately.
Read the worked answer
RPO (5 minutes):
- Add bandwidth: a 10 Gbps path with low utilization is the cleanest fix, but it alone does not solve the latency requirement for NearSync unless the path is also under ~5 ms RTT.
- If the requirement is genuinely minutes, the architecture has to change: shorten the distance (Metro-style stretched cluster within latency limits) or reduce change rate by tiering data, splitting the 40 VMs into a smaller critical set, or moving the write-heavy database to an architecture that replicates at the application layer.
- If neither is possible, renegotiate the RPO in writing rather than promising it. An honest 60–120 minute RPO with tested restores beats an untested 5-minute claim.
RTO (30 minutes):
- The four-hour test was dominated by manual steps, not by data transfer. Automate: pre-staged VM shells, protection domain or Leap runbooks, DNS and IP re-mapping, and a documented start order.
- Test the runbook on a schedule and measure it; RTO is a process property as much as a replication property.
Separate the two conversations. Bandwidth fixes RPO; automation fixes RTO; conflating them is why neither gets funded.