Win 2003 High Availability Solutions, Virtual Servers and More

By Marcin Policht (Send Email)
Posted Apr 26, 2007


Throughout our recent articles on Microsoft Windows 2003 High Availability Solutions, we dealt mainly with topics essential to the early stages of planning Server Cluster implementations, namely selecting quorum type (with Single Shared, Single Local, and Majority Node Set as viable options), shared storage technology (which affects overall architecture, reliability, and pricing), and the setup of test environment (required to properly evaluate proof of concept and confirm whether benefits derived from clustering justify increase in cost and complexity).

This installment of the series focuses on designing clustered virtual servers, groups and resources. We define each of these and then look at their types and respective characteristics.

Discuss this article in the ServerWatch discussion forum

This installment will focus on another stage of this process: designing clustered virtual servers, groups and resources, starting with their definitions and following with a review of their types and characteristics.

Cluster Resource is a virtualized representation of a software or hardware component that is functioning according to clustering principles. This means that such resource gracefully handles standard clustering operations, such as failing over from one cluster node to another or switching between online (available) and offline (unavailable) modes. This also implies there can be only a single instance of a particular resource, representing specific instance of software or hardware, within the same cluster at any given time. The node, which operating system controls that resource's behavior is called its owner. As resources failover between nodes, ownership changes.

Resources are implemented as dynamic link libraries (DLLs) and are characterized by two types of properties. The first type describes features specific to the software or hardware component that a particular resource represents (e.g., a disk drive letter or IP address and subnet information). The second type determines its clustering behavior (e.g., a list of nodes that can take ownership of the resource). This article will concentrate on the first type.

Resources can be dependent on one another, mirroring dependencies of their software and hardware counterparts. For example, most networking services require a physical disk to host their installation and configuration files, as well as IP settings that makes them accessible to other systems.

