SQL Server 2005 Server Clustering | Microsoft SQL Server 2005: The Complete Reference: Full Coverage of all New and Improved Features

Now that you have had a crash course in clustering, it is time to look at a SQL Server cluster that is a group of Window Server 2003 servers-nodes-that are grouped together and appear as a single system to clients. As for the Windows Server 2003 operating system, the base operating system must be either Windows Server 2003 Enterprise or Datacenter Server. The clustering also appears to administrators as a single system, rather than separate computers, no matter what server they are actively managing.

Besides the SQL Server binaries, a server cluster runs two separate groups of software to support cluster-aware applications. There is the group that runs the cluster, called the clustering software, and the group used to administer the cluster, which is the administrative software.

Clustering Software

The clustering software allows the nodes to communicate with each other over a high-speed interconnect network that runs between the nodes, which is also known as the “heartbeat” connection. The network between the nodes is a dedicated high-speed network that is in no way connected to the local area network. It is specifically dedicated to the messages that travel between the nodes. The messages that travel across the interconnect network trigger the transfer of resources upon a fail-over event, such as the shutdown of a service on one end of the disaster scale and the crash of the entire server on the other end.

The Cluster Service also includes software called the Resource Monitor. The Resource Monitor manages the communication between the Cluster Service and application resources. The Cluster Service runs under the control of the Service Control Manager on each node in the cluster. Its role is to control the activity, the intercommunications between the nodes, and the failure procedures.

The Cluster Service takes control of disaster on two fronts. First, if SQL Server on the active node fails, this signals the Cluster Service to try to restart SQL Server. If the SQL Server cannot restart or the failure is more severe, the Cluster Service will fail over to one of remaining nodes in the cluster and force the new node to become the primary server, or the active node.

The Administrative Software

As an operating system administrator, you use the cluster management software to configure, control, monitor, and maintain the cluster nodes. Windows Server 2003 includes the Cluster Administrator software for cluster administration. The software is installed when you add the Cluster Server components to the node. The Cluster Service can also be administered from the command line using the cluster command.

Understanding and knowing how to work with the Cluster Service in Windows Server 2003 is not necessarily something the DBA needs to do. But administration of Windows Server 2003 is a prerequisite course for Microsoft DBA certification and includes cluster administration.

When configuring clustering, you cluster resources into functional units, called groups. The groups are then assigned to individual nodes. If a node freaks out, the Cluster Service will transfer the groups that were being hosted by the dead node to the other nodes in the cluster. This is essentially the definition of fail-over. There a reverse process known as fail-back. When fail-back takes place, the failed node becomes active again. The groups that were failed over to other nodes are then transferred back to the primary node.

SQL Server 2005 Enterprise Edition and SQL Server 2005 fail-over clustering provide high-availability support. As described earlier in the discussion on fail-over or cluster models you can configure a SQL Server cluster to fail-over to a secondary node if the primary fails. This lets you minimize system downtime, and thus provide high server availability.

There are specific installation steps and configurations that must be followed to use fail-over clustering:

First you need to specify multiple IP addresses for each virtual server that you create. SQL Server 2005 lets you to use the available network IP subnets, which provides alternate ways to connect to the server if one subnet fails. This also results in increased network scalability. On a single network adapter, for example, a network failure can disrupt operations because clients will not be able to connect to their databases. But with multiple network cards in the server, each network can be sitting on a different IP subnet. Thus, if one subnet fails, another can continue to function and provide service to the clients. Even if a router fails, MSCS can continue to function, and all IP addresses will still work. But if the network card on the local computer fails, well then, you have a problem. It is also common practice to place a redundant network card in the server and have it on standby in the event the primary card fails.
Next you need to administer a fail-over cluster from any node in the clustered SQL Server configuration. To set up the Cluster Service, you must be working from the node in control of the cluster disk resource. This computer is often referred to the node that owns the disk resource, a shared array of SCSI disks, usually in RAID-5 configuration.
You must also allow one virtual server to fail over to any other node on the fail-over cluster configuration. And you must be able to add or remove nodes from the fail-over cluster configuration using the setup program.
The setup program will allow you to reinstall or rebuild a virtual server on any node in the fail-over cluster without affecting the other nodes.
To perform full-text queries by using Microsoft Search service with fail-over, clustering also needs to be specifically configured.

