2012-11-02 08:31 AM
We are running Ontap 8.1 and need to move a Snapmirror destination volume (13TB) to a new aggregate without re-initializing.
Is the best solution to snapmirror the destination volume to a new volume/break SM between old and new destination/Resync from source to new destination?
I do notice when I do this the orginal SM job goes into a "pending" state because the destination is now busy Snap Mirroring to the new destination. Being that the volume is 13TB the new SM job (old destination to new destination but in same DataCenter) will take about 3 days to complete and the existing SM source -> desination will stay in a pending state
Just checking if there are any other options.
2012-11-02 09:48 AM
I'd say it is a valid approach.
I think you can quiesce / resume the transfer from old to new destination, so source gets a chance to send incremental updates before the whole migration is completed.
2012-11-02 09:50 AM
Is the aggregate you are relocating to on the same controller? If so, there vol copy or vol move may work out better for you.
If you are moving to another controller, then I'm pretty sure SM is the best option. I think you may be able to speed up your initialize time though by looking at a few things:
1) Consider snapmirror multipathing. We've seen a 30% or more increase in throughput by doing this.
2) Make sure as little as possible is occuring on the controllers. SM performance is very much so affected by business on the filer. IN my case, I had to reduce the frequency of SM Updates to those controllers as I moved the volume. Frequent updates caused several volume deswizzling scans to run almost nonstop, driving my CPU % busy to about 60% at all times. When I reduced this, my throughput increased by more than 6x.
Hope that helps!
2012-11-02 09:53 AM
Does that work? I've actually tried that without success. What I see happen is when I pause the intialize from B - > C, then trigger an update from A -> B, then B is flagged as changed and the initialize starts all over again next time I trigger it. I'd really really love to be wrong about this, so if you can fill in any detail on that I'd be ingratiated to you.
2012-11-02 09:57 AM
This is how I normally do it. Like firstname.lastname@example.org wrote, ideally you can use vol move.
Example Environment Equipment
Configure SnapMirror Relationship between NetApp02 and Netapp03
Break the SnapMirror Relationship between netapp01 and netapp02
Break the SnapMirror Relationship between netapp02 and netapp03
Delete SnapShots and Volume on netapp02
Delete SnapShots on netapp01
2012-11-02 10:44 AM
I think 'pending' status comes only when you're using snapmirror triggered snapshots for base line transfer.
So, better try creating a manual snapshot (eg: snap_base_transfer) at source and let that replicate to original destination.
Then create a new destination volume, restrict it and then initialize transfer between original destination and new one.
With this, the manually created snapshot only has softlock on the original destination, and remaining snapmirrored snapshots will be transferring normally.
But when you do this, monitor the source volume snap reserve, as the manually created snapshot grows in size until all data gets transferred to new destination volume.
For this, you can priorly increase the source volume size.
Hope this helps
2012-11-02 10:46 AM
I liked the detail on that reply, too, and the general strategy. But, you might have been hoping to keep the mirrored volume current on your original target during the three days it takes to re-initialize the new target. I'm not sure there's a good way to do that.