This is NOT my choice, but I am being forced to plan for migrating my 2 SQL database clusters (SQL 2000 SP3 running on Windows 2000 Advanced Server SP4) from their current SAN environment to a new SAN environment (from EMC Clariion to IBM DS4300).
The SAN hosts a quorum disk, a data disk and a log disk for both clusters. Each cluster is a 2-node Active/Passive cluster.
I have never done anything like this before and neither has the 3rd party contract service provider charged with making it happen. They did prepare a 56-step plan for the migration (plus 14 steps for backing out), but I wondered if anyone here had any experience in this realm.
We have a 4-hour window to complete the migration; realistically that is not enough time to perform a bare-metal install (which I would almost prefer to do). Your thoughts and comments are welcome (prayers are welcome, too).
Regards,
hmscottAssuming that you have two complete sets of hardware (SAN, server, infratructure), this is relatively easy. Run both systems in parallel, loading the new system from a dump of the existing one. At a point in time near cutover, do a full dump/restore. Once you reach user downtime, do a differential backup and restore it to the new box. Change the cluster ip address of the new cluster to that of the existing cluster, and you ought to be "up and running" with little fuss, muss, or bother.
It helped that we did this three times for QA before we had to do it in production. The confidence and having the bugs worked out helped a lot.
-PatP|||Nope, I do not have 2 complete sets of hardware. I have 2 clusters currently running in production (each with 2 nodes). I do not have any additional server hardware to allocate.
I do (or will) have two complete SANs (an existing EMC Clariion CX500 and a proposed IBM DS4300).
I have raised the possibility of consolidating the two clusters prior to the migration (which would yield 2 "free" servers), but this has not yet been accepted (the two clusters operate in different subnets).
Regards,
hmscott
Assuming that you have two complete sets of hardware (SAN, server, infratructure), this is relatively easy. Run both systems in parallel, loading the new system from a dump of the existing one. At a point in time near cutover, do a full dump/restore. Once you reach user downtime, do a differential backup and restore it to the new box. Change the cluster ip address of the new cluster to that of the existing cluster, and you ought to be "up and running" with little fuss, muss, or bother.
It helped that we did this three times for QA before we had to do it in production. The confidence and having the bugs worked out helped a lot.
-PatP|||Ok, then another scenario that we looked at was to install both SANs at the same time. In other words have one SAN available as drive X and the other available as drive Y. Periodically move one database at a time using detach/attach, as database usage permits. This avoids the trauma of dropping the whole load at once, and allows some "practice" on the less critical elements.
It is relatively ugly if you need to move master, model, and msdb too. If you need to do that, then what you have to do becomes a bit more complex, but it isn't a "show stopper" either.
-PatP|||What about the Quorum disk? That's the one I am stuck on. Moving the databases doesn't bother me too much. I've done master, model, tempdb and msdb before; but I am more concerned with MSCS and how it will react.
Thanks for your quick input. I've always been grateful for the responses received here.
hmscott
Ok, then another scenario that we looked at was to install both SANs at the same time. In other words have one SAN available as drive X and the other available as drive Y. Periodically move one database at a time using detach/attach, as database usage permits. This avoids the trauma of dropping the whole load at once, and allows some "practice" on the less critical elements.
It is relatively ugly if you need to move master, model, and msdb too. If you need to do that, then what you have to do becomes a bit more complex, but it isn't a "show stopper" either.
-PatP|||The exact details escape me, but I can find them. The gist of the idea is:
1) Break the SQL cluster
2) Down the SQL Servers
3) Copy the files wholesale disk X to Y
4) Swap drive letters X with Y
5) Bring the SQL Servers back up
6) Reunite (heal) the cluster.
-PatP|||Okay, I think that's what the 3rd party service provider is also saying. I'm still trolling through MS for references on moving the quorum disk. If you know of any KBs off the top of your head, I would be grateful.
Have you done this before? Do you know anyone who has?
Again, thanks for your responses.
Regards,
hmscott
The exact details escape me, but I can find them. The gist of the idea is:
1) Break the SQL cluster
2) Down the SQL Servers
3) Copy the files wholesale disk X to Y
4) Swap drive letters X with Y
5) Bring the SQL Servers back up
6) Reunite (heal) the cluster.
-PatP|||I'd go to IBM for that information. As SAN vendors, they can get propaganda from Redmond that isn't available to mere mortals.
The problem is that from the Microsoft/SQL Server perspective, if you do this little slight of hand right, nothing at all happened. MS-PSS really doesn't do much with it, because from their perspective its a non-issue.
There's an ADC in Dallas that is quite familiar with the process. He's actually done this several times (I've only done this once). I'll see if he can scare up any documentation for the process that he can give me without needing blood first.
-PatP|||That would be most excellent. I have found a few documents on MS support site. Most are only tangentially related, though one seems pretty close to the mark (280353).
I really wish I did not have to do this, but our organization just switched to a single-source contract with IBM.
Thanks again,
hmscott
