Using the Cluster Database

The cluster database is part of the Microsoft® Windows NT® registry that is resident on each cluster node. It contains information about all physical and logical elements in a cluster.

The following table lists the keys under which cluster data is stored:

Cluster Database Key	Type of Stored Data
Cluster\Parameters\Groups	Information about cluster groups.
Cluster\Parameters\Nodes	Information about cluster nodes.
Cluster\Parameters\Quorum	Information about the quorum resource.
Cluster\Parameters\Resources	Information about cluster resources.
Cluster\Parameters\ResourceTypes	Information about resource types.

The following data shows an excerpt from the information stored in the cluster database for Cluster Server's Physical Disk resource type:

Physical Disk 
    AdminExtensions : REG_MULTI_SZ : {4EC90FB0-D0BB-11CF-B5EF-00A0C90AB505}
    DllName : REG_SZ : clusres.dll
    IsAlivePollInterval : REG_DWORD : 0xea60
    LooksAlivePollInterval : REG_DWORD : 0x1388
    Name : REG_SZ : Physical Disk

Much of the information that is stored in the cluster database is property information. For the Physical Disk resource type, AdminExtensions, DllName, IsAlivePollInterval, LooksAlivePollInterval, and Name are all common properties. The entries are in order by property name, followed by type and value.

Individual resources often store both common and private property information in the cluster database. Whereas common properties apply to all resources regardless of their type, private properties apply only to resources of a specific type. For example, an IP Address resource requires an address, network name, and subnet mask while a Physical Disk resource requires a signature.

Resources and groups store their key name as a GUID. This is the unique identifier for the resource or group. Groups store the following pieces of information in the cluster database:

List of GUID values that identify resources that are members of the group.
Name of the group such as Cluster Group or Disk Group.
Numeric constant that indicates the group's operational status.

Cluster-aware applications should use the cluster database exclusively for saving state and property information; they should not use the system registry. Using the cluster database makes it easier to manage and administer the cluster and allows a resource's configuration for a specific node to be modified even when the node is offline.

However, it is possible for a cluster-unaware application to use the system registry to store important information. In the event that the application is moved, it would be essential to maintain access to this information. The Cluster API includes a feature known as registry checkpointing to insure the availability of information stored on a tree in the system registry. The application establishes a registry checkpoint by calling ClusterResourceControl with the CLUSCTL_RESOURCE_ADD_REGISTRY_CHECKPOINT control code. Whenever anything changes on the checkpointed registry tree and the application is online, the Cluster Service stores a copy of the tree in the quorum resource's log file. If the application moves to another node, the Cluster Service restores the registry tree from the log file to the system registry on the new node.

To access information in the cluster database, applications should use the control code functions in the Cluster API whenever possible. The control code functions are:

ClusterResourceControl to access resource information.
ClusterResourceTypeControl to access resource type information.
ClusterGroupControl to access group information.
ClusterNodeControl to access node information.

These functions provide access to state and property information through a variety of control codes. There is a different set of control codes that are valid for each function. For example, to access a resource's modifiable common properties, call ClusterResourceControl with the control code CLUSCTL_RESOURCE_GET_COMMON_PROPERTIES. For a comprehensive list of the operations available with the control code functions, see one of the following topics:

For resources, see Control Codes for Resources.

For resource types, see Control Codes for Resource Types.

For groups, see Control Codes for Groups.

For nodes, see Control Codes for Nodes.

When an application requires information that is not exposed through a control code, usually one of the cluster database management functions included in the Cluster API can be called to retrieve the information. The database management functions are similar to the Microsoft Win32® registry functions, but there is one important difference. With the database management functions, changes made on one node are atomically distributed as they occur to all affected nodes in the cluster. Therefore, all members of a cluster have consistent access to the information. Because the Win32 registry functions lack this important replication feature, applications should never use them to access the cluster database.