SRDF/A Session Suspends Every Night at 01:20

Per-cycle volume at peak: 2.4 TiB/hour ÷ (3600 / 30) cycles per hour = 2.4 TiB / 120 = 20.5 GiB per cycle.

Available throughput: two 10 GbE links ≈ 2 × 1.15 GB/s ≈ 2.3 GB/s raw, roughly 2.0 GiB/s usable after protocol overhead. At line rate, 20.5 GiB drains in about 10 seconds - comfortably inside a 30-second cycle on average.

The problem is burstiness, not average bandwidth. Within the batch, change rate is not uniform: a few seconds of heavy redo or a large direct-load can produce several cycles' worth of deltas at once, and each cycle's delta set must be fully transmitted and acknowledged before the cycle can close. At 21 ms RTT, in-flight data and RA buffer occupancy limit how fast a delta set can actually drain, so a burst can exceed the 30-second window. When a cycle cannot close, SRDF/A suspends the session rather than transmit dependent writes out of order - consistency is preserved by dropping the session, not by skipping data. The 55 % average simply hides those peaks.

Suspending and resuming manually does not fix this; it converts a burst problem into an inconsistent R2 copy that needs a full resync.

1. Increase cycle time from 30 s to 60–90 s. A longer cycle lets each delta set absorb more change and gives the links time to drain bursts. RPO becomes cycle time plus drain time: at 90 s plus roughly 20 s of drain, RPO ≈ 110 s - still far inside the five-minute target. This is the lowest-risk change and can be done with symrdf modify on the group.

2. Enable delta-set extension with a dedicated DSE pool on the R1 side, sized for a couple of hours of peak change (2.4 TiB/hour × 2 ≈ 5 TiB). DSE spills delta sets to disk when RA buffers fill instead of suspending the session. It buys burst tolerance at the cost of capacity and a slightly longer drain time; it does not reduce link bandwidth need, so it complements the cycle-time change rather than replacing it.

3. Consider a third 10 GbE link only if the batch trend shows sustained (not bursty) growth; it does nothing for a 20-second burst that a bigger cycle time and DSE already absorb.

4. Stop the manual suspend/resume workaround. Replace it with an alert-driven runbook: on a session suspend, capture the RDF group state and delta-set fill first, then decide between resume and full resync.

On R1:

• Session state returns to active/consistent after a full cycle, with no invalid tracks accumulating outside the incident window (symrdf -g query, delta-set state, cycle time).
• DSE pool has capacity and is actually being used during the batch, not just configured. Size and monitor it; a full DSE pool re-creates the original failure.
• RA port utilisation and queue depth across the whole batch, not the daily average, to confirm the burst is now absorbed.

On R2:

• The pair state and consistency state per device after the first full batch following the change.
• SRP capacity, since DSE and any resync traffic consume space; 30 TiB free is adequate now but needs a trend.

Monitoring and process:

• Alert on SRDF/A session suspend and on DSE pool utilisation thresholds, so the next event pages someone instead of being handled by hand at 01:20.
• Run a controlled split in a maintenance window and verify the R2 copy is clean, so the recovery assumption is proven rather than inferred.
• Record the new RPO (cycle + drain) in the DR plan, because the five-minute requirement is now met with a different margin than the old documentation states.