To make these concepts easier to understand, let's review the list of some commonly used clustering resources available as part of standard Windows Server 2003 R2 Enterprise Edition based Server Cluster installation:

  • IP Address consists of the IP address and subnet mask, with the default gateway assigned indirectly by associating the resource with one of the clustered public networks. Each cluster node is connected to at least two networks, typically referred to as private and public, with the former dedicated to internal cluster communication and the latter intended mainly for connectivity with clients utilizing clustered resources.

    This configuration has two important implications: 1)the IP address must be statically assigned, and 2) more importantly, you need a sufficient number of available IP addresses within the subnet on which cluster nodes reside to accommodate all of your planned clustered installations, in addition to a single IP address for each of cluster nodes and one used by the cluster itself. You also have an option of disabling NetBIOS support for this resource in cases where traffic targeting its IP address does not require it. By default, this feature is turned on.

  • Network Name designates a name associated with an IP Address resource and dependent on it. Once the name gets registered in DNS, which you can ensure by enabling its configuration parameter "DNS Registration Must Succeed," clients can use it instead of the more-cumbersome and difficult-to-remember IP address.

    Network Name Resource when grouped with IP Address Resource, together, form a clustered virtual server. Typically, such combination also includes other types of Resources, such as Physical Disk and dependent on it File Share. From the network access perspective, such virtual server has the same characteristics as its hardware-based counterpart: It appears to be a separate system with its own IP address and name, and some specific purpose, dependent on additional clustered resources assigned to it.

    The most significant difference between them is their default authentication mechanism. Windows 2003 Server in Active Directory domain uses Kerberos as its primary method of verifying clients credentials. Virtual server relies on legacy NTLM (or NTLMv2) protocol for the same purpose, since its computer account does not get published into Active Directory when created. To alter this behavior, which also improves security, turn on "Enable Kerberos Authentication" parameter of its Network Name Resource. This also can be configured via Command Line with cluster utility on Windows 2000 Server SP3/SP4 clusters by following steps in the Microsoft Knowledge Base Article 235529.

    Keep in mind, to successfully complete such an arrangement, you will likely need to modify properties of the user account used by Cluster Service by granting it sufficient permissions and user rights on relevant Active Directory containers and objects, as well as on the local cluster nodes. For more information on this subject, refer to Microsoft Knowledge Base article KB307532. In addition, note that the Network Name resource must be offline to perform this operation. When enabling Kerberos, consider also turning on "DNS Registration Must Succeed" parameter for the same Network Name resource.

    Virtual server is a special (although also the most common) case of a Resource Group, which is simply a collection of clustered Resources. Typically, albeit not necessarily, they are associated with each other. Groups constitute boundaries for failover of resources, which means all resources that belong to a specific group have the same owner. Thus, you cannot move individual resources within a group to an arbitrary node without moving all remaining resources from the same group to the same node.

  • Physical Disk represents a volume on a shared disk. As mentioned before, its criticality should not be underestimated, since its availability and performance affect most of cluster operations (e.g., Physical Disk resource is required to set up a shared quorum). Unlike IP Address or Network Name Resources, Physical Disk cannot be simply created through cluster administrative utilities. Specifics of its setup depend to a large extent on the type of shared storage (FC SAN, iSCSI, SCSI) in use and its vendor, although, once hardware gets installed, you would typically use Windows Disk Management MMC snap-in on one of the nodes to assign it a desired drive letter.

  • Print Spooler is dependent on Network Name (which, in turn depends on the IP address associated with it) and Physical Disk resources, and functions as a print server (i.e., hosts network shared printers to which clients can send their print jobs). During its configuration you must specify the location of the spool folder (hence the need for a Physical Disk resource) and print job completion timeout, which is the amount of time the Print Spooler will wait for active print jobs to complete when moving to offline state. Note that these jobs will continue after the resource is brought back online on the same or another node.

    To create individual-shared printers (print queues) once the Print Spooler resource is created and operational, launch Windows Explorer, pointing to the virtual server via its Network Name Resource (i.e. \NetworkName) from any client system; open its Printers and Faxes folder; invoke Add Printer wizard; and simply follow its pages, in the same manner as on a non-clustered computer. Any network ports defined are automatically shared across entire cluster, and printer drivers installed are propagated across remaining nodes when ownership of the group containing Print Spooler resource is transferred to them. This behavior is different from clustered Print Spoolers in earlier versions of Windows, where it was necessary to repeat setup of printer queues on each cluster member.

    By default you are limited to standard TCP/IP port type. If you intend to use LPR port-based printers, you must install "Print Services for Unix" (from "Other Network File and Print Services" group in Add/Remove Windows Components Wizard launched through Add or Remove Programs Control Panel applet) on each cluster node, and ensure that their bi-directional printing option is disabled. Another alternative is printing to a file, which is possible using ClusFilePort (implemented via INF and DLL file combination) available from Windows 2003 Server Resource Kit. Avoid using third-party port monitors, as well as print processors and drivers, since they frequently cause stability and performance issues affecting other clustering resources.

    When creating large number of printers, you might need to increase the threshold at which the quorum log is reset (by adjusting value of "Reset quorum log at" parameter on the Quorum tab of the Cluster Properties dialog box in the Cluster Administrator interface). Otherwise, you might potentially lose some of the changes in case the log gets overwritten before they replicate to individual copies of the Cluster database (implemented as %SystemRoot%ClusterClusDB file) on all of the nodes. The value at which the quorum log gets reset should be larger than the database size.

    If you decide to publish your clustered printers in Active Directory, ensure that the Cluster Service account has Full Control permissions to resulting PrintQueue object. This can be done using Active Directory Users and Computers, with the View menu option "Users, Groups, and Computers as containers" turned on. This requirement stems from the fact that the PrintQueue object is associated with the computer object of its current owner, which must be automatically modified following a failover to a different node.

    Assign unique names to all shared printers across all Print Spoolers on an entire cluster to prevent duplicate names clashes — in case two groups hosting identically named printers failover to the same node. You might simplify your task by leveraging Windows Server 2003 Print Management console (included with its Administration Pack), which enables you to review all clustered and non-clustered printers through a single management interface.

  • DHCP Service operates according to the same principles as its stand-alone counterpart but stores its database audit and backup files on the shared-clustered disk. This implies it has dependencies on the Physical Disk (hosting DHCP database and its backup), Network Name and IP Address, which make it accessible via network. To set it up, install DHCP Service from Networking Services node of Windows Components in the Add or Remove Programs Control Panel applet on every node of the cluster. Once this is completed, use Cluster Administrator (or cluster Command Line utility) to create DHCP Service Resource. During its configuration, specify locations of database, audit, and backup folders on the Physical Disk Resource. Make sure each path ends with the backslash character. To authorize the service in Active Directory, use the DHCP management console, as you would in case of a non-clustered installation.

  • WINS Service, like DHCP Service, depends on Physical Disk (hosting WINS database and its backup), as well as Network Name and IP Address, which make it a networked entity, clustering resources. Just as before, you must install WINS from Networking Services node of Windows Components in Add or Remove Programs Control Panel applet on every node of the cluster. Following the installation, create the WINS Service resource and assign its Database and Backup paths, ending with the backslash character, pointing to an arbitrary location on the Physical Disk.

We will continue our description of the remaining built-in resource types in Windows Server 2003 R2 Enterprise Edition-based Server Cluster in the next article in this series. Note that in addition to the built-in ones, vendors provide their own, application-specific ones, as is the case with Microsoft Exchange Server or SQL Server.

Page 1 of 1


Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.