If you are upgrading using old hardware, reusing the former virtual name and IP address is not an issue because the old cluster is brought down, then the new one back up, so there is never a case where the virtual name and IP address could be on two clusters at the same time (which won’t work).
But if you upgrade by using new hardware, you will need to assign a virtual name and IP address for testing, but you won’t be able to use the old ones because they are currently in use. In this case, you will need to use a temporary virtual name and IP address for testing, and when you are ready for the actual changeover from the old to the new cluster, you will need to follow these general steps:
- Secure your data.
- Remove SQL Server clustering from the old cluster, or turn off the old cluster.
- On the new cluster, remove SQL Server 2005 clustering, and then reinstall it using the virtual name and IP address of the old cluster.
- Restore the data.
Uninstalling SQL Server 2005 clustering, and then reinstalling it with the old virtual name and IP address is a pain, but doesn’t take a long time. Besides, this is the only way to change the virtual name or IP address of a SQL Server 2005 cluster install.
Now, how do you move the data from the old cluster to the new? This depends somewhat on whether or not you are using old hardware or new hardware.
If you use old hardware, all you really have to do is to back up the system and user databases, and then detach the user databases. Rebuild the cluster without deleting the backups or detached databases. When the cluster is rebuilt, restore the system databases and reattach the detached databases. This of course assumes that the databases will remain in their current location. If you need to move the databases, then you need to follow the next option.
If you are moving to new hardware, or will be moving the location of the databases on old hardware, you would first do full backups of the system and user databases, and then detach the user databases. Next, move these to the new server, or new location. Then when the cluster is rebuilt, restore the system databases and reattach the user databases.
Because of space limitations, the above steps don’t include all the complex details, such as what happens if the drive letter changes, and so on. The key to success is to plan all of these steps, and if possible, perform a trial run before you do an actual cutover.
Backout Plan
No matter how you decide to upgrade to SQL Server 2005 clustering, you need to have a backout plan. Essentially, a backout plan is what you do if your upgrade fails. I can’t tell you exactly what to do for a backout plan because I don’t know your particular circumstances. But I do know you need a backout plan if the upgrade fails. So as you are planning your upgrade, consider how the plan could fail, and come up with options to get you back in business should things not go well. Your job could depend on how good your backout plan is.
Which Upgrade Option Is Best?
Speaking from personal experience, I always prefer to upgrade by rebuilding my clusters from scratch on new hardware. This is the easiest, fastest, least risky and least stressful way. Unfortunately, you may not have this option for whatever reasons management gives you. In this case, you will have to work with what you have been given. The key to a successful upgrade is lots of detailed planning and testing, and of course, having a great backout plan.
]]>