The Cluster Server architecture is made up of the following software components:
The Cluster Service is the 'brains' of a cluster. There is one instance of Cluster Service running on every node in a cluster. The Cluster Service manages resources and coordinates with other instances of the Cluster Service in the cluster. The Cluster API is used by applications and resources to interact with the Cluster Service. The Cluster API allows applications and resources to manage cluster components and to access the cluster database.
The Cluster Network Driver provides highly available communication between cluster nodes and helps to maintain cluster membership. The Cluster Network Driver maintains configuration information provided by the Cluster Service and communicates with the other nodes in the cluster. When a communication failure is detected, the Cluster Network Driver notifies the Cluster Service.
Resource Monitors act as an interface between the Cluster Service and cluster resources. Each resource is exposed by a dynamic link library (DLL) that is loaded into the Resource Monitor process. Resource Monitors isolate the Cluster Service from failures in a resource DLL. Multiple Resource Monitors can be used to isolate resources from one another.
Resource DLLs are used to manage cluster resources of a particular type. Each resource DLL is written to manage one or more resource types. When the Cluster Service issues a request to a resource, that request is passed to the Resource Monitor. The Resource Monitor in turn calls an entry point function in the resource DLL responsible for the resource. The entry point functions are part of the Resource API. When a resource DLL is loaded, it passes a table to the Resource Monitor containing pointers to each of these functions.
Cluster Server provides resource DLLs for the resource types that it supports, such as the IP Address and Physical Disk resources. However, a cluster is not limited to these resource types. Third-party developers can create their own resource DLLs to replace or augment Cluster Server's resource DLLs. For a conceptual overview of resources, see About Cluster Resources.
Every node in a cluster can own one or more groups consisting of dependent or related resources. Administrators use a graphical application known as Cluster Administrator to establish and configure these resource groups and other cluster objects and to initiate failover, handle maintenance, and monitor cluster activity. Any Microsoft® Windows NT® system, regardless of whether it is a cluster node, can install Cluster Administrator.
Cluster Administrator allows administrators to view, add, and change resources belonging to any of the resource types defined by Cluster Server. Third-party developers providing their own resource types can write an extension that enables Cluster Administrator to manage their custom types.
The following diagram shows how these Cluster Server components relate to applications of various types and to each other within a single Windows NT Server network operating system.
The diagram shows three types of applications:
Cluster management applications are used to administer clusters, to perform such tasks as adding resources, changing the membership of groups, and moving a group from one node to another. One example of a cluster management application is Cluster Administrator; another is a command line tool also provided with Cluster Server called CLUSTER.EXE. Administrators can use these applications to configure their cluster and establish resource dependencies and failover policies, but not to add a node to a cluster. A node can only be added to a new or existing cluster when the node installs Cluster Server. Cluster management applications use the Cluster API to communicate with the Cluster Service.
Both cluster-aware and cluster-unaware applications run on a cluster node and can be managed as cluster resources. However, only cluster-aware applications can take advantage of features offered by Cluster Server through the Cluster API. For example, cluster-aware applications can:
A cluster-aware application is typically managed by the Cluster Service as a custom resource type, a resource type created by a third-party developer responsible for the application. To create a custom resource type, a developer provides two DLLs: a resource DLL and a Cluster Administrator extension DLL. The Cluster Administrator extension DLL implements methods included in the Cluster Administrator extension API.
A cluster-unaware application is typically managed as a Generic Application resource, one of the resource types defined by Cluster Server. Generic Application resources can be administered with Cluster Administrator and can be failed over to an alternate node when a failure occurs. Cluster-unaware applications do not communicate directly with the Cluster Service through the Cluster API.