Resource Dependencies; Groups; Quorums - HP Rx2620-2 - Integrity - 0 MB RAM Installation And Configuration Manual

If the resource cannot be brought online or taken offline after a specified amount of time, and
the resource is set to the failed state, you can specify the amount of time that cluster service waits
before failing the resource by setting its pending timeout value in Cluster Administrator.
Resource state changes can occur either manually (when you use Cluster Administrator to make
a state transition) or automatically (during the failover process). When a group fails over, the
states of each resource are altered according to their dependencies on the other resources in the
group.

Resource Dependencies

A dependency is a reliance between two resources that makes it necessary for both resources to
run on the same node (for example, a Network Name resource depending on an IP address).
The only dependency relationships that cluster service recognizes are relationships between
resources. Cluster service cannot be told, for example, that a resource depends on a Windows
2003 service; the resource can only be dependent on a resource representing that service.

Groups

Groups are a collection of resources to be managed as a single unit for configuration and recovery
purposes. Operations performed on a group, such as taking it offline or moving it to another
node, affect all resources contained within that group. Usually a group contains all the elements
needed to run a specific application, and for client systems to connect to the service provided by
the application.
If a resource depends on another resource, both resources must be a member of the same group.
For example, in a file share resource, the group containing the file share must also contain the
disk resource and network resources (such as the IP address and NetBIOS name) to which clients
connect to access the share. All resources within a group must be online on the same node in the
cluster.
NOTE: During failover, entire groups are moved from one node to another node in the cluster.
A single resource cannot fail from one node to another.

Quorums

Each cluster has a special resource called the quorum. The quorum provides a means for
arbitration leading to node membership and cluster state decisions. Only one node at a time can
own the quorum. That node is designated as the primary node. When a primary node fails over
to a backup node, the backup node takes ownership of the quorum.
The quorum resource also provides physical storage to maintain the configuration information
for the cluster. This information is kept in the quorum log, which is a configuration database for
the cluster. The log holds cluster configuration information, such as which servers are part of
the cluster, what resources are installed in the cluster, and what state those resources are in. By
default the quorum log is located at \MSCS\quolog.log.
NOTE:
Quorums are only used in the server cluster, not in NLB. References to quorums
throughout the remainder of this document apply to server clusters only.
The quorum resource is important in a cluster for the following reasons:
Consistency Because a cluster is multiple physical servers acting as a single virtual server,
it is critical that each physical server have a consistent view of how the cluster
is configured. The quorum acts as the definitive repository for all configuration
information relating to the cluster. In the event that the cluster service is unable
to read the quorum log, it cannot start because it is unable to guarantee that
the cluster is in a consistent state.
Cluster Terminology 15