Increasing Data Availability by Using Clustering

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

The information presented in this section assumes an understanding of basic cluster terminology. If you are not familiar with clustering, you can refer to a number of sources for further information:

  • For general information about server clusters, including terminology, procedures, checklists, and best practices, see Help and Support Center for Windows Server 2003.

  • For information about designing server clusters, see "Designing and Deploying Server Clusters" in this book.

You can use clustered file servers to make sure that users can access business-critical data, such as home directories and software distribution shares. You can also use clustered servers to consolidate multiple nonclustered file servers onto a clustered file server. Each server is then re-created on the cluster as a virtual server.

Important

  • Because multiple network names might belong to the same server, File Share resources might appear under these names and might also be accessible through them. To avoid client connectivity interruptions, make sure that clients use the network name that is associated with the group in which the File Share resource belongs. For more information about using the proper network name, see article Q170762, "Cluster Shares Appear in Browse List Under Other Names" in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

Choosing Virtual Server Names

If you are migrating nonclustered file servers to clustered file servers, and you do not currently use (or plan to use) DFS, you should use the IP address and network name of each migrated server to create an identical virtual server on the clustered file server. Doing so allows users to continue to access data by using the server names that they are familiar with. You also ensure that links and shortcuts continue to work as they did before the migration.

Choosing the File Share Resource Type

A clustered file server uses the File Share resource type to make data available to users. You have three options when configuring this resource type:

Normal share

Normal shares function similarly to shared folders created on nonclustered file servers, except that you use the Cluster Administrator snap-in to create them. When you create a normal share, you publish a single folder to the network under a single name. Normal shares do not have required dependencies; however, if the normal share is located on cluster storage, the normal shares should, at a minimum, have dependencies on the cluster storage device (the Physical Disk or other storage-class resource), with the preferential addition of dependencies on the network name and IP address.

You can create a maximum of 1,674 resources, including File Share resources, on a cluster. To provide good failover performance, do not approach this limit in production environments. In addition, if you need to create a large number of normal shares, it is better to use the Share Subdirectories option.

Share subdirectories (or hide subdirectories)

A share subdirectories share publishes several network names: one each for a folder and all of its immediate subfolders. For example, if you create a share subdirectories share called Users, any folder you add to the Users folder is automatically shared.

Important

  • When sharing subdirectories, do not use the same name for subfolders under different folders (for example, \folder1\name1 and \folder2\name1). The first shared subdirectory to come online will remain online, but the second shared subdirectory will not be initialized and will not come online.

Share subdirectories offer a number of advantages:

  • They do not require you to create a File Share resource for every folder. As a result, you reduce the potential time and CPU load needed to detect failures.

  • They are an efficient way to create large numbers of related file shares on a single file server. For example, you can use this method to create a home directory for each user who has files on the server, and you can hide the subdirectory shares to prevent users from seeing the subdirectory shares when they browse the network.

  • They allow administrators who are not experienced with server clusters or using the Cluster Administrator snap-in to easily create folders that are automatically shared.

When using the share subdirectories feature, determine the number of file shares you plan to host on the cluster, because the number of file shares affects server cluster capacity planning and failover policies. Specifically, you need to determine the following:

  • The number of nodes you plan to have in the server cluster

  • The number of node failures you want the server cluster to withstand while still providing acceptable performance

  • Whether the remaining nodes can handle the load of the failed nodes

The number of nodes is important because a single node can support a limited number of file shares, which varies according to the amount of RAM in the server and which is described in "Reviewing File Server Limits" later in this chapter. If you want the cluster to be able to survive the loss of all but one node, make sure that the cluster hosts no more than the maximum number of file shares that can be hosted by a single node. This is especially important for two-node clusters, where the failure of one node leaves the single remaining node to pick up all the file shares.

In a four-node or eight-node cluster, you have other options that might be more appropriate, depending on the failure scenarios that you want to protect against. For example, if you want a four-node cluster to survive one node failing at any point, you can configure the file shares so that if one node fails, its file shares are spread across the remaining three nodes. In this scenario, each node can be loaded to 66 percent of the maximum number of file shares and still be within the maximum limit of a single node in the event of a single failure. In this case, the cluster can host three times the number of file shares that a single server can host. If you want to survive two nodes failing, a four-node cluster can hold twice as many files shares (because if two nodes fail, the remaining two nodes pick up the load from the two failed servers) and so on.

