The procedure to create SRDF pair and establish relationship is already documented. Here i am attempting to visualise the various operations/commands with the SRDF pairs by using simple replication set-up shown as below.
Current scenario: Site-A is Production site where the Application(s) are currently running live. Device-A is ReadWrite(RW) Enabled and mounted in Server-A, synchronously replicating to Device-B in Array-B. Device-B is in WriteDisabled(WD) state,visible to Server-B but not mounted/using. The SRDF link between Array-A and Array-B are in Read/Write state and the RDF Pair is in Synchronised state.
Let us see the commands/operations can be done on this scenario and the resulting states.
This command is using to temporarily suspend the I/O traffic on the SRDF link by making the RDF Links to NotReady(NR)state. RDF pair state changes to Suspended.
symrdf -file pair.txt suspend
Resulting setup will look like below after making a suspend action.
Resume the I/O traffic on the SRDF link by making the RDF Links to Read/Write(RW)state,( probably after a suspend action). This will start incrementally copying the changed data on R1 to R2 and finally set RDF pair state to Synchronised once done.
symrdf -file pair.txt resume
Resulting setup will look like Diagram-1 after making a resume action.
This command results Read Write access to both R1 and R2 devices. The replication between R1 and R2 devices will be stopped, by putting the RDF link to NotReady(NR) state. The R2 device can be mounted on Server-B for ReadWrite operations.
symrdf -file pair.txt split
Resulting setup will look like below after making a split action.
We usually start a full copy while creating the initial SRDF pairing.This is done by using -establish option along with createpair command.
Incase we have done a SPLIT operation( as an example ) on a RDF pair, and later want to copy ALL the data from R1 to R2( not just the changed data on R1 while being on split) the "establish -full" must be used.
This command start a fresh copy from R1 to R2, WriteDisable the R2 device( if not already in that state). The RDF Pair state changes to "Synchronised" once fully copied R2 and fully identical to the R1 data.
symrdf -file pair.txt establish -full
Resulting setup will look like Diagram-1 after making a full establish .
This is the common command used to copy the changed data on R1 to R2 device after a SPLIT.
This command start an incremental copy from R1 to R2, WriteDisable the R2 device( if not already in that state). The RDF Pair state changes to "Synchronised" once fully copied R2 and fully identical to the R1 data.
symrdf -file pair.txt establish
Resulting setup will look like Diagram-1 after making a incremental establish .
Failover command makes ReadWrite access to the R2 volumes while protecting the data on R1 keeping it WriteDisabled.
This is the common command used while performing Disater Recovery Exercise(DRE) Test, which verify the consistency of the data and applications, temporarily switching over to the DR side. The R1( Device-A) must be unmounted from Server-A prior to issuing this command.The replication from R1 to R2 will stop and RDF link state changes to NotReady(NR).
State of the RDF pair will be set as "Failed Over".
symrdf -file pair.txt failover
Resulting setup will look like below after making a failover action.
We can use the failback after a "failover" command, wanted to copy the changes made in R2 to R1. If we don't want to copy the changes done on DR back to Production device, issue the "establish" command to overwrite the changes in R2 device with the old data on R1.
This command start copying( in background ) the changes done on Device-B(R2) to Device-A(R1), RedWrite enable Device-A, WriteDisable Device-B and enable the RDF link from R1 to R2.
symrdf -file pair.txt failback
Resulting setup will look like Diagram-1 after making a failback .
Update command used in situations where we already in "Failedover" state , added/modified so much of data on R2 side , and want to failback( R2 changes to be copied to R1). In this scenario , giving a direct "Failback" command will result in ReadWrite enabling of R1, WriteDiabling of R2 and incrementally copying updated data from R2 to R1 in background. If the host request for modified data on R1 , which still may not be copied from R2, has to read through the SRDF links from R2.This might cause a performance impact.
Update command can be issued prior to "failback" to avoid such a situation. This will start copying the incremental data from R2 to R1 and readily available modified data on R1 after the failback.
symrdf -file pair.txt update
To be continued..