Fail-over clustering also supports multiple instances. You will find that multiple instance support makes it easier to build, install, and configure virtual servers in a fail-over cluster. Your applications can easily connect to each instance on a single server just as they connect to instances of SQL Server running on multiple computers with no fancy clustering in place.

With multiple instance support, you can isolate work environments. For example, you can isolate development systems and testing systems from production systems or volatile application environments. You can also provide a different system administrator for each instance of SQL Server residing on the same server.

Modeling the Multinode Cluster

Before you install a SQL Server 2005 fail-over cluster, you must select the hardware and the operating system on which SQL Server 2005 will run. You must also configure Microsoft Cluster Service (MSCS), and review network, security, and considerations for other software that will run on your fail-over cluster. Before you begin the fail-over cluster installation process, review the items that follow.

Verify Your Hardware Solution

Your hardware must be listed on the Microsoft Windows Catalog and Hardware Compatibility list. The hardware system must appear under the category of a cluster solution.

Note

Individual cluster components added together do not constitute an approved system for fail-over clustering. Only systems purchased as a cluster solution and listed in the cluster group are approved. When checking the Microsoft Windows Server Catalog and Windows Hardware Compatibility List, specify “cluster” as the category. All other categories are for OEM use. For more information, see the Microsoft support policy for server clusters, the Hardware Compatibility List, and the Windows Server Catalog.

Special hardware compatibility testing is necessary when implementing a fail-over server cluster on a storage area network (SAN). The entire hardware solution must be in the Cluster/Multi-cluster Device category of the Microsoft Windows Catalog and Hardware Compatibility List. For more information, see the Microsoft Knowledge Base for hardware compatibility and support for multiple clusters attached to the same SAN device.

If the cluster solution includes geographically dispersed cluster nodes, additional items like network latency and shared disk support must be verified. The entire solution must be on the Geographic Cluster Hardware Compatibility List. For more information, see the Microsoft Knowledge Base article “Windows Clustering and Geographically Separate Sites.”

SAN configurations are also supported on Windows Server 2003. The Microsoft Windows Catalog and Hardware Compatibility List category “Cluster/Multi-cluster Device” lists the set of SAN-capable storage devices that have been tested and are supported as SAN storage units with multiple MSCS clusters attached. By matching the devices on this list with the complete cluster configurations defined in the Microsoft Windows Catalog and Hardware Compatibility List cluster category, it is possible to deploy a set of Windows servers and clusters on a SAN fabric with shared storage devices in a way that is supported by Microsoft.

Consider quorum disk resource sharing. In a server cluster, the quorum disk contains a master copy of the server cluster configuration and is also used as a tie-breaker if all network communication fails between cluster nodes. Depending on the type of server cluster you implement, the quorum disk may or may not be a physical disk on the shared cluster disk array. Although it is best to reserve an entire cluster disk for use as the quorum disk, resources other than the quorum resource may be permitted to access the quorum disk.

However, making the quorum resource share the same disk with other resources forces you to choose between two undesirable alternatives. Either you must configure the resource so that its failure does not affect the group, or you must allow the group to be affected by the other resource’s failures. In the first case, you lose fail-over support for the resource; in the second, the quorum resource fails over along with the rest of the group that contains both the quorum resource and the failed resource. As a result, the entire cluster is offline for as long as it takes the group to fail over.

Verify Your Operating System Settings

Make sure that your operating system is installed properly and designed to support fail-over clustering.

Enable Windows Cryptographic Service Provider (CSP) on Windows Server 2003. If the CSP service is stopped or disabled on any cluster node, SQL Server Setup will fail with a Windows Logo Requirement dialog.

Enable the Task Scheduler service on all operating systems. If the Task Scheduler is stopped or disabled, SQL Server Setup will fail with Error 1058. For more information, see “How to: Enable Windows Task Scheduler Service in SQL Server Books Online.”

