Upgrading SQL Server Clustering | Professional SQL Server 2005 Administration (Wrox Professional Guides)

If your organization is like most, it probably already has some older version SQL Server clusters in production. If so, you will have to make a choice about how to upgrade them to SQL Server 2005. Your available options include:

Don't upgrade.
Perform an in-place SQL Server 2005 upgrade.
Rebuild your cluster from scratch, and then install SQL Server 2005 clustering.

We'll look at all of these options in this section.

Don't Upgrade

This is an easy decision. Not upgrading is simple and doesn't cost anything. Just because a new version of SQL Server comes out doesn't automatically mean you have to upgrade. If your current SQL Server cluster is running fine, why change it? You are just asking for potential new problems where you have none now, and you will have new costs.

On the other hand, if your current SQL Server cluster is not fine, you have the perfect reason to upgrade. SQL Server 2005 offers many new benefits and they may solve the problems your current cluster is experiencing. But don't automatically assume this is the case. Before you upgrade, do the research to determine if the new features of SQL Server 2005 will actually resolve your problems. If not, sticking with what you know may be the best choice.

Upgrading Your SQL Server 2005 Cluster In-Place

If you decide to upgrade, your next step is to decide whether you want to upgrade in-place or start over from scratch with a fresh install. In this section, we take a look at how you upgrade in-place.

Before we begin talking about how to upgrade a current cluster to a SQL Server 2005 cluster, we first need to discuss what operating system you are currently running. If you are on Windows Server 2003 with the latest service pack, you are in good shape and upgrading to SQL Server 2005 in-place should not be a problem. But if you are not running Windows 2003 Server, then you should seriously consider rebuilding your server nodes so that they are running at the latest operating system level.

The logic behind this is that if you are going to all the trouble to upgrade to SQL Server 2005, you should be running on the latest operating system platform, otherwise, you are not taking advantage of the latest technology and the benefits they bring to high availability. So if you are still running Windows Server 2000 (or earlier), I strongly recommend that you don't upgrade in place. And don't even think about upgrading the operating system in place, then upgrading to SQL Server 2005 in place. You are just asking for trouble.

You can upgrade from a SQL Server 7.0 or SQL Server 2000 cluster to SQL Server 2005. If you are running SQL Server 6.5, you are out of luck.

Assuming you are running Windows Server 2003, these are the major steps to performing an upgrade from your current version of SQL Server to SQL Server 2005.

Ensure that your current SQL Server cluster is running 100 percent correctly. If there are any problems with the current cluster, do not perform an in-place upgrade. It will most likely fail.
Review the preparation steps found later in this chapter, and follow them closely.
Run the free Microsoft ClusPrep utility. It will help you determine if you can perform a successful upgrade. Download this tool from Microsoft's Web site.
Run the SQL Server 2005 Upgrade Advisor to identify any potential issues that should be corrected before the upgrade begins.
Assuming all of the previous steps are successful, you can then perform the upgrade by running the SQL Server 2005 Installation Wizard and follow its instructions. The Installation Wizard will recognize your current SQL Server cluster installation and will guide you through the upgrade.
Once the upgrade is complete, you will want to test the upgrade extensively before releasing it to production.

Even if you will be performing an upgrade, you will want to read this entire chapter in order to familiarize yourself with SQL Server 2005 clustering.

Rebuilding Your Cluster from Scratch

Instead of upgrading in place, it is often a good idea to rebuild your cluster from scratch. This is especially true if any one of the following conditions exist:

You need to upgrade your current hardware (it is either old or underpowered).
You need to upgrade the operating system.
The current cluster installation is unstable.
You have disdain for upgrading software in-place and prefer a fresh install.

If you do decide to upgrade from scratch, you have to decide whether you will be installing onto new hardware or will be using your old hardware.

If you install on new hardware, you have the convenience of building the cluster, and testing it, at your own pace, while the current cluster is still in production. This helps to ensure that you have done an outstanding job and at the same relieves some of the stress that you will experience if you have to reuse your old hardware and then rebuild the cluster during a brief and intense rebuild.

If you don't have the luxury of new hardware, and have to use your old hardware, you will have to identify a good time so that your system can be down while the rebuild occurs. This could range from a 4 to a 12 hour period, depending on your particular circumstances. Besides the time your cluster will be down, there is also the added risk of unexpected problems. For example, you might make an installation mistake halfway through the upgrade and have to start over. Because of the uncertainty involved, you should first estimate how much time you thing the upgrade will take under good circumstances, and then double this time as the size of your requested window of downtime. This way, your users will be prepared for the worst.

Whether you upgrade using new hardware or old hardware, there are two additional issues you will have to consider. Will you reuse your current virtual server name and IP address or select new ones? And how will you move your data from the old cluster to the new cluster? Let's look at each of these issues, one at a time.

The clients that access your current SQL Server cluster do so using a cluster's virtual name and IP address. If you want the clients to continue using the same virtual name and IP address, you will need to reuse the old virtual name and IP address in the new cluster. This is the most common approach because it is generally easier to change a single virtual name and IP address than reconfiguring dozens, if not hundreds, of clients who access the cluster.

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).

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, these steps don't include all the gory 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. We can't tell you exactly what to do for a backout plan, because we don't know your particular circumstances. But we do know that 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, we always prefer to upgrade by rebuilding 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 as much testing as possible, and of course, having a great backout plan.