SRDF Skew Value Configuration ?

If cache utilization is a concern, then you may want to consider switching SRDF modes to Adaptive Copy Disk (acp_disk) instead of Write Pending (acp_wp). Acp_disk allows the Symm to destage local writes to disk (thus freeing up the cache slot), and then will read those changed tracks from the physical disks when they're ready to be copied over the RDF links. In contrast, acp_wp prevents tracks from being destaged to disk until they have been copied over the RDF links.. in cases where there is a write spike, or a congested link between the R1 and R2 frame, this can cause excessive changes to build up in the cache of the R1 frame.

The skew value defines the number of I/Os that can be out of sync between the R1 and the R2 frame. When this value is reached, SRDF reverts to its primary mode, which is nearly always synchronous. The other primary mode is semi-sync, but this is rarely used. If your links revert to sync mode, and your R1 and R2 frames are far apart geographically, or your links have high latency, then your production performance will be affected.

I also noticed that your replication flow appears to be directly from R1 -> R2 -> BRBCV, with no local BCVs/Clones in the production frame. Keep in mind that if you are running in adaptive copy mode with this replication flow, there is no mechanism in place to give you consistency on the R2/BRBCV volumes. In Adaptive Copy mode, the changed tracks are just copied as quickly as possible, without regard to write order or consistency.. so in Adaptive Copy modes, we typically combine local BCVs with SRDF to achieve consistency... e.g. STD -> BCVR1 -> R2 -> BRBCV. If you want to achieve consistency in a direct R1 -> R2 replication flow, you can do this by using SRDF/A or SRDF/S.

Hope that helps,

- Sean

" so in Adaptive Copy modes, we typically combine local BCVs with SRDF to achieve consistency... e.g. STD -> BCVR1 -> R2 -> BRBCV."

If we copy from BCVR1 -> R2 in Adaptive copy mode how it will be consistent? Even though there is no change happening at the source(BCVR1) and how the adaptive mode(copy as quick as posible) can keep the consistency??

Also i have another question is it possible to do both [STD -> BCVR1 ] & [BCVR1 -> R2 ] sync at the same time? Also what would be best mode then between [BCVR1 -> R2 ] ? I mean srdf/a ; srdf/s or adaptive copy?

When copying from BCVR1 -> R2, you are copying from a point-in-time copy of data that has already been created in a consistent manner by TimeFinder. So TimeFinder creates your consistent point-in-time image on the BCVR1, and then you ship the contents of the BCVR1 to your R2 volume using SRDF Adaptive Copy. The data on the R2 is inconsistent during the SRDF copy process, but once the copy is complete, the R2 data is consistent.

You can mitigate the fact that the R2 is inconsistent during the SRDF copy process be using Gold BCVs on the target... before starting the SRDF copy, you would ensure that you had a gold copy of the R2 data on your BRBCV... that way if something went wrong during the copy process, you can restore your previous consistent point-in-time image from the remote gold copy.

As for what mode to use when copying from BCVR1 to R2 -- Adaptive Copy Disk.

You would normally want to run each copy process in sequence... in a standard single-hop SRDF/DM configuration, you would first run your local TimeFinder STD -> BCVR1 sync/split, then run the SRDF job from BCVR1 to R2 and suspend, then run the remote TimeFinder R2->BRBCV sync/split.. then start the cycle again.

"You would normally want to run each copy process in sequence... in a standard single-hop SRDF/DM configuration, you would first run your local TimeFinder STD -> BCVR1 sync/split, then run the SRDF job from BCVR1 to R2 and suspend, then run the remote TimeFinder R2->BRBCV sync/split.. then start the cycle again"

That is what we do. But do you see an advantage having srdf/a between [BCVR1 to R2] compared to srdf/s. ? what difference it makes interms network bandwidth consumption.? also why it is recommended to suspend before starting the R2->BRBCV sync/split?

Gig-E directors do have the capability to compress RDF traffic -- if compression is enabled, it will compress regardless of which SRDF mode is used.

Perhaps you're thinking about the way SRDF/A inherently deals with multiple writes to the same block within a short time period... If there are several writes to the same block during a particular SRDF/A capture cycle, then only the last write to that block will need to be transmitted across the RDF link when that capture cycle switches to a transmit cycle. This really only applies when you are replicating an R1 that is receiving writes from a host.. it doesn't apply when you are replicating a static point-in-time copy of data like a BCVR1.

"There is no benefit of running SRDF/A or SRDF/S from a point-in-time BCVR1 to an R2"

are you sure about that? AFAIK, there is a compression facility built at the director level while using srdf/a. I am expecing the compression to lessen the load on the srdf link. Isn't that true?

There is no benefit of running SRDF/A or SRDF/S from a point-in-time BCVR1 to an R2.

If you tried issuing a STD->BCVR1 establish with TimeFinder prior to suspending SRDF replication from BCVR1->R2, you would find that your BCVR1->R2 SRDF replication is suspended automatically anyway. Alternately, if you tried resuming BCVR1->R2 SRDF replication while STD->BCVR1 replication is still occurring via TimeFinder, you would get an error stating that this is not possible because a STD is currently attached to the BCV.

Compression is for Gig-E directors (REs) only; for RFs you'd need external compression gear.

is that compression not available for RF directors "SRDF over Fiber channel".?Or limited to only Gig-E directors?