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

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.

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Vitor MontalvãoMSSQL Senior EngineerCommented:
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.
NIS_RULEAuthor 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ãoMSSQL Senior EngineerCommented:
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?
The 7 Worst Nightmares of a Sysadmin

Fear not! To defend your business’ IT systems we’re going to shine a light on the seven most sinister terrors that haunt sysadmins. That way you can be sure there’s nothing in your stack waiting to go bump in the night.

NIS_RULEAuthor 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ãoMSSQL Senior EngineerCommented:
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.
NIS_RULEAuthor Commented:
Out of the 250, probably about 30 to 40 are critical  (main customer facing sharepoint sites)
Scott PletcherSenior DBACommented:
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.
NIS_RULEAuthor 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.
Ryan McCauleyEnterprise Analytics ManagerCommented:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Scott PletcherSenior DBACommented:
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 McCauleyEnterprise Analytics ManagerCommented:
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 :(
NIS_RULEAuthor 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!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server

From novice to tech pro — start learning today.