Before you set up your MSCS cluster, consider what you actually want it to do. Providing access to shared files is certainly one of the most common uses for a server, so you may be creating a server cluster to provide high availability for mission-critical data and files. Or perhaps you simply want to ensure that one or more departments isn’t left idle for several hours in the event a server crashes.

Here, I’ll provide a guide to setting up a simple file server cluster that clusters network file shares. Once you gain experience setting up this type of cluster, you can experiment with other clustered resources such as print servers and Web servers.

Share and share alike
To share files on a nonclustered Windows server, you must create a file share for the directories that contain the files you want to share. The same is true with clustered file shares. You have three main options for creating a clustered file share resource:

  • Create a basic file share.
  • Share subdirectories under a main share.
  • Create a file share associated with a standalone Distributed File System (Dfs) root.

A basic file share shares a folder as a single sharepoint with a single name. Users can connect to the shared folder by this name and see any subfolders and items contained in the shared folder, subject to their permissions in the folder(s). You would typically use this option to share a folder containing application subdirectories or a set of document folders users need to access only through the main sharepoint. The share is available through the network using the name specified by the network name resource you indicated when you set up the resource.

For example, assume you have a cluster node named \\Node1. You create a file share resource for the Applications folder, using AppServe as the network name resource. Users connect to and use the share at \\AppServe\Applications. Someone browsing the network would also see \\Node1, and browsing that server, would see the Applications share (\\Node1\Applications). However, connecting through the virtual server name ensures that the users will always be able to access the resource, even if the active node goes down. If \\Node1 went down and \\Node2 took over, for example, the users would still see the resource available at \\AppServe\Applications, but not at \\Node1\Applications.

The second option allows you to also share subdirectories under the main sharepoint. In this case, MSCS shares the specified root folder using the name you specify. It also shares each subdirectory as a separate share. You have the option of sharing the subdirectories as visible shares or as hidden shares. For example, assume you create a folder named Share that contains subdirectories named Sub1, Sub2, and Sub3. Using the former option, MSCS creates four visible shares named Share, Sub1, Sub2, and Sub3. Using the latter option, MSCS creates a visible share named Share and three hidden shares named Sub1$, Sub2$, and Sub3$.

Why share subdirectories if their contents will be accessible if you share the root folder? The main reason is to provide a means of easily and quickly sharing a large number of folders. For example, you can use this method to share a folder that contains a folder for each user called Users. Administrators might use the Users share on the active node to manage the folder and its contents, while individual users would connect to their own share by their individual share names.

For example, assume you create a cluster share with a network name resource of Home that points to a share named Users on the physical server \\Node1. The Users folder contains the subdirectories Al, Joe, Kate, and Alice. When you create the file share resource, you direct MSCS to share the subdirectories, but not hide them. Kate could get to her folder through the UNC pathname \\Home\Kate and Joe to his through \\Home\Joe. You would probably map these folders to a local drive letter through the user’s login script.

The third option is to create a file share associated with a standalone Distributed File System (Dfs) root. Dfs allows you to create a homogenous file system structure from disparate servers. For example, you might create a Dfs root that makes four shares on four different servers available from a single sharepoint. This simplifies user access because the users don’t need to know the specific location of resources, only the Dfs share name by which the resources are combined. Setting up a clustered file share to a Dfs root lets you provide failover capability for the share. You can create a clustered file share for a standalone Dfs root, but not for a domain-based root.

Creating the share
For the purpose of this example, assume that your cluster comprises two nodes, Node1 and Node2, with Node1 being the primary, active node for the share. The first share will have its root at \Applications and will be shared as a single folder. We’ll configure the virtual server to appear on the network as \\Server. The second share will have its root at the \Users folder, which will contain subdirectories, one per user. We’ll configure this second share to share the subdirectories and hide those shares.

Before jumping into the fire, however, you need to do a little prep work. On the active server, open the shared volume, assume Z for this example, and create a folder named \Applications. Create a second folder named \Users and then create a few subdirectories under \Users. With the folders created, you’re ready to proceed.

You can create a virtual server and cluster resources manually, but the easiest way to set up a new resource is to use the Cluster Application wizard. Open the Cluster Administrator, right-click anywhere in the left pane, choose Configure Application, and then click Next. Select the option Create A New Virtual Server and click Next. Select Create A New Resource Group and click Next. When prompted for a resource group name, use File Share Virtual Server and click Next. The wizard will prompt you for the Network Name and IP Address properties for the virtual server. The Network Name is the name by which the users will see the server on the network. In this example, use SERVER for the Network Name and specify an appropriate IP address in the public subnet for your cluster; then, click Next. You can specify advanced properties for each of the resources, but at this point, just click Next—we’ll adjust the properties later.

The wizard will ask if you want to create the cluster resource now or later. Choose Yes and click Next. From the Resource Type drop-down list, choose File Share and click Next. The wizard will prompt you for the resource name and an optional description. This information appears in the Cluster Administrator and has no bearing on the name that users see when they browse for the resource. Specify the name Application Share and click Next.

