How to migrate SQL 2012 Cluster to new SAN storage without down time?

NIS_RULE
NIS_RULE used Ask the Experts™
on
We have a 2 node SQL cluster (Vmware 6.0,  Windows 2012, SQL 2012) in an active/Passive model.  Both nodes currently connect via iscsi (through windows iscsi initiator) to shared LUNs on a equallogic SAN.

We are replacing the aging equallogic with a new Compellent SAN.

Are there any articles/KB/discussions out there on how to do a migration of the shared iscsi sql disks to a new iscsi SAN with minimal (or better, zero) down time?

The SQL DB's host our main web site and we can't afford to have much down time (anything more than a couple of minutes is too much).  

Anyone have any recommendations/experienceon how to get this done?

We can do the OS/Swap disks via vmware storage vmotion as they are VMDK's.  but the data/log disks for sql are shared iscsi luns on the SAN and equallogic doesn't talk to Compellent so we can't do a copy directly.


Thanks
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Vitor MontalvãoIT Engineer
Distinguished Expert 2017

Commented:
Are the SAN systems from the same vendor or compatible at least?
If so I think you can replicate the storage online without stopping the SQL Server service. What it does is to copy the storage from the old system to the new one but keeping both available and perform writes on the new storage and reads on the old one. After replication finish you can disconnect the old SAN.
For better understanding contact you SAN vendor.

Author

Commented:
Unfortunately they are not compatible with eachother.  While both are sold by Dell, the old one is equallogic while the new one is compellent.  They cannot replicate to eachother.  I've already contacted the vendor and they do not know if a way to migrate data between the two units.
Vitor MontalvãoIT Engineer
Distinguished Expert 2017

Commented:
That's pitty. So, you'll need a downtime period but a couple of minutes is asking to much. Maybe 10 or 15 minutes will be more affordable.
How big is the database? Or there are more than one database?
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Author

Commented:
There's somewhere on the order of 250 databases totaling about 3 TB of data.  It would take more than just 10 or 15 minutes to copy that much data.
Vitor MontalvãoIT Engineer
Distinguished Expert 2017

Commented:
And all databases are that critical or you can do it by phases? First those one that can be offline out of working hours and so on, letting the critical ones for the last.

Author

Commented:
Out of the 250, probably about 30 to 40 are critical  (main customer facing sharepoint sites)
Scott PletcherSenior DBA
Most Valuable Expert 2018
Top Expert 2014

Commented:
You could do full backups on the existing instance and restore them on the new instance with norecovery.  Then, for the actual cut-over, do a differential backup on the old instance, after everyone is disconnected, and apply the diffs to the new instance, and recover the dbs.

Author

Commented:
There is no new instance.  We're keeping the SQL servers in the cluster the same.  Not creating new instances as there are too many apps that would require updating to point to a new instance (some requiring a full uninstall/re-install in order to point to a different sql instance).

We are simply looking to move the data that's on iscsi LUNs on the old SAN to iscsi LUNs on the new SAN with as little down time (preferably zero) as possible.
Senior Data Architect
Commented:
Here's another approach that might afford you some very minimal downtime, though with some significant additional effort on your part (which, honestly, will be the tradeoff for minimal downtime):

1. Take your source database ("SourceDB") and set up transactional replication to a database on the same instance called "SourceDB_new" (or whatever), located on the new SAN (presumably, mounts from both are available on your cluster and the fiber is set up to both homes.
2. When you're ready to cut over, check replication to ensure it's up to date (or as up to date as it's going to get, depending on transaction volume).
3. Put "SourceDB" into READ_ONLY mode to stop updates
4. Check to ensure that replication is still up to date
5. Rename the old database to "SourceDB_old" (starting your downtime)
6. Rename the new database to "SourceDB" (ending your downtime)
7. Repeat for every "critical" database you have

This way, you stay on the same cluster. That should also keep downtime extremely limited, though at the cost of setting up replication for every single database you consider critical. If any of the remaining 200 or so databases can be moved traditionally (detach, copy to folder on new SAN, reattach), I'd encourage you to proceed that way with those since it's easier.
Scott PletcherSenior DBA
Most Valuable Expert 2018
Top Expert 2014
Commented:
Like what I described above, you might also consider a similar method but without the hassle of replication:

1) backup and restore, with norecovery, all existing databases to a new db name hosted on the new SAN
2) just before the cutover, take differential backups and apply them, with norecovery
3) at cutover time, stop all external connections, take tran log backups of current dbs
4) apply the tran log backups, with recovery, to the new db names
5) rename the original dbs
6) rename the new dbs to the original db names
7) re-allow external connections
Ryan McCauleySenior Data Architect

Commented:
If you can stomach the slightly longer downtime, then backups will for sure will be simpler - it just depends on how long each would take and how much tolerance you have for the outage you'll be taking.

I support the point to both of these options is that there isn't a zero-downtime choice, but we can get you close :(

Author

Commented:
Thanks for the ideas guys.  I found an article online that describes how to convert an iscsi shared disk to a shared vmdk.  Only requires a reboot (which in our case is usually 30 seconds or less).  So only down time would be about 30 seconds + amount of time needed to change a couple of settings in vmware.

We're going to try that in a test environment to see how well it works.  Then if that doesn't work, we're going to use the backup/restore method you guys recommended.  thanks!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial