The following list contains the many terms associated with Windows
Server 2008 R2 clustering technologies:
Cluster—A cluster is a group of independent servers (nodes) that are accessed and
presented to the network as a single system.
Node—A node is an individual server that is a member of a cluster.
Cluster resource—A cluster resource is a service, application, IP address, disk, or
network name defined and managed by the cluster Within a cluster, cluster
resources are grouped and managed together using cluster resource groups, now
known as Services and Applications groups.
Services and Applications group—Cluster resources are contained within a cluster
in a logical set called a Services and Applications group or historically referred to as a
cluster group. Services and Applications groups are the units of failover within the
cluster. When a cluster resource fails and cannot be restarted automatically, the
Services and Applications group this resource is a part of will be taken offline, moved
to another node in the cluster, and the group will be brought back online.
Client Access Point—A Client Access Point is a term used in Windows Server 2008
R2 failover clusters that represents the combination of a network name and associated
IP address resource. By default, when a new Services and Applications group is
defined, a Client Access Point is created with a name and an IPv4 address. IPv6 is
supported in failover clusters but an IPv6 resource either needs to be added to an
existing group or a generic Services and Applications group needs to be created with
the necessary resources and resource dependencies.
Virtual cluster server—A virtual cluster server is a Services or Applications group
that contains a Client Access Point, a disk resource, and at least one additional
service or application-specific resource. Virtual cluster server resources are accessed
either by the domain name system (DNS) name or a NetBIOS name that references
an IPv4 or IPv6 address. A virtual cluster server can in some cases also be directly
accessed using the IPv4 or IPv6 address. The name and IP address remain the same
regardless of which cluster node the virtual server is running on.
Active node—An active node is a node in the cluster that is currently running at
least one Services and Applications group. A Services and Applications group can
only be active on one node at a time and all other nodes that can host the group are
considered passive for that particular group.
Passive node—A passive node is a node in the cluster that is currently not running
any Services and Applications groups.
Active/passive cluster—An active/passive cluster is a cluster that has at least one
node running a Services and Applications group and additional nodes the group can
be hosted on, but are currently in a waiting state. This is a typical configuration
when only a single Services and Applications group is deployed on a failover cluster.
Active/active cluster—An active/active cluster is a cluster in which each node is
actively hosting or running at least one Services and Applications group. This is a
typical configuration when multiple groups are deployed on a single failover cluster
to maximize server or system usage. The downside is that when an active system
fails, the remaining system or systems need to host all of the groups and provide the
services and/or applications on the cluster to all necessary clients.
Cluster heartbeat—The cluster heartbeat is a term used to represent the communication
that is kept between individual cluster nodes that is used to determine node
status. Heartbeat communication can occur on a designated network but is also
performed on the same network as client communication. Due to this internode
communication, network monitoring software and network administrators should
be forewarned of the amount of network chatter between the cluster nodes. The
amount of traffic that is generated by heartbeat communication is not large based
on the size of the data but the frequency of the communication might ring some
network alarm bells.
Cluster quorum—The cluster quorum maintains the definitive cluster configuration
data and the current state of each node, each Services and Applications group,
and each resource and network in the cluster. Furthermore, when each node reads
the quorum data, depending on the information retrieved, the node determines if it
should remain available, shut down the cluster, or activate any particular Services
and Applications groups on the local node. To extend this even further, failover clusters
can be configured to use one of four different cluster quorum models and essentially
the quorum type chosen for a cluster defines the cluster. For example, a cluster
that utilizes the Node and Disk Majority Quorum can be called a Node and Disk
Majority cluster.
Cluster witness disk or file share—The cluster witness or the witness file share are
used to store the cluster configuration information and to help determine the state
of the cluster when some, if not all, of the cluster nodes cannot be contacted.
Generic cluster resources—Generic cluster resources were created to define and
add new or undefined services, applications, or scripts that are not already included
as available cluster resources. Adding a custom resource provides the ability for that
resource to be failed over between cluster nodes when another resource in the same
Services and Applications group fails. Also, when the group the custom resource is a
member of moves to a different node, the custom resource will follow. One disadvantage
or lack of functionality with custom resources is that the Failover Clustering
feature cannot actively monitor the resource and, therefore, cannot provide the
same level of resilience and recoverability as with predefined cluster resources.
Generic cluster resources include the generic application, generic script, and generic
service resource.
Shared storage—Shared storage is a term used to represent the disks and volumes
presented to the Windows Server 2008 R2 cluster nodes as LUNs. In particular,
shared storage can be accessed by each node on the cluster, but not simultaneously.
Cluster Shared Volumes—A Cluster Shared Volume is a disk or LUN defined
within the cluster that can be accessed by multiple nodes in the cluster simultaneously.
This is unlike any other cluster volume, which normally can only be accessed
by one node at a time, and currently the Cluster Shared Volume feature is only used
on Hyper-V clusters but its usage will be extended in the near future to any failover
cluster that will support live migration.
LUN—LUN stands for Logical Unit Number. A LUN is used to identify a disk or a
disk volume that is presented to a host server or multiple hosts by a shared storage
array or a SAN. LUNs provided by shared storage arrays and SANs must meet many
requirements before they can be used with failover clusters but when they do, all
active nodes in the cluster must have exclusive access to these LUNs.
Failover—Failover is the process of a Services and Applications group moving from
the current active node to another available node in the cluster when a cluster
resource fails. Failover occurs when a server becomes unavailable or when a resource
in the cluster group fails and cannot recover within the failure threshold.
Failback—Failback is the process of a cluster group automatically moving back to a
preferred node after the preferred node resumes operation. Failback is a nondefault
configuration that can be enabled within the properties of a Services and
Applications group. The cluster group must have a preferred node defined and a failback
threshold defined as well, for failback to function. A preferred node is the node
you would like your cluster group to be running or hosted on during regular cluster
operation when all cluster nodes are available. When a group is failing back, the
cluster is performing the same failover operation but is triggered by the preferred
node rejoining or resuming cluster operation instead of by a resource failure on the
currently active node.
Live Migration—Live Migration is a new feature of Hyper-V that is enabled when
Virtual Machines are deployed on a Windows Server 2008 R2 failover cluster. Live
Migration enables Hyper-V virtual machines on the failover cluster to be moved
between cluster nodes without disrupting communication or access to the virtual
machine. Live Migration utilizes a Cluster Shared Volume that is accessed by all
nodes in the group simultaneously and it transfers the memory between the nodes
during active client communication to maintain availability. Live Migration is
currently only used with Hyper-V failover clusters but will most likely extend to
many other Microsoft services and applications in the near future.
Quick Migration—With Hyper-V virtual machines on failover clusters, Quick
Migration provides the option for failover cluster administrators to move the virtual
machine to another node without shutting the virtual machine off. This utilizes the
virtual machine’s shutdown settings options and if set to Save, the default setting,
performing a Quick Migration will save the current memory state, move the virtual
machine to the desired node, and resume operation shortly. End users should only
encounter a short disruption in service and should reconnect without issue depending
on the service or application hosted within that virtual machine. Quick
Migration does not require Cluster Shared Volumes to function.
Geographically dispersed clusters—These are clusters that span physical locations
and sometimes networks to provide failover functionality in remote buildings and
data centers, usually across a WAN link. These clusters can now span different
networks and can provide failover functionality, but network response and throughput
must be good and data replication is not handled by the cluster.
Multisite cluster—Geographically dispersed clusters are commonly referred to as
multisite clusters as cluster nodes are deployed in different Active Directory sites.
Multisite clusters can provide access to resources across a WAN and can support
automatic failover of Services and Applications groups defined within the cluster.
Stretch clusters—A stretch cluster is a common term that, in some cases, refers to
geographically dispersed clusters in which different subnets are used but each of the
subnets is part of the same Active Directory site—hence, the term stretch, as in
stretching the AD site across the WAN. In other cases, this term is used to describe
a geographically dispersed cluster, as in the cluster stretches between geographic
locations.
