Do you find the Support WebCast transcripts helpful?
Let us know!

Note: This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Oscar Doosik Lee: My name is Oscar Doosik Lee. I'll be presenting the first part of "Introduction to Microsoft SQL Server 2000 Clustering," and Ranjit will deliver the rest of the presentation. This is a 200-level course, which requires basic Windows^® clustering knowledge.

There are three modules in this presentation: Module 1, Microsoft SQL Server™ 2000 Cluster Changes; Module 2, Setup; and Module 3, Best Practices and Tips.

A cluster server (slide 4) is a group of servers managed as a single system for higher availability, easier manageability, and greater scalability. Throughout this presentation, we'll go over the features that are specific to a SQL Server 2000 server. Single image is defined as when a cluster projects its own unique network identity distinct from the identity of nodes. What this means is the client connects to a SQL Server cluster to a virtual server name reference.

This picture (slide 5) shows the basic components of a cluster. Public network is where the client connects, and each server has a local disk. Heartbeat is for the intercluster communication. Heartbeat is used to check if the other node is running. If the heartbeat fails, the cluster servers will initiate the failover.

Server A owns Disk A and Server B owns Disk B, in this picture. When Server A fails, Disk A will be taken over by Server B, and it runs the application.

Microsoft uses a shared nothing model (slide 6). At any given time, the cluster disk is owned by only one node, until that node fails. In this picture, when NodeA fails, NodeB will take the ownership of the disk.

This slide (slide 7) shows you the improved changes of SQL Server 2000 over SQL Server 7.0 cluster. There is no more SQL Failover Cluster Wizard. SQL Server 2000 uses only a setup program to install SQL Server Cluster. SQL Server 7.0 had a two-step installation: installation of a SQL Server, and setup of a SQL Server Cluster by running SQL Failover Cluster Wizard.

Single-node clusters are supported on SQL Server 2000. You can start as a single-node cluster, and add nodes as you go on. Node recovery and maintenance are much improved over SQL Server 7.0. You do not need to run the Failover Cluster Wizard to uncluster and recluster when you have configuration changes. You can add or remove a node or change the configuration through our setup program.

Multiple IP support. SQL Server 7.0 listened to only one IP address, but in SQL Server 2000, we support multiple IPs, as long as they're in a different subnet.

SQL Server 2000 supports up to 16 virtual instances. This is a major feature change in SQL Server 2000. You can set up to 16 virtual server instance per cluster. And full text is now fully cluster aware. The catalog will be written on a cluster disk.

Let's take a look at multi-instancing on SQL Server 2000 (slide 8). Tools, COM components, and MDAC are shared among all instances. For example, the SQL Server Enterprise Manager can manage all of the virtual instances of a SQL Server on Enterprise Manager. There is no need to install MDAC for each instance of the SQL Server. Like I mentioned, we support up to 16 instances per cluster.

SQL registry settings are isolated between instances. The SQL registry key is located at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer. Under this key, there will be separate keys created based on the virtual server instance name.

Only one default instance is allowed. A default instance is solely based on computer name, and after the default instance has been installed, the default option will be unavailable.

Performance counters are available after failover to a second node (slide 9); in SQL Server 7.0 cluster, after you fail over to the other node, the performance counter will no longer be available. In SQL Server 2000 cluster, the counter will be automatically loaded in the case of a fail over. All SQL Server binary files are installed on every node. Setup will go through a silent installation phase to copy all of the necessary binary files to all of the nodes. So when the cluster fails over, it loads binaries from its local disk.

Windows 2000 Advanced Server supports up to two nodes, and Windows 2000 Datacenter Server supports up to four nodes, so far (slide 10).

The next topic is enhancements to a SQL Server 2000 admin tools for a cluster. The full-text search is fully cluster aware, because the catalog will be written on a cluster disk. With the SQL Server Enterprise Manager, you can stop and start the service and change the account password. In SQL Server 7.0, you had to uncluster a recluster to change a password, and Cluster Administrator was the only place to stop and start the service.

With SQL Service Control Manager you can start and stop the service instead of with Enterprise Manager or Cluster Administrator. The replication directories are now represented as a UNC path to a cluster disk. For example, in SQL Server 7.0, the Snapshot directory had a local drive presentation. It's easy to add and remove nodes. SQL Server 2000 uses a setup program to add and remove nodes. In SQL Server 7.0, you had to uncluster a recluster every time you added or removed nodes.

The ability to change IP addresses in SQL Server 2000 is also integrated in the Setup program. Ranjit will go through the setup process later in this presentation. You can change the virtual server IP address by running the setup program any time without reboot. In SQL Server 7.0, once again, we had to uncluster and recluster.

Lets talk about connectivity changes. First, client connectivity changes (slide 11). To connect to a named instance in SQL Server, you need to specify the server and instance name. For example, when you use ISQL command to connect to a named instance over SQL Server, ISQL /S servername/instancename. In addition, you need MDAC 2.6 to connect to a named instance in SQL Server 2000. MDAC 2.6 can be downloaded from http://www.microsoft.com/data/. ODBC drivers also support the named instances.

Server-side changes (slide 12): the default pipe has an instance name added to differentiate between the instances. This example shows that next to the server name, the instance name is added. TCP/IP port issues: only one instance can be listed to port 1433. The rest of the virtual server instance will have to pick a different port. You may choose any open port or use a dynamic port selection. The dynamic port selection can be configured by setting value of a numeric zero (0) for the port number. When dynamic port selection is used, the UDP port 1434 is used to provide a new listener service to client. First, a client makes a connection to UDP port 1434 and finds out what port the server is listening to, and connects to server.

The supported operating systems (slide 13) are Microsoft Windows NT^® Server 4.0 Enterprise Edition, Windows 2000 Advanced Server, and Windows 2000 Datacenter Server. SQL Server 2000 Enterprise Edition is required to install SQL Cluster Server.

Failover models (slide 14): the active-passive model. While virtual SQL Server runs on primary node, the second node will be in an idle state until the virtual SQL Server fails to a second node. The active-passive model represents that one active server will be running on one node at all times.

The active-active model: the virtual server is running on a primary node, and another instance of a virtual server is running on a second node. When it fails over to the second node, the secondary node will run both servers at the same time. This model doesn't assure database or load-balanced client connections. The active-active model represents that two active virtual SQL Servers are running at the same time. When you design this model, you have configured sufficient hardware resources to run both SQL Servers without performance degradation. Virtual instance: Windows 2000 Datacenter Server now supports up to four nodes with 16 instances.

