A cluster is a set of computers that appear to be a single host computer when viewed from outside the cluster. The computers are separate processors, or nodes, which are interconnected and utilized as a single, unified computing resource.
A collection of several server computer nodes into a single, unified cluster makes it possible to share a computing load without users or clients needing to know that more than one server is involved. For example, if any resource in the cluster fails, the cluster, as a whole, may continue to offer service to clients using a resource on one of the other servers in the cluster, regardless of whether the failed component is a hardware or software resource.
Various software products are available for managing a clustered environment that includes at least two nodes. One such product, offered by Microsoft Corporation, is called Microsoft Cluster Server (MSCS). MSCS improves resource availability by allowing applications and resources to “fail-over” from a server that is not functioning correctly to another server in the cluster.
In MSCS, a cluster includes a group of nodes organized so that, if a node fails, another node may take over the failed node's resources. Communication between the nodes of the cluster enables the cluster service to detect node failures. The cluster service keeps track of the current state of the nodes within a cluster (i.e., active node or inactive node) and determines when a node and its resources should fail-over to an alternate node (after a fault of the resource to be failed-over).
In MSCS, a node typically includes a computer system running MS Windows™ NT Server, MS Windows™ 2000 Server, or MS Windows™ Net Server that is organized into a cluster. Each node manages its own groups of resources. Each group of resources runs together on the same node. When a node fails, all the resources in a group may be moved over to another node in the cluster. Such a group is also known as a fail-over group, because all the resources of the group, namely all software and hardware entities used for processing, fail-over to another node. Examples of resources are: Software Service, Software Program, Network Name, IP Address, Disk Drive, Data Base, etc.
One resource that may be included on each node of a cluster is a database management system (DBMS). A DBMS is typically a set of software programs that controls the organization, storage, and retrieval of data included in a database. The DBMS also controls the security and integrity of the database.
It is becoming increasingly desirable that DBMS environments should be available 24 hours a day, 7 days a week. This is true for both on-line and batch operations. As such, on-line transaction processing (OLTP) transactions desirably co-exists with traditional batch transactions, such as queued inserts and range updates/deletes. Therefore, it is desirable that the DBMS be constantly available, regardless of failures or faults related to the DBMS running on the cluster.
MSCS includes a health check facility known as “Looks-Alive.” “Looks-Alive” is a polling facility that executes a regular probe (heartbeat) over the requisite network. The heartbeats are sent from one node in the cluster to its counterpart nodes to detect node failures. Therefore, “Looks-Alive” checks to see if the physical server or node at an opposing side of a cluster is active (i.e., able to respond).
In the event that one node in the MSCS cluster detects a communication failure with another node (via “Looks-Alive”), it broadcasts a message to the entire cluster causing all members to verify their view of the current cluster membership. This is called a regroup event. If the node manager on an individual node does not respond, the node is removed from the cluster and its active resource groups are moved to another active node.
On a two-node cluster, the node manager moves resource groups from a failed node to the surviving node. On a three- or four node cluster, the node manager may move the resource groups from the failed node to a next node. For example, the resource groups from failed node 2 may be moved in their entirety to node 3. The resource groups from failed node 3 may be moved in their entirety to node 4, and so on.
As such, MSCS includes a mechanism for determining if a DBMS on a node in a cluster has failed. Also, MSCS includes a fail-over mechanism for moving the resource groups from a failed node in the cluster to a surviving node in the cluster. In the context of a DBMS, this means that MSCS will restart the DBMS on a surviving node in the cluster in the event of a failure of the DBMS on another node in the cluster.
Unfortunately, the health check facility included in MSCS only provides the type of reactive health check described above by reference to “Looks Alive.” In other words, the DBMS on a given node may have already failed by the time MSCS detects the problem. As such, critical information in the DBMS may be lost. Further, DBMS resources may be unavailable for a certain period of time during detection of the failure and the subsequent re-start.
As such, it would be desirable to have a health check facility included in a DBMS running in a clustered environment, that reduces the potential loss of information and unnecessary unavailability associated with a node or resource failure.