SRDF - Simple (Symmetrix) Remote Data Facility

Alright... been ages I wrote something on SRDF. Let me write something bout the much talked about - Performance issues with SRDF/A. But before I do that, here is a simple layout on how a SRDF looks like. (Click to expand)

Basic storage fact of life: if you're doing synchronous replication, the source has overhead and delay because remote write operations must be confirmed. That limits the distance for synchronous to 300 km over fiber, per http://www.intellimagic.net/intellimagic/what-is-spm/copy-services/srdfs. Asynchronous avoids that.
Storage systems are reliant upon the network in one way or another. EMC DMX SRDF synchronous data replication, NetApp MetroCluster node-to-node communication, data replication, iSCSI and NDMP backups all rely on the network to be stable and functioning. But sometimes, it's not, and network troubleshooting is required to fix the problem.

Virtual Provisioning with SRDF:
.Storage is allocated in extents of 768KB
.SRDF operations continue to be supported with the granularity of blocks (512 bytes)
.SRDF supports connecting a VP device to another VP device (thin to thin only)
.Indirection penalty with every write
.Noticable at high I/O rates
.Consequently more SRDF CPU power is needed to achieve equivalent performance

.Maximal 2500 IOPS (roughly, still doing testing and engineering)

Best Practice Consideratoins:
.Always consider disk throughput requirements when creating or growing a data device pool
.Segregate applications by pools if they won’t play well together
.Use R1 or R5 (3+1) when write performance is critical. Use R6 for highest available within a thin pool.
.Pre-allocate capacity if response sensitive applications expand by randomly writing into new space.
.Use concatenated meta volumes for ease of expansion
.Be aware of performance considerations of replication

.General performance tuning principles still apply to thin devices