Should You Upgrade Your Current SQL Server Cluster to a SQL Server 2005 Cluster?

If your organization is like many organizations, it may have some older version SQL Server clusters in production. If so, at some point 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.

Let's look at all of these options.

Don't Upgrade

This is an easy decision. It's 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, then 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, then 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, then 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 directly to SQL Server 2005. If you are running SQL Server 6.5, you are out of luck.

Now, assuming you are running Windows Server 2003, let's look at the major steps to performing an upgrade in-place from your current version of SQL Server to SQL Server 2005.

• Insure that your current SQL Server cluster is running 100% correctly. If there are any problems with the current cluster, do not perform an in-place upgrade. It will most likely fail.
• 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 above are successful, you can then perform the upgrade by running the SQL Server 2005 Installation Wizard and following 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.

If you do decide to upgrade in-place, be sure you reserve plenty of downtime to complete the upgrade and for testing, along with including extra time to deal with any unforeseen problems.

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 (because it is either old or underpowered).
• You need to upgrade the operating system.
• The current cluster installation is unstable.
• You have a 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 building the cluster, and at the same time, it helps relieve 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 think 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?
• 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 the cluster's virtual name and IP address. If you want the clients to continue using the same virtual name and IP address to access your cluster, then 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 reuse a single virtual 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).

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.