Concurrent SRDF could be used in a couple of scenarios such as setting up a temporary replication to another array in order to migrate large amount of data, or a permanent solution as part of DR strategy. Below are the steps that should generally be followed in order to set up the replication for a temporary migration purpose. It is all a courtsey of my knowledgeable collegaue Colm O’Loughlin.
Zoning:
Zone two RA’s together from source and destination arrays.
RA Flags:
Check both sides RA’s have these flags enabled:
Switched RDF Configuration State : Enabled
Concurrent RDF Configuration State : Enabled
Dynamic RDF Configuration State : Enabled
Concurrent Dynamic RDF Configuration : Enabled
To set them use symconfigure:
# symconfigure -sid 1234 -cmd 'set symmetrix concurrent_rdf=enable;' prep -nop
Same for the other flags.
Configure concurrent RDF link:
It is advisable to use a high number like 66 to avoid conflict with existing numbers & put tmp in the label name.
To set up the link
# symrdf -sid 1234 addgrp -label 1234-5678-temp -rdfg 66 -dir 8c,9c,8d,9d -remote_rdfg 66 -remote_sid 5678 -remote_dir 8c,9c,8d,9d -v
To remove the link
# symrdf -sid 1234 removegrp -label 1234-5678-tmp
To modify the link
# symrdf -sid 1234 modifygrp -label 1234-5678-tmp remove/add -dir 8c
Migrations PROCESS:
NOTE: All commands run from the R1 side.
* Create pair from Production R1 to target migration R1 which will be a stand alone device at first configured as an R2. Make sure that the new RDF relationship is not created yet.
# symrdf -sid 1234 -rdfg 66 -f df_concur_1234-5678 createpair -type R1 -est -remote
* Set the mode to acp_disk to as to not affect performance on the production link if set up during the week. Best to set up beforehand as sync is done before migration.
# symrdf -sid 1234 -rdfg 66 -f df_concur_1234-5678 -type RDF1 set mode acp_disk
* Depending on the application you might need to split the concurrent link during business hours and re-establish at night time to allow further updates.
a. Change mode to sync to allow fully synced link with no invalid tracks on R2.
# symrdf -sid 1234 -rdfg 66 -f df_concur_1234-5678 -type RDF1 set mode sync
b. Split the link
# symrdf -sid 1234 -rdfg 66 -f df_concur_1234-5678 -type RDF1 split <-force|–symforce># force and –symforce – if there are invalid tracks
c. Re-establish at evening time
# symrdf -sid 1234 -rdfg 66 -f df_concur_1603_2758 -type RDF1 establish
* Check the sync status
# symrdf -sid 1234 -rdfg 66 –f df_concur_1234-5678 -type RDF1 query
* Set mode to sync
# symrdf -sid 1234 -RDFG 66 -f df_concur_1234-5678 -type RDF1 set mode sync
* Request for application team to shut down their host or quiece the IO on the R1 side so that you have a cut off point where data doesn’t change. This is when the downtime clock starts.
* Split the link first – if there are invalid tracks then the new R1 might have issues being discovered on host as labels might be corrupt.
# symrdf -sid 1234 -rdfg 66 -f df_concur_1234-5678 -type RDF1 split
* Delete Concurrent link once in a split state
# symrdf -sid 1234 -rdfg 66 -f df_concur_1234-5678 -type RDF1 deletepair <–symforce>
* Set up the SRDF relationship between the new R1 and the new target R2.
* Reclaim the old R1’s from the server. Allocate the new R1’s to the server. Allocate R2’s to the DR server.
* Tell application team to bring back online disks which will have the same device labels etc.
* Quote a time that DR will be available. R2’s won’t be available to discover until the sync is fully completed.
No comments yet.