case, it’s important to use a file share witness in a third location to ensure that if one
site fails, the other site can use the witness vote and make quorum and offer services.
If you have a synchronous storage replication solution that supports arbitration of
storage, a disk witness could be used, but this is rare, which is why in most cases a file
share witness would be used. It is important that both sites have an equal number of
nodes. You would need to leverage a technology to replicate the storage used by
Hyper-V virtual machines to the other location. If this type of SAN replication of
storage is not available, the Hyper-V Replica technology can be leveraged. However,
this would require separate clusters between locations and would not be an automated
failover. The good news is that Windows Server 2016 has a native Storage Replica
capability, and a stretched cluster is a specific scenario that Storage Replica has been
designed to support and solve, providing automatic failover between sites.
CAN I HOST MY FILE SHARE WITNESS IN MICROSOFT AZURE
IAAS?
Microsoft Azure IaaS enables virtual machines to run in the Microsoft Azure
cloud service, which can include a file server offering a file share that can be
domain joined, making it seem a plausible option to host the witness for a cluster.
Technically, the answer is that the file share for a cluster could be hosted in a
Microsoft Azure IaaS VM, and the Microsoft Azure virtual network can be
connected to your on-premises infrastructure using its site-to-site gateway
functionality or ExpressRoute. Both of these solutions can connect to multiple
on-premises locations. However, while the use of a file share in Azure may be
required for Windows Server 2012 R2 clusters, it is unnecessary in a Windows
Server 2016 cluster since an Azure storage account can be directly used as the
witness resource. Therefore, if you have a multisite cluster, the use of the cloud
witness is likely the best solution.The other option is a manual failover in which services are manually activated on the
disaster-recovery site. In this scenario, it would be common to remove votes from the
disaster-recovery site so that it does not affect quorum on the primary location. In the
event of a failover to the disaster-recovery location, the disaster-recovery site would be
started in a Force Quorum mode.
Both with Hyper-V and for other services hosted in a multisite cluster, there is often
the concept of a primary site and a secondary or DR site. If a split occurs in the cluster
communications, the requirement is to control which of the partitions keeps running
(that is, the primary site). One option is the LowerQuorumPriorityNodeID property I
referred to earlier, which is configured on the cluster to indicate a specific node that in
the event of a 50-50 vote split would lose its vote, thereby causing its partition to lose
quorum and keep the other partition running. You would configure this node as one in
the secondary location.