You then need to specify the location of the folder you want to share, as well as how you want to share it. In the Share Name field, specify the name by which you want the folder shared. In this case, use Applications as the share name. For the Path field, type Z:\Applications. Leave permissions alone for now and click Advanced. Select Normal Share and click OK. Click Next and then click Finish.

MSCS creates the group and resources but does not bring the group online. That’s your next step. In the Cluster Administrator, expand the Groups branch, right-click the Application Share group you just created, and choose Bring Online. MSCS brings the resources online one at a time, starting with the share, then the IP address, and finally the network name. When you browse the network, you should see a server named \\APPS. Browsing through that server, you should find an Applications share.

Create another share using the same virtual server but for the \Users share. Right-click Cluster Administrator and choose New Resource. In the Name field, type User Share. Select File Share Virtual Server from the Group drop-down list and click Next. Select the nodes in the cluster that you want MSCS to allow to host the share and click Next. In the Dependencies dialog box, select the File Share Virtual Server IP Address and the File Share Virtual Server Network Name resources and click Add. The Users share need not be dependent on the Applications share.

Click Next and specify Users as the Share Name and z:\Users as the path. Click Advanced and select Share Subdirectories and Hide Subdirectory Shares; then, click OK. Click Finish to create the resource and click OK to close the status dialog box. Right-click the newly created resource and choose Bring Online. At this point, you should be able to browse the network for \\Server\Applications and \\Server\Users.

Setting failover and failback policies
After you create your group and resources, you can set failover and failback policies for them. To set the policies for the group, right-click the File Share Virtual Server group in the Groups branch and choose Properties. First, check and configure the list of preferred owners. On the General page, click Modify to open the Modify Preferred Owners dialog box. Select the desired nodes in the Available Nodes pane and click the right arrow to move them to the Preferred Owners pane. Use the up and down arrows to rearrange the nodes in the list according to the desired priority. MSCS will failover the group to the available servers in the order listed. Click OK when you’re satisfied with the list.

Next, click the Failover tab. The options on this tab allow you to specify the number of times the group can fail in a given period of time before the cluster places the group in a failed state and does not attempt to bring it back online. The Threshold value specifies the number of failures, and the Period value specifies the time in which those failures must occur before the group is marked as failed.

Use the Failback tab to specify whether or not the group can failback when the primary node comes back online. You can configure failback to occur immediately when the server comes back online or during a specified time of day (based on a 24-hour clock). Use this latter option to restrict failback to off-peak hours.

Setting resource properties
Next, turn your attention to configuring properties for individual resources in the group. To do so, expand the group in the Cluster Administrator, right-click a resource in the right pane, and choose Properties. I’ll use the User Share resource for this example.

The General page lets you configure the name, description, and possible owner list for the resource. By default, the resource runs in the same resource monitor process as the Cluster service resources. However, you can select the option Run This Resource In A Separate Resource Monitor if the resource’s DLL might cause conflicts with other resource DLLs or when you need to debug a resource. However, in most cases—particularly with standard resources—you can allow the resource to share the same resource monitor as the Cluster service resources.

Use the Dependencies tab to specify resource dependency. The User Share resource you created previously, for example, is dependent on the File Share Virtual Server IP Address and File Share Virtual Server Name resources. If either of these resources fails, the User Share will fail as well. You can specify dependencies only within a resource group, not between groups.

The Advanced tab contains several options that show the resource functions within the group. For example, you configure through the Advanced tab whether or not MSCS will attempt to restart the resource if it fails. If you choose the Restart option, you can specify whether or not the resource affects the group, causing the group to fail if the resource fails. You also specify the failure threshold and period, just as you do for a group. MSCS will make the specified number of attempts to restart the resource in the given period, and failing that, fails over the group.

The Looks Alive poll interval specifies the polling period that MSCS uses to determine if the resource appears to be active. The Is Alive poll interval specifies the polling period that MSCS uses to determine if the resource is active. MSCS requests a more extensive check of the resource’s status for the Is Alive poll. The default values are set through the properties for each resource type. For example, to change the values for the File Share resource type, click the Cluster Configuration/Resource Types branch in the Cluster Administrator and open the properties for the File Share resource type. In the properties for each resource, you can specify that the resource use the default values for its type or you can specify custom values, if needed. Finally, configure the Pending Timeout value for the resource. This is the period of time that the resource can be in an Offline Pending or Online Pending state before MSCS fails the resource.

The Parameters tab lets you configure various properties that vary according to the resource type. For the File Share resource, for example, you can modify the share name, path, number of allowed connections, share permissions, and advanced properties including whether or not to hide subdirectory shares. The Parameters tab of an IP Address resource lets you specify the IP address, subnet mask, network interface, and whether or not to enable NetBIOS for the address. If you wanted to change the NetBIOS name for your virtual file server, for example, you would open the properties for the Network Name resource, click the Parameters tab, and enter the desired server name.

Conclusion
Merely setting up a server cluster doesn’t do you much good until you configure the resources you want to be clustered. Even though the process can be a bit cumbersome and confusing, Microsoft has tried to make things easier by creating the Cluster Administrator and some wizards to help you on your way. Do a bit of planning to make sure your clusters do what you want them to do. After that, use the Cluster Administrator and its wizards to create clusters that will ensure that your users will always be able to safely and reliably access their data.