6.5.1

Failover cluster nodes use the network to send heartbeat packets to other nodes of the cluster. If a node does
not receive a response from another node for a specied period of time, the cluster removes the node from
cluster membership. By default, a guest cluster node is considered down if it does not respond within 5
seconds. Other nodes that are members of the cluster will take over any clustered roles that were running on
the removed node.
An MSCS virtual machine can stall for a few seconds during vMotion. If the stall time exceeds the heartbeat
time-out interval, then the guest cluster considers the node down and this can lead to unnecessary failover.
To allow leeway and make the guest cluster more tolerant, the heartbeat time-out interval needs to be
modied to allow 10 missed heartbeats. The property that controls the number of allowed heart misses is
SameSubnetThreshold. You will need to modify this from its default value to 10. From any one of the
participating MSCS cluster nodes run the following command:
cluster <cluster-name> /prop SameSubnetThreshold=10:DWORD.
You can also adjust other properties to control the workload tolerance for failover. Adjusting delay controls
how often heartbeats are sent between the clustered node. The default seing is 1 second and the maximum
seing is 2 seconds. Set the SameSubnetDelay value to 1. Threshold controls how many consecutive
heartbeats can be missed before the node considers its partner to be unavailable and triggers the failover
process. The default threshold is 5 heartbeats and the maximum is 120 heartbeats. It is the combination of
delay and threshold that determines the total elapsed time during which clustered Windows nodes can lose
communication before triggering a failover. When the clustered nodes are in dierent subnets, they are
called CrossSubnetDelay and CrossSubnetThreshold. Set the CrossSubnetDelay value to 2 and the
CrossSubnetThreshold value to 10.
vSphere MSCS Setup Limitations
Before you set up MSCS, review the list of functions that are not supported for this release, and
requirements and recommendations that apply to your conguration.
The following environments and functions are not supported for MSCS setups with this release of vSphere:
n
Clustering on NFS disks.
n
Mixed environments, such as congurations where one cluster node is running a dierent version of
ESXi than another cluster node.
n
Use of MSCS in conjunction with vSphere Fault Tolerance (FT).
n
Migration with vSphere vMotion
®
of clustered virtual machines on a single host (CIB).
n
N-Port ID Virtualization (NPIV)
n
ESXi hosts that use memory overcommitment are not suitable for deploying MSCS virtual machines.
Memory overcommitment can cause virtual machines to stall for short durations. This can be
signicantly disruptive as the MSCS clustering mechanism is time-sensitive and timing delays can
cause the virtual machines to behave incorrectly.
n
Suspend or resume of more than one MSCS node in an ESXi host with a ve-node cluster in a box
conguration is not supported. This I/O intensive operation is disruptive of the timing sensitive MSCS
clustering software.
n
Storage spaces are not supported with Failover clustering on Windows 2012 and above.
MSCS and Booting from a SAN
You can put the boot disk of a virtual machine on a SAN-based VMFS volume.
Booting from a SAN is complex. Problems that you encounter in physical environments extend to virtual
environments. For general information about booting from a SAN, see the vSphere Storage documentation.
Chapter 1 Getting Started with MSCS
VMware, Inc. 13