SQL Server 2005 supports mount points; the clustered installations of SQL Server are limited to the number of available drive letters. Assuming that you use only one drive letter for the operating system, and all other drive letters are available as normal cluster drives or cluster drives hosting mount points, you will be limited to a maximum of 25 instances of SQL Server per server.

A mounted volume, or mount point, allows you to use a single drive letter to refer to many disks or volumes. If you have a drive letter, D:, that refers to a regular disk or volume, you can connect or “mount” additional disks or volumes as directories under drive letter D: without the additional disks or volumes requiring drive letters of their own.

Special Mount Point Considerations for SQL Server 2005 Fail-Over Clustering

The base drive, the one with the drive letter, cannot be shared among virtual servers. This is a normal restriction for virtual servers, but is not a restriction on stand-alone, multiinstance servers.

Take extra care when setting up your virtual server to ensure that both the base drive and the mounted disks or volumes are all listed as resources in the resource group. SQL Server Setup will not take care of this automatically, nor will SQL Server check for this during CREATE/ALTER DATABASE.

Ensure that the mounted disks or volumes are mounted under the correct lettered base drive.

Configure Microsoft Cluster Server

The Microsoft Cluster Server must be configured on at least one node of the cluster. MSCS is only supported if it is installed on a hardware configuration that has been tested for compatibility with the MSCS software. You will know soon enough if you can cluster your systems, as the cluster setup process does this check for you.

The MSCS must also be able to verify that the virtual server is running by using the IsAlive thread. This requires connecting to the server using a trusted connection. You must ensure that the account that runs the Cluster Service is configured as an administrator on all nodes in the cluster, and that the BUILTIN \Administrators group has permission to log in to SQL Server. These permissions are set by default, so these settings will change only if you change permissions on the cluster nodes.

If the BUILTIN\Administrators account is removed, ensure that the account that the Cluster Service is running under can log in to SQL Server for the IsAlive check. If it cannot, the IsAlive check will fail. The MSCS Cluster Service account must have sysadmin rights to SQL Server. These are configured automatically by the SQL Server setup process.

Other Software Considerations

Before installing SQL Server 2005 on a fail-over cluster, install and configure the Microsoft Distributed Transaction Coordinator (MS DTC). SQL Server 2005 requires MS DTC in the cluster for distributed queries and two-phase commit transactions, as well as for some replication functionality.

After you install the operating system and configure the base cluster, install and cluster the MSDTC as a cluster resource in its own group. This help ensure availability between multiple clustered applications (such as Microsoft Exchange, which also depends on the MS DTC resource).

Disk drive letters for the cluster-capable disks must be the same on all nodes to which the service can fail over. Ensure that all cluster nodes are configured identically, including COM+, disk drive letters, and users in the administrators group.

Verify that you have cleared the system logs in all nodes and viewed the system logs again. Ensure that the logs are free of any error messages before continuing.

If you install SQL Server 2005 into a Windows Server 2003 cluster group with multiple disk drives and choose to place your data on one of the drives, the SQL Server resource will be set to be dependent only on that drive. To put data or logs on another disk or use additional disk resources, you must first add a dependency to the SQL Server resource for the additional disk.

Network Considerations

To ensure that all clients can find your virtual server name, your MSCS solution should include use of a WINS server for NetBIOS resolution. WINS of course is not necessary if your clients are fully Active Directory and DNS integrated.

Verify that you have disabled NetBIOS for all private network cards before beginning SQL Server Setup.

The network name and IP address of your SQL server should not be used for any other purpose, such as file sharing. If you want to create a file share resource, use a different, unique network name and IP address for the resource.

SQL Server 2005 supports both named pipes and TCP/IP sockets over TCP/IP within a cluster. However, it is strongly recommended that you use TCP/IP sockets in a clustered configuration.

To create a fail-over cluster, you must be a local administrator with the “Log on as a service” permission, and to act as part of the operating system on all nodes of the virtual server. SQL Server fail-over clustering is not supported on domain controllers.

Caution

