Microsoft KB Archive/327518

From BetaArchive Wiki

Article ID: 327518

Article Last Modified on 11/21/2007



APPLIES TO

  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2000 Developer Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 7.0 Enterprise Edition



This article was previously published under Q327518

SUMMARY

This article describes the Microsoft support policy for SQL Server failover clustering. Microsoft Product Support Services (PSS) 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

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 Web site:

The Windows Server Catalog replaces the Cluster Hardware Compatibility List (HCL) that is still accessible at the following Microsoft Web site:

The term "server clusters" means computers that run the Microsoft Cluster Service. The Windows Server 2003 family provides the following types of clustering services:

  • Server Cluster (Failover Cluster)
  • Network Load Balancing
  • Compute Cluster Server

Only the 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.

Supported SQL Server failover clustering installations must also follow the Microsoft support policy for server clusters, and the Windows Server Catalog/Hardware Compatibility List.

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

309395 The 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:

810391 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 Cluster Service, you must contact that third party provider for any support issues that are related to SQL Server.

PSS will only support non-Microsoft Cluster Service third party cluster installations as a stand-alone version of SQL Server; PSS will not support this type of cluster installation.

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 failover cluster.

  • 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.

Note If you upgrade Microsoft SQL Server 2000 (32-bit) to Microsoft SQL Server Enterprise Edition (64-bit), SQL Server will still only support four nodes.

Mounted drives

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 number to view the article in the Microsoft Knowledge Base:

819546 SQL Server 2000 and SQL Server 2005 support for mounted volumes


Note SQL Server 2005 failover cluster instances are not supported on failover cluster instance nodes that are used as domain controlers.

MORE INFORMATION

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, PSS will offer troubleshooting tips and provide reasonable support if requested. However, PSS does not guarantee that a resolution will be found for non-Windows Server Catalog/HCL cluster solutions.

For support, follow these steps:

  1. 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.
  2. Upon agreement that no solution is guaranteed, and that no incident refund will be provided, PSS 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, PSS will not troubleshoot the issue and will refund the incident.
  3. PSS will use standard troubleshooting processes to isolate the server cluster issue. Some typical troubleshooting methods that are used by PSS include:
    • 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).
    Note If the cluster is not certified, there is no hotfix support available. PSS cannot determine whether the problem is caused by hardware incompatibility or by unwanted software behavior.
  4. If there is no solution to the problem, PSS 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 Cluster HCL.
    • Having you work with the OEM to get the cluster on the Cluster HCL.
    • Asking you to work with the OEM for a solution.

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 failures.
  • The cluster solution does not correctly isolate the shared disk and host bus adapters (HBAs) from other devices on the shared bus.
  • The SCSI controller does not support operating in a multiple-initiator environment.
  • 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 Resource" type.
  • The SCSI controller does not deploy proper termination.

This list does not include all the issues that can cause problems with a server cluster. None of these issues can be detected by PSS. 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.

Support for mixed 32-bit and 64-bit SQL Server failover cluster instances

Support for mixed 32-bit and 64-bit SQL Server failover cluster instances is based on the following Microsoft Knowledge Base articles. SQL Server criteria for support of this scenario is based on the operating systems requirements and restraints as listed in the Microsoft Knowledge Base articles.

For IA-64 installations, see the following article in the Microsoft Knowledge Base:

312090 Cannot use 32-bit resources on a 64-bit server cluster


For X64 installations, see the following article in the Microsoft Knowledge Base:

875423 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


Warning 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 2000.

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:

905618 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 completing.

Note 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.

REFERENCES

For more information, see the "Failover clustering" topic in Microsoft SQL Server 2005 Books Online or in Microsoft SQL Server 2000 Books Online.

Keywords: kbhowto kbsql2005cluster kbinfo KB327518