This picture (slide 15) shows a Microsoft two-node active-active cluster model. The public network is where a client connects. Each virtual SQL Server has a local disk. Heartbeat connection is for the intercluster communications. Virtual SQL Server A owns Disk A, and Virtual SQL Server B owns Disk B. When Virtual SQL Server A fails, Node2 will take over Disk A and runs the Virtual SQL Server A. As a consequence, node B will be running two virtual SQL servers.

This picture (slide 16) shows the Microsoft four-node cluster in the Windows 2000 Datacenter Server model. A client connects to a virtual named instance, SQLCLUSTA\INST1, SQLCLUSTB\INST2, SQLCLUSTC\INST3, SQLCLUSTD\INST4. Each node has a local disk. All of the virtual servers are connected to a fibre channel disk array system as a storage solution.

Destination folders (slide 17): SQL Server binaries are installed on the local disk. The databases are installed on a cluster disk. The full-text catalog will be installed on the cluster disk. Only a SQL Server-dependant disk can be used by SQL. What this means is that the drive resource must be included in a SQL Server group to use disk resources for the SQL Server cluster server.

Naming conventions (slide 18): a named instance must be unique to domain. Named instance has a two-part name, a server name, and an instance name. The server name and instance name must be unique as well. Lets take a look at these examples. Vss1/instance1 is acceptable, because it's unique. Vss1/instance2 is not acceptable, because vss1 is already used as a server name. Vss2/instance1 is not acceptable, because instance1 is already used as an instance name. Vss2/instance2 is acceptable because it's unique.

In this next module (slide 19), we'll cover clustering installation prerequisites (slide 20), SQL virtual cluster installation, and upgrade paths.

We'll now cover software requirements, hardware requirements, the cluster preinstallation checklist, network recommendations, common network-related issues, and configuring cluster network connections (slide 21).

Software requirements (slide 22) include Windows NT 4.0 Enterprise Edition, Windows 2000 Advanced Server or Windows 2000 Datacenter Server. The recommended member servers in their domain controllers have the overhead of running a domain-related services.

Hardware requirements (slide 23) must meet HCL qualifications as a solution. We do not support the clusters built from HCL-listed components. We have a Web site for checking the HCL list, http://www.microsoft.com/hwtest/hcl/. There are three categories on this Web site. You need to look under Cluster, Cluster/Datacenter 2-Node, and Cluster/Datacenter 4-Node.

Let's look at the preinstallation checklist (slide 24). Let's talk about SQL Server Cluster service account. First, the SQL Server 2000 cluster account must use Windows Authentication. A local account cannot be used. Second, it must be member of local admin group in the case of Windows NT 4.0 Enterprise Edition. Third, you need to configure the account with the following rights: Act as a part of operating system, Logon as a service, Replace a process-level token. If you are a member (slide 25)of local admin, your are a system admin in SQL Server as a default. The SQL Server cluster server checks every three seconds by running a LookAlive and IsAlive query for every five seconds to make sure the other SQL virtual servers are still running in a good condition and in a reciprocal way.

If the query fails, the Cluster service will initiate the failover. For this reason, the Cluster service account must have the sysadmin rights to log into SQL Server to run this query. Virtual SQL Server service accounts should be an admin account of a cluster as well. The other administrative shares must be available to a SQL Server at all times.

Next on the checklist (slide 26), a unique cluster name must be used. You need a unique static IP address and subnet mask for SQL Server. Make sure that there are no duplicate IP addresses and subnets. I recommend you ping the address before you configure the IP address for the virtual server. If you get a reply, then there is a duplicate IP address.

Use the SQL Server Enterprise Manager to change the service account password. If you do not use Enterprise Manager to change your service account password, full-text search and the virtual SQL Server resource might not start.

Next is network configuration recommendations (slide 27). No NIC teaming of private adapters is allowed. We have a great article on this subject: "Network Adapter Teaming and Server Clustering," Q254101, at http://support.microsfot.com/support/kb/articles/q254/1/01.asp, and "Recommended Private Heartbeat Configuration on the Cluster," Q258750, at http://support.microsoft.com/support/kb/articles/q258/7/50.asp. Disable media sense (slide 28) on all NICs. Media sense is used to find out if the network speed is running at 10 MB or 100 MB. While media sense is determining the speed, the network adapter will not function. This can lead to a possible failover. Enable NetBIOS over TCP/IP for a public network; however, you have to disable NetBIOS over TCP/IP in DNS and the default gateway entries for a private network.

As far as the other issues (slide 29), a duplicate network name can be an issue. Please make sure that the network name is unique in domain. If you have a duplicate network name, the SQL Server resource will not come online. A disk name should be the same as the group name, or any other cluster resource name. In other words, all of the resource names must be unique.

