Moving a Snapmirror destination volume to another aggregate

[KDEAN1961]

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.

Thanks

Kathy

[radek_kubka]

Hi Kathy,

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.

Regards,
Radek

[bsti]

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!

[bsti]

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. 

[ryanbeaty]

This is how I normally do it. Like bsti@plex.com wrote, ideally you can use vol move.

Example Environment Equipment

• Netapp01 (original / production source)
• Netapp02 (original SnapMirror destination)
• Netapp03 (new SnapMirror destination)
• Volume named exchange

Configure SnapMirror Relationship between NetApp02 and Netapp03

1. Log into netapp03
2. Create a volume named "sm_exchange"
3. Restrict the volume "sm_exchange"
4. Edit the snapmirror.conf file
   1. Netapp02:sm_exchange netapp03:sm_exchange - * * * *
5. Snapmirror initialize the "netapp03:sm_exchange" volume

Break the SnapMirror Relationship between netapp01 and netapp02

1. Log into netapp02
2. Quiesce the snapmirror "netapp02:sm_exchange"
3. Break the snapmirror "netapp02:sm_exchange"
4. Edit the snapmirror.conf file to remove the relationship "netapp01:exchange netapp02:sm_exchange"

Break the SnapMirror Relationship between netapp02 and netapp03

1. Log into netapp03
2. Quiesce the snapmirror "netapp02:sm_exchange"
3. Break the snapmirror "netapp02:sm_exchange"
4. Edit the snapmirror.conf file to change the relationship from "netapp02:sm_exchange netapp03:sm_exchange" to "netapp01:exchange netapp03:sm_exchange"
5. Snapmirror resync "netapp03:sm_exchange"

Delete SnapShots and Volume on netapp02

1. Log into netapp02
2. Snap list the sm_exchange volume
3. Snap delete the sm_exchange (snapmirror) snapshot
4. Offline the "sm_exchange" volume
5. Destroy the "sm_exchange" volume
6. Verify the relationship between "netapp01:exchange netapp02:sm_exchange" is gone

Delete SnapShots on netapp01

1. Log into netapp01
2. Snap list the exchange volume
3. Snap delete the exchange (netapp02 snapmirror) snapshot
4. Verify the relationship between "netapp01:exchange netapp02:sm_exchange" is gone

[radek_kubka]

Nasty - I thought that as long as B->C uses common snapshot, new A->B update shouldn't cause full reinitialisation?

[KDEAN1961]

Unfortunatley it is on a different controller.

Can you provide more info on snapmirror multipathing?

Thanks for your reply!

[KDEAN1961]

Thanks for the detailed respone!  I will let you know the outcome.

[naveenkumar_e]

Hi,

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

-naveen

[cfbnetapp]

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.

[bsti]

https://library.netapp.com/ecm/ecm_get_file/ECMP1113957

Starting on page 137.

One thing to note on this setup:

You need two different network interfaces on each controller, each in its own subnet and VLAN. This is probably the most difficult part of the setup.  However, once setup it works really well.  I'm not sure why, but even against a Interface Group of 2+ interfaces it performs better.  You might want to test it in your environment to be sure, but we swear by it.

Also, be sure to add the proper snapmirror.conf entries for multipathing, and add your entry for your new SM relationship BEFORE starting your SM initialization, or it will NOT multipath.  You can verify multpathing as it's running using ifstat -a.

[bsti]

Can you elaborate?  I'm not sure this works.

I create manual snapshots all the time on my original SM source, and that changes nothing. 

If you are referring to the -s option on snapmirror initilaize (to specify a snapshot to transfer), then that does not work unless you are Snapmirroring to a qtree.

[KDEAN1961]

I followed your steps exactly and when I tried to do the resync from original to new destination I got the following

"Snapmirror resynchronization of snapmirror_test_newdest to sdcnasnap2n1:snapmirror_test : no common snapshot to use as the base for resynchronization

Aborting resync"

[bsti]

Now that I look, the steps I take are slightly different. 

I don't do a resync.  Where you have A -> B then B -> C, then once you've finished initializing B -> C, then you edit the snapmirror.conf  file on C to reflect the new relationship from A -> C.

After that, run a snapmirror update -S source_filer:source_vol new_dest_filer:new_dest_vol

Also, I don't delete snapshots on either destination until the relationship from A ->C is going.  THis may be why you get your error (you are deleting the base snapshot).

Try this basic procedure:

1) Create your destination volume on C as he states above.

2) Perform an initialize from B -> C.  Whiile this is happening you cannot update A -> B.

3) Once that is done, edit snapmirror.conf on C to reflect A -> C

4)  Do an update on C:  as in my example above.

5)  If that works, then clean up by removing snapshots on A that refer to B, then updating to C again.

6) Once you are 100% happy, delete volume on B.

Hope that helps.

[KDEAN1961]

Ok..I remember chaging a snapmirror destination  over a year ago and I know recall performing an UPDATE and not a Resync.  (It's all coming back to me now!)

I will try it again.  I did NOT delete any snapshots.  I think the UPDATE command will do the trick!

Thanks!

[ryanbeaty]

The only reason why you would need to delete the snapshots is to remove them from the "snapmirrorr status" list. Until you delete those old relationship snapshots they will always show up when you run snap mirror status. This is more of a cleanup phase after you are done.