Windows File and Print Clustering |
![]() |
![]() |
![]() |
Written by David Noel-Davies | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This white paper presents scenarios for creating highly available file and printer shares with the Cluster service feature in the Microsoft® Windows® 2000 operating system. Although this document by no means presents a comprehensive list of every possible scenario, it tries to provide enough examples so that administrators can implement Cluster service in the way that best serves their users' needs.
IntroductionPrint service availability is often considered critical in computer network deployments. Consequently, enabling administrators to create highly available print shares is one of the key goals of the Cluster service feature in the Microsoft® Windows® 2000 Advanced Server operating system. Because clustering is new to Windows, administrators must move away from machine-centric view of Windows. This document covers the basic information you need to know to implement Windows 2000 Cluster service correctly and describes the shared-nothing architecture of Cluster service, group structure, and virtual servers. This document also describes in detail how to create print spooler resources, and the Appendix A provides a detailed illustration of the cluster setup that is referred to throughout this document. Basic Terms and Concepts This section covers the basic terms and concepts that are used throughout this document. Naming ConventionsIf you're new to clustering in Windows, you may become confused by the different naming conventions that are used. During beta testing of the Cluster service, the product was code-named Wolfpack. The product was released with the nameMicrosoft Cluster service and is sometimes referred to as MSCS. In addition, some Knowledge Base articles refer to the technology as Cluster Server or Server Clustering. By any name, the technology is the same. Note: Do not confuse This type of clustering should not be confused with Network Load Balancing or Component Load Balancing. Shared-Nothing ArchitectureCluster service uses a shared-nothing model of clustering. This model does not allow cluster members to access resources on other members of the cluster, as a shared-everything model would. It also avoids the overhead and inherent scalability limits that would be imposed by a shared-everything model. In terms of file and printer shares, this means that a file share is owned by only one node. To split file share load among multiple servers, the file shares themselves must be split into different virtual servers. ResourcesA resource provides a service to a client, such as a file share, an Internet Protocol (IP) address, or a network name. Resources are the smallest management unit of Cluster service. Resources can depend on other resources and are organized into groups. DependenciesA dependency is a relationship between resources similar to service dependencies. Dependencies additionally define the order that resources are brought online and offline and are typically represented as dependency trees. Figure 1 illustrates a standard dependency tree for a file share resource. This illustration shows that should an administrator attempt to take the disk resource offline, the file share resource also goes offline, followed by the disk resource. The network name resource does not go to an offline state, because there is no direct dependency on the disk for the network name. Conversely, if we then try to bring the file share resource online when the initial state of all the resources is offline, the disk and IP address are brought online, followed by the network name, and then the file share resource. Note that there is no explicit dependency between the file share resource and the IP address. This is because dependencies are said to be transitive—a definition that is not technically correct but provides a good description of the empirical behavior of a dependency. ![]() Figure 1: Typical file share dependency tree Given the above information, it would appear that a dependency is strictly a one-way relationship. This is not the case, however—a point which is best illustrated here by the print spooler resource. When adding a printer to a virtual server, it is absolutely necessary to run the Cluster Application Wizard from the network name for which the print spooler has a dependency. Applications, network name resources, and generic services also exhibit some similar behavior. Note: For more information on dependencies, see the following Microsoft Knowledge Base articles:
GroupsA group is a logical collection of resources that must all run on the same node to function properly. For example, if the Information Store and Message Transfer Agent in Microsoft Exchange Server were to run on different servers, this would obviously generate some problems. This information also implies one very important fact: A group is the unit of failover in the cluster. Entire groups of resources move from one node to the other, not individual resources. The easiest way to build groups is around storage. Most applications and services require storage to function, as in the Exchange example. Because dependencies can be created only within the same group, every application or resource that uses the same disk must be in the same group as the disk resource. Groups are also generally organized as virtual servers, though more than one virtual server can exist in a group. Failover and FailbackFailover is the process by which a group moves from one server to another. Failover can occur for several reasons:
The third reason provides the definition for failback—that is, the group fails back to a preferred owner if so configured. Preferred owners are configured as a group property. Failback can be configured to occur either immediately or within a specific time period. Note: For more information on failover and failback, consult the following Knowledge Base articles:
Virtual Server![]() Figure 2: Virtual server dependency tree A virtual server is a combination of two resources (for instance, an IP address resource and a network name resource) that work together to present a namespace to a client. Figure 2 illustrates the resources and dependency tree for a virtual server. Note that there is no reason that a group cannot contain multiple virtual servers, but this means that all virtual servers in the group can be owned by only one node at a time. Organizing groups into virtual servers provides finer granularity and better scalability, especially in scenarios where additional nodes are to be added later. Figure 3 illustrates the namespaces that are presented to a client by the cluster nodes. Note: Virtual servers are based on NetBIOS and thus have certain limitations. Creating a Virtual ServerYou can construct a virtual server in either of two ways. Although you can create a virtual server manually, the easiest method is to use the Cluster Application Wizard. The Cluster Application Wizard creates a virtual server with the option to configure a cluster server application. Creating a virtual server manually requires that an IP address and network name resource be configured in the appropriate group. For a detailed scenario that shows both procedures, see Appendix B. Printer SharesCluster service makes it possible to host multiple spooler resources. This allows the service to provide high availability for printer shares, along with the ability to distribute load among the cluster nodes. The print spooler resource is limited to one spooler resource per group. It has required dependencies for a network name resource (for consistent access to the spooler) and a physical disk (to store spooler files). After a spooler resource is created, printers must be added to it. In Windows 2000, the job is greatly simplified, because the spooler resource maintains information about clustered printer ports in the cluster configuration database. This eliminates the need to install the ports twice, once on each node. Drivers, however, must be installed on both nodes, because printer drivers are copied to the PRINT$ share of the remote server. Clustered print spoolers support only standard port monitors and Line Printer Remote (LPR) printers. LPR ports do not support bidirectional printing. Currently, no other ports are supported. When a group containing a print spooler resource fails over to another node, the document that is currently being spooled to the printer is restarted from the other node after the failure. When you move a print spooler resource or take it offline, Cluster service waits until all documents are finished spooling or until the configured wait time has elapsed. Documents that are spooling from an application to a print spooler resource are discarded and must be re-spooled to the resource (or reprinted) if the group containing the resource fails over before the application has finished spooling. Printers hosted by a cluster node are added to Active Directory by the spooler service. Creating a Spooler ResourceThe print spooler resource has required dependencies on a network name and a storage class resource. Figure 2 shows the dependency tree for a spooler resource. ![]() Figure 4: Dependency tree for a spooler resource On the resource parameters page of the New Resource Wizard, the only parameters provided are the location of the spool folder and the duration of the job completion timeout. The wizard, based on dependencies, provides these parameters automatically, so there is usually no need to modify them. Adding PrintersCreating the virtual server and the spooler resource is only half of the job. The spooler resource is useless without printers. To add a printer, you must first note the owning node of the virtual servers, because the Add Printers Wizard copies the drivers to the owning node only. The driver must then be manually installed on the other node. The Add Printers Wizard must be started from the virtual server—specifically, the network name on which the print spooler depends. After the printer is successfully installed, you must add the driver to the other node. Although several different methods exist to add the drivers to the other node, the command line shown in Figure 6 below starts the Add Printers Wizard directly. You might find it useful to create a shortcut to this command line on a file and print cluster. For a detailed scenario, see Appendix C. Adding Additional DriversAdding additional drivers that are not Windows 2000 drivers is relatively uncomplicated. After the initial drivers are installed, you can install additional drivers through the printer user interface (UI). The procedure is as follows:
ScenarioReskit.com has multiple printer servers it would like to consolidate to one cluster, SEA-NA-CLUS-02. There are approximately 200 printers, and performance is of prime importance. Implementation To achieve better performance, the printers are split roughly evenly between two virtual servers, SEA-NA-PRINT-01 and SEA-NA-PRINT-02. Each virtual server is configured in its own resource group with a print spooler resource. Half the printers are installed on one virtual server with the remaining half allocated for the other virtual server. Preferred owners are configured for each group, and each is assigned to a particular group. Failback is configured to occur between 23 and 0 hours. Procedural Overview
For a detailed scenario, see Appendix D. ConclusionBecause of the importance of print services to the end users on a computer network, Windows 2000 Advanced Server provides Cluster service, a powerful feature for improving the reliability and performance of print services. However, you must deploy Cluster service properly to provide these benefits to your users. Since clustering is new to Windows, you may be required to look at familiar tasks in new ways. For example, although clustered file shares behave exactly like normal file shares, creating and administering them is a bit different, because they run on multiple machines. Moreover, you must create clustered file shares using the Cluster Administrator in Administrative Tools, and they can involve more complicated administration of permissions. Similarly, the use of clustering for printer services requires that you apply dependencies for a network name resource and a physical disk. Related LinksFor more information about Windows 2000 Cluster service, see the following resources: See also the following Knowledge Base articles:
Appendix A: Cluster SetupInstallation Notes
Appendix B: Creating a Virtual ServerUsing the Cluster Application Wizard To start the Cluster Application Wizard, open the Cluster Administrator. On the File menu, click Configure Application. At the Welcome to the Cluster Application Wizard page, click Next. On the Select or Create a Virtual Server page, you can configure an application for an existing virtual server or create a virtual server. Because this section is about creating virtual servers, Create a new virtual server is selected. The next page is used to select a group for the virtual server or to create a new group. In general, you should use an existing cluster group, unless storage class resource is either not needed or will be created or moved to the new group. The storage class resource to be used by this virtual server is located in Disk Group 1. Even though an existing group is selected, you'll want to give the group a new name and description to reflect its current function. In this particular instance, the group is named after the virtual server, but this is not necessary and may not even be desirable because a group can host more than one virtual server. After you configure the group name and description, the IP address and network name for the virtual server are provided. After the virtual server properties are provided, the wizard lets you edit detailed information about the group and resources. This is not necessary at this time, so it is skipped. At this point, the virtual server is configured. The wizard prompts you to create an application resource. In this example, only the virtual server itself is of interest, so select No, I'll create a cluster resource for my application later. The wizard then provides a status page. After you click Finish, the group is created in an offline state. To fully test the virtual server, right-click the group, and then click Bring Online. ![]() Figure 17: Right clicking the group in the Cluster Administrator and clicking Bring Online If all is well, the group should come completely online. To check the virtual server, ping from a client by IP address. To test name resolution, ping by name. Using the Manual Method Rather than use the Cluster Application Wizard, you can create a virtual server manually simply by adding an IP address and a network name to an existing group. To begin, right-click the group in which the virtual server will exist, click New, and then click Resource. In this example, the Disk Group 2 was clicked. This starts the New Resource Wizard. The first resource that must be created is an IP address resource. This example shows the creation of the SEA-NA-FILE-02 virtual server. The first step is to identify the resource type. In the Name box, you can type a convenient label. The Description box lets you provide more detailed information. The next page in the wizard lets you specify possible owners. By default, all nodes in the cluster are possible owners. If a node is removed from the possible owners list of a resource, the group in which the resource exists cannot fail over to that node. In this example, the group is intended for failover, so the default is used. The next step in correctly adding the resource is to configure resource dependencies. IP addresses have no dependencies, so you can leave this page as is. The final step is to configure resource-specific properties. An IP address has the following parameters:
When you click Finish, the IP address is created and a confirmation message appears. Now you must configure a network name for the virtual server. The procedure is much the same, with the exception of the way you select the type of resource dependencies and resource-specific parameters. You start the New Resource Wizard from Disk Group 2 by right-clicking the group, clicking New, and then clicking Resource. The resource type is, of course, a network name. Leave Possible owners at the default setting. A dependency is configured for the previously created IP address. A dependency on an IP address is required for a network name. The only resource-specific parameter for a network name is the name itself. This is the name of the virtual server on the network, and it must conform to standard computer naming rules. Click Finish to create the network name. At this point, you can bring the resource group online in the same manner described in the Cluster Application Wizard example. To give the group a more descriptive name, right-click the group, and then click Rename on the shortcut menu. Appendix C: Creating a Print Spooler Resource with the Cluster Application WizardIn this example, the Cluster Application Wizard is used to create the virtual server SEA-NA-PRINT-01 and configure the print spooler resource. To start the Cluster Application Wizard, open the Cluster Administrator. On the File menu, click Configure Application. In this example, the intent is to create a new virtual server and configure the application in one step. Select Create a new virtual server, and then click Next. For this example, select an existing resource group with a storage class resource. This virtual server uses the storage class resource in Disk Group 3. The group name and description are provided. No additional configuration items are needed for the Advanced Properties page. Click Next to create the virtual server. On the next screen, Yes, create a cluster resource for my application now is selected. Click Next. The resource type is Print Spooler. Click Next. The name and description for the resource are provided. To add dependencies, click Advanced Properties. In the Advanced Resource Properties dialog box, click the Dependencies tab, and then click Modify. In the Modify Dependencies dialog box, move the appropriate dependencies from the Available Resources list to the Dependencies list. After you have configured the dependencies, click OK to close all the dialog boxes until you see the screen below. The resource is created, and the wizard prompts you for resource-specific parameters. The wizard fills in the parameters based on dependencies. Usually, no additional modification is needed, so you can click Next. ![]() Figure 38: The provided print spooler parameters generally do not need to be modified. The virtual server and spooler resource are now configured. The group can now be brought online. Adding a PrinterIn this example, the connection must be made to SEA-NA-PRINT-01. To start the connection, on the Start menu, click Run. The Printers folder is selected. From the Printers folder, start the Add Printer Wizard. From a remote connection, the only option is to add a printer to the remote print server. Because this is a new printer, you must create a new port. The Add Standard TCP/IP Printer Port Wizard is started. The port name field is populated as soon as you type the printer name or IP address. After you configure the port, the Add Printer Wizard prompts you for a driver. In this example, a Lexmark Optra is selected. You then name the printer. The share name is populated automatically, but you can change it. You can then provide information about the printer's location and capabilities. When you click Next, the status screen shows you that the printer has been installed. Adding Drivers to the Other NodeTo start the connection, on the Start menu, click Run. The command shown in the Figure 50 starts the Add Printer Driver Wizard. You can use this wizard to install the necessary print drivers for the other node. This step is necessary only for the first Windows 2000 printer driver. After you complete this step, you can install additional drivers for other platforms through the printer user interface. Appendix D: Configuring FailbackThis section describes how to configure a group for failback to a preferred owner. The example is drawn from the scenario for creating normal file shares and configuring failback. To begin configuring failback, right-click the group, and then click Properties. On the General tab in the group Properties dialog box, click Modify. In the Modify Preferred Owners dialog box, add the desired preferred owner. This example is drawn from the first scenario, so SEA-NA-CLN-01 is added. On the Failback tab, the default option of Prevent failback is changed to Allow failback, with Failback between configured for 23 and 0 hours. When you click OK, the process is complete and the group is configured for failback to a preferred owner. |
< Prev | Next > |
---|