After you create the cluster, you can specify the resources that you want to be highly available and configure the policies that you want to follow to administer those resources. You can, for example, specify how resources fail over and fail back as well as which nodes are the primary owners of resources.
Once you create a cluster, you can specify the resources that you want to be highly available. Each primary resource, such as a file share or print spooler, has a group of resources that it depends on. These resources should all be placed in the same group to allow seamless failover from one node in the cluster to another. Although you could place the resources in the main Cluster group, it is usually better to group resources together by dependencies as discussed previously.
The Cluster service defines specific resource types that can be configured for high availability and added to resource groups. The available resource types include the following:
Physical Disk The Physical Disk resource type is used to manage disks that are on a shared cluster storage device. You can assign drive letters to disks that are on a cluster storage device or use mount points. If you assign drive letters, the disks must have the same drive letters on all cluster nodes. Physical Disk resources are created automatically for cluster disks when you use drive letters and must be manually created when you use mount points.
DHCP DHCP provides dynamic IP addressing in the domain. When you can run it as a resource of the cluster, you provide for high availability. For DHCP to fail over successfully, the DHCP database must be on the shared cluster storage. Be sure to use the full directory path and end the path with a backslash (), such as g:dchpdata.
WINS WINS provides resolution of NetBIOS names to IP addresses. When you can run it as a resource of the cluster, you provide for high availability. For WINS to fail over successfully, the WINS database must be on the shared cluster storage. Be sure to use the full directory path and end the path with a backslash (), such as g:winsdata.
File Share For file servers, the File Share resource type provides for high availability of the shared folders. You can manage file shares in several ways. As a normal file share, only the top-level folder is visible as the share name. This is the most basic type of file share. As shared subfolders, the top-level folder and each of its immediate subfolders are shared with separate names. This allows you to create a large number of related file shares easily, such as those for user's home directories. As a stand-alone DFS root, you can share DFS roots that aren't configured to be fault tolerant. This is ideal when the DFS data changes frequently and you don't want to have to replicate changes to DFS replicas frequently.
Print Spooler For print servers, the Print Spooler resource type provides for high availability of network-attached print devices. Printers connected directly to print servers cannot be included because there is no way to fail over control to a different server. If a print server fails, all jobs that are currently spooling are restarted. Jobs that are in the process of spooling are discarded and must be respooled or reprinted to the Print Spooler resource. Although multiple Print Spooler resources can be configured in a cluster, each resource group can have only one Print Spooler.
Internet Protocol Address The Internet Protocol Address resource type is used to manage the IP addresses of the cluster. When an IP Address resource is included with a resource group with a Network Name resource, the resource group can be accessed by network clients as a virtual server. Virtual servers allow clients to continue to use the same name to access the cluster even after a failover has occurred. Failover happens seamlessly for clients and no change is required on the clients.
Network Name The Network Name resource type is used to provide an alternate computer name. When included in a resource group with an IP Address resource, the resource group can be accessed by network clients as a virtual server.
Local Quorum The Local Quorum resource type is used to manage the system disk on the local node of a single-node cluster. This resource type cannot fail over to another node because there are no other nodes available. If you create a Local Quorum resource on one node of a multinode cluster, you migrate the node so that it uses the Local Quorum as its quorum resource. That node then acts as a one-node cluster and is isolated from the other nodes, which is useful for troubleshooting in some cases.
Majority Node Set The Majority Node Set resource type allows the quorum data, which includes cluster configuration changes and state information, to be stored on the system disk of each node in the cluster. It is used to ensure the data remains consistent across nodes that might be geographically dispersed. Only one Majority Node Set can exist in a server cluster.
Generic Application The Generic Application resource type is used to manage cluster-unaware applications that can be failed over. Generic applications must use an IP-based protocol for their network communications and must be able to store their data in a configurable location.
Generic Script The Generic Script resource type is used to manage Windows scripts as cluster resources. Only the most basic clustering functionality is provided. If the script is running, it is assumed that it is online.
Generic Service The Generic Script resource type is used to manage Windows services as cluster resources. Only the most basic clustering functionality is provided. If the service is running, it is assumed that it is online.
Volume Shadow Copy Service Task The Volume Shadow Copy Service Task resource type allows you to create jobs in the Scheduled Tasks folder that must be run on the node that is currently hosting a particular resource group. This allows you to define scheduled tasks that can fail over from one cluster node to another. The functionality is limited because it is primarily designed to support shadow copies of shared folders in server clusters.
When planning resource groups, you should list all server-based applications and services that will run in the cluster environment, regardless of whether they will need high availability. Be sure to look at applications and services running on front-end servers, application logic servers, and back-end servers. Afterward, divide the list into three sections: Support, HA, and Non-HA. The Support section should include all applications and services that run on severs that aren't part of the cluster and on which clustered resources do not depend. The HA section should include all applications and services running on the cluster servers that need high availability. This section should also include the resources these applications and services are dependent on. The Non-HA section should include all applications and services running on the cluster servers that do not need or do not support failover. Put an asterisk next to any items that need further research or discussion as a reminder that the deployment team should reexamine the items later.
Support applications and services often interact with clustered applications and services, and these interactions should be clearly understood and tracked. Failure of a support application or service shouldn't impact the core functions of the business system. If it does, the support application or service might need to be clustered or load balanced.
Applications and services in the HA section represent resources that should be placed into resource groups. Resources should be grouped together according to their dependencies. Resources cannot span groups. For example, if several applications depend on a particular resource, the applications and the resource must be placed into a single resource group.
Applications and services in the Non-HA section represent resources that might not need to be placed into resource groups. Before making the final determination, administrators should ensure that failure of a support application or service doesn't impact other applications or services. If it does, the application or service represents a dependency for another application or service—and all dependent resources must be together in a single resource group. Failure of a support application or service shouldn't impact the core functions of the business system. If it does, the application or service might need to be clustered or load balanced. In the case of dependent services that don't support clustering, you might want to provide backup planning in case these services fail or might want to attempt to make the services cluster-aware by using Windows scripts.
Each application and service that you've identified as HA, such as a file share or print spooler, has a group of resources that it depends on. These resources should all be placed in the same resource group to allow seamless failover from one node in the cluster to another. Although you could place the resources in the main Cluster group, it is usually better to group resources together by dependencies.
To get a better understanding of dependencies, you should draw a dependency tree for each resource group. This will help you understand not only which resources that an application or service is dependent upon, but also how those dependencies are interrelated. For example, a high-availability print server is dependent on a Print Spooler resource, which in turn is dependent on a Physical Disk resource and a Network Name resource. The Network Name resource is in turn dependent on the IP Address resource, and ultimately the dependency tree is similar to that shown in Figure 18-17.
By using the Cluster service you can control operations on a per-node basis. To stop the Cluster service on a node, select the node in Cluster Administrator, and then click File and then Stop Cluster Service. When you stop the Cluster service, you prevent clients from accessing resources on that node. If the node's failover policies are configured to move resources to another node, all resource groups on the node are moved to another node. If no failover policies are configured, however, clients cannot access the node's resources. To start the Cluster service again, select the node in Cluster Administrator, and then click File and then Start Cluster Service.
The key reason for stopping and starting nodes is to repair a node. Here, you stop the Cluster service, make the necessary repairs, and then when you are finished you bring the node back online by starting the Cluster service. If the server must be rebooted to complete the repairs, you should follow these steps after making repairs and before rebooting:
Set the Cluster service to start manually before you shut down. To do this, start Services from the Administrative Tools menu. In the details pane, right-click Cluster Service, and then choose Properties. In the General tab of the Properties dialog box, set the Startup Type to Manual, and then click OK.
Restart the server. When it comes back online, access the node in Cluster Administrator, and then choose File and then Start Cluster Service.
Start services from the Administrative Tools menu. In the details pane, right-click Cluster Service, and then choose Properties. In the General tab of the Properties dialog box, set the Startup Type to Automatic, and then click OK.
Troubleshooting: Resolve problems with the quorum resource
You can start the Cluster service from the command line as well. This is useful if there are problems with the quorum resource and you want to try to repair them. In this case, stop the Cluster service by selecting File, Stop Cluster Service. Then, at the command line, type clussvc /debug /fixquorum. (Only one node can be started at a time using this approach.) The server will start the Cluster service but won't bring any resources online. You can then try to bring the quorum resource online manually and troubleshoot, or you could switch to another quorum resource. For Majority Node Set server cluster when one of the nodes loses communication with the nodes in another location, you can try to restore the quorum using the force quorum technique, which involves stopping the Cluster service on all remaining nodes, making a change to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesClusSvcParameters subkey in the Registry for the current node and then starting the Cluster service on the remaining nodes. When you access this subkey, you'll want to create a String value called ForceQuorum and set the value of this string to a comma-separated list of the names of the nodes that are to be part of the quorum set.
You also have the option of using Pause and Resume. To pause a node, select the node in Cluster Administrator, and then click File, Pause Node. When you pause a node, existing groups and resources stay online, but additional groups and resources cannot be brought online. You can later allow new groups and resources to be brought online by selecting File, Resume Node.
The resources in a group fail over and fail back together according to the failover and failback policies set on the group as a whole. Basically, the failover policy for a group sets a threshold for the maximum number of times that the group is allowed to fail over in a specified period before it is left in a failed state. If a group fails over more often than the failover policy allows, the Cluster service leaves it offline. For example, if a group failover threshold is set to 4 and its failover period to 2, the Cluster service will fail over the group at most four times within a 2-hour period.
You can set group failover policy in Cluster Administrator by clicking the Groups folder in the left pane, selecting the group you want to work with in the right pane, and then clicking File, Properties. In the Failover tab, set the Threshold and Period options as appropriate for the type of resources in the group.
For a failback policy, you specify whether and how the resource group is returned to its preferred owner. You set group failback policy in Cluster Administrator by clicking the Groups folder in the left pane, selecting the group you want to work with in the right pane, and then clicking File, Properties. In the Failback tab, select either Prevent Failback or Allow Failback. If you click Allow Failback, select Immediately to allow immediate failback, or click Failback Between and set the time interval during which it is permissible to fail back the group. Enter numbers between 0 and 23 to specify the beginning and end of the interval. These numbers correspond to the local time of the cluster group with regard to a 24-hour clock.
When you create a resource group in Cluster Administrator, you assign the group a name, description, and preferred owner. The group name and description are for administrative purposes only. They have no relation to the virtual server name that clients use to connect to the group. All resources within a group fail over together. If you want a group to fail back to a certain node, assign that node as the preferred owner, and set the failback policy as discussed in the previous section. If it doesn't matter to which node the resource fails back, don't assign a preferred owner.
Tip
Balance the load
One of your goals in defining groups and assigning them to nodes should be to balance the load among all nodes and maximize the performance of the cluster. If a group has very little impact on performance, you might not want to assign it a preferred owner. That way, if the group fails, it can fail over to a new node but won't fail back to the previous node.
You can create a new group in Cluster Administrator by clicking File, New, Group. This starts the New Group Wizard. Enter a name and description for the group, then click Next. If you want to assign a preferred owner, select the nodes you want to be the preferred owners for the group, and then click Add. The owner listed first has priority, meaning it will be the first node attempted for failback. You can change the priority of an owner by selecting the owner and clicking Move Up or Move Down. When you are finished, click Finish.
After you create a group, you can assign resources to the group as discussed in the section entitled "Creating and Managing Resource Groups" earlier in this chapter. Once resources are assigned, you can manage the group in several ways:
Bring a group online You can bring a group online so that the resources are available to clients. Double-click the Groups folder, select the group you want to bring online, and then click File, Bring Online. Resources in a group come online in the order of their dependencies.
Take a group offline You can bring a group offline so that the resources are no longer available to clients. Double-click the Groups folder, select the group you want to bring offline, and then click File, Bring Offline. Resources in a group go offline in the order of their dependencies.
Move a group to another node You can move a group to another node to help balance resource usage or in case you need to bring a server offline. Double-click the Groups folder, select the group you want to move, and then click File, Move Group. In clusters with three or more nodes, choose Best Possible or select the specific node to which you want to move the group. Once the group is moved, the new node owns all resources in the group and the Owner option in the details pane should reflect this.
Delete a group You can delete a group that you no longer want to use. Double-click the Groups folder, and select the group you want to delete. Delete or move all resources in the group, then click File, Delete.
When you create a resource in Cluster Administrator, you specify the group to which the resource will belong first and then set the resource's properties. Double-click the Groups folder, select the group to which you want the resource to belong, and then click File, New, Resource. When the New Resource Wizard starts, enter a name and description for the resource, select the appropriate resource type using the Resource Type list, and then click Next. If you want to assign possible owners, select the nodes that can host this resource. Click Next so that you can configure the dependencies for the resource.
If this is the first resource you are defining for the group, there will be no other resources to assign as dependencies. For other resources, you might have dependencies to assign. To add dependencies, click a resource, then click Add. To remove dependencies, click a resource, then click Remove. You can also assign dependencies later.
When you click Next again, the page you see depends on the type of resource you are creating, as follows:
For Physical Disk, you'll see the Disk Parameters page that will let you choose the physical disk drive for the resource.
For IP Address, you'll see the TCP/IP Parameters page that lets you specify the IP address, subnet mask, and network adapter to associate with the resource. You can also enable NetBIOS name resolution.
For Network Name, you'll see the Network Name Parameters page that lets you specify the name for the virtual server.
After you configure the necessary parameters, click Finish to create the resource and assign it to the designated group. When you are done creating resources for a group, you can bring the group online by selecting it, then clicking File, Bring Online.
Once you create resources, you can manage them in several ways:
Bring a resource and its dependent resources online Double-click the Resources folder, select the primary resource, and then click File, Bring Online.
Take a resource and its dependent resources offline Double-click the Resources folder, select the primary resource, and then click File, Take Offline.
Move a resource and all its dependent resources to a new group Double-click the Resources folder, select the primary resource, click File, Change Group, and then click the name of the group to which you want to transfer ownership. You can also select the resource you want to move, then drag and drop it in another group.
Initiate a resource failure to trigger a restart or failover Double-click the Groups folder, select the group that contains the resource in the left pane, and then in the right pane select the resource on which you want to initiate failure. Click File, Initiate Failure. When a resource fails, it automatically restarts according to its restart policy (if any). If a resource fails repeatedly, the entire group to which the resource belongs can fail over, depending on the failover policy defined (if any).
For clustered print services, you should create a resource group to hold the printer's dependent resources. You would then complete the following steps:
Create a Physical Disk resource for the drive on which the print spool folder is located.
Create an IP Address resource, which is used in conjunction with the Network Name resource so the print service can be accessed by network clients as a virtual server.
Create a Network Name resource and add IP Address as a dependency.
Create a Print Spooler resource and add as dependencies the Physical Disk, IP Address, and Network Name resources.
Afterward, you add these resources to the resource group you previously defined. You then bring the virtual server containing the print spooler resource online by selecting it and then choosing File, Bring Online. Afterward, you prepare the printer for high availability use by completing the following:
Installing a print port monitor on all nodes in the cluster
Installing print drivers on the virtual server
Installing a printer port for the printer on the virtual server
Adding a print queue on the virtual server
Cluster-managed file shares work in much the same way. You start by creating a folder on the cluster disk to which the Cluster service account has Full Control rights. Create a resource group to hold the file share's dependent resources, and then complete the following steps:
Create a Physical Disk resource for the drive on which the shared folders are located.
Create an IP Address resource, which is used in conjunction with the Network Name resource so the shared folders can be accessed by network clients as a virtual server.
Create a Network Name resource and add IP Address as a dependency.
Create a File Share resource and add as dependencies the Physical Disk, IP Address, and Network Name resources.
After you add these resources to the resource group you previously defined, you select the File Share resource that you created and edit its properties by clicking File, Properties. In the Parameters tab, use the Path field to set the path to the folder whose subfolders you want to share. Then click Permissions to configure the File Share permissions according to the users and groups who should have access to the file share. The File Share permissions are different from the NTFS permissions assigned locally on the computer. When you are finished assigning permissions, you can bring the File Share resource online by selecting it and then choosing File, Bring Online.