Assuming you read my previous article, "Planning and Implementing a SQL Server Cluster," December 2008, you know the overall process of preparing for and installing a SQL Server cluster. If you intend to set up a cluster in a SQL Server 2008 environment, you may not realize that the process of installing a clustered SQL Server configuration has changed dramatically in SQL Server 2008. I'll help you navigate that process by giving a brief overview of clustering, then guiding you through the steps needed to set up clustering for a SQL Server 2008 system running under Windows Server 2008. Note that this article assumes that Server 2008 has been installed in full mode and not Server Core mode. Configuring a server for clustering in core mode is more difficult because it's all done from the command line, which is beyond the scope of this article.
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, then it is 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, as there's no way to change a traditional single-server installation into 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.
When 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 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 2005 Enterprise Edition and SQL Server 2008 Enterprise Edition start up much faster because they roll forward any completed transactions, bring the database online, then roll back any completed transactions. The other editions of SQL Server 2008 and 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. This includes the ability to keep a SQL Server system running even after a hardware failure. A new feature in SQL Server 2008 is the ability to do rolling upgrades. This lets you patch each node of the SQL Server cluster independently of the others without taking the SQL Server 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 as well as 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 technically isn't 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 can't be the standard RAID array that you plug into the server. Instead it must be an array designed specifically to be used in a cluster. Although Windows Server 2003 still supports using SCSI arrays for clustering, Server 2008 has removed support for using a SCSI array 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 array that can present its disks over iSCSI to the servers. 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 Rocket Division Software's StarWind 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 as performance from these software packages will depend on the hardware behind them and the network configuration.
Like SQL Server 2005, SQL Server 2008 supports clustering using both the Standard and Enterprise editions. 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 supports up to eight nodes in the cluster. Server 2008 supports up to 16 nodes when using the x86 or x64 platforms; when using Itanium processors, Server 2008 supports up to eight nodes in the cluster.
When Server 2008 was released, included in the clustering configuration were some exciting new features that greatly increase the flexibility you can obtain when clustering services. The biggest changes are that you can now use DHCP for clustering and use 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.