1
00:00:00,940 --> 00:00:02,140
Cluster Quorum Options.

2
00:00:02,140 --> 00:00:05,180
What does quorum mean anyway?

3
00:00:05,180 --> 00:00:09,190
Well, quorum, in our context for server high availability,

4
00:00:09,190 --> 00:00:13,020
refers to the number of failures required to take a cluster offline.

5
00:00:13,020 --> 00:00:17,820
A node or a Windows Server box that's participating in a failover

6
00:00:17,820 --> 00:00:21,180
cluster is going to have a vote, and then depending upon whether

7
00:00:21,180 --> 00:00:24,440
you have an even or odd number of votes,

8
00:00:24,440 --> 00:00:27,850
you can bring in a witness to provide a tiebreaker vote.

9
00:00:27,850 --> 00:00:30,580
For example, in my lab environment here,

10
00:00:30,580 --> 00:00:34,890
I have a two‑node cluster. Ideally, you should have an odd

11
00:00:34,890 --> 00:00:39,000
number of nodes in your cluster because the votes are

12
00:00:39,000 --> 00:00:41,070
counted such that the majority wins.

13
00:00:41,070 --> 00:00:46,730
So if over 50% of the vote casters in a failover cluster

14
00:00:46,730 --> 00:00:49,170
report that they're online and available,

15
00:00:49,170 --> 00:00:52,440
then that would mean that the cluster continues to operate.

16
00:00:52,440 --> 00:00:56,440
But what if you're in a situation with an even number of voters

17
00:00:56,440 --> 00:01:00,830
where you've got one down and one up? Then you have a tie, and

18
00:01:00,830 --> 00:01:03,630
this brings in the idea of a witness.

19
00:01:03,630 --> 00:01:07,430
So Microsoft's guidance here is that your clusters should always have an odd

20
00:01:07,430 --> 00:01:11,840
number of total voters so you don't run into a tie situation.

21
00:01:11,840 --> 00:01:12,700
For example,

22
00:01:12,700 --> 00:01:20,140
with a four‑node cluster, three voters must be online in order to avoid a tie.

23
00:01:20,140 --> 00:01:24,700
Now let's understand the specific configuration options available to us as

24
00:01:24,700 --> 00:01:29,040
Windows Server administrators with regard to quorum.

25
00:01:29,040 --> 00:01:32,430
If you do want to bring in a witness as a tie breaking

26
00:01:32,430 --> 00:01:34,650
vote, your options are threefold.

27
00:01:34,650 --> 00:01:36,550
The first is the disk witness,

28
00:01:36,550 --> 00:01:40,120
This is literally a disk that's accessible to all nodes in

29
00:01:40,120 --> 00:01:43,240
the cluster, and it can cast a vote itself.

30
00:01:43,240 --> 00:01:49,180
This is not a supported witness type when you're using S2D, or Storage Spaces

31
00:01:49,180 --> 00:01:54,090
Direct, only when you're using a storage area network array. Microsoft

32
00:01:54,090 --> 00:01:59,290
recommends considering disk witness if you are using a non‑S2D shared storage

33
00:01:59,290 --> 00:02:02,240
solution and also your within a single site.

34
00:02:02,240 --> 00:02:04,720
This is because the cluster nodes all need to be able to

35
00:02:04,720 --> 00:02:08,690
see the disk. For multi‑site clusters,

36
00:02:08,690 --> 00:02:12,680
you can do a file share witness. This is an SMB, or Server

37
00:02:12,680 --> 00:02:15,440
Message Block, share on a cluster node.

38
00:02:15,440 --> 00:02:19,990
And this is best because that share should be accessible or

39
00:02:19,990 --> 00:02:24,440
viewable across your multi‑site architecture.

40
00:02:24,440 --> 00:02:28,380
And then lastly, you've got the cloud witness, and this is a shared folder,

41
00:02:28,380 --> 00:02:31,840
an SMB share, in an Azure storage account.

42
00:02:31,840 --> 00:02:37,100
And this is good when your cluster nodes can go either over the internet or

43
00:02:37,100 --> 00:02:48,000
over a private endpoint link or over a site‑to‑site VPN or over an ExpressRoute circuit in order to reach that cloud witness.