Appendix E: Using Generic Services and Applications in a Failover Cluster
Applies To: Windows Server 2008
In failover clustering, configuring a service or application for high availability usually involves running the High Availability Wizard and selecting the appropriate option, such as a file server, print server, or DHCP server. However, some services or applications that are not in the list can be supported by selecting one of the three generic options in the High Availability Wizard: Generic Application, Generic Script, or Generic Service. This means that you can configure high availability for some services and applications that are not "cluster-aware" (not originally designed to run in a cluster). This topic provides information about the following:
Applications and services listed in the High Availability Wizard
How a Generic Application, Generic Script, or Generic Service works in a failover cluster
Basic requirements for a service or application in a failover cluster environment
For additional information about planning for a failover cluster, see the Failover Cluster Design Guide. For information about deploying a failover cluster, see the Failover Cluster Deployment Guide (https://go.microsoft.com/fwlink/?LinkId=129457).
Applications and services listed in the High Availability Wizard
The following specific services and applications are listed in the High Availability Wizard. If you want to configure high availability for one of these services and applications, do not select Generic Service, Generic Application, or Generic Script in the wizard. Instead, select the service or application that you need:
DFS Namespace Server
DHCP Server
Distributed Transaction Coordinator (DTC)
File Server
Internet Storage Name Service (iSNS) Server
Message Queuing
Print Server
Virtual Machine
WINS Server
In addition, the wizard offers the "Other Server" option, which configures a client access point and storage only, so that you can add an application later. Use this option if you are familiar with configuring a particular application this way, or if the documentation for clustering your application tells you to use it.
How a Generic Application, Generic Script, or Generic Service works in a failover cluster
In failover clusters, you can use the Generic Application, Generic Script, and Generic Service options to configure high availability for some services and applications that are not specifically listed in the High Availability Wizard. These services or applications may not be "cluster-aware" (not originally designed to run in a cluster).
Generic Application
If you run an application as a Generic Application, the cluster software will start the application, then periodically query the operating system to see whether the application appears to be running. If so, it is presumed to be online, and will not be restarted or failed over.
Note that in comparison with a cluster-aware application, a Generic Application has fewer ways of communicating its precise state to the cluster software. If a Generic Application enters a problematic state but nonetheless appears to be running, the cluster software does not have a way of discovering this and taking an action (such as restarting the application or failing it over).
When creating a failover cluster design that uses a Generic Application, make note of the path of the application and the names of any registry keys under HKEY_LOCAL _MACHINE that are required by the application. You will need this information when you run the High Availability Wizard.
Generic Script
You can create a script that runs in Windows Script Host and that monitors and controls your application. Then you can configure the script as a Generic Script in the cluster. The script provides the cluster software with information about the current state of the application. As needed, the cluster software will restart or fail over the script (and through it, the application will be restarted or failed over).
When you configure a Generic Script in a failover cluster, the ability of the cluster software to respond with precision to the state of the application is determined by the script. The more precise the script is in providing information about the state of the application, the more precise the cluster software can be in responding to that information.
When creating a failover cluster design that uses a Generic Script, make note of the path of the script. You will need this information when you run the High Availability Wizard.
Generic Service
The cluster software will start the service, then periodically query the Service Controller (a feature of the operating system) to determine whether the service appears to be running. If so, it is presumed to be online, and will not be restarted or failed over.
Note that in comparison with a cluster-aware service, a Generic Service has fewer ways of communicating its precise state to the cluster software. If a Generic Service enters a problematic state but nonetheless appears to be running, the cluster software does not have a way of discovering this and taking an action (such as restarting the service or failing it over).
When creating a failover cluster design that uses a Generic Service, make note of the name of the service as it appears in the registry under HKEY_LOCAL _MACHINE\System\CurrentControlSet\Services. You will need this information when you run the High Availability Wizard.
Basic requirements for a service or application in a failover cluster environment
To be appropriate for a failover cluster, a service or application must have certain characteristics. The most important characteristics include:
The service or application should be stateful. In other words, the service or application should have long-running in-memory state or large, frequently updated data states. One example is a database application. For a stateless application (such as a Web server front end), Network Load Balancing will probably be more appropriate than failover clustering.
The service or application should use a client component that automatically retries after temporary network interruptions. Otherwise, if the server component of the application fails over from one clustered server to another, the unavoidable (but brief) interruption will cause the clients to stop, rather than simply retrying and reconnecting.
The service or application should be able to identify the disk or disks it uses. This makes it possible for the service or application to communicate with disks in the cluster storage, and to reliably find the correct disk even after a failover.
The service or application should use IP-based protocols. Examples include TCP, UDP, DCOM, named pipes, and RPC over TCP/IP.