SRDF Remote Replication Operations
SRDF questions test the replication modes, how pairs are created and controlled, and what each state means to a host. The recurring theme is direction: which side is R1, which is R2, and which command moves data where.
Modes
- SRDF/S is synchronous: a write is acknowledged only after the R2 acknowledges, giving zero RPO but adding link latency to host response time.
- SRDF/A is asynchronous: writes are grouped into delta sets and cycled to the R2, giving a bounded RPO set by cycle time and link bandwidth.
- SRDF/Metro is active/active: both arrays present the same device to hosts, with a witness array (or vWitness) for tie-break and a bias attribute deciding which side survives a split.
- Adaptive copy disk or write-pending is used for initial synchronization to avoid saturating the link, then the group is switched to S or A.
Objects and setup
- Pairs are R1/R2 with identical size and emulation. SRDF groups are logical collections of pairs; RA groups are the director ports that carry replication traffic, and matching RA connectivity is needed on both sides.
- Consistency groups (device groups) preserve dependent write ordering across multiple SRDF groups.
States and commands
- symrdf -g query shows states such as Synchronized, SyncInProg, Split, Failed Over and Suspended.
- split stops replication and leaves the R2 available; failover makes the R2 writable and the R1 unavailable; swap reverses roles permanently; restore resynchronizes from R2 back to R1.
- While a pair is synchronized, the R2 is not available for host I/O, so do not plan read/write access to it.
Worked example
A 1 TB database must replicate 300 km away with an RPO of minutes. Choose SRDF/A with a defined cycle time, size the link for peak write rate, and consider delta set extension (DSE) so bursts spill to a pool instead of forcing longer cycles. Start with adaptive copy disk until pairs are synchronized, then set the group to asynchronous mode and test a controlled failover and restore.
Traps
Choosing SRDF/S for a long, high-latency link and then blaming the array for slow writes; confusing failover with swap; forgetting R2 devices are not host-accessible while in sync; and enabling DSE without capacity planning.