Why a Disk Witness is Better than a File-Share Witness

Q: Is it better to use a file-share witness or disk witness for my cluster?

A: In Windows Server 2012 R2, you always configure a witness, and clustering automatically decides when it needs a vote based on if there are an even or odd number of nodes in the cluster. Prior to Server 2012 R2, there were still many scenarios where you would configure a witness, especially if you had an even number of nodes, as an additional vote is required for quorum reasons. The decision has to be made to use a file-share witness or a disk witness.

If you have a multi-site cluster, then most likely you will have to use a file-share witness as there wouldn't be shared storage between the two sites. Additionally the file-share witness should be placed in a third site to provide 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's a very 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. Within that folder, a file is created that's used in times of arbitration, so only one partition of a cluster can lock the file. The file shows a timestamp (see screen shot below) of the last time a change was made to the main cluster database, although the file share doesn't actually have a copy of the cluster database.

Consider a scenario of a two-node cluster: node A and node B. If Node A goes down, then Node B carries on running and makes updates to the cluster database, such as new resources added. It would update the timestamp of the Witness.log on the fileshare witness.

Then Node B goes down and Node A tries to start. Node A would see the timestamp is in advance of its own database and realize its cluster database is stale, and so wouldn't start the cluster service. This prevents partition-in-time occurring, since Node A is out-of-date, which is a good thing, as you don't want the cluster to start out of date (that would mean different cluster states on different nodes). You can't start the cluster without Node B coming back or forcing quorum on Node A.

Now consider a disk witness which actually stores a complete copy of the cluster database.

In the same two-node cluster scenario, when Node A tries to start and sees its database is out of date, it can just copy the cluster database from the disk witness, which is kept up-to-date. Thus a file-share witness prevents partition-in-time occurring, and a disk witness solves partition-in-time.

For this reason, always use a disk witness over a file-share witness, if possible.