Before using fail-over clustering, you should consider that the fail-over clustering resources, including the IP addresses and network names, must be used only when you are running an instance of SQL Server 2005. You must not use the services for other purposes, such as file sharing (which should be done on a separate file server cluster).

To create a SQL Server 2005 fail-over cluster, your first step is to create and configure the virtual servers on which the fail-over cluster will run. The virtual servers are created during SQL Server setup and are not provided by Microsoft Windows Server 2003.

The virtual server you will set up will include the following factors:

You must have a combination of one or more disks in a Microsoft Cluster Service (MSCS) cluster group. Each MSCS cluster group must contain at least one virtual SQL Server server.
There must be a network name for each virtual server. This network name is the virtual server name.
There must be one or more IP addresses that are used to connect to each virtual server.
There must be one instance of SQL Server 2005, including a SQL Server resource, a SQL Server Agent resource, and a full-text resource.

Note

If an administrator removes an the instance of SQL Server 2005 on a virtual server, then the virtual server, including all IP addresses and the network name, will also be removed from the cluster group.

A fail-over cluster can be installed on one or more Windows Server 2003 Enterprise Server machines or the Windows Server 2003 Datacenter Server servers that are participating nodes of the cluster. A SQL Server virtual server, however, always appears on the network as a single Windows Server 2003 server.

Naming a Virtual Server

SQL Server 2005 relies on the existence of certain registry keys and service names within the fail-over cluster to allow operations to continue correctly after a fail-over. This means that the name you provide for the instance of SQL Server 2005, which includes the default instance, must be unique across all nodes in the fail-over cluster, as well as across all virtual servers within the fail-over cluster. In other words, if all instances failed over to a single server, their service names and registry keys would conflict. If INSTANCE1 is a named instance on virtual server VIRTSRVR1, there cannot be a named instance INSTANCE1 on any node in the fail-over cluster, either as part of a fail-over cluster configuration or as a stand-alone installation.

You must also use the VIRTUAL_SERVER\Instance-name string to connect to a clustered instance of SQL Server 2005 running on a virtual server. You cannot access the instance of SQL Server 2005 by using the computer name that the clustered instance happens to reside on at any given time. You should also understand that SQL Server 2005 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 2005.

If you are using the Windows Server 2003 Address Windowing Extensions (AWE) API to take advantage of memory greater than 3 gigabytes (GB), then you need to 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. This is important because if the fail-over node has less physical memory than the original node, the new instances of SQL Server may fail to start or may start with less memory than they had on the original node. In any event, you should give each server in the cluster the same amount of physical RAM. Also ensure that the summed value of the max server memory settings for all instances are less than the lowest amount of physical RAM available on any of the virtual servers in the fail-over cluster.

If you need to configure or make available a cluster server configuration in a replication scenario, it is recommended that you use an MSCS cluster file share as your snapshot folder when configuring a Distributor on a fail-over cluster. When, for example, the server fails, the distribution database will be available and replication will continue to be configured at the Distributor.

Another thing: When you create publications, you need to specify the MSCS cluster file share for the additional storage of snapshot files or as the location from which Subscribers apply the snapshot. This will ensure that the snapshot files are made available to all nodes of the cluster and to all Subscribers that must access it.

If you want to use encryption with a f fail-over cluster, you must install the server certificate with the fully qualified DNS name of the virtual server on all nodes in the fail-over cluster. For example, if you have a two-node cluster, with nodes named mcsql.cityhall.genesis.mcity .org and mcsq2.cityhall.genesis.mcity.org and a virtual SQL server “Virtsql,” you need to get a certificate for “virtsql.cityhall.genesis.mcity.org” 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 fail-over cluster for encryption.

It is also vital that you not remove the BUILTIN\Administrators account from SQL Server. The IsAlive thread runs under the context of the Cluster Service account, and not the SQL Server service account. The Cluster Service must be part of the administrator group on each node of the cluster. If you remove the BUILTIN \Administrators 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 Fail-Over Cluster

The following steps will let you create a fail-over cluster using the SQL Server setup program:

Have ready all the information you need to create your virtual server. Items must include cluster disk resources, IP addresses, network name, and the nodes available for fail-over. The cluster disks that you intend to use for fail-over clustering should thus all be in a single cluster group and owned by the node from which the setup program is run. You must configure your cluster disk array before you run the setup program, and this is done through Cluster Administrator. You will need one MSCS group for each virtual server you want to set up.
Start the setup program to begin your installation. After you have entered all the required information, the setup program will install the new instance of SQL Server on the local disk of each computer in the cluster. It then installs the system databases on the cluster disk or array. 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.
If any resource (including SQL Server) fails for any reason, the services (SQL Server, the SQL Server Agent, Full-Text Search, and all services in the fail-over cluster group) fail over to any available nodes defined in the virtual server.
You install one instance of SQL Server 2005, creating a new virtual server and all resources.

Before you create a SQL Server 2005 fail-over cluster, you must configure Microsoft Cluster Service (MSCS) and use Cluster Administrator to create at least one cluster disk resource. Note the location of the cluster drive in the Cluster Administrator before you run SQL Server Setup because you need this information to create a new fail-over cluster. The following summarizes creating the cluster:

Run Setup and when you get to the Computer Name dialog box, click Virtual Server and enter a virtual server name. If Setup detects that you are running MSCS, it will default to Virtual Server. You must have configured your shared SCSI disks first. Click Next. The User Information dialog box loads.
On the User Information dialog box, enter the user name and company. Click Next. The Software License Agreement dialog box loads. Enter your license information. The Failover Clustering dialog box loads.
On the Failover Clustering dialog box, enter one IP address for each network configured for client access. That is, enter one IP address for each network on which the virtual server will be available to clients on a public (or mixed) network. Select the network for which you want to enter an IP address, and then enter the IP address. Click Add.
The IP address and the subnet are displayed. The subnet is supplied by MSCS. Continue to enter IP addresses for each installed network until you have populated all desired networks with an IP address. Click Next. The Cluster Disk Selection dialog box loads.
On the Cluster Disk Selection screen, select the cluster disk group where the data files will be placed by default and click Next. The Cluster Management dialog box loads.
On the Cluster Management dialog box, review the cluster definition provided by SQL Server 2005. By default, all available nodes are selected. Remove any nodes that will not be part of the cluster definition for the virtual server you are creating. Click Next. The Remote Information dialog box loads.
On the Remote Information dialog box, enter login credentials for the remote cluster node. The login credentials must have administrator privileges on the remote node(s) of the cluster. Click Next. The Instance Name dialog box loads.
On the Instance Name dialog box, choose a default instance or specify a named instance. To specify a named instance, clear the Default check box, and then enter the name for the named instance. Click Next. The Setup Type dialog box loads. (You cannot name an instance DEFAULT or MSSQLSERVER.)
On the Setup Type dialog box, select the type of installation to install. The Setup program automatically defaults to the first available cluster disk resource from the group you previously selected.

If you need to specify a different clustered drive resource, however, under Data Files, click Browse and then specify a path on a clustered drive resource. You will be required to select a clustered drive resource that is owned by the node on which you are running the setup program. The drive also must be a member of the cluster group you previously selected. Click Next. The Services Accounts dialog box loads.

On the Services Accounts dialog box, select the service account that you want to run in the fail-over cluster. Click Next. The Authentication Mode dialog box loads. From here on installation continues.

Step-by-Step Clustering SQL Server

Preparation for SQL Server 2005 clustered installation should starts with the operating system of the individual nodes. First make sure all security patches are up to date. This is easy to do if you are using R2 or later of the Windows Server 2003 operating system. Run the Microsoft Baseline Security Analyzer (MBSA) penetration tests. Also check if antivirus software is installed and configured properly, and not scanning the folders that will be holding your databases, both user and system. You should strive to lay a strong foundation from the operating system before the installation CD is even inserted.

Also, make sure that the minimum system requirements are met. Verify the requirements and that you meet them. If the OS is not a fresh install, then download the latest service packs and hotfixes and security patches from the Microsoft SQL Server Web site (www.microsoft.com/sql). You can also check if the Active Directory administrators have software updates locally and if they are online to serve you.

