Win 2003 High Availability Solutions, Virtual Servers and More

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 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