Lets start by explaining what is quorum.
Quorum may be defined as the number of members of a group that must be present to conduct business.
Windows 2008 Cluster service have 4 Quorum type:
- Node Majority: Each node that is available and in communication can vote. The cluster functions only with a majority of the votes, that is, more than half.
- Node and Disk Majority: Each node plus a designated disk in the cluster storage (the “disk witness”) can vote, whenever they are available and in communication. The cluster functions only with a majority of the votes, that is, more than half.
- Node and File Share Majority: Each node plus a designated file share created by the administrator (the “file share witness”) can vote, whenever they are available and in communication. The cluster functions only with a majority of the votes, that is, more than half.
- No Majority: Disk Only: The cluster has quorum if one node is available and in communication with a specific disk in the cluster storage.
One of the common question is, which quorum should I use?
The answer depend on the numbers of Node, Nodes Location and also the application it self that will be clustered.
The validation process for clusters in Windows Server 2008 R2 can validate the cluster against best practices and suggest a different quorum model if the current selection is not the best option
Check this table below that give you a clear view about quorum settings regarding for node number
Description of cluster
Odd number of nodes
Even number of nodes (but not a multi-site cluster)
Node and Disk Majority
Even number of nodes, multi-site cluster
Node and File Share Majority
Even number of nodes, no shared storage
Node and File Share Majority
So What is FSW
A FSW is simply a file share that you may create on a completely separate server from the cluster (It should not be on any of the cluster Member and it and it should have to dependency ) to act like a disk for tie-breaker scenarios when quorum needs to be established. The share could reside on a file server, domain controller, or even a completely different cluster. if you are using the FSW option for quorum. The purpose of the FSW is to have something else that can count as a vote in situations where the number of configured nodes isn’t quite enough for determining quorum. A FSW is more likely to be used in multi-site clusters or where there is no common storage ( Microsoft Exchange Server DAG also Depend on FSW, as example) . A FSW does not store cluster configuration data like a disk. It does, however, contain information about which version of the cluster configuration database is most recent. Other than that, the FSW is just a share. Resources cannot fail to it, nor can the share act as a communications hub or alternate brain to make decisions in the event cluster nodes cannot communicate.
Remember the old capture the flag game you might have played at summer camp? Typically each team had a flag and had to protect it from capture by the opposing team. However, a variation on that game is where there is only one flag located at an alternate location in the woods and two teams try to find it. When the flag is captured by one team, that team wins. A FSW is somewhat like the flag at an alternate location where a team of surviving nodes that can obtain it are able to reach quorum and other nodes that cannot drop out of the active cluster.( For short, the first set of nodes to successfully gain access to the FSW will survive ).
If you like this article, please leave a comment, share or like it