Link to home
Avatar of NIS_RULE
NIS_RULEFlag for United States of America

asked on

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.

Avatar of Vitor Montalvão
Vitor Montalvão
Flag of Switzerland image

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.
Avatar of NIS_RULE


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.
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?
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.
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.
Out of the 250, probably about 30 to 40 are critical  (main customer facing sharepoint sites)
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.
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.
Avatar of Ryan McCauley
Ryan McCauley
Flag of United States of America image

Blurred text
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
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 :(
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!