Like SQL Server 2005, SQL Server 2008 Standard Edition and Enterprise Edition both support clustering. The Standard edition supports a two-node cluster, and the Enterprise edition supports the maximum number of nodes that the OS supports. Windows 2003 Enterprise Edition supports up to eight nodes in the cluster. Server 2008 Datacenter Edition supports up to 16 nodes when using the x86 or x64 platforms; when using Itanium processors, Server 2008 Datacenter Edition supports up to eight nodes in the cluster.
Server 2008 includes some exciting new features in the clustering configuration that greatly increase the flexibility you can obtain when clustering services. You can now use DHCP for clustering and IP addresses from different subnets for each side of the cluster. The ability to use IP addresses from different subnets is most useful for creating multisite clusters, called geographically distributed clusters.
Planning the Cluster Upgrade
When you’re building a new SQL Server cluster, you have to lay out all your hard disk drives in advance. However, when you’re upgrading a SQL Server cluster, the hard disk drives are already laid out (when the SQL Server 2005 instance was installed). For the purpose of this article, I’ll be using a Windows cluster that has three disks assigned to it: The E drive will hold the data files, the L drive will hold the log files, and the T drive will hold the tempdb database. (Your configuration might vary.)
Also, I’ll be using a cluster very similar to the one that I described in the article Planning and Implementing a SQL Server Cluster. The nodes of the cluster will be called SQL01A and SQL01B. The cluster root name will be SQL01, and the SQL Server instance will be running under the name SQL01V01. Both nodes of the cluster will be running Windows 2003 Enterprise Edition because a SQL Server 2005 cluster probably isn’t running on Server 2008. If your SQL Server 2005 cluster is running under Server 2008, your upgrade process will be very similar, with any differences noted as I walk through the process. As for the IP addresses, the SQL01A node will use the public IP address 10.3.0.31 and the SQL01B node will use the public IP address 10.3.0.32. The cluster root SQL01 will use the public IP address 10.3.0.33, and SQL01V01 will use the public IP address 10.3.0.34.
To begin the installation, first ensure that the SQL Server instances are fully patched and all required Windows 2003 hotfixes are installed. When upgrading a SQL Server 2005 cluster, a rolling upgrade approach is taken, similar to the way a new SQL Server 2008 cluster is installed. You’ll upgrade the active node first, then the passive node. You upgrade the cluster in this way not so that you can fail the instance between the SQL Server 2008 node and the SQL Server 2005 node (in fact, you can’t do this), but so that the installer on the first node doesn’t need permission to run the installer on the second node. After you’ve upgraded the first node, don’t attempt to fail the cluster over to the second node until the second node has been upgraded because the second node still has the SQL Server 2005 version on it, so it won’t be able to read the SQL Server 2008 data files.
Upgrading the Cluster
When you launch the SQL Server 2008 setup on an already installed SQL Server 2005 cluster, you’ll be prompted to install the usual set of Windows and .NET updates, which the SQL Server 2008 installer would install for any Windows 2003 installation.
When upgrading a SQL Server 2005 cluster to a SQL Server 2008 cluster, the installer will do its best to keep the instance online for as long as possible during the upgrade. To do this, when you begin the upgrade process, start on a passive node. If you attempt to start by upgrading the active node, the installer will prompt you to fail over the SQL Server instance to another node before proceeding.
After launching the installer, you’ll be presented with the typical SQL Server Installation Center, which you would typically see when installing SQL Server 2008. In the menu on the left, click Installation, which displays the screen shown in Figure 1.
Typically, when installing SQL Server on a new cluster, you’d select the second option, New SQL Server failover cluster installation. Because you’re performing an upgrade, you’ll select the fourth option, Upgrade from SQL Server 2000 or SQL Server 2005. Selecting this option will launch a separate Upgrade to SQL Server 2008 wizard, which will guide you through the upgrade process. The first thing this wizard will do is open Internet Explorer to the Windows Upgrade page to ensure that you have all the current hotfixes installed. After installing any hotfixes that are missing, you can continue with the installation.
Back in the installer, the SQL Server Installation wizard will check the setup support rules to ensure that the installer can continue. These checks are similar to the checks that the installer runs when performing a new SQL Server 2008 installation. It makes sure that the server OS is supported, that the user has Administrative rights, and that the computer isn’t pending a reboot, among other checks that it performs. After the checks have been completed, click OK to move into the rest of the wizard.
On the next screen, you’ll be prompted to enter your license key. If you have a volume license installer, this field will be filled out for you. Otherwise, you’ll need to enter the key, which is provided by Microsoft on your installation media. On the next screen, agree to the license terms and click Next. Then you’ll be prompted to install the Setup Support Files. Click the Install button to proceed with the installation.
Next, the installer will run another set of checks. These checks ensure that the cluster is ready to continue with the installation. After the checks have been completed, click Next. The next page of the installer shows which instance you want to upgrade. In this case, you’re selecting the default instance (MSSQLSERVER). You can see in Figure 2 that the installer has identified all of the features that are installed on your SQL Server 2005 instance, as well as the version and edition (Developer edition in this case) that you’re upgrading from.
If you have more than one instance installed on the cluster, each one must be upgraded independently of the others.