What is the best way to peform a LUN migration?

[DIVIDE1024]

Hello everyone,

    We just purchased new storage for our Netapp controllers.
Everything is connected via ISCSI. I would like to know what is the best
possible way to migrate data from one Netapp LUN to another Netapp LUN within
and outside the same Aggregate?

Thanks in advance for any help on this!

[resqme914 · Accepted solution]

Your question wasn't detailed enough for us to provide you a decent answer, so we have to make assumptions.  Assuming you want to move a lun (contained in a volume) from one aggregate to another (within the same controller), and assuming one lun per volume (or multiple luns in a volume but you're willing to move them all), the best way to move the volume is to use the "vol move" command.  If your situation is otherwise, please provide more details on what you want to accomplish.

[DIVIDE1024]

Yes, it just one LUN per volume. But I'm also moving LUN/volumes from one controller to another. I was told by someone to use SnapMirror for this purpose.. what do you think? EMC has a very easy way of just moving volume from one disk group to another... I'm looking for a solution that will not need downtime or any reconfiguration on my systems.

[resqme914]

Assuming 7-mode (which is most likely), and without the use of any 3rd-party "data motion" software, your best bet to avoid any disruption is to move your data via host-based mirroring (i.e. create and present new luns on the other filer then host mirror the old lun to the new lun, then eventually remove the old lun). Snapmirroring the volume/lun from one controller to another will require "downtime" when you switch over.

[DIVIDE1024]

  I'm not familiar with "host based mirroring" what is that? Also I was researching your recommendation of using the "volmove" command, that's looking very promising! Is that what you mean by "host based mirroring"?

[resqme914]

Unfortunately, vol move will not work for you because it's only for within the same controller.  Host-based mirroring is a generic term I used to refer to disk mirroring which is available on most host operating systems.  You have not specified what hosts are using these luns.  If it's Windows or unix, then most likely they will be capable of disk mirroring.

[DIVIDE1024]

Oh, I'm using Windows host connected by ISCSI. So from my understanding it looking like this.

1: For volumes that are in the same controller and need to be migrated to another aggregate I can use the vol move command. (not downtime)

2: For volumes that are in a deferent controller I would need to use Snapmirror. (with downtime to reconnect the new volumes"

Is this correct?

[resqme914]

Yes.

And 3rd option is to host mirror the lun from the old controller to a new, same-size lun on the new controller, then break the mirror when they are in sync, then remove the old lun. (no disruption).

[DIVIDE1024]

  Understood! I like to thank you very much for your help on this. I believe I now have the information I need to complete the task at hand.

[DIVIDE1024]

Oh one more think, I came across this solution called Data Motion for vFiler Migration. What's that about?

[resqme914]

I don't know what the current status is of Data Motion.  You will have to ask NetApp about that.

[DIVIDE1024]

I have a quick question for you. I’m using the “vol move” command to migrate volumes to the new aggregate. In order to use this command I notice that I have to remove the NFS share that ONTAP creates for each volume. My question is what risks if any am I taking by removing the shares so that I can migrate the data? Are these shares critical to the normal operations of
Netapp? Why does DATAON TAP creates these shares?

    I plan on placing the shares back once I’m done with all the migrations. Or should I add them back right after I complete each migration?

Thanks again in advance for all your help!!

[resqme914]

When you use System Manager (and maybe some other utilities, I'm not sure) to create a volume with storage type SAN, an NFS export is automatically created.  Why... I don't know.  I think it's a pain in the neck and I have to keep deleting the exports.  You can safely delete these exports... make sure you're not deleting exports of volumes that are actually being accessed through NFS, if you have any.  And there's no need to add these exports back after your migration.

[JGPSHNTAP]

You need to turn off nfs auto update

options nfs.export.auto-update  off

[DIVIDE1024]

I see. Thank you very much for that info. I will make the changes.. it also seems to be a security best practices to perform this action if your not using NFS shares.