Unsolved
This post is more than 5 years old
3 Posts
0
6698
Open Replicator -hot -pull
Hello All,
I would like to use Open Replicator from VNX to VMAX...
What is the best option to complete a full copy before the cutover and then an incremental once server/database is down?
I need the source LUN to remain accessible until the server is down.
I was thinking...
Thanks!
seancummins
226 Posts
1
March 19th, 2014 12:00
BTW, one other point -- The process you described would be applicable if you performed the migration with Incremental SAN Copy push... in which case, you'd perform a full SAN Copy with apps online on the VNX, then periodic incremental SAN Copy sessions to keep things in sync before the outage window. Then during the outage window, you'd shutdown apps, perform a final incremental SAN Copy, and bring apps back up on the VMAX.
seancummins
226 Posts
1
March 19th, 2014 12:00
Roadkill,
The process you're describing would be appropriate for a hot differential push, or for other migration methods like SRDF or host/based file copy (e.g. rsync). But Open Replicator hot pull works differently.
With hot pull, you shutdown your production apps, then create & activate the open replicator sessions. Immediately upon activating the sessions, the control devices (in this case, your target VMAX devices) are in a read/write state. You can bring your apps back online using the VMAX devices immediately after session activation -- before data has been copied. Open Replicator uses CopyOnFirstAccess here -- if the host requests a block that hasn't yet been copied from the VNX to the VMAX, then Open Replicator will reach back to the VNX, retrieve & copy the block, and return it to the host. All of this happens transparently to the host and its applications.
The end result of all this is that your migration cutover outage window actually ends up being shorter than the traditional push or SRDF methods of migration -- because you don't have to wait for a differential copy to complete before cutting over your hosts.
I'd highly suggest reading through the Solutions Enabler Migration CLI guide -- it covers hot pull technology and provides some procedural examples of how a hot pull migration works. I've just provided a high level overview here.
Hope that helps,
- Sean
roadkill1
3 Posts
0
March 19th, 2014 12:00
I was going to try...
symrcopy -file or_test create -copy -hot -pull -differential...
but it states that it's not supported for the current Enginuity which is 5876
roadkill1
3 Posts
0
March 19th, 2014 13:00
That makes sense, thank you!
Michael Robinson
Senior Systems Engineer
Michael.robinson@cerner.com | 816-201-4644
www.cerner.com
1 Attachment
image001.png
donlab1
6 Posts
0
March 24th, 2014 10:00
we just migrated most of our environmnet with OR hotpull (20K to 40K). It just requires a quick down time to replace source luns with target luns and kick off the OR session then bring the host up on the target luns while the data copies in the back ground.
You must zone the FAs of the VNX and VMAX together, then you must mask the SG of VNX you want to migrate to VMAX then from vmax you create the same size or bigger devices and define a txt file matching source to target. We chose to use donor update which writes changes back to source. 25 is a good number for ceiling to start with. Watch your masked FAs on VNX and don't let them go past 75%.
**** Create Open Replicator Sessions (choose one to set ceiling) ****
symrcopy set ceiling 10 -dir all -sid 1757 -noprompt
symrcopy set ceiling 25 -dir all -sid 1757 -noprompt
symrcopy set ceiling 50 -dir all -sid 1757 -noprompt
**** drop host and remove DEV/RDM ****
symrcopy create -copy -name cguschp3012vm -pull -hot -frontend_zero -donor_update -file cguschp3012vm.txt -nop
symrcopy -file cguschp3012vm.txt activate -nop
symrcopy -file cguschp3012vm.txt query -i 15
**** verify all luns in a copied state ****
symrcopy verify -file cguschp3012vm.txt
symrcopy set donor_update off -session_name cguschp3012vm -consistent -nop
symrcopy -file cguschp3012vm.txt terminate -nop