Next, you should have all of your necessary clustered installation resources information ready ahead of time. Here is a basic list of what you will need before you begin:

Appropriate cluster hardware that has been certified by Microsoft.
Windows Server 2003, Enterprise Edition, with its latest updates, installed properly as a cluster (clustering is not possible on the Standard Edition).
Windows Server 2003 Cluster Service, properly installed and configured.

The Windows Server 2003 Cluster Service needs to have been thoroughly tested to ensure that it is working correctly and that the Cluster Service account has been properly created. This means ensuring that the domain [user] account that you will be using for the SQL Server services has been added to the local administrators groups of all participating servers and is not a member of Domain Admins.
That you (the installer) are a local administrator on all participating nodes of the cluster.
A copy of the SQL Server installation CDs.
A name you can assign to the SQL Server cluster. This is the virtual name that clients will use to access SQL Server. This name must consist only of letters or numbers, no special characters. You can default to the name of the cluster, but that is not always a practical solution.
An IP address you can assign to the SQL Server cluster. This IP address will be assigned to the virtual server that clients will use to connect to SQL Server.

Make sure to use Microsoft Distributed Transaction Coordinator (MS DTC). SQL Server 2005 requires Microsoft Distributed Transaction Coordinator (MS DTC) on Microsoft Windows Server 2003 and Microsoft Windows Server 2003 operating systems. MS DTC is required in the cluster for distributed queries and two-phase commit transactions, as well as for some replication functionality. After you install the operating system and configure your cluster, you must configure MS DTC to work in a cluster by using the Cluster Administrator.

Using Cluster Administrator, go to New Resource, and create the MS DTC resource. Assign the MS DTC resource its own unique resource group.

Install Only One MS DTC Resource. When MS DTC is running in clustered mode, you create only one MS DTC resource on the entire cluster. Any process running on any node in the cluster can use MS DTC. These processes simply call the MS DTC Proxy, and the MS DTC Proxy automatically forwards MS DTC calls to the MS DTC transaction manager, which controls the entire cluster.

If the node running the MS DTC transaction manager fails, the MS DTC transaction manager is automatically restarted on another node in the cluster. The newly restarted MS DTC transaction manager reads the MS DTC log file on the shared cluster disk to determine the outcome of pending and recently completed transactions. Resource managers reconnect to the MS DTC transaction manager and perform recovery to determine the outcome of pending transactions. Applications reconnect to MS DTC so that they can initiate new transactions.

For example, suppose that the MS DTC transaction manager is active on system B. The application program and resource manager on system A call the MS DTC proxy. The MS DTC proxy on system A forwards all MS DTC calls to the MS DTC transaction manager on system B.

If system B fails, the MS DTC transaction manager on system A will take over. It will read the entire MS DTC log file on the shared cluster disk, perform recovery, and then serve as the transaction manager for the entire cluster.

The MS DTC transaction manager, MS DTC Proxy, and Component Services administrative tools are installed on each node of the Windows server cluster. The cluster uses the Microsoft Cluster Service (MSCS) as part of the setup of the Windows server cluster.

To install SQL Server onto the cluster, do as follows:

Click Setup on the SQL Server CD or DVD. The Welcome dialog box loads, select Next.
Enter the name of the virtual server. This is the name of the server client applications connect to. It is the name used in the connection strings and tools like Management Studio will use this name to open the instance of the server for management. This is illustrated in Figure 9–1. Click Next.

Figure 9–1: Setting the Virtual Server name
Next enter user information if it is not automatically selected; click Next.
You will be presented with the request to acknowledge the end user licensing agreement. Select Yes and continue with the installation.
The first cluster information is IP address used by the virtual SQL server. Under “Network to Use,” select the public network connection your clients are going to connect to (via DNS). This is network connection that is connected to the LAN for client access (remember this is not the heartbeat). See Figure 9–2.