Lastly, here is some documentation regarding WINS configuration for SQL Server Cluster (slide 30): "Recommended WINS Configuration for Microsoft Cluster Server" (http://support.microsoft.com/support/kb/articles/q193/8/90.asp) and "WINS Registration and IP Address Behavior for Microsoft Cluster Server" (http://support.microsoft.com/support/kb/articles/q195/4/62.asp). These KB articles will go into detail about WINS in the clustering environment.

This screen shot (slide 31) shows the example of naming cluster network connections to make it easy to distinguish between private and public adapters, so you don't make a mistake adding an incorrect interface.

Next, Ranjit will give the rest of the presentation.

Ranjit Kurian: Thank you, Oscar. In the next part (slide 32), we'll talk about the Microsoft Distributed Transaction Coordinator, installing the SQL Server virtual cluster, installing Cluster Administrator on more computers, and finally, how to verify a successful installation.

Microsoft Distributed Transaction Coordinator (slide 33), as the name implies, is used to handle distributed transactions. It's used in replication. For example, in transaction replication, in immediate updating subscribers, and in other two-phase commit transactions. In Windows NT 4.0, you had to manually create the MS DTC resource in the Cluster Administrator. With Windows 2000, we now simply fire the procedure by using the utility Comclust. When you run Comclust from the command line, from the primary node, it will create the DTC resource in the cluster group, it will create the DTC log file on the cluster disk, and it will copy the DTC registry entries to the shared cluster registry.

In this slide (slide 34), we see a screen shot of the Cluster Administrator of the two-node Windows 2000 Advanced Server. As you can see, there are two groups, SQL1 and SQL2. There are two nodes, W2KN1 and W2KN2. There are four resources. You have the Cluster IP Resource, you have the Cluster Name Resource, you have the Disk X resource, which is a quorum root drive, and you have the MS DTC resource.

Before we go forward with the installation steps, a couple of points to remember here are that you want to make sure that you are on Windows NT 4.0 or Windows 2000 Server. You want to make sure that only the default services are running, prior to going through the installation of SQL Server. For example, you want to stop all third-party services. You also want to stop all IIS-related services. You want to make sure that only the default services are running on the operating system. Also, you want to make sure that the event log entries are clean. If you see any hardware, software, or network errors, they have to be addressed immediately before you run the SQL Server virtual cluster setup.

After you run Setup from the SQL Server 2000 Enterprise Edition CD, and after you choose the database server, you'll be presented with the Welcome screen. After you click Next on the welcome screen, you'll be presented with the Computer Name screen (slide 35), as you see here. As you can see, there are three options, the Local Computer option, the Remote Computer, and Virtual Server. In this case, because we're going to install a virtual server, we're going to choose the Virtual Server option and enter a name for the virtual server.

After you click Next, in the next screen (slide 36) you're prompted for the user information, your name, and company information. You click Next. In this screen (slide 37), you're presented with the Software License Agreement. After you completely read the licensing agreement, click the Yes button. In the next screen (slide 38), you're presented with the virtual server information. In this example, the virtual server name is SQLTEST. The IP address is 10.10.1.1, the subnet mask is 255.0.0.0, and the network to use is Public. After you enter all this information, you need to click the Add button and click Next.

In this screen (slide 39), you're presented with the IP information for the private network card. If you have configured the private network card to use all communications, then you'll be presented with this screen. We recommend that the public network card be configured for all communications, and the private network card be configured only on the cluster interconnect.

In this screen (slide 40), you're asked to select the cluster disk to which you want to install the SQL Server data files. In this example, you can see there is only one disk resource, which is X. In the next slide (slide 41), you get a warning message if you choose the Disk X that we saw earlier. It says "You have chosen the group containing the quorum resource. It is strongly recommended that you should not use the quorum group with SQL Server. Are you sure you want to proceed? Click Help for more information" We highly recommend that you do not use the same disk resource to install the SQL data files. We recommend that you have a separate disk resource for every virtual server you install on the cluster. If you still decide to install the data files on the quorum drive, you can click the Yes button and go on to the next screen.

In this section of the setup (slide 42), you have the Cluster Management setup screen. You would see under the Available Nodes section the two nodes, W2KN1 and W2KN2. Highlight both of them, click the Add button, and make sure they fall under the Configure Nodes section.

Here (slide 43) you are asked to enter a Username and Password that's a valid administrator account for all the nodes in the cluster system. After you enter the proper user name, password, and domain, click the Next button. Here (slide 44) you are asked to choose the instance name. As Oscar pointed out earlier, you can have a default instance or a named cluster instance. If you decide to install a default instance then you need to select the Default check box.

In the next slide (slide 45), you see that if you decide to install a named cluster instance on SQL Server, then you clear the Default check box enter a name for the instance. You click Next. In this screen (slide 46), you are asked to choose a setup type. You have three options: Typical, Minimum, and Custom. We recommend that you choose Typical for the virtual server installation. In the Destination Folder section, you see that the program files or the binary files are located on drive C, and the data files are located on drive X, in our example. As you know, drive X is a shared cluster disk, in our example. A point to note here is that in SQL Server 7.0, the SQL Server binary files and the SQL Server data files were installed on the shared cluster disk. In SQL Server 2000, only the SQL Server binary files are installed on the local drive off every node, and only the data files are located on the shared cluster disk.

After you click Next, in the next step (slide 47) you're asked to choose authentication mode. You want to choose Windows Authentication Mode to make a trusted connection. Click Next, and on the next screen (slide 48) you see that setup has enough information to prompt you for the licensing mode information and start copying the program files. At this stage, you could decide to go back and make any changes if you see that something is not correct. After you make all the appropriate changes, and after you return to this stage of the setup screen, click Next. You're asked to choose the licensing mode for the SQL Server virtual cluster (slide 49). SQL Server 2000 supports two cluster licensing modes. Per Seat is where each device that accesses Microsoft SQL Server 2000 requires a separate Client Access License, and a Processor License is where each processor on the server requires a separate Processor License. After you choose the appropriate license you have purchased, click the Continue button, and on the next screen (slide 50) you see that setup is performing the required operations on the cluster nodes. This might take a few minutes.

After a few minutes, you'll be presented with the final screen (slide 51), which says that the setup is complete, and then you're prompted to restart the node. Select the option to restart the node, click Finish, and restart the node.

After you restart the node, you want to open Cluster Administrator and connect to the cluster. In this screen (slide 52), as you can see, there are five SQL Server resources created for you. The SQL Server IP Address resource is the IP address to which the users and clients will connect. The SQL Server Network Name resource is the network name to which the clients will connect; the SQL Server resource is the clustered instance resource of the SQL Server 2000 Service. Then you have the SQL Server Agent resource and the SQL Server Fulltext resource.

In this example, SQL2K1 is the name of the virtual server, and (FIRST) is the name of the named instance. So when the users or clients connect to the SQL virtual cluster, they connect to SQL2K1\FIRST.

On the next slide (slide 53) are examples of the cluster registry entry. If you choose to install a default instance, then the registry key for SQL Server is located under HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer. If you install a named instance, then the registry key for SQL Server is located under HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server, and below that the name of the instance.

Cluster administration tools (slide 54) can be installed on the nonclustered remote computer to manage a cluster remotely. You can manage a cluster from either Windows NT 4.0, SP3 or later, or from Windows 2000. We recommend using the Windows 2000 cluster administration tool to remotely manage Windows NT 4.0 or Windows 2000 clusters. The files are located on the Windows 2000 delivery CD, under the location I386\Adminpak.msi. One point to note here is that you must have administrative permissions on the local computer before you can install and run Windows 2000 administration tools.

In the next slide (slide 55), we're going to talk about how to verify a cluster installation. In Cluster Administrator, you want to make sure that you can fail over the virtual server across the nodes. You want to make sure that all the SQL Server resources come online without any problems, and you want to fail the SQL Server resource back to Node1 and make sure that all the resources come online. Manually fail over the group by right-clicking the group and selecting Move group. That's a simple test to make sure that the virtual servers and all the resources are coming online in Cluster Administrator.

You definitely want to look at the event log entries. You want to make sure that there are no hardware, software, or network errors reported. If any of these errors manifest themselves in the event log, then they need to be addressed immediately.

Finally, connect with your named resolutions disk. From the server node, make certain that all the servers can properly see each other. Use the Ping command-line utility for each server node to check connectivity to all the private and public IP addresses and names associated with the cluster. And from a client perspective, you ping the public names and IP addresses of the cluster resources. It includes the cluster itself, and the SQL Server from the client computer. These are a few steps that you use to can verify that your SQL Server cluster and the cluster in general is functioning correctly.

In the next slide (slide 56), we want to talk about upgrading a SQL Server 6.5 or 7.0 active-passive cluster to a SQL Server 2000 cluster. On the first node, you want to fail over the instance to its original installation node. You want to make sure that the SQL group is part of the node from which it was originally installed, and if it is not, you want to fail over back to the original node.

You can uncluster the existing SQL Server 6.5 or 7.0 installation. You do this by running the SQL Server Failover Cluster Wizard. At this point, SQL Server becomes a standalone machine. You then upgrade the SQL Server 7.0 default instance to a SQL Server 2000 default instance, and then upgrade the SQL Server 2000 default instance to a cluster instance.

In the next slide (slide 57), we talk about upgrading the SQL Server 6.5 or 7.0 active-active cluster to a SQL Server 2000 cluster. In step 1, on both the first and second nodes, you want to fail over the instance to its original installation node. In step 2, on both the first and second nodes, you will uncluster both the SQL Server 6.5 or 7.0 installation using the Failover Cluster Wizard. In step 3, on the first node, install a named clustered instance of SQL Server 2000. You then use the Copy Database Wizard in Enterprise Manager to migrate the data from the default instance to the named instance. After this is complete, you can uninstall the SQL Server 6.5 or 7.0 installation.

In step 4, on the second node, you want to upgrade the SQL Server 6.5 or 7.0 installation to the SQL Server 2000 default instance, then upgrade the SQL Server 2000 default instance to a clustered instance. As you can see here, there is a named instance on node 1, and there is a default instance on node 2. This is because, as Oscar pointed out earlier, you can have only one default instance in a cluster.

In Module 3 (slide 58), we're going to talk about best practices and tips. Microsoft supports MSCS (slide 59) only when MSCS is used on a validated cluster configuration. We recommend that you buy a hardware solution from your vendor that is validated on the Hardware Compatibility List. Make sure they are approved for the operating system: Windows NT 4.0 Enterprise Edition, Windows 2000 Advanced Server, or Windows 2000 Datacenter Server. Make sure that you make a complete cluster solution, instead of buying it from a component list.

Reapply SP4, followed by SP6a on Windows NT 4.0, if you remove and reinstall Cluster service. At any point, if you have to remove and reinstall Cluster service, you will be automatically asked to install SP3. After you complete the installation of SP3, you will apply SP4, and then proceed directly to apply SP6a. The reason why we recommend you apply SP4 and then go to SP6a is because some of the fixes in SP4 did not make it to SP6a. Also, if you install any new programs after you install the cluster, we recommend that you reapply SP6a on the Windows NT 4.0 Enterprise Edition CD.

Ensure that each server is a member of the same domain. You want to make sure that all the nodes for the cluster are part of the same domain. You want to make sure they can connect to the domain controller, and that the DNS WINS servers are all configured directly.

Ensure that the domain account has Logon as service and Act as part of the operating system rights on all the nodes of the cluster (slide 60). You want to make sure that the privileges you give for the domain account are the same on all the nodes of the cluster. Run Setup to change the SQL virtual server IP address. We do not recommend changing the SQL Server IP address in the Cluster Administrator directly. This is because the SQL Server network name has a dependency on the SQL Server IP address. As Oscar pointed out earlier, in SQL Server 2000, everything is built into Setup, so you need to run Setup to change the IP address of SQL Server.

Have a separate IP address and network name for MS DTC. We recommend this because if you have to configure the same IP address for both SQL Server and MS DTC, and if MS DTC fails, that will take down SQL Server, too. You can also install MS DTC on a separate group to make sure that the failure of MS DTC does not affect the SQL Server resources, because the failover is always at the group level, and not at the resource level.

SQL Mail is not supported in a cluster, because MAPI is not cluster aware. While this does not change in SQL Server 6.5, SQL Server 7.0, or SQL Server 2000, we recommend using System Monitor to set alerts in Windows 2000, and use the performance counter in Windows NT 4.0.

Configure all the nodes to use TCP/IP (slide 61). MSCS uses only TCP/IP for communications, so if you have Net Library, Novell NetWare, AppleTalk, or anything else, you can confidently delete them.

Unattended installation of a clustered instance is not supported in SQL Server 2000. Disable NetBIOS over TCP/IP for the private network, and do not configure the WINS and DNS default gateway entry for the private network card. This should be configured only for the public network card.

You must install MSCS completely (slide 62) on at least one node before you run Windows NT Server Enterprise Edition, or Windows 2000 Advanced Server or Windows 2000 Datacenter Server, simultaneously on both nodes. When using MSCS, it is critical that one node be in control of the shared SCSI bus prior to the other node coming online. Failure to do this can cause application failover to go into an online pending state, and either prevent failover to the other nodes, or totally fail. The exceptions to this would be if your cluster system has a proprietary install process. In those cases, the proprietary process should be used.

Although it is best to reserve an entire cluster disk for use as a quorum disk, resources other than the quorum resource can also access the quorum disk. A drawback to making the quorum resource and other resources share the same disk is that this design causes you to choose between two bad alternatives. The first is to configure the resource so that its failure does not affect the group. In this case, you lose failover support for the resource. The second alternative is to allow the group to be affected by the other resource's failures. In this case, the quorum resource is failed over along with the rest of the group, which 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. We recommend a minimum of 500 MB for the quorum drive.

It is highly recommended by PSS that no IRQ sharing be allowed between network interface cards and the SCSI controllers. Although some hardware might support IRQ sharing, we experience that sharing IRQs provides a repeated source of failure, and is it not recommended. Additionally, IRQ 9 is not recommended for NIC use.

Only one MS DTC resource is required in a cluster. As pointed out earlier, you run Comclust to create the MS DTC resource, and be it a two-node cluster or a four-node cluster, there is only one MS DTC resource. The point to note, however, is that you need to run Comclust on all nodes of the cluster to make MS DTC cluster aware.

Moving on to the next slide (slide 63), to remove a virtual server, move the SQL group to the node from which it was originally installed, and then run Setup to remove the virtual server. Uninstall the virtual server before you evict a node from the cluster. If you evict a node before you uninstall the virtual server, that could to lead to reinstalling the virtual server.

Each public and private NIC of a node must have an IP address that is on a different network or subnet. Do not use special characters for the names of the public and private NICs. As Oscar pointed out earlier, a good naming convention would be, for the public network NIC, call it "public network," and the private NIC, "private network." And don't include any special characters like ampersand (&), hyphen (-), colon (:), or anything of that sort, because that could lead to problems during failover.

In this next slide (slide 64), I wanted to answer some of the common questions we get at PSS. SQL Server 2000 Analysis service, which was formerly known as OLAP, is not supported in the cluster. Each virtual server can support a different code page. This is because the data on each active installation of SQL Server is separate from the other, which means it's stored on different disks and arrays, so this should not be a problem. For instance, the active virtual server, Virtual Server A on NodeA, will have within its resource group a disk in the array disk X, and it will be dependent on that disk. The SQL Server data on that disk will have a particular code page and sort order. The active virtual server on second node, for example Virtual Server B, will have its resource group and will be dependent on a completely separate disk, for example, disk Z, whose data is stored with a different code page than the Virtual Server A data.

Should Virtual Server B virtual server fail, it and all the resources in the group with it will fail to the first node. So if the data for Virtual Server B is stored on Disk Z, and the data is completely separate and distinct from the data for Virtual Server A on Disk X, no mingling of the data will occur.

We can run rebuild master (rebuilm) on both the default and named instances in a cluster. A few points to note here before you run the rebuild master are that you want to bring the SQL resource to the node on which the SQL Server was initially installed, and you then take the SQL Server resource offline in Cluster Administrator. You then ensure that the original shared installation files of the SQL Server CD are available at this point. You then remove the read-only attributes after copying the files from the CD, and you execute a Rebuildm.exe and punch it to the original shared installation files. Click on SQL collation and then complete the rebuild master. You then need to verify the resources and be brought online in Cluster Administrator, and then you definitely want to do a failover test to make sure that everything is working fine.

Another way to confirm that the changes have taken place is to run the stored procedure sp_helpsort from the Query Analyzer to make sure that the new changes have indeed taken effect.

Another couple of points I wanted to add here: first, file compression and encryption on cluster disks are not supported. You need to apply certifications to all the nodes when using encryption in a clustered environment of SQL Server.

You must have identical SQL Server versions (slide 65) on each node of the cluster. For example, SQL Server 7.0 on Node1 and SQL Server 2000 on Node2 is not supported. If this is a SQL Server 2000 cluster you're planning to install, then all the nodes must be installed with SQL Server 2000 Enterprise Edition. You can't have Node1 installed with SQL Server 2000 Enterprise Edition and Node2 installed with SQL Server 7.0 Enterprise Edition.

Finally, MDAC 2.6 is not supported in a SQL Server 6.5 or 7.0 cluster. For example, if you have an existing SQL Server 7.0 cluster, and you decide to install a SQL Server 2000 named instance in the cluster, for testing purposes, for example, that will install MDAC 2.6. And because MDAC 2.6 is not supported in a SQL Server 7.0 or 6.5 cluster, it will break your cluster. This will lead to reinstalling the SQL Server 7.0 cluster from scratch. So be careful not to upgrade the MDAC version to MDAC 2.6 on an existing SQL Server 6.5 or 7.0 cluster server.

On the next slide (slide 66), I've listed a couple of KB articles. Q274446 (http://support.microsoft.com/support/kb/articles/Q274/4/46.asp) talks about upgrading to a SQL Server 2000 fairover solution for all non-SQL Server 2000 Virtual Servers. We highly recommend that you upgrade as soon as possible from an existing SQL Server 6.5 or 7.0 cluster to a SQL Server 2000 virtual cluster. Q243218 (http://support.microsoft.com/support/kb/articles/Q243/2/18.asp) talks about installation of SQL Server 2000 Enterprise Edition on the Microsoft Cluster Server.

On the next slide (slide 67), there are some KB articles on Microsoft Cluster service installation resources, and a couple of white papers on how to build a highly available database cluster.

On the next slide (slide 68), I have highlighted a few more articles and white papers. We have white papers on capacity planning (slide 69), for high availability and planning, deploying, and managing highly available solutions.

And definitely don't forget to use TechNet and MSDN^® (slide 70), because there are a lot of resources in there on SQL clustering, Windows clustering, and high availability. I would highly recommend that you use SQL Server 2000 Books Online before you go to any other Web site, because there is a wealth of information on clustering in SQL Server 2000 Books Online.

In the last slide (slide 71), I've listed a few books on high availability and Windows clustering. I would definitely recommend that you check out these books if you're interested in Windows clustering or high availability. Windows NT Clusterserver Guidebook by David Libertone talks specifically about Windows clustering. He also mentions Exchange 2000 in a cluster, SQL Server 2000 in a cluster, and so on.

This completes our talk for today. I will hand it over to Jim for the Q&A session. Thank you.

Jim Coll: Excellent. Thank you so much for that presentation, Oscar and Ranjit. Our first question today is about multiple instances on SQL Server 2000 Cluster. On an active-passive SQL Server 2000 cluster, can one shared disk array be used, or is it required for us to have an additional disk array when multiple instances are installed?

Oscar: Yes, each instance requires a disk resource. So, in case of failover, the disk as a resource will take fail over to the other node. So if you have two instances, you must have two separate disk resources for each instance.

In the case of SQL Server 2000, we support up to 16 instances, so you may have up to 16 disk resources, then you install 16 instances.

Jim: Okay. Our next question is about multiple instances: Can two or more instances share the same logical, physical drive for the data files?

Oscar: No, you have to have a separate disk. The reason is you need to include a disk resource to a SQL group when you install an instance. So that disk resource has to be a separate disk resource to be able to function as one instance. In other words, data cannot be separated or shared by different instances.

Jim: Okay. The next question is about naming conventions. It's asking: It is possible to have Server1/Instance1 and Server1/Instance2, correct?

Oscar: No. That's what I went over with the naming conventions, that the server name and instance name must be unique. I made the same mistake when I configured the server by configuring Server1 and Instance1 and Server1 and Instance2. The server name must also be unique, so it has to be Server1/Instance1 and Server 2/Instance 2.

Jim: Okay. The next question is: Can DHCP be used for assigning IPs in the cluster?

Oscar: Yes, SQL Server 2000 supports DHCP addressing for the node IP. However, the cluster IP and SQL Server virtual IP must be a static entry. So yes, you can configure your interface to be subscribed to a DHCP address, but your virtual server and the cluster IP must be static.

Jim: The next question is referring back to slide 12. If you can specify 0 for dynamic port allocation, can you specify a port range?

Oscar: No. As far as I know, 0 is a dynamic port selection. We do not have the capability to specify the range of the port.

Jim: Okay. Why can't the install procedure stop all services that might conflict?

Ranjit: That's a design requirement, to make sure that only the default operating system services should be running. For example, if you have a Compaq hardware solution, you want to make sure you stop all the Compaq Insight Agents and all other Compaq agents, because that might conflict during the installation of virtual server.

Oscar: Just to add to Ranjit's response, we require that you stop any services that require an ODBC component. So that's another thing they need to ensure, that all the all the ODBC component-related services are stopped as well.

Jim: You stated that SQL Server 2000 clustering uses the shared nothing model. What does that mean, and what are the other models?

Ranjit: There are two models. In the shared nothing model (which the Microsoft Cluster service uses), in a two-node cluster, only one node has access to the cluster disk at any given time. In a shared disk model, both nodes have access to the shared cluster disk at the same time. I believe they use a distributed lock manager to manage the failover.

Oscar: Yes, when you talk about the shared nothing model, one node has full ownership of the drive. The other node won't even see it. So in other words, to read/write, everything goes from one node. The other node has no business accessing to that node.

Jim: The next question is about MS DTC: What if you do not install MS DTC prior to the virtual SQL Server installation? Can you install MS DTC after installing the virtual server?

Oscar: Yes, you can run it any time. In Windows 2000, we made a great improvement in setting up MS DTC. You just have to run Comclust in both nodes, and the resource will be configured for the cluster.

Jim: Please confirm whether in your install you switched the private and public IPs per your slides? That is, should the private IP be 10.1.1.1/255.0.0.0 and not vice versa?

Oscar: The IP address we have there is just for our slides. That's not the actual IP address we'll be using, so that was just for demonstration purposes.

Jim: Why does SP4 have to be installed first? Are there files that are not in SP6a?

Ranjit: As I explained earlier, after you complete the SP3 installation on Windows NT 4.0 Enterprise Edition, you need some of the SP4 hot fixes in place before going to SP6a, because a few of the hot fixes in SP4 did not make the SP6a. So we recommend SP4, and then go to SP6a directly.

Oscar: Just adding another point on that. After you remove a Cluster service, in Windows NT 4.0 you're going back to a SP3 level, by design. You're losing all the DLL context, and all that. So that's why we recommend going in and applying retroactively from Service Pack 4 and on. You may also skip Service Pack 4 and directly go to SP6a. But you may encounter problems later on, if you skip it. But you can do it both ways. I had a problem in the past when I did not apply Service Pack 4, but in a lot of instances, with setting up a server and going directly to SP6a, it was fine.

Jim: Our next question is related to that. It's referring back to slide 59. Will this impact only SQL Server installations, or will it impact everything? This is not something we've been told before in regard to SP4 and SP6a.

Oscar: This is for the Windows NT clustering aspect, not the SQL Server aspect. The service pack is the Windows NT Service Pack. This is not the SQL Server service pack.

Jim: Excellent. The next question is: Because OLAP is not supported in a cluster, can OLAP be installed on another server device and access data from both in that cluster to build its cubes?

Oscar: If you are asking if we can query a SQL Server running on a cluster and build the cube, the answer is yes.

FYI, NLB (Network Load Balancing) is used to provide availability and scalability for analysis services applications. NLB in a balanced environment can be used for analysis services databases and other 24 ´ 7 analysis services situations, where required.

Jim: The next question is: Some Microsoft documents recommend using SQL Server authentication when the client is running on IIS. What authentication is recommended with IIS and SQL Server cluster systems?

Oscar: The SQL Server cluster has to configure Windows Authentication, no exceptions, for the service account. And the same goes for the Cluster Service account. I'm not sure about the IIS accounts, but I'm sure that that has to be Windows Authentication context.

Jim: The next question is asking about SQL Server node versions: Can two nodes have different service pack versions of SQL Server, as per slide 63?

Ranjit: That would be a bad idea. It might work, but we strongly suggest that you sync up the two nodes. Even the BIOS level has to be the same, SCSI BIOS, and then SQL service pack and Windows NT service pack has to be identical in case of failover; that's the most optimal condition to run.

Jim: Does Microsoft support using separate disks for data and logs in the SQL Server 2000 cluster?

Ranjit: Yes. That would be a great solution, actually. You could have the data files on a separate disk resource, you can have the log files on a separate disk resource. For example, what you commonly see is the data files on a RAID 0 + 1 configuration, and the log files on a RAID 1 mirror. So yes, you can do that.

Oscar: One other key point on that, too, is that the disk resource must be a member of the SQL Server group. So there has to be a dependency to a SQL Server group.

Jim: Before we move on to the rest of the questions, I'd like to take a moment to ask everybody who's listening to submit some feedback to us. We are interested in feedback regarding this session, feedback on sessions you heard in the past, or any suggestions you have on WebCast topics for the future. You can send that feedback to us using the e-mail alias feedback@microsoft.com, and please include "Support WebCast" in the subject line.

Okay, let's move on to the rest of the questions: How can I rename the SQL cluster instance after it is installed to a different instance name?

Oscar: You cannot rename the instance. You will have to uninstall the virtual server and then provide a new name. So you can't rename it directly.

Jim: Okay. Our next question is: How is GEO cluster different than Microsoft SQL Cluster?

Oscar: GEO cluster is a concept that the two servers are separated by a great distance. I think that we have a future release that will fully support the GEO cluster in our next release of Windows. But I can't comment specifically on that.

Jim: Our next question is: With two instances, can a partitioned disk array work?

Oscar: The partitioning of disks really depends on the vendors. Some vendors can carve out the drive so you can just represent the physical drive to Windows NT, even if it's the same drive. So I really can't answer that question. You need to go back to the vendor and find out whether you can partition so that SQL Server understands there are two physical drives. Then yes, you can do that. You need the physical drive resource to be used in the SQL Server, for different instances.

Jim: Okay, the next question is about a quorum disk. I've seen documentation indicating that this should be 5 MB, and another indicating it should be 50 to 500 MB. We've already configured a 5-MB quorum disk.

Ranjit: Okay, quorum is an issue. You want to make sufficient space for your quorum logs. If you're running into a space problem, your cluster will corrupt it. So I know it's a 500 MB, it has to be a dedicated a physical drive as well, not to interfere with other installations. I have customers saying, "I've got 18 GB on each drive, should I dedicate 18 GB to a quorum drive?" Some of the vendors have a tool to carve out the partition, which will be represented as a physical drive, even if it's the same drive, and we'll recommend about 500 MB for the quorum drive. That will be sufficient.

In answer to the question, yes, you can move the quorum log if you're getting into a space problem. You can define the drive resource that has more than a 5 MB and you can move the quorum. We have KB articles to explain how to move quorum logs to different drives.

Jim: Excellent. Our next question is: Why is the SQL Server 2000 Analysis Service not supported when clustering?

Oscar: It is not currently supported because of a design limitation of the product.

Jim: The next question is about failover. After a node has failed, and the failover has taken place, what is the preferred process for removing the failed node from a 24 ´ 7 production environment, and then reinstalling it after repair has taken place?

Ranjit: In SQL Server 2000, we have simplified this process in setup, where you can easily remove the node, repair the node, and rejoin the node.

Oscar: First, you have to run SQL setup, and you remove that node. That becomes SQL prospective, and then you go to cluster admin, and then evict the node. After everything is completed, you need to join the cluster, and then you run SQL setup to add the node for the SQL virtual server.

Jim: Are instances required for clustering? And if not, why would I want multiple instances in a non-ISP/ASP scenario?

Ranjit: Well, if you decide to install more than one virtual server, then in SQL Server 2000, you can have only one default instance. The other instance has to be a named instance. There's no getting around that. If there is only one virtual server you're trying to install, then you could choose a default installation, and not choose a named instance for that.

Jim: In an active-active installation, can I install a default instance on each virtual server?

Oscar: No, we've been stressing this issue through the presentation. You can have only one default instance. The reason is the default instances will take the computer name, and it will have a separate registry different from the named instance registry setting. I think Ranjit went over that registry picture on your presentation, right?

Ranjit: Yes. The default instances located under HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer, and the named instances are installed in the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server and then the instance name.

Jim: Should the cluster IP and the cluster name be showing up in an instance resource or in the cluster group resource?

Ranjit: The cluster IP and the cluster name should be in the cluster group resource. That's the default installation, and that's why we recommend you have those resources.

Jim: Can the IsAlive query fail if the CPU is too busy, that is at 100 percent?

Oscar: Yes, this could lead to in some cases to SQL Server not responding, which will cause the IsAlive query not to fire. We would recommend setting the affinity mask to n-1, and also do not set priority boost to 1. For more information, look in Microsoft SQL Server 2000 Books Online.

Jim: When you install active-active, do you install each virtual server from the node you want it to run on?

Ranjit: Yes, you need to run it from the local node to install the virtual server.

Jim: What system monitor software do you recommend to monitor the SQL failover server?

Oscar:. There are no SQL Server counters in System Monitor to monitor SQL failover.

Jim: Our next question is about transactions: What happens to a live transaction when SQL Server fails over?

Ranjit: During the failover process, there will be client disconnects. For example, in a stateless scenario, like the Web server, it could just refresh and reconnect. During failover, what's going to happen is after the SQL Server service is started on the other node, you'll go to a regular commit reprocess, and all committed transactions will be rolled forward, and all uncommitted transactions would be rolled back, just like any of the regular recovery SQL Server procedures.

Oscar: Just adding that the transaction consistency and integrity is still maintained, regardless whether you have a failover server or not. It's just works the same way as a stand-alone.

Jim: Why does the DTC require a separate IP address?

Oscar: Well, this was the problem from the SQL Server 7.0 days. The SQL MS DTC will be installed in the first available group that it can find. Often it became a SQL group. So after the MS DTC resource has been created in the SQL group, when the MS DTC resource fails, SQL Server will fail as well. So we recommend separating MS DTC resource from the SQL resource. That's why you need the separate network name and a separate IP address for the MS DTC.

Jim: Our next question is asking: How long is fail over? You mentioned three to five seconds as heartbeat timings. How long does it take after failure is detected for the passive node to take control?

Ranjit: From the tests we have seen here, it shouldn't take more than 30 seconds for the failover to occur. So it should be around 30 seconds.

Jim: Do you have to uncluster SQL Server 2000 nodes to install Windows 2000 and SQL Server 2000 service packs, or can you just install them directly on the cluster? If you can install directly on the cluster, do you need to install the service packs on all nodes, or do you need to apply them just to one node?

Oscar: Okay, first of all, there are no unclustered nodes in SQL Server 2000. In the SQL Server 7.0 days, the loading of service pack required certain steps, stopping services and all that. In SQL Server 2000, you go right in. I have no problems just applying a service pack at any point.

Ranjit: And a point to add is that because with Windows NT 4.0 SP4 or later and with Windows 2000 we support rolling upgrades. So you can apply the service packs directly on the nodes of the cluster. In SQL Server 2000, there is no Failover Cluster Wizard, so as Oscar pointed out, you just directly apply the service pack on all the nodes.

Oscar: One practice might be to pause the node while you're applying a service pack. But that also depends on your production scenario.

We recommend that you sync up the service pack between two nodes. This is in preparation for the application, which is a SQL Server failover in a reciprocal way, that you want to make sure that you provide the same environment for the application to run. So it is a good idea that you sync the service pack level.

Jim: Our next question is about MS DTC: Clustering has already recommended that additional resources not be added to the cluster group. It appears that MS DTC does this by default. Are there any implications when MS DTC resides in the cluster group?

Ranjit: In Windows 2000, by default, when you run Comclust, MS DTC will fall under the cluster group. So that is the actual default installation for MS DTC. You could have MS DTC on a different group. If you decide to, you will have to first stop the resource; you want to then delete the resource in the Cluster Administrator, and then re-create the MS DTC resource on a different disk drive, and then delete the DTC log on the existing drive.

I think we will soon be publishing a KB article on the procedures for how to move MS DTC to a different group.

Oscar: Adding a couple points there. MS DTC will find the first available group, which happens to be a cluster group. That's why if you do not separate the MS DTC IP address network name, they will write on that cluster group. That's why you end up with a cluster group. We recommend moving it to a different resource, because if that resource fails, then you have a problem.

Jim: Can we add and remove disk drive letters for backup and restore purposes without defining them as shared resources?

Ranjit: We will need a detailed scenario from you to answer this question . If you could provide a scenario where you would do the above, we would be in a better position to answer your question

Jim: Our next question is, in a resource group in which disks are visible to an instance: I have three disks within a resource group, but EM can still only see the original disk the instance was installed on. How do I get to see the other?

Oscar: This a common question that customers ask. That group has to be part of the SQL Server group. So you have to move that drive resource to a SQL Server group, and then SQL Server will be able to see those drives through the Enterprise Manager.

Jim: Okay. Will a demo of installing cluster server be available?

Ranjit: I believe there is a demo available in the MCSE Training Kit: Microsoft Windows 2000 Advanced Server Clustering Services (ISBN: 0-7356-1293-5; http://mspress.microsoft.com/books/5036.htm).

Oscar: Also, you don't have to have cluster settings to actually do this. You can install one node, a single node cluster, as we indicated.

Jim: Our next question is about clustering via ATM. Is there a supported way to change the heartbeat time out to allow a cluster to work across several thousand kilometers via ATM or similar technology?

Oscar: No. The heartbeat is not configurable on any MSCS configuration. Microsoft is currently working on certification process for a geographically dispersed cluster. For more information, please look at the following KB article http://support.microsoft.com/support/kb/articles/q280/7/43.asp.

Jim: Thank you. Our next question is: Do you have to uncluster SQL Server if the IP address of the physical node changes? In SQL Server 7, we had to uncluster first.

Ranjit: As I pointed out earlier, there is no cluster wizard in SQL Server 2000. You will need to run Setup to change the IP address.

Oscar: The node IP address really has no business in SQL Server 2000. Like I indicated, node IP can be subscribed to a DHCP as long as a SQL IP and a cluster IP stays static.

Jim: Okay, our next question is about load balancing. Is there any supported way to get load balancing or something like it for an active-active SQL cluster?

Oscar: There is no load balancing. Microsoft active-active cluster is not designed to load balance. However, you may set up some replications or log shipping between two servers. That may be a possibility; but we do not support load balancing.

Jim: Is there a step-by-step installation guide available for SQL Server 2000 clustering?

Ranjit: Yes, it is available, I put that in slide 64. Q243218 (http://support.microsoft.com/support/kb/articles/q243/2/18.asp) talks about the installation of SQL Server 2000 Enterprise Edition. Another good place is SQL Server Books Online, and look under the topic Failover Clustering. It talks about all of the installation steps.

Oscar: We have a lot of KB articles and white papers regarding how to set up a SQL Server 7.0 cluster, because it was very procedure oriented. If you missed one of those points, you might have to go back and redo it. In SQL Server 2000, we really integrate everything into the Setup program, so it's very intuitive. After you've gone through it, it's going to be much, much easier than SQL Server 7.0.

Jim: If the failed machine recovers, does it get control from the failover machine, or does it have to be removed and reinstalled into the cluster?

Ranjit: After you repair a failed node and you bring it online, depending on the failback policy that's set, you can either have it fail back immediately, or you could set up a different time to fail it back. So it depends on how you configure the failback policy.

Oscar: Yes, after the node comes back up from a failure, first you need to make sure that it will be able to join the cluster. After it joins the cluster, that means that node can participate in a failover mode. At that point, it's up to you. As a default, I think the SQL Server will try to fall back to the previous node. You have to determine what your business requirement is, and make sure that you will fall back after the node has come back.

Jim: Our next question is about notification of a failover: Is there any way that the cluster or virtual machine can send an e-mail or run a program when the virtual machine fails over? That is, send e-mail saying it has failed over?

Ranjit: I wanted to highlight here that SQL Mail is not supported on a cluster. We could provide an alert on that, but it's not 100 percent guaranteed that SQL Mail will fire an e-mail every time a virtual server fails.

Oscar: Yes, the SQL alert will not trigger through the e-mail; however, you may find some Windows NT solution on this one. You may explore whether there is an option that you can set for alerts through Windows NT.

Ranjit: You can set alerts in System Monitor in Windows 2000 if you want to send out alerts. So right now, that is the recommended way of going about it.

Jim: All disks are in the SQL Server group; only the original disk can be seen by the EM. That's a follow up to disks in a resource group.

Oscar: Yes, that drive has to be part of the SQL Server group, so the Enterprise Manager will be able to write to that disk resource. This is the dependency problem. SQL Server requires you to have the disk resource in the same group to be able to write logs and data to that drive. So make sure that that drive resource is in a SQL Server group.

Jim: Is it possible to have an instance of IIS on one node, SQL Server on another, and then have them fail over to one another?

Oscar: I don't see why not. Unless you have a specific problem, I don't see why not, going on two different servers on two different nodes. You may have to design sufficient hardware to run both servers, but I don't have any specific issues as to why not.

Jim: If MSCS is active-passive, why can SQL be installed in an active-active mode?

Oscar: I guess if I rephrase the question, if Microsoft Cluster Server is the active-passive, why can SQL Server be installed on active-active? Okay, the active-active model is really the point of the application. SQL Server cluster or Windows NT clustering will give you capability of running the application on the other node in case there's a failover. So I guess the active-active model really depends on how you design the SQL Server part of it. Windows NT is just the basic underlying provider of clustering, of failover capabilities.

In terms of the active-active model, the datacenter model has four nodes. So if you run your four instances, one instance on each server, you'd be talking about active-active-active-active. This is just the terminology. What active means is that you have the active virtual SQL Server running on that node. So this is terminology that's pointed to the Windows NT clustering.

Jim: Our next question is a follow up about the question about which disks in a resource group are visible to an instance. The follow up question is: All the disks are in the same group as the SQL Server. The original question was: I have three disks within this resource group, but EM still only sees the original disk the instance was installed on. How do I get to see the other?

Oscar: Well, I guess that may lead into a very specific issue with this customer.

Ranjit: You might have a look this problem disk, and if you still cannot see the other two, the resources in the same group, then we'll have to look at it from the Windows NT level, the Cluster service level, to see why SQL Server is not able to find those disks. So we will have to look at that on a case-by-case basis.

Jim: You may want to submit an incident on the Web, or call into Product Support Services and speak to a support professional.

The next question is: For single-database, single-instance SQL application, how many logical drives are recommended in a two-node cluster?

Oscar: The minimum is one; you need one drive for the zero SQL Server, but there are no restrictions on how many is has to configure.

Jim: Okay. Does SQL Server/MSCS support disk resource access through Storage Area Network appliances (not System Area Networks).

Ranjit: MSCS/SQL Server only supports disk resource access through Storage Area Network appliances that are certified on the HCL list. For more information, see http://www.microsoft.com/hcl/.

Jim: Okay, with that question answered, we have answered all of the questions that were submitted today. So that will wrap up our session. I want to thank all of you for joining us and I hope this information was useful to you.

Once again, we are very interested in your feedback regarding the WebCast program. You can send us your feedback using e-mail alias feedback@microsoft.com, and please be sure to include "Support WebCast" in the subject line.

We hope you join us again in the near future. Thank you, and goodbye.