Export (0) Print
Expand All
0 out of 1 rated this helpful - Rate this topic

Creating a Failover Cluster

SQL Server 2000

To create a Microsoft® SQL Server™ 2000 failover cluster, you must create and configure the virtual servers on which the failover cluster runs. You create virtual servers during SQL Server Setup. Virtual servers are not provided by Microsoft Windows NT® 4.0 or Microsoft Windows® 2000.

To create a failover cluster, you must be a local administrator with rights to log on as a service and to act as part of the operating system on all computers in the failover cluster.

Elements of a Virtual Server

A virtual server contains:

  • A combination of one or more disks in a Microsoft Cluster Service (MSCS) cluster group.

    Each MSCS cluster group can contain at most one virtual SQL Server.

  • A network name for each virtual server. This network name is the virtual server name.

  • One or more IP addresses that are used to connect to each virtual server.

  • One instance of SQL Server 2000, including a SQL Server resource, a SQL Server Agent resource, and a full-text resource.

    If an administrator uninstalls the instance of SQL Server 2000 within a virtual server, the virtual server, including all IP addresses and the network name, is also removed from the MSCS cluster group.

A failover cluster can run across one or more actual Windows 2000 Advanced Server or Windows 2000 Datacenter Server servers or Windows NT 4.0, Enterprise Edition servers that are participating nodes of the cluster. However, a SQL Server virtual server always appears on the network as a single Windows 2000 Advanced Server, Windows 2000 Datacenter Server, or Microsoft Windows NT 4.0, Enterprise Edition server.

Naming a Virtual Server

SQL Server 2000 depends on distinct registry keys and service names within the failover cluster so that operations will continue correctly after a failover. Therefore, the name you provide for the instance of SQL Server 2000, including the default instance, must be unique across all nodes in the failover cluster, as well as across all virtual servers within the failover cluster. For example, if all instances failed over to a single server, their service names and registry keys would conflict. If INST1 is a named instance on virtual server VIRTSRV1, there cannot be a named instance INST1 on any node in the failover cluster, either as part of a failover cluster configuration or as a stand-alone installation.

Additionally, you must use the VIRTUAL_SERVER\Instance-name string to connect to a clustered instance of SQL Server 2000 running on a virtual server. You cannot access the instance of SQL Server 2000 by using the computer name that the clustered instance happens to reside on at any given time. SQL Server 2000 does not listen on the IP address of the local servers. It listens only on the clustered IP addresses created during the setup of a virtual server for SQL Server 2000.

Usage Considerations

Before you create a failover cluster, consider the following:

  • If you are using the Windows 2000 Address Windowing Extensions (AWE) API to take advantage of memory greater than 3 gigabytes (GB), make certain that the maximum available memory you configure on one instance of SQL Server will still be available after you fail over to another node. If the failover node has less physical memory than the original node, instances of SQL Server may fail to start or may start with less memory than they had on the original node. You must:
    • Give each server in the cluster the same amount of physical RAM.

    • Ensure that the summed value of the max server memory settings for all instances is less than the lowest amount of physical RAM available on any of the virtual servers in the failover cluster.

    For more information about AWE, see Using AWE Memory on Windows 2000.

  • If you need high-availability servers in replication, it is recommended that you use an MSCS cluster file share as your snapshot folder when configuring a Distributor on a failover cluster. In the case of server failure, the distribution database will be available and replication will continue to be configured at the Distributor.

    Also, when creating publications, specify the MSCS cluster file share for the additional storage of snapshot files or as the location from which Subscribers apply the snapshot. This way, the snapshot files are available to all nodes of the cluster and to all Subscribers that must access it. For more information, see Publishers, Distributors, and Subscribers and Alternate Snapshot Locations.

  • If you want to use encryption with a failover cluster, you must install the server certificate with the fully qualified DNS name of the virtual server on all nodes in the failover cluster. For example, if you have a two-node cluster, with nodes named test1.redmond.corp.microsoft.com and test2.redmond.corp.microsoft.com and a virtual SQL Server "Virtsql", you need to get a certificate for "virtsql.redmond.corp.microsoft.com" and install the certificate on both nodes. You can then check the Force protocol encryption check box on the Server Network Utility to configure your failover cluster for encryption.

  • The MSCS service account must be a part of the administrator group on each node of the cluster for SQL Server. The IsAlive thread runs under the context of the cluster service account, and not the SQL Server service account. If you remove the MSCS service account, the IsAlive thread will no longer be able to create a trusted connection, and you will lose access to the virtual server.
Creating a Failover Cluster

Here are the basic steps for creating a failover cluster using the Setup program:

  1. Identify the information you need to create your virtual server (for example, cluster disk resource, IP addresses, and network name) and the nodes available for failover.

    The cluster disks to use for failover clustering should all be in a single cluster group and owned by the node from which the Setup program is run. This configuration must take place before you run the Setup program. You configure this through Cluster Administrator in Windows NT 4.0 or Windows 2000. You need one MSCS group for each virtual server you want to set up.

  2. Start the Setup program to begin your installation. After all necessary information has been entered, the Setup program installs a new instance of SQL Server binaries on the local disk of each computer in the cluster and installs the system databases on the specified cluster disk. The binaries are installed in exactly the same path on each cluster node, so you must ensure that each node has a local drive letter in common with all the other nodes in the cluster.

    In SQL Server 2000, during a failover only the databases fail over. In SQL Server version 6.5 and SQL Server version 7.0, both the SQL Server databases and binaries fail over during a failover.

    If any resource (including SQL Server) fails for any reason, the services (SQL Server, SQL Server Agent, Full-Text Search, and all services in the failover cluster group) fail over to any available nodes defined in the virtual server.

  3. You install one instance of SQL Server 2000, creating a new virtual server and all resources.

How to create a new failover cluster

SQL Setup

How to install a one-node failover cluster

SQL Setup

Upgrading to a SQL Server 2000 Failover Cluster

To upgrade from a SQL Server 6.5 or SQL Server 7.0 failover cluster to a SQL Server 2000 failover cluster, you must first uncluster the previous installation. SQL Server 6.5 or SQL Server 7.0 clusters cannot exist on the same computer as a failover cluster. For more information about upgrading, see Upgrading to a SQL Server 2000 Failover Cluster.

To upgrade from a SQL Server 6.5 active/passive failover cluster

SQL Setup

To upgrade from a SQL Server 6.5 active/active failover cluster

SQL Setup

To upgrade from a SQL Server 7.0 active/active failover cluster

SQL Setup

To upgrade from a SQL Server 7.0 active/passive failover cluster

SQL Setup

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.