migrate a san volume from a 32bit aggregate to 64bit aggregate

[mdvillanueva]

Hello Experts,

I am trying to think of a way to migrate a SAN volume without needing to change so much on the host level, in which the LUNs are mapped. Here is what I am thinking, can you please let me know if it is possible?

1. Snapmirror sanvol1 to SM_sanvol1

2. Once in sync, schedule a cutover date.

3. shutdown SQL server

4. Perform finaly sync.

5. Break SnapMirror

6. rename sanvol1 to sanvol1_old

7. rename SM_sanvol1 to sanvol1

8. make sure sanvol1 has all the inititators

9. Turn on SQL server

Will this work? I am trying to minimize the tasks that need to be performed. I inherited an environment in which alot of Netapp management tools such as SnapDrive is not in place.

Thanks in advanced.

[billshaffer]

Snapmirror will migrate the data, but you'll need to create the luns and mappings again.  When you rename the volume, the lun names will be renamed as well.  Make sure you get all the lun ID info before you do anything....

You'll also want to make sure you keep the lun serial numbers; otherwise you could confuse SQL.  Get the current lun serial # with lun show -v <path> or lun serial <path>; set the lun serial with lun serial <path> <serial>.  Set the old lun serial to something else, and set the new lun serial to what the old one was.

Other than that, you're right on.

Hope that helps

Bill

[mdvillanueva]

When you say create do you mean from SnapDrive? Connect, maybe but not create.

When you rename volume, the lun will be renamed as well? That is also wrong.

[billshaffer]

I stand corrected - I recall migrating luns this way in the past, and having to do this, but maybe I'm just remembering having to remap the new luns.  Sorry for the incorrect information.

The lun serial # note, however, is still correct (at least it was an issue for exchange luns, so I'm assuming SQL will want the same serial # as well).

Thanks, mdvillanueva, for setting me straight...

Bill

[mdvillanueva]

Thanks Bill.

I have been testing and here is what I confirmed so far.

-renaming the volume is non issue.

-renaming the LUN is non issue

-changing LUN ID is also non issue.

I will test other scenarios of change.

[shaunjurr]

Ever thought about 'vol move'?  It basically does what you are considering but much more "automagically"...

S.

[mdvillanueva]

The problem with that is that we have to do the move in one go. We will not have the option of performing a baseline, then series of updates, thepick a cutover date for the final update then migrate.

[shaunjurr]

I think if you read the 'vol' manpage you will find that you can do this too, not that it really makes any difference. You could sync with snapmirror ( also an element of 'vol move') for a year before you did the final move. It doesn't matter really when you start. When you decide to do the cutover, it just does all of the necessary operations in the background with the added advantage that you don't have to eve stop your server.

I don't see the point in your objections.

S.

[mdvillanueva]

Thanks. Sorry, don’t mean for it to sound like an objections, only soliciting more information.

Will it repoint initiators and serial number for a LUN? As much as possible I would like to minimize the tasks that need to be done on the client level, specially since we have a lot of MS SQL clusters and also the Exchange.

[shaunjurr]

Yes. If you are running ONTap 8.1 or better, then vol move is your tool for moving volumes (and accompanying LUNs). The limitations are, unfortunately, that your volumes (and LUNs) are in vfiler0 if you are using Multistore on 7-Mode. Cluster Mode just does this as part of it's normal magic although I don't know how often you'll encounter 32-bit aggregates there. 64-bit aggregates in ONTap 7.3.x also have had some performance problems, so you might want to do a bit of testing before you jump in with both feet.

S.