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.