This article describes the Microsoft support policy for SQL
Server failover clustering. Microsoft Customer Support Services (CSS) supports
SQL Server failover clustering that is based on the failover clustering
features of the Microsoft Cluster Service in the following products:
- Windows 2000 Advanced Server
- Windows 2000 Datacenter Edition
- Windows Server 2003 Enterprise Edition
- Windows Server 2003 Datacenter Edition
- Windows Server 2008 Enterprise Edition
Windows Server 2008 failover clusters only support SQL Server 2005 Service Pack 2 or later versions.Important
Upgrading SQL Server 2000 Enterprise Edition to SQL Server 2005 Standard Edition is not a supported upgrade path. For more information, visit the following Microsoft Developer Network (MSDN) Web site:
If you want a fallback solution when you upgrade the SQL Server 2000 failover cluster instance, we recommend that you perform a new installation of the SQL Server 2005 failover cluster instance because of extreme recovery measures. Then, migrate the data to the new installation. The current installation will remain intact if unforeseen circumstances prevent the SQL Server 2005 installation from completing in a timely manner.
Microsoft server clusters are only supported on cluster
solutions that are listed in the Windows Server Catalog under Cluster
Solutions. To view the Windows Server Catalog, visit the following Microsoft
The term "server clusters" means computers that run the Microsoft
Cluster Service. The Windows Server 2003 family provides the following types of
- Server Cluster (Failover Cluster)
- Network Load Balancing
- Compute Cluster Server
Server Cluster solutions can be used together with SQL Server for high
availability if a node is lost or if a problem exists with an instance of SQL
Server. Network Load Balancing may be used in some cases together with
stand-alone read-only SQL Server installations. SQL
Server Failover Clustered Instances each require a unique group. This
requirement is true on cluster disk resources that use drive letters that are
unique to the cluster and to each SQL Server Failover Clustered Instance. Each
Failover Clustered Instance of SQL Server must also
have at least one unique IP address. Depending on the version that is
installed, multiple unique IP addresses may be possible. Additionally, each
Failover Clustered Instance must have both virtual server and instance names
that are unique to the domain to which the cluster belongs.
SQL Server failover clustering installations must also follow the Microsoft
support policy for server clusters, and the Windows Server Catalog/Hardware
For more information, click the
following article number to view the article in the Microsoft Knowledge Base:
Microsoft support policy for server clusters, the Hardware Compatibility List,
and the Windows Server Catalog
Starting with Windows Server 2003, Microsoft SQL
Server 6.5 and Microsoft SQL Server 7.0 clustering will no longer be supported,
as noted in the following Microsoft Knowledge Base article:
SQL Server 6.5, SQL Server 7.0,
and MSDE 1.0 support on Windows Server 2003
If you cluster SQL Server with any clustering product other than Microsoft Server Clustering, your primary support contact is the third-party cluster solution provider for any support issues that are related to SQL Server. SQL Server was developed and tested by using Microsoft Server Clustering. Third-party clustering solutions that support SQL Server installations should be your primary contact for any installation issues, performance issues, or cluster behavior issues. CSS provides commercially reasonable support for third-party cluster installations in same manner that we do for a stand-alone version of SQL Server.
Number of supported nodes
The following is a list of the number of nodes that are supported
by each version of Microsoft SQL Server:
- Microsoft SQL Server 7.0
Microsoft SQL Server 7.0 supports up to two nodes in a
- Microsoft SQL Server 2000 Enterprise Edition (32-bit)
Microsoft SQL Server 2000 Enterprise Edition (32-bit)
supports up to four nodes in a failover cluster.
- Microsoft SQL Server Enterprise Edition (64-bit)
Microsoft SQL Server Enterprise Edition (64-bit) supports up
to eight nodes in a failover cluster.
- Microsoft SQL Server 2005 Standard Edition (32-bit or 64-bit)
Microsoft SQL Server 2005 Standard Edition supports up to two
nodes in a failover cluster.
- Microsoft SQL Server 2005 Enterprise Edition (32-bit or 64-bit)
Microsoft SQL Server 2005 Enterprise Edition supports up to
eight nodes in a failover cluster.
If you upgrade Microsoft SQL Server 2000 (32-bit) to Microsoft
SQL Server Enterprise Edition (64-bit), SQL Server will still only support four
SQL Server 2008 and SQL Server 2008 R2 information
For SQL Server 2008 and SQL Server 2008 R2 editions, please refer to the following topics in SQL Server Books Online:
In summary, SQL Server 2008 and SQL Server 2008 R2 editions support up to 8 nodes on Windows Server 2003 and 16 nodes on Windows Server 2008 and later versions.
The use of mounted drives is not supported on a cluster that
includes a Microsoft SQL Server installation. For
more information, click the following article numbers to view the articles in the
Microsoft Knowledge Base:
SQL Server support for mounted volumes
SQL Server 2008 setup fails to install on a Windows Server 2008-based cluster mount point
SQL Server 2005 failover cluster instances are not supported on
failover cluster instance nodes that are used as domain controllers.
For more information about installating SQL Server failover clusters in a hardware virtualization environment, click the following article number to view the article in the Microsoft Knowledge Base:
Support policy for Microsoft SQL Server products that are running in a hardware virtualization environment
SQL Server failover clustering for clusters that are not listed on the HCL in the cluster category
If your SQL Server failover cluster solution is not listed in the
Windows Server Catalog/Hardware Compatibility List. as a supported "Cluster
Solution", it is considered unsupported and may yield unexpected behavior.
However, CSS will offer troubleshooting tips and provide reasonable support if
requested. However, CSS does not guarantee that a resolution will be found for
non-Windows Server Catalog/HCL cluster solutions.
For support, follow
- Before any troubleshooting begins, you must contact the
Original Equipment Manufacturer (OEM) to discuss whether your particular
cluster implementation is supportable. The OEM can best answer configuration
and supportability questions for the cluster hardware.
- Upon agreement that no solution is guaranteed, and that no
incident refund will be provided, CSS can troubleshoot the issue. Microsoft
does not guarantee a solution with non-HCL clusters. If no resolution is found,
the incident will not be refunded.
If it is not agreed that a solution
is not guaranteed, CSS will not troubleshoot the issue and will refund the
- CSS will use standard troubleshooting processes to isolate
the server cluster issue. Some typical troubleshooting methods that are used by
Note If the cluster is not certified, there is no hotfix support
available. CSS cannot determine whether the problem is caused by hardware
incompatibility or by unwanted software behavior.
- Use of the Microsoft Knowledge Base. The Microsoft
Knowledge Base is available to customers through Microsoft TechNet, or you can
visit the following Microsoft Web site:
- Determine whether the problem can be replicated on
supported clusters (where possible).
- If there is no solution to the problem, CSS may recommend
some constructive alternatives, which include:
- Having you reproduce the problem on a cluster that is
on the Cluster HCL.
- Asking you to use a cluster solution that is on the
- Having you work with the OEM to get the cluster on the
- Asking you to work with the OEM for a
The hardware specifications for server clusters are extremely
stringent. The Cluster HCL contains a list of known acceptable cluster
configurations that have been tested. You can waste a lot of time by trying to
troubleshoot perceived server cluster issues that are being caused by the
cluster hardware that you are using.
Some examples of hardware
incompatibilities that can cause cluster problems include:
- SQL Server Failover Clustering installation
- The cluster solution does not correctly isolate the shared
disk and host bus adapters (HBAs) from other devices on the shared
- The SCSI controller does not support operating in a
- The HBA does not correctly handle reservations or release
or renew a device on the shared bus.
- The caching mechanism on the controller is incompatible
with the cluster configuration.
- The network adapters for intra-cluster communication have
too high a latency.
- The RAID controller does not correctly replicate
configuration information between controllers.
- The PCI bus is incorrectly configured and has incorrect
adapters in the wrong bus (primary, secondary, tertiary).
- The controllers are incompatible with the "Physical Disk
- The SCSI controller does not deploy proper
This list does not include all the issues that can cause
problems with a server cluster. None of these issues can be detected by CSS.
All these issues would typically be discovered if the complete cluster solution
were tested for Cluster HCL compatibility.
If a complete cluster
configuration is listed for an earlier operating system but is not listed for
the newer operating system that you are using, support as documented in this
section will be followed.
SQL Server 2005 support for mixed 32-bit and 64-bit SQL Server failover cluster
You must be running Windows Server 2003 Service Pack 1 or a later version. For more information, see the following Microsoft Knowledge Base articles. For IA-64 installations, see the following article in the
Microsoft Knowledge Base:
Cannot use 32-bit resources on a 64-bit server cluster
For X64 installations, see the following article in
the Microsoft Knowledge Base:
Support for 32-bit programs on 64-bit server clusters is included in Windows Server 2003 Service Pack 1 and in x64-based versions of Windows Server 2003
Resource DLLs for 32-bit programs cannot run on a 64-bit computer
that is running a 32-bit version of Windows Server 2003 without any service
packs installed. Therefore, you cannot run 32-bit programs on a 64-bit server
cluster. In this scenario, you must use a 64-bit version of the resource DLL.
Limitations of using mixed SQL Server 2000 and SQL Server 2005 failover cluster instances
When you use SQL Server 2000 installations and SQL Server 2005
installations on the same cluster, the SQL Server 2000 installations must be
installed before you install SQL Server 2005 instances locally or as failover
cluster instances. All failover cluster instances will use the SQL Server 2005
Server Cluster resource. This includes the instances of SQL Server
Additionally, after SQL Server 2005 is installed, SQL Server
Native Client is the primary protocol that is used. The changes to the Server
Cluster resource DLL and the primary protocol that is used will prevent
installation of SQL Server 2000 or re-addition of nodes to SQL Server 2000
failover cluster instances. This occurs because neither the resource DLL nor
the primary protocol existed at the time SQL Server 2000 was released and will
not be recognized as a valid Server Cluster resource DLL or as a primary
protocol for SQL Server failover cluster instances.
For more information, click the following article
number to view the article in the Microsoft Knowledge Base:
You may receive a connection error message when you try to connect to an instance of SQL Server 2000 or of SQL Server 7.0 that was installed after you installed SQL Server 2005
Stand-alone installations are not affected during
initial installation like virtual failover cluster instances. In virtual
failover cluster instances, this will prevent the initial installation from
After you install SQL Server 2005, SQL Server Service Manager
displays the node name instead of the virtual SQL Server 2005 server name. It
does this because SQL Server Service Manager was not coded to handle SQL Server
2005, and SQL Server 2005 does not include SQL Server Service Manager.
Windows Server 2008 Failover Clusters
Only SQL Server 2005 Service Pack 2 (SP2) or later versions of SQL Server 2005 are supported with Windows Server 2008 Failover Clusters.
Migrating SQL Server Failover Cluster Instances to New Domain
SQL Server 2000 can be migrated to a new domain while clustered when using domain users for service accounts on Windows 2000 and Windows 2003 server failover cluster. SQL Server 2005 and later versions cannot be migrated to new domain. You will need to uninstall and reinstall the failover cluster components. For more information about how to move a Windows Server cluster from one domain to another, click the following article number to view the article in the Microsoft Knowledge Base:
How to move a Windows Server cluster from one domain to another
Prior to uninstalling SQL Server must be set to use mixed mode security or new domain accounts added to the SQL Server logins and the DATA folder containing system databases must be renamed prior to uninstalling so this folder may be swapped back in once reinstalled to reduce down time. No removal of SQL Server support files, SQL Server Native Client, Integration Services or Workstation Components should be done.
For more information, see the "Failover clustering" topic in
Microsoft SQL Server 2005 Books Online or in Microsoft SQL Server 2000 Books