USEFUL SITES :
Write for Us
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:
Let's look at all of these options.
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.
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.
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.
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:
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:
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.
