File Share witness vs Disk witness for local clusters
This article was contributed by Ryan Doon , a PFE working at Microsoft Canada.
Clustering in Windows 2008 R2 has been greatly simplified, and one of those areas of simplification includes choosing which quorum model to use. Based on the cluster configuration, the best quorum model will be chosen for you. In some cases users will override the automatic choice and choose a different quorum model.
This blog post is to explain why you should not override the quorum choice for local clusters, and not utilize the File Share Witness model for local clusters.
Quorum models: Disk vs File Share witness
Witness Disk: Recommended for local clusters in an environment where there is shared storage
- The witness disk will contain a backup of the cluster database
File Share witness: Recommended for geographically dispersed clusters where there is no shared storage
- The File Share witness does not keep a copy of the cluster database. It utilizes something called the paxos tag to understand which node has the latest version of the cluster database
- A single file share witness can be used by multiple clusters (a folder will be created within the file share for each cluster)
If at all possible it is always best to utilize the disk witness, because the disk witness will always have a backup of the cluster database. The file share witness keeps track of which node has the most up-to-date version of the cluster database, but does not keep a copy.
There is a scenario called the “partition in time” where you can definitely see why disk witness is ideal…
Partition In Time (when the cluster is utilizing File Share witness)
- You have a local two-node cluster with nodes A and B. Both nodes are running and their replicas of the cluster configuration are synchronized.
- B is turned off.
- Changes are made on node A. These changes are only reflected on node A’s replica of the cluster configuration.
- A is turned off.
- Node B is turned on. B does not have the most recent replica of the cluster configuration, and the file share witness does not have a replica at all. However, the file share witness contains the information that node A has the most recent replica, so the file share witness prevents node B from forming the cluster. If (for any reason) you force the quorum on node B to start the cluster service, this will overwrite the paxos tag, and the file share witness will think that B has the latest cluster database, when in fact A does. When A comes back online any changes will be lost, because the cluster thinks that the most up to date cluster database is what resides on node B.
The File Share witness was designed ideally for a 3 site cluster. Site A and Site B would house the cluster nodes, and Site C would house the File Share witness. That way if Site A were to go down, Site B would still be up.
So, the Disk witness is the ideal solution, because it always has a copy of the cluster database, and you don’t have to worry about the issue with “partition in time”.
Posted by Tristan Kington , MSPFE Editor and occasional word of the week.