Installing a Failover Cluster

Article
12/03/2008

To install a Microsoft SQL Server 2005 failover cluster, you must create and configure a failover cluster instance by running SQL Server Setup. This topic explains the elements of a failover cluster, as well as important information about naming a failover cluster instance. It also describes basic steps for installing a failover cluster.

Elements of a Failover Cluster Instance

A failover cluster instance can run on one or more computers that are participating nodes of a failover cluster. The number of participating nodes is limited only by the operating system.

A failover cluster instance contains:

A combination of one or more disks in a Microsoft Cluster Service (MSCS) cluster group, also known as a resource group. Each resource group can contain at most one instance of SQL Server.
A network name for the failover cluster instance.
One or more IP addresses assigned to the failover cluster instance.
One instance of SQL Server 2005 that includes SQL Server, SQL Server Agent, and the Full-text Search (FTS) service.

Naming a Failover Cluster Instance

A SQL Server failover cluster instance always appears on the network as if it were a single computer. You must use the SQL Server failover cluster instance name to connect to the SQL Server failover cluster, not the machine name of the node it happens to be running on. Doing so ensures that you are always able to connect to the failover cluster instance using the same name, regardless of which node is running SQL Server.

The name of your failover cluster instance must be unique to your domain. SQL Server does not listen on the IP address of the local servers. Instead, SQL Server listens only on the virtual IP address created during installation of the SQL Server failover cluster instance.

SQL Server depends on distinct registry keys and service names within the failover cluster to ensure that SQL Server functionality continues after a failover. Therefore, the name you provide for the instance of SQL Server, including the default instance, must be unique across all nodes in the failover cluster. Using unique instance names ensures that instances of SQL Server that are configured to fail over to a single server have distinct registry keys and service names.

Considerations for SQL Server Consolidation with a Failover Cluster

When planning to consolidate multiple stand-alone servers to SQL Server failover cluster instances, we recommend, as part of the planning process, that you verify that the cluster node hardware configuration is sufficient to support the number of instances of SQL Server to be hosted.
Presented below are two common scenarios and the basis for the recommended solutions that can be applied to your site configuration.
Scenario 1
You are a hosting site and want to offer up to 23 instances of SQL Server with the following resource requirements:
- 2 processors for 23 instances of SQL Server as a single cluster node would require 46 CPUs.
- 2 GB of memory for 23 instances of SQL Server as a single cluster node would require 48 GB of RAM (2 GB of additional memory for the operating system).
- 4 disks for 23 instances of SQL Server as a cluster disk array would require 92 disks.
  If you limit the failover members to only half of the available nodes, the hardware requirements would be reduced to:
- 23 processors, 24 GB of memory per node, and availability of 46 disks.
  With support for mount points, the total number of disks could be further reduced. SQL Server would require 23 disks each hosting 3-mount points or more, for increased disk space availability.
  A potential limitation is if the processor and memory requirements rise, the existing hardware might not be capable of supporting those requirements without loss of performance to the existing instances of SQL Server.
  Scenario 2
  Migration of existing instances of SQL Server to a failover cluster
  First, you must collect current baselines for the existing servers, noting any existing bottlenecks. Assuming baseline performance statistics provide the following needs, and that a single drive with mount points would cover drive requirements, that would leave you with the following configuration:
- SQL Server 1 - 8 processors, 16 GB of RAM
- SQL Server 2 - 4 processors, 8 GB of RAM (needs RAM, plan for 12 GB)
- SQL Server 3 – 2 processors, 16GB of RAM (baseline shows need for additional processors)
- SQL Server 4 – 4 processors, 8 GB of RAM (needs additional network bandwidth, add network adapters for 4 dedicated connections)
  To replace these four servers, the cluster node would require the following minimum configuration:
- 18 processors, 54 GB of RAM, and 6 network adapters

The process for calculating the minimum configuration for a single node in a failover cluster considers:

Total CPU requirements
Total memory requirements, and
Required disks
Add 2 GB of RAM for the operating system

Note that the disk constraint encountered in previous SQL Server versions does not affect SQL Server 2005. With support for mounted drives in SQL Server 2005, each instance of SQL Server requires just one cluster disk for data files.