Next, SQL Server prompts you to assign a VIP address to the virtual SQL Server name and specify a network for the SQL Server to use, as Figure 4 shows. Type the VIP address and the network name, and click Add.
The next parts of the installation process let you specify where you want to put the data files and what nodes are possible owners of your SQL Server instance. On the screen where you specify the path of the data and binary files, confirm the path to your data once more. I've noticed, for example, that sometimes even though I specified that I wanted the data on the P drive, the selection might change on the final confirmation screen. The SQL Server program binaries will install on the local servers across any node that you selected earlier as a possible owner of your instance. The data files will reside on the shared cluster drive.
The last step in installing SQL Server on the cluster is to type the username and password of a valid administrator account for all nodes that are possible owners of SQL Server. You use this account to copy the data from the node where you've installed SQL Server to the other participating nodes. Then, SQL Server will copy the binaries to all the nodes and register the ActiveX controls (as it does in a typical SQL Server installation).
This process can take as long as 10 minutes, during which time you'll see only the message Setup is performing required operations on cluster nodes. This may take a few minutes. Eventually, the SQL Server service and supporting services start, and the installation is complete. As with a typical SQL Server installation, you might need to reboot both nodes, depending on whether you use updated Microsoft Data Access Components (MDAC) and whether the setup could obtain exclusive access to some of the files.
If an installation fails, you might be in for a long debugging process because during setup, you don't see the error on the screen, so you have to dig through many logs to determine the root cause. To learn some techniques for trouble-shooting a SQL Server installation in a clustered environment, see the Web-exclusive sidebar "Troubleshooting a Failed Installation," InstantDoc ID 40037, at http:// www.sqlmag.com.
5: Configuring Cluster Drives
After you install SQL Server on the cluster, you have to configure the cluster's drives. SQL Server's default cluster setup allows only one clustered drive for its data. This means that if you have more than one clustered drive, SQL Server won't be able to see the other drives to create backups or write data to. If you want to use additional drives, you need to first ensure that the drives are in the cluster group with the SQL Server service. Then, you need to make the SQL Server resource dependent on the new drives because SQL Server can write only to drives that it knows are available. If the drive fails, then SQL Server too must fail or you risk database corruption.
To set a SQL Server resource to be dependent on the new drives, you must first take the SQL Server resource offline by right-clicking the resource in the MMC Cluster Administrator snap-in, then selecting Take Offline. This selection stops the SQL Server service, resulting in downtime for applications connecting to your database. Next, right-click the resource, and select Properties. On the SQL Server Properties screen, you can select the Dependencies tab to view the current dependencies. Click the Modify button to add new drives.
To find out which clustered drive resources are accessible to the SQL Server instance, you can use the T-SQL function fn_servershareddrives(). In the query
SELECT * FROM ::FN_SERVERSHAREDDRIVES()
the function will list the drives that SQL Server can access in the cluster. You can use this function for troubleshooting if you've forgotten to create a dependency.
Now that you've set up the cluster and installed and configured your first SQL Server instance, you have a single-instance cluster. To create a multiple-instance cluster, you simply install another instance of SQL Server on a separate node.
6: Installing Service Packs
Even though you've successfully set up your cluster, you're not finished yet. The last step in creating your cluster is to install Win2K Service Pack 4 (SP4) and SQL Server 2000's latest service pack, SP3a. Win2K SP4 includes many clustering fixes and solves some frustrating problems you might encounter, such as a mysterious failure when SQL Server loses drive connectivity. SQL Server SP3a also provides clustering fixes and is as simple to install on a cluster as it is to install in a typical SQL Server environment.
One final note about running your cluster long term: If your SQL Server is dedicated to database processes (i.e., it's not a Web server), you don't need to install antivirus software on the server. Installing antivirus software on your SQL Server might cause problems when a failover occurs. For example, during a failover, the antivirus software sees new drives on the standby node and begins to scan them. If you have drives that contain hundreds of gigabytes or terabytes of data, the antivirus scan can force your processors to spend too much time scanning and not enough time taking SQL Server requests, resulting in degraded performance during the scan. If you want to run antivirus software on your SQL Server, as many corporations mandate, make sure you don't scan your quorum drive or data, log, or backup files.
Clustering is not a mysterious art; it's a straightforward process that you can break into manageable steps. Although this article describes the bulk of what you might encounter when installing a cluster, you might need to practice deploying your cluster a couple of times before you find all the quirks of your hardware. To view an online demo of building a cluster, see the free Microsoft TechNet Webcast "0 to Cluster in 60 minutes—Clustering Windows Server 2003 and SQL Server" at http://www .microsoft.com/usa/webcasts/ondemand /2030.asp.