You can configure a variety of different services or applications for high availability in a failover cluster. For a list of the services or applications most commonly configured for high availability, see Configuring a Service or Application for High Availability.

This topic contains the following sections:

Services or applications that can be run as a Generic Application, Generic Script, or Generic Service

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 "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).

Before running the High Availability Wizard to configure high availability for a Generic Application, make sure that you know the path of the application and the names of any registry keys under HKEY_LOCAL _MACHINE that are required by the application.

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.

Before running the High Availability Wizard to configure high availability for a Generic Script, make sure that you know the path of the script.

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

Before running the High Availability Wizard to configure high availability for a Generic Service, make sure that you know the name of the service as it appears in the registry under HKEY_LOCAL _MACHINE\System\CurrentControlSet\Services.

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.

Additional references

  • Configuring a Service or Application for High Availability
  • Understanding Hyper-V and Virtual Machines in the Context of a Cluster