Composite SRDF commands 1. Failover: 1. Actions: 1. Write disables (WD) R1 2. Sets link to Not Ready (NR) 3.

Write enables R2 2. Command: symrdf -g ${group} failover 2. Update: Helps to speed up the failback operation by copying invalid tracks before write disabling any disks. 1. Actions: 1. Leaves service state as is. 2. Merges the tracks 3. Copies invalid tracks 2. Command: symrdf -g ${group} update 3. Failback: 1. Actions: 1. Write disables R2 2. Suspends RDF link 3. Merges the disk tracks. 4. Resumes the link 5. Write enables R1 6. Copies the changed data 2. Command: symrdf -g ${group} failback 4. Split: Leaves both R1 & R2 in write enabled state. 1. Actions: 1. Suspends the rdf link. 2. Write enables R2 2. Command: symrdf -g ${group} split

5. Establish: 1. Actions: 1. Write disables R2 2. Suspends the rdf link 3. Copies data from R1 to R2 4. Resumes the rdf link. 2. Command: symrdf -g ${group} [ -full ] establish 6. Restore: Copies data from R2 to R1 1. Actions: 1. Write disables both R1 & R2 2. Suspends the rdf link. 3. Merges the track tables 4. Resumes the rdf link. 5. Write enables R1 2. Command: symrdf -g ${group} [ -full ] restore Singular SRDF commands 1. Suspend: symrdf -g ${group} suspend 2. Resume: symrdf -g ${group} resume 3. Set mode: symrdf -g ${group} set mode sync symrdf -g ${group} set domino on symrdf -g ${group} set acp_disk skew 1000

Conceptually, even operationally, SRDF is very similar to Timefinder. About the only difference is that SRDF works across Symms; while Timefinder works internally to one Symm. That difference, intersymm vs intrasym, means that SRDF operations can cover quite a bit of ground geographically. With the advent of geographically separated symms, the integrity of the data from one symm to the other becomes a concern. EMC has a number of operational modes in which the SRDF operates. The choice between these operational modes is a balancing act between how quickly the calling application gets an acknowledgement back versus how sure you need to be that the data has been received on the remote symm. Synchronous mode Synchronous mode basically means that the remote symm must have the I/O in cache before the calling application receives the acknowledgement. Depending on distance between symms, this may have a significant impact on performance which is the main reason that EMC suggests this set up in a campus (damn near colocated) environment only.

If you're particularly paranoid about ensuring data on one symm is on the other, you can enable the Domino effect (I think you're supposed to be hearing suspense music in the background right about now...). Basically, the domino effect ensures that the R1 devices will become "not ready" if the R2 devices can't be reached for any reason - effectively shutting down the filesystem(s) untilthe problem can be resolved. Semi-synchronous mode In semi-synchronous mode, the R2 devices are one (or less) write I/O out of sync with their R1 device counterparts. The application gets the acknowledgement as soon as the first write I/O gets to the local cache. The second I/O isn't acknowledged until the first is in the remote cache. This should speed up the application over the synchronous mode. It does, however, mean that your data might be a bit out of sync with the local symm. Adaptive Copy-Write Pending This mode copies data over to the R2 volumes as quickly as it can; however, doesn't delay the acknowledgement to the application. This mode is useful where some data loss is permissable and local performance is paramount. There's a configurable skew parameter that lists the maximum allowable dirty tracks. Once that number of pending I/Os is reached, the system switches to the predetermined mode (probably semi-synchronous) until the remote symm catches up. At that point, it switches back to adaptive copy-write pending mode.

Differences between active-active and active-passive

Active-active Setup: Two Adaptive Servers are configured as companion servers, each with independent workloads. These companions run on the primary and secondary nodes, respectively, as individual servers until one fails over. Failover: When fail over occurs, the secondary companion takes over the devices, client connections, and so on from the primary companion. The secondary companion services the failed-over clients, as well as any new clients, until the primary companion fails back and resumes its activities. Failback: Failback is a planned event during which the primary companion takes back its devices and client connections from the secondary companion to resume its services. Client Connection failover: During failover, clients connect to the secondary companion to resubmit their uncommitted transactions. During failback, clients connect to the primary companion to resubmit their transactions. Clients with the failover property reestablish their connections automatically.

Active-passive Setup: A single Adaptive Server runs either on the primary node or on the secondary node. The Adaptive Server runs on the primary node before a fail over and the secondary node after fail over. Failover: When a system fails over, the Adaptive Server and its associated resources are relocated to, and restarted on, the secondary node.

Failback: Failback is a planned fail over or relocation of the Adaptive Server and its resources to the primary node. Failback is not required, but can be done for administrative purposes. Client Connection failover: During failover and failback, clients connect to the same Adaptive Server to resubmit uncommitted transactions. Clients with the failover property reestablish their connections automatically.