Figure 9–2: The IP address for the virtual server
It is possible to add additional virtual IP addresses for multiple-instance clustering, but this is not necessary to configure the default installation or active/passive, single-instance installations of SQL Server on a cluster. Click Next to continue.
Next you need to tell SQL Server setup which logical disk of the shared disk array to place the logical database files. Please be sure that you do not select the Quorum drive. Here you are actually telling the SQL Server Setup Wizard where to install the SQL Server system database files. You also tell the SQL Server Setup Wizard that the disk resource selected should become part of the SQL Server clustering resources. Thus if resource failure occurs, the disk resource used by SQL Server for system databases will fail over as one resource group with the rest of the dependent resources. Go ahead and select the appropriate drive and then click Next.
You now need to define which of the available nodes of the Windows cluster set should be used for SQL Server fail-over in the event of resource failure. Figure 9–3 illustrates this. Once complete, click Next.

Figure 9–3: Specifying the available node
In order to install SQL Server on the secondary node from the primary node, a remote SQL Server 2005 installation is performed. In order for a remote installation to work, the wizard must log in to the secondary node as an administrator.

This dialog box tells the SQL Server setup wizard the name of the instance of SQL Server that you are currently installing. The figures represent a default instance of SQL Server on the cluster, and this will be a “default” installation. A named instance is only required if you intend to run more than one instance of SQL Server on the cluster, creating a multiple instance installation leading to active/active clustering and N+1 configurations.
Now you will have arrived at what looks like the setup screen for SQL Server 2005. Take note of the “Destination Folder” locations. These should not have to be changed. If the destination folder for your SQL Server data files is not the logical drive on the shared storage disk array that you specified earlier during setup, there is a problem. The SQL Server 2005 “Program Files” need to be installed on the local disk of each node, not on the logical drive on the shared array. Verify this is correct for your setup and click Next.
Now installation proceeds much as it does on standard installs. Select which components you want to install. The default options are usually sufficient.

To finalize the installation, enter the SQL Server 2005 service account information, as is necessary for any SQL Server 2005 installation. Choose the appropriate authentication mode for your situation, the appropriate SQL Collation, the appropriate network libraries (usually TCP/IP) licensing mode, and you’re done.

The SQL Server 2005 installation can finally commence. The messages displayed will change, giving you a watered-down explanation of what is going on behind the scenes. This process will take a fair amount of time to complete. Although you will not be prompted to do so, once the install is complete it is highly advisable that you reboot all nodes of the cluster. First, reboot the primary node (the node you have just run the SQL Server Installation Wizard on.

Make sure it comes up successfully Next reboot the secondary node(s), and then be sure they come up successfully. Once you have a successful installation of SQL Server 2005 on the cluster, it’s time to install the most recent SQL Server 2005 service pack. Even if you did not reboot the nodes of the cluster you will be prompted to reboot them before you can install the service pack.

There are some additional items that can be extremely helpful when running this installation. This includes copying the installation media to the local hard drive and running them from there instead of the CD-ROM drive. It is also helpful to copy the most updated service packs, hot fixes, and security patches to the local disk drive for installation.

Node Sense: Cluster Advice You Must Follow

Several products interact with Microsoft SQL Server 2005 fail-over clustering. To ensure that your fail-over cluster functions properly, you must understand these interactions.

Avoid sharing the SQL Server network name or IP address. No additional resources should attempt to share the existing SQL Server network name or IP address. Any new resources added to the cluster group must have a separate and unique network names and IP addresses, if required.
Avoid file shares. Using file shares on SQL Server data drives is not recommended, as it could hurt SQL Server behavior and diminish performance.
Avoid dependencies on SQL Server and the SQL Server Agent. Adding dependencies on SQL Server and the SQL Server Agent is not recommended, as it could hurt SQL Server behavior. If a dependency must be made, it should be on the SQL Server Agent, and the SQL Server Agent should be set not to affect the group.
Use the Domain Name Service or Windows Internet Name Service. A Domain Name Service (DNS) server or Windows Internet Name Service (WINS) server must be running in the environment where your SQL Server virtual server will be installed. SQL Server Setup requires Dynamic Domain Name Service (DDNS) registration of the SQL Server IP interface virtual reference. If the dynamic registration cannot be completed, Setup will fail and the installation will be rolled back. If no dynamic registration is available, you must have preregistered your server in DNS.