You can decide whether it is better to have a disk witness, cloud witness, or a file
share witness. If you have a multisite cluster, you most likely will have to use a
file share witness or a cloud witness because there would not be shared storage
between the two sites. The decision to use a cloud witness or file share witness
will likely depend on whether you already have a third location to host the file
share. If you have a third site, you can leverage a file share witness; however, if a
third site is not available or you simply don’t want to use or manage a file share,
then use the cloud witness. Either way, it provides protection from a site failure.
In a cluster where shared storage is available, always use a disk witness over a file
share cluster, and there is a good reason for this. When you use a file share
witness, a folder is created on the file share named with the GUID of the cluster,
and within that folder a file is created that is used in times of arbitration so that
only one partition of a cluster can lock the file. Also, the file shows a timestamp of
the last time a change was made to the main cluster database, although the file
share does not have a copy of the cluster database. Every time a change is made to
the cluster database, the timestamp on the file share witness is updated but the
data is not stored on the file share witness, making the amount of network traffic
very light.
Consider a scenario of a two-node cluster, node A and node B. If node A goes
down, node B keeps running and makes updates to the cluster database, such as
adding new resources, and it also updates the timestamp of witness.log on the
file share witness. Then node B goes down, and node A tries to start. Node A sees
that the timestamp on the file share witness is in advance of its own database and
realizes that its cluster database is stale, and so it will not start the cluster service.
This prevents partition-in-time from occurring because node A is out-of-date
(which is a good thing, because you don’t want the cluster to start out-of-date)
and you would have different cluster states on different nodes, but you can’t start
the cluster without node B coming back or forcing quorum on node A.
Now consider a disk witness that stores a complete copy of the cluster database.
Every time a change is made to the cluster database, that change is also made to
the copy of the cluster database on the disk witness.
Now in the same two-node cluster scenario, when node A tries to start and sees
that its database is out-of-date, it can just copy the cluster database from the disk
witness, which is kept up-to-date, so while a file share witness prevents partition-
in-time from occurring, a disk witness solves partition-in-time.
For this reason, always use a disk witness over a file share witness or cloud
witness if possible.As you can see, the number of votes is key for a cluster quorum (specifically having
more than 50 percent of the total number of votes), but the total number of votes can
be a problem. Traditionally, the number of votes is set when the cluster is created,
when the quorum mode is changed, or when nodes are added or removed from the