This post is more than 5 years old
36 Posts
0
2440
October 5th, 2011 05:00
SRDF/S DR Testing
This weekend I will be performing DR testing on our DMX environment. Once we failed over, users will work on R2 LUNs for 4 hours and we need to retain the modified R2 data by copying it to R1. I have read the SRDF guide and understood that failover/failback would be the correct method to retain the modified R2 data and drafted the below specified steps. Please add your points if I miss something.
Note: Both Prod & DR are in Microcode Version 5772.
###########
FAILOVER:-#
###########
APP DBA Shutdown the application & SA umount the FS.
#symrdf -g DGNAME query ==> Check the R1 (Rw), R2 (WD) & Link (RW) status.
#symrdf -g DGNAME failover
#symrdf -g DGNAME query ==> Check the R1 (WD), R2 (RW) & Link (NR) status.
#symrdf -g DGNAME verify -failedover
###########
FAILBACK:-#
###########
APP DBA Shutdown the application & SA umount the FS at DR.
#symrdf -g DGNAME query ==> Check the invalid tracks count.
#symrdf -g DGNAME failback
#symrdf -g DGNAME query ==> Check the R1 (Rw), R2 (WD) & Link (RW) status.
#symrdf -g DGNAME verify -synchronized
#symrdf -g DGNAME query -i 10
###########
ROLLBACK:-#
###########
If they want to cancel the DR testing (for any said reasons) after I failedover, I am planning to use the below steps to roll back without copying the R2 data.
#symrdf -g DGNAME rw_enable R1
#symrdf -g DGNAME establish
#symrdf -g DGNAME query
Thanks much for your time
0 events found
GEMC
36 Posts
0
February 22nd, 2012 08:00
It worked well. When we rolled back, I performed the below specified steps. #symrdf -g rw_enable R1 -force -nop #symrdf -g query ==> It should be in "Split" state. #symrdf -g establish -nop ==> Copy the data from R1 to R2. Ignoring the modified R2 data. #symrdf -g query
SKT2
2 Intern
•
1.3K Posts
0
October 5th, 2011 10:00
interesting
after the unmount , also make sure VGs are exportted if under LVM
GEMC
36 Posts
0
October 5th, 2011 23:00
You are right.. SA will deport/deactivate the VG...
Am I okay to proceed with this steps?
SKT2
2 Intern
•
1.3K Posts
0
October 6th, 2011 12:00
I am not sure how many people in reality do this kind of test.Looking at the feedback you received so far, it does not sounds like there is many.
why dont you make a test grp and test th failover/failback and rollback
GEMC
36 Posts
0
October 7th, 2011 01:00
I am working in a Banking domain where I am not allowed to perform any sort of test :)!!! Will let you know the outcome of this DR testing by Monday morning. Cheers :)
psivakumar
8 Posts
0
October 7th, 2011 08:00
You could possibility take a BCV copy before testing for additional protection. We had followed the steps outlined in your post (steps) for rolling upgrades. Please and kinldy factor in your application connectivity (changes) and time to copy changed tracks to r1 side once testing is complete. In theory, you can start using applications immediately after failing back to r1 side. However, we had noticed sluggish response when large number of tracks coming over from r2 side. Also, I always inform EMC support before and after test to minimze call home calls coming out DMX boxes besides they are in the loop; just in case. (we had a situation when one track fail to come from r2 -> r1. The support folks helped us to bring that track).
good luck.
GEMC
36 Posts
1
October 10th, 2011 00:00
Thanks for your suggestions psivakumar. DR testing has been postponed due to inevitable reasons but I would add the BCV copy steps while I perform this. I see you had encountered performance problem due to large number of invalid tracks. I would suggest you to use #symrdf -g DGNAME update command (If you see large number of invalid tracks at R2) before you failback. "Update" command copy the invalid tracks from R2 to R1 without changing the service status or write disabling any disks. Once considerable amount of tracks copied back to R1 you can perform the failback.
#symrdf -g update
1. Leaves service state as it is
2. Merges track tables
3. Copies the invalid tracks