The challenge is that LowerQuorumPriorityNodeID applies in only a 50-50 split, which
often will not be the case, as in Windows Server 2012 R2 you should always configure
a witness resource that dynamically has its vote status changed depending on the
number of nodes and ensures that there is always an odd number of votes. What
actually happens is that the core cluster group is owned by a node in the cluster, and
that core cluster group includes the witness resource. In the event of a cluster split,
the partition that already owns the core cluster group and therefore the witness will
typically keep it and therefore maintain quorum. This means that you can proactively
move the core cluster group to a node in your preferred site to help ensure that site
would stay active. It can be moved by using the following:
Move-ClusterGroup "cluster group" -Node
It can also be moved through Failover Cluster Manager via the More Actions ➣ Move
Core Cluster Resources context menu for the cluster.
Therefore, make sure that the core cluster group is running on your preferred site and
set LowerQuorumPriorityNodeID to a node in the secondary site to try to ensure that
your primary site will win in the event of a split. This is not very pretty, and it gets
much better with Windows Server 2016, as will be explored shortly.
In reality, it was not that common to see stretched clusters for Hyper-V virtual
machines because of the historical difficulty and high expense of replicating the
storage prior to Windows Server 2016. Additionally, if virtual machines moved
between locations, most likely their IP configuration would require reconfiguration
unless network virtualization was being used or VLANs were stretched between
locations, which again is rare and can be expensive. In the next chapter, I cover Hyper-
V Replica as a solution for disaster recovery, which solves the problems of moving
virtual machines between sites. Multisite clusters are commonly used for application
workloads, such as SQL and Exchange, instead of for Hyper-V virtual machines.
As mentioned, Windows Server 2016 changes multisite cluster practicality in
numerous ways, and not just with the introduction of Storage Replica to enable
storage replication between locations. Clustering has become site aware in Windows
Server 2016, providing enhanced multisite cluster capabilities. Site awareness enables
nodes to be grouped based on their physical location. This knowledge of physical
location is used in various ways by clustering:
When a node fails or needs to be drained, the resources are moved to nodes in the
same site if possible.
VMs follow the site owning the CSV, so if a CSV moves to a new site, the VMs will
follow within a minute via Live Migration.
A primary site can be defined that in the event of a split and all other things being
equal will maintain quorum and offer services, as dynamic quorum prunes nodes
from the nonpreferred site first. The preferred site is also used at startup; VMs will
start in the preferred site first.