Standard Order of Preference
The Failover Cluster API may offer more than one way of performing a cluster operation. For example, the PendingTimeout property for a resource can be set through the following API elements.
ClusterResourceControl with the CLUSCTL_RESOURCE_SET_COMMON_PROPERTIES control code.
ResUtilSetPropertyParameterBlock
If the Failover Cluster API offers more than one way of performing an operation on a cluster object, the following orders of preference is recommended.
For cluster-aware applications
- Use a control code function whenever possible. This maximizes the reliability and security of the operation, and ensures that resource DLLs receive proper notification.
- Use a cluster object management function if a control code operation is not possible.
- Use a utility function.
- Use a cluster database access functions as a last resort.
In general, try not to perform direct updates to the cluster database unless absolutely necessary.
A change to the cluster database typically has an impact on many different cluster elements. Using indirect API elements allows the Cluster service to ensure that the necessary notifications take place, and that the data is replicated to all nodes.
For resource DLLs
- Use a cluster utility function or a cluster database access function (a "ResUtil" function). A resource DLL is expected to access the cluster database, unlike a cluster-aware application.
- Use a control code function (but see Cautions).
- Use a cluster object management function.
In general, try not to use the Cluster API unless absolutely necessary.
The Failover Cluster API is not always available to resource DLLs because it depends on the Cluster service. The Resource API, however, is always available to resource DLLs.