Storage Migration using NMC

[JLundfelt]

Hey Everyone,

Have a quick question regarding using the NetApp Management Console. What is the most efficient way to migrate volumes between aggregates / controllers? Is it to

A) Create target volumes, and setup snapmirror relationships, restrict the source volume(s), complete the mirror(s), and change the CIFS / NFS export path(s)

B) Create target volumes,  restrict the source volume(s), use ndmpcopy and change the CIFS / NFS export path(s)

C) Use NMC / Migration Manager to define datasets, and select resource pools to dynamically provision the targets, and CIFS / NFS export path(s)

Thanks in advance!

-Jon

[sarbjit]

Hi,

Couple of questions for clarification:

What version of Data ONTAP are you running?

Also please could you let us knoe if you already have a snapmirror licensed on your NetApp storage controller?

Setting up of snapmirror could be done either manually via CLI or via NMC(protection manager) or via System Manager.Once the baseline snapmirror is done,you should stop the IO to the original production CIFS/NFS volume & do a cutover to the new snapmirror destination volumes which will become yiur new production volumes.You may also rename the old production volume to something like vol_old & rensme the snapmirror destination as the name of the original pemrod volume so that you dont have to modify the share path/nfs exports.

Thanks,

Sarbjit

[adaikkap]

Hi Jon,

     When you say storage migration is it primary volumes or secondary volumes( secondary aka mirror/snapvault destination). If its later, then you can use Secondary storage migration in Protection Manager to migrate the volumes which takes care of both incoming and outgoing relationship to the volume being migrated.

If its  migration of primary volume using NMC/PM the volume would be unavailable to users for the entire duration of the migration and not just only during the cut-over phase.

Attached is the doc that explains how to do SSM using DFM 4.0 but it holds good for any release later.

[JLundfelt]

Here are my details-

Application name: NetApp Management Console

Version: 3.0.2

Build number: 3.0.2.4201

DFM Version: 4.0.2.7803 (4.0.2)

Ontap NetApp Release 7.3.6:

I also have 4 active/active controllers running NetApp Release 8.0.3RC1. I was able to setup a dataset with NMC, and start a mirror, which was successful, but I am wondering if thats the best way to do it, as I would up with my target volume read-only-

MirrorStatus	: unmirrored
Name	: ArchiveData_mirror_IRV_SAN_NA1_ArchiveData

RaidStatus

: raid_dp,snapmirrored,read-only,sis

State

: online

So just to be clear I am just trying to find the most efficient way to shuffle primary volumes around, so I can destroy, and rebuild aggregates as 64-bit once I am on Ontap 8.x. For now, I am wondering what the procedure to get a clean migration of this first volume would be, e.g.

Restrict primary volume

Perform final snapmirror

Delete snapmirror relationship?

Set the primary volume offline

rename primary volume

rename mirrored volume

Or something like that so the cifs shares local mask is still relative. Hope that makes sense.

Thanks,

Jon

[JLundfelt]

Awesome doc! I like the concept of being able to view my environment at the aggregate level. One thing though, while I have licensing for everything I would think I would need, the migrate button is grayed out on all volumes, on all controllers?

Any thoughts as to why that would be?

Thanks,

Jon

[JLundfelt]

How do I stop the snapmirror relationship w/ NMC? Delete the Dataset? Also, how do I change the target volume from being read-only?

Thanks,

Jon

[JLundfelt]

OK, I guess its grayed out since it still has a CIFS share associated with it. So this begs the question, for large multi TB volumes, what is the best way to migrate them as efficiently and with as little downtime as possible? It seems like there are pro's and con's of each method-

1) NMC Protection Manager

Pro: Provisions target volume, and configures snapmirror relationship. Allows for target volume to be staged, while source remains active

Con: Have to remove NMC dataset, and offline source volume / rename target and break snapmirror relationship to make target writable?

2) NMC Secondary Space Management Wizard

Pro: Allows for one click volume migration

Con: Intra-controller only. Requires Source volume to be inaccessible during migration. Requires CIFS / NFS exports to be recreated

3) CLI based OnTap / Powershell / DFM CLI

Pro: Allows for complete control of process

Con: Requires target volumes be provisioned in advance

Is this an accurate assessment?

Thanks,

Jon

[arunchak · Accepted solution]

Hi,

SSM checks the eligibility criteria, which if fails it remains grayed out. For migration there shouldn't be any shars, exports or LUN maps associated with it..

Also please notice that we recommend to use this solution only on secondary volumes and not on primary volumes. Though it works for primary volumes, its not a foolproof mechanism as you need to manually export/map NFS/LUN.

>>Have to remove NMC dataset

  You need not delete the dataset, you can break the relationship from ONTAP or induce a disaster on source which will make the secondary volume writable.

>>

2) NMC Secondary Space Management Wizard

Pro: Allows for one click volume migration

Con: Intra-controller only. Requires Source volume to be inaccessible during migration. Requires CIFS / NFS exports to be recreated

This is the reason we recommend it only for migrating secondary volume for which there won't be any exports.

Thanks,

Arun

[JLundfelt]

Thanks for confirming, so I guess I a going to probably go with option 3, Powershell specifically. I had to use it to break the mirror since your right, removing the dataset in NMC doesn't break, or remove the relationship. The only other question I guess I have is that I heard something about not being able to mirror data from 32-bit to 64 bit aggregates.... is that true? if so, why?

[ERIC_TSYS]

You could always qtree snapmirror data between ontap 7g (32 bit) and 8g (64 bit) family.

New from Ontap 8.1 on destination controller is that you can also volume snapmirror from a source

32 bits aggr. I dont think you can failback in case of a DR so be weary

https://library.netapp.com/ecmdocs/ECMP1120690/html/frameset.html

Support for volume SnapMirror replication between 32-bit and 64-bit volumes

Starting with Data ONTAP 8.1, you can replicate volumes by using  SnapMirror technology between 32-bit and 64-bit volumes. For both  synchronous and asynchronous volume replication, the SnapMirror source  and destination volumes can be either 32-bit or 64-bit.

Cheers,

Eric

[JLundfelt]

Thanks, we are running NetApp Release 8.0.3RC1 7-Mode, and I am struggling to understand how to create a qtree in a volume, where all the data already exists in the root of the volume. What is the procedure to setup a QSM relationship on a pre-existing CIFS volume where there isn't already a qtree?

[adaikkap]

I suggest you to try the DR policies which can be used to mirgrate data including those inside the root of the volume. The DR protection polices allows you to create your destination with same properties as primary.

Which everyone would want for migration as well. Also it allow you to do a baseline, update and break and run script post and pre failover which is required for Migration too. Using this you can migrate your data between controllers.

Also you can try workflow automator which gives you even more flexibility and customization.

[JLundfelt]

Do you have any links to guides on any new software, or methodologies for moving secondary volumes between controllers? We are migrating between a FAS3140 running 8.03RC2 to a FAS6210 running 8.1.3. P1, and I don't see any great way to do this, the best thread I've found on the subject is-

https://communities.netapp.com/thread/15402

Thanks,

Jon