Protection domain design for a 15-minute RPO and SQL consistency
A financial services company runs an eight-node AHV cluster at its primary site and a DR cluster 600 km away. Protection domain PD-FIN protects 120 VMs, including a three-node SQL Server Always On cluster and 40 general application servers. The current async replication schedule runs every four hours; the replication window takes 5.5 hours and sometimes overlaps the next snapshot. Tier-1 RPO is 15 minutes, tier-2 RPO is four hours. During the last DR test, PD-FIN was restored to the latest snapshot, but the SQL databases needed two hours of log recovery because the snapshot was crash-consistent. The team proposes enabling NearSync for all 120 VMs and reducing snapshot retention from seven days to two days to shorten the window. The network team confirms a dedicated 2 Gbps replication link with 35 ms round-trip time. What should you recommend?
1. Is NearSync for all 120 VMs appropriate? Explain the trade-off.
Read the worked answer
NearSync for all 120 VMs is not appropriate. NearSync gives a low RPO by replicating much more frequently, but it increases snapshot frequency, metadata load, and bandwidth demand. The current 5.5-hour window for a four-hour schedule already shows the link cannot keep up with the change rate. Adding 120 VMs to NearSync would likely make the backlog worse and could affect production. Use NearSync only for the tier-1 VMs that truly need a 15-minute RPO, and keep tier-2 on async replication at four hours. The 2 Gbps link and 35 ms RTT may support a small tier-1 set, but validate with actual change rate, not VM count. Also, NearSync is not a substitute for SQL application consistency; it replicates the same crash-consistent snapshots faster.
2. How should protection domains and schedules be restructured?
Read the worked answer
Split PD-FIN into at least two protection domains: PD-T1 for tier-1 VMs and PD-T2 for tier-2 VMs. Put the SQL Always On cluster and its dependent app servers in PD-T1 with a 15-minute or better NearSync schedule; keep the 40 general app servers in PD-T2 on a four-hour async schedule. Stagger schedules so PD-T1 and PD-T2 do not overlap. For SQL, enable Nutanix Guest Tools VSS quiescing if supported and test an application-consistent snapshot. Always On gives database-level protection, but it does not protect the whole app group; the PD snapshot should include all VMs in the same consistency group. If VSS is not validated, use SQL log backups or log shipping and document the recovery time.
3. Should retention be cut to two days, and what should the next DR test prove?
Read the worked answer
Do not reduce retention from seven days to two just to shorten the replication window. Retention controls how many snapshots you keep, not how much changed data must cross the link. Shortening it may violate policy and reduce recovery points. Instead, right-size retention per tier based on compliance, keep enough daily and weekly points to meet the DR runbook, and monitor the replication window after splitting PDs. For the DR test, restore PD-T1 and PD-T2 separately, measure actual RPO and RTO, validate SQL consistency with DBCC checks, and record whether the 15-minute target was met. Test a failover during a low-change period and again during peak change to prove the design.