In my previous articles, Planning and Implementing a SQL Server Cluster and Set Up a SQL Server 2008 Cluster, I showed you how to install SQL Server 2008 and SQL Server 2005 in a cluster. In this article, I’ll combine these two installations as I show you how to upgrade an existing SQL Server 2005 cluster to a SQL Server 2008 installation. As we learned when building a SQL Server 2008 cluster in “Set Up a SQL Server 2008 Cluster,” the SQL Server installer has changed quite a bit since SQL Server 2005 was released. These same changes affect the upgrade process as well. To start this process off, I’ll review some of the basic concepts of clustering, and then I’ll guide you through an upgrade of a SQL Server 2005 active/passive cluster to SQL Server 2008.
You might want to consider upgrading your SQL Server 2005 cluster to take advantage of SQL Server 2008’s ability to perform rolling upgrades in the future when patching your cluster. With SQL Server 2005 and earlier, patching a cluster requires the instance to be down while the service pack is deployed. With SQL Server 2008, you patch each node separately, so the only downtime is when you’re moving the instance from one node to another via the typical failover features of Windows clustering.
How Clustering Works
Failover clustering is a fairly basic concept. A service runs on each cluster node looking to see whether the SQL Server service is running on any of the nodes (physical servers). If the SQL Server service isn't running on any of the nodes, it’s started on one of the nodes. What's actually happening under the hood during this process is a bit more complex. When you install SQL Server in a clustered configuration (SQL Server must be installed using the cluster installation tool because you can’t change a traditional single-server installation to a clustered installation), the services are installed on all the cluster nodes. If you open the Services applet in the Administrative Tools menu on any of the nodes, you'll see all the SQL Server services listed with a start-up type of manual. When you move the running service from one node to another, the services are stopped on the original node and started on another node within the cluster.
If the machine running SQL Server goes offline in the event of a hardware failure, the Cluster service on the passive node will detect that the SQL Server machine has gone offline, take ownership of the SQL Server service and other resources in the resource group (e.g., IP address, network name, disk drives), and bring the service back online. With SQL Server 2000, this process can take several seconds to several minutes, depending on how much data is in the transaction log to be rolled forward and back. SQL Server 2008 Enterprise Edition and SQL Server 2005 Enterprise Edition start up much faster because they roll forward any completed transactions, bring the database online, and then roll back any completed transactions. The other editions of SQL Server 2008 and SQL Server 2005 bring the database online after the transactions have been rolled backward and forward.
Clustered SQL Server 2008 servers have many uptime advantages over previous versions and standalone servers. These advantages include the ability to keep a SQL Server system running even after a hardware failure. SQL Server 2008 also gives you the ability to do rolling upgrades, which lets you patch each node of the SQL Server cluster independently of the others without taking the SQL Server system down for several minutes or up to an hour, depending on how long the patch takes to install.
Hardware and Software Requirements
Clustering your SQL Server environment requires two servers and shared storage. Although the servers don't need to be identical, configuration is easier if they are. The servers should at least have the same number of CPUs and the same amount of RAM. It isn't technically necessary for even the CPU count and RAM to match, but matching these counts makes it easier to estimate the amount of load the backup server can take. Using matched servers also gives you the luxury of not having to worry about which server the database is running on, because both servers will perform the same, provided that the backup server has no other tasks.
The storage used for the SQL Server databases can't be the standard RAID array that you plug into the server. Instead, it must be an array designed specifically for use in a cluster. Although Windows Server 2003 supports using SCSI arrays for clustering, Windows Server 2008 doesn’t support using SCSI arrays for clustering your servers. When using Server 2008 to cluster your SQL Server systems, you'll need to use a Fibre Channel RAID array, a Fibre Channel SAN, or an iSCSI SAN. This can present a problem when trying to cluster under Hyper-V or VMware if you don't have a hardware-based iSCSI solution. However, you can use StarWind Software’s iSCSI Target for Microsoft Windows, Nimbus Data Systems' MySAN, or the open-source Openfiler to present local disks from a third server as iSCSI disks to your cluster. You should use caution when using a software iSCSI target because the performance of these software packages will depend on the hardware behind them and the network configuration.