Migrate storage for SQL Cluster using snapmirror

[Willybobs27]

I have multiple Microsoft 2000/2003 Clusters running SQL 2000 and am required to migrate all databases to new storage.

One option is:

Snapmirror all the existing volumes then.

Stop SQL services

Update the snapmirror

Break the Snapmirror relationship to make the mirrored data read / write

Present the mirrored LUNs to the SQL cluster

Assign the new LUNs the drive letters of the existing LUNs

Start up SQL

My concern is that there may be an issue with Cluster didk signatures etc.

Has anyone done this? Is there a flaw to this approach?

[BrendonHiggins]

Hi

We have moved our SQL volumes between aggergates and between filers using these steps:

• Setup snapmirrors
• Offline SQL and LUNs
• Note the LUN serial number on the filer ~ CLI to filer lun show -v {Snapmirror changes this}
• Powerdown the host
• Create LUN snapshoot and update snapmirror
• Break mirror
• Remove the initiators between the host and the old filer
• Set the LUN serial number of the destination
• Bring the luns online
• Set the initiators between the host and the new storage
• Power on the host
• Start cluster service
• Start snapdrive service
• Connect the LUNs ~ Resolve issue if required
• Confirm all the luns are correct
• Start SQL

Works for use

Bren

[radek_kubka]

Hi Bren,

Quick question re this:

Note the LUN serial number on the filer ~ CLI to filer lun show -v {Snapmirror changes this}
     [...]
Set the LUN serial number of the destination

Are you sure it is necessary? If that would be the case, then recovery times for a DR plan in similar environment should be substantially increased.

I always thought Windows is blind for LUN serial number & the fact that LUNs at the destination have the same signatures are good enough to seamlessly recover.

(After quick web research I am doing at this very moment it looks to be slightly more complex, e.g.:

http://windowsitpro.com/article/articleid/84495/jsi-tip-9797-windows-server-2003-may-mistake-a-new-lun-storage-device-for-a-former-lun-storage-device-...

But it is still for me hard to believe LUN serial number fix would be required for a site-to-site failover...)

Kind regards,
Radek

[BrendonHiggins]

If you want to power down your servers and move the luns and then just start the servers without any changes. Change the ID.

If you want to discount the drives, move luns and then reconnect disks in snap drive. There is no need to change the ID.

I use both methods without issue.

Bren

[VIRTUALLYMIKEB]

Brenden,

Thanks for the sequence of events.  One thing to note, though, for those folks using SnapDrive and SMSQL; the final snapshot should be taken with SMQL/SnapDrive in order to successfully mount the LUN on the far end.  If the snapshot is not taken or taken via the CLI or System Manager, you'll receive an error stating, "Unable to find a Snapshot copy containing a consistent LUN to restore."

You can see this thread for the idea: https://communities.netapp.com/thread/15903

Cheers,

Mike Brown

http://VirtuallyMikeBrown.com

https://twitter.com/VirtuallyMikeB

http://LinkedIn.com/in/michaelbbrown

[thomas_glodde]

if possible, most secure & clean way is to disconnect using snapdrive and then reconnect, all while server is still runing but SQL services stop

ped. this makes sure you really have the correct disks at the right driveletter/mountpoint.

i strongly suggest a full reboot of the server after everything was moved & changed anyway to make sure its all reboot persistent.

[k_madikiri]

Hi Willybobs,

good day!

what method did you follow, please could you let me know as i am in a similar situation and wanted some advise.

many thanks

KK

[thomas_glodde]

KK, follow the method brandon provided, it works. Have done it like this a hundred times.

[k_madikiri]

Thanks Thomas!

i will give it a try.

Kind regards

KK