For more information about server cluster capacity planning and failover policies, see "Designing and Deploying Server Clusters" in this book.

Note

DFS root

You can use the File Share resource type to create a resource that manages a stand-alone DFS root on a cluster. The DFS root File Share resource has required dependencies on a network name, which can be either the cluster name or any other network name for a virtual server. However, it is recommended that you do not use the cluster name (in the Cluster group) for any resources.

The Cluster service manages a resource group as a single unit of failover. Therefore, if you want four DFS roots to fail over independently, create them in different groups. Each group has a network name or the virtual server name with which the root is associated.

When creating a DFS root in clustered file servers, review the following issues:

  • The name that you specify for one DFS root cannot overlap with the names for the other DFS roots in the same cluster. For example, if you name one DFS share C:\Dfsroots\Root1, you cannot create other roots using names that are derived from the first DFS root, such as C:\Dfsroots or C:\Dfsroots\Root1\Root2, and so forth.

  • On server clusters, do not create clustered DFS roots that have the same name as nonclustered DFS roots or shared folders.

  • Clustered file servers running Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition support multiple stand-alone DFS roots. These DFS roots can exist in multiple resource groups, and each group can be hosted on a different node.

  • Clustered file servers running Microsoft® Windows® 2000 Advanced Server or Windows® 2000 Datacenter Server support one DFS root per server. Mixed-version clusters running Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition on some nodes and Windows 2000 on others only support one DFS root per cluster as well. For more information about mixed-version clusters and rolling upgrades, see "Deploying Clustered File Servers" later in this chapter.

    Caution

    • Do not make DFS configuration changes (for example, creating new roots, adding new links, new link targets, and so on) while operating a mixed-version cluster, because all DFS changes are lost upon failover.

For more information about creating DFS roots on a clustered file server, see article Q301588, "HOW TO: Use DFS on a Server Cluster to Maintain a Single Namespace," in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

Using Shadow Copies on Server Clusters

Windows Server 2003 supports creating shadow copies on cluster storage. Shadow copies are point-in-time copies of files that are stored on file servers running Windows Server 2003. By enabling shadow copies, you can reduce the administrative burden of restoring previously backed-up files for users who accidentally delete or overwrite important files.

If you plan to enable shadow copies on a server cluster, review the following issues:

  • Cluster-managed shadow copies can be created only on cluster storage with a Physical Disk resource. In a cluster without cluster storage, shadow copies can be created and managed only locally.

  • The recurring scheduled task that generates volume shadow copies must run on the same node that currently owns the storage volume (where the shadow copies are stored).

  • The cluster resource that manages the scheduled task must be able to fail over with the Physical Disk resource that manages the storage volume.

  • If you place the source volume (where the user files are stored) and the storage volume (where the shadow copies are stored) on separate disks, those disks must be in the same resource group.

  • When you configure shadow copies using the procedure described in "Enable Shadow Copies for Shared Folders in a cluster" in Help and Support Center for Windows Server 2003, the resources and dependencies are set up automatically. Do not attempt to modify or delete these resources and dependencies directly.

To ensure availability, plan to enable shadow copies before you deploy the server cluster. Do not enable shadow copies in a deployed cluster. When you enable shadow copies, the shadow copy volumes (as well as all resources that directly or indirectly depend on the disk) go offline for a brief period while the resource dependencies are created. The shadow copy volumes are not accessible to applications and users while they are offline.

Note

  • If you enable shadow copies before clustering your servers, you must disable, and then re-enable, shadow copies. If you cluster a disk containing a previously created shadow copy, the shadow copy might stop functioning after that disk’s Physical Disk resource fails over.

For additional guidelines and information about shadow copies, see "Designing a Shadow Copy Strategy" later in this chapter. For in-depth information about using shadow copies on server clusters, see "Using Shadow Copies of Shared Folders in a server cluster" in Help and Support Center for Windows Server 2003.