Replication and Disaster Recovery
Domain 4 tests replication and DR design: synchronous versus asynchronous, topology, failover and failback, and how Dell products implement recovery point objectives. Expect questions that compare SRDF, RecoverPoint, and Data Domain replication.
Core rules
- Synchronous replication acknowledges the write only after the remote site has it. RPO is effectively zero, but latency and distance limits apply. Asynchronous replication acknowledges locally and ships changes later; RPO equals the replication interval or lag.
- Topologies include unidirectional, bidirectional, cascade, fan-out, and active-active. A consistency group keeps related volumes or VMs in a crash-consistent order.
- SRDF provides array-based replication for PowerMax/VMAX environments. SRDF/Sync is synchronous; SRDF/Async is asynchronous; SRDF/Metro provides active-active stretched configurations; SRDF/Global supports cascaded DR.
- RecoverPoint uses a journal to provide continuous data protection and any-point-in-time recovery for local and remote copies. RecoverPoint for VMs is hypervisor-based and protects VM-level consistency groups.
- Data Domain replication can replicate MTrees or collections. It sends deduplicated data, so WAN bandwidth is closer to the change rate than the full data size.
- Failover brings up the secondary site; failback returns to the primary. A DR runbook must cover DNS, IP changes, application dependencies, and validation.
Worked example
An application writes 500 MB/s and the primary-to-secondary round-trip latency is 100 ms. Synchronous replication would put about 50 MB of data in flight (500 MB/s x 0.1 s) and add latency to every write, which may violate the application SLA. Asynchronous replication with a five-minute interval gives an RPO of up to five minutes and needs bandwidth for 500 MB/s of change plus overhead, not for the full 100 TB database. If the business requires zero RPO, SRDF/Metro or synchronous replication with a short-distance second site is the better fit, paired with backups for logical corruption.
Traps that cost marks
- Assuming replication replaces backup.
- Ignoring latency and distance in synchronous designs.
- Sizing replication bandwidth for full data instead of change rate.
- Forgetting consistency groups for multi-volume applications.
- Testing failover but never failback.
- Overlooking DNS and application dependency changes.