Windows Server 容錯移轉叢集 可為在 Azure 本機和 Windows Server 叢集上執行的工作負載提供高可用性。 如果託管資源的節點已啟動，則這些資源被視為高可用性;不過，叢集通常需要一半以上的節點才能執行，這稱為具有 仲裁。
仲裁的設計目的是要防止網路中有分割區，且節點子集無法彼此通訊時可能發生的 腦裂 案例。 這可能會導致這兩個節點子集嘗試擁有工作負載並寫入相同的磁碟，這可能會導致許多問題。 不過，使用故障轉移叢集的仲裁概念來避免這種情況，這隻會強制其中一個節點群組繼續執行，因此只有其中一個群組會保持上線。
法定人數決定叢集在仍能維持在線狀態的可承受失敗數目。 仲裁的設計目的是在叢集節點子集之間的通訊出現問題時處理案例，以避免多部伺服器嘗試同時運行資源群組並寫入相同的磁碟。 藉由擁有此仲裁概念，叢集會強制叢集服務停止在其中一個節點子集中，以確保特定資源群組只有一個真正的擁有者。 已停止的節點可以再次與主要節點群組通訊，並會自動重新加入叢集並啟動其叢集服務。
在 Azure 本機和 Windows Server 2019 中，系統的兩個元件都有自己的仲裁機制：
- 叢集仲裁：這會在叢集層級運作 （亦即，您可能會遺失節點，並讓叢集保持啟動狀態）
- 集區仲裁：這會在集區層級運作 （亦即，您可能會遺失節點和磁碟驅動器，並讓集區保持運作）。 儲存池被設計用於叢集和非叢集方案，這就是它們有不同仲裁機制的原因。
叢集仲裁概觀
下表概述每個案例的叢集仲裁結果：
| 伺服器節點 | 可以承受一個伺服器節點失敗 | 可以承受一個伺服器節點失敗，然後再承受另一個節點失敗 | 可以承受兩個同時發生的伺服器節點失敗 |
|---|---|---|---|
| 2 | 50/50 | No | No |
| 2 + 證人 | Yes | No | No |
| 3 | Yes | 50/50 | No |
| 3 + 見證 | Yes | Yes | No |
| 4 | Yes | Yes | 50/50 |
| 4 + 證人 | Yes | Yes | Yes |
| 5 (含) 個以上 | Yes | Yes | Yes |
叢集法定人數建議
- 如果您有兩個節點，則 需要見證人。
- 如果您有三個或四個節點，強烈 建議使用見證。
- 如果您有五個以上的節點，則不需要見證，也不會提供額外的復原能力。
- 如果您有網際網路存取權，請使用 雲端見證。
- 如果您在具有其他機器和檔案共用的 IT 環境中，請使用檔案共用見證。
叢集仲裁的運作方式
當節點發生故障時，或當節點的某些子集與另一個子集失去聯繫時，倖存的節點需要驗證它們是否構成叢集的 大部分 才能保持在線狀態。 如果他們無法驗證，他們將會離線。
但是，只有當叢集中的節點總數為奇數 （例如，五個節點叢集中的三個節點） 時， 多數 概念才會運作得很乾淨。 那麼，具有偶數節點的叢集呢？（例如，四個節點叢集）？
叢集有兩種方式可以讓 總票數 變得奇數：
- 首先，它可以通過添加一名具有額外投票的證人來增加一票。 這需要用戶設定。
- 或者，它可以通過將一個不幸節點的投票歸零 來下降一個 （根據需要自動發生）。
每當倖存的節點成功驗證他們是 多數時， 多數 的定義就會更新為僅在倖存者中。 這可讓叢集失去一個節點、另一個節點、另一個節點等等。 在連續失敗后調整 的投票總數 的概念稱為 動態仲裁。
動態見證
動態見證會切換見證的投票，以確保 總票數 是奇數。 如果有奇數的選票，證人沒有投票。 如果有偶數票數，證人有投票權。 動態見證顯著降低因為見證失效導致叢集停運的風險。 叢集會決定是否根據叢集中可用的投票節點數目來使用見證投票。
動態仲裁會以下列方式與動態見證搭配運作。
動態仲裁行為
- 如果您有 偶數 個節點且沒有見證人，則 一個節點的投票將歸零。 例如，四個節點中只有三個獲得選票，因此 總票數 為三張，而有選票的兩名倖存者則被視為多數票。
- 如果您有 奇數 個節點並且沒有見證人，它們 都會獲得投票。
- 如果您有 偶數 個節點加上見證人，則 見證人投票，因此總數為奇數。
- 如果您有 奇數 個節點加上見證人，則 見證人不會投票。
動態仲裁能夠動態地將投票分配給節點，以避免失去多數票，並使叢集可以僅由一個節點運行（即所謂的「獨立節點運行」模式）。 讓我們以四節點叢集為例。 假設法定人數需要 3 票。
在此情況下，如果您損失兩個節點，叢集就會崩潰。
不過，動態配額仲裁可防止這種情況發生。 法定人數所需的 投票總數 現在會根據可用的節點數來決定。 因此，使用動態仲裁時，即使失去三個節點，叢集仍會持續運作。
上述案例適用於未啟用儲存空間直接存取的一般叢集。 不過，啟用 Storage Spaces Direct 時，叢集只能支援兩個節點故障。 這會在 集合池法定數一節中進一步說明。
Examples
沒有見證的兩個節點
一個節點的投票為零，因此 多數 票是從總共 1 票中確定的。 如果非投票節點意外關閉，則倖存者有 1/1，而叢集仍可存留。 如果投票節點意外故障，倖存節點的數量變為 0/1，導致叢集停運。 如果投票節點正常關閉，投票會傳輸到另一個節點，而叢集會倖存下來。 這就是為什麼設定見證很重要的原因。
- 可以倖存一部伺服器失敗： 百分之五十的機會。
- 可以在一次伺服器故障後倖存下來，然後在另一台伺服器故障中倖存下來： 不可以。
- 可以同時承受兩個伺服器故障： 不可以。
具有見證的兩個節點
兩個節點都投票，加上見證人投票，因此 多數 票是從總共 3 票中確定的。 如果任一節點發生故障，則倖存者將保留三分之二的資源，叢集仍能運行。
- 可以在一次伺服器故障中倖存下來： 是的。
- 可以在一次伺服器故障後倖存下來，然後在另一台伺服器故障中倖存下來： 不可以。
- 可以同時承受兩個伺服器故障： 不可以。
沒有見證的三個節點
所有節點都投票，因此 多數 票是從總共 3 票中確定的。 如果有任何節點關閉，有 2/3 的節點倖存，叢集能繼續運作。 叢集會變成兩個沒有見證的節點 ，此時您位於案例 1。
- 可以在一次伺服器故障中倖存下來： 是的。
- 可以抵擋一個伺服器故障，再抵擋另一個：五成機率。
- 可以同時承受兩個伺服器故障： 不可以。
具有見證的三個節點
因為所有節點都會投票，所以見證者起初不參與投票。 多數票由總共 3 票決定。 一次失敗之後，叢集會有兩個帶有見證的節點，也就是回到案例 2。 因此，現在兩個節點和見證人投票。
- 可以在一次伺服器故障中倖存下來： 是的。
- 可以在一次伺服器故障後倖存下來，然後在另一台伺服器故障中倖存下來： 是的。
- 可以同時承受兩個伺服器故障： 不可以。
四個無見證節點
一個節點的投票為零，因此從總共 3 張投票中確定多數。 一次失敗之後，叢集會變成三個節點，而您位於案例 3。
- 可以在一次伺服器故障中倖存下來： 是的。
- 可以在一次伺服器故障後倖存下來，然後在另一台伺服器故障中倖存下來： 是的。
- 一次可以倖存兩個伺服器失敗： 50% 的機會。
具有見證的四個節點
所有節點投票，見證人投票，因此從總共 5 票中確定多數票。 一次失敗之後，您位於案例 4。 在兩次同時失敗之後，您跳到情境2。
- 可以在一次伺服器故障中倖存下來： 是的。
- 可以在一次伺服器故障後倖存下來，然後在另一台伺服器故障中倖存下來： 是的。
- 可以同時承受兩個伺服器故障： 是的。
五個節點及更多
所有節點都投票，或有一個節點不投票，總之要讓總票數為奇數。 儲存空間直接存取無論如何都無法處理兩個以上的節點，因此此時不需要見證或有用。
- 可以在一次伺服器故障中倖存下來： 是的。
- 可以在一次伺服器故障後倖存下來，然後在另一台伺服器故障中倖存下來： 是的。
- 可以同時承受兩個伺服器故障： 是的。
既然我們瞭解法定人數的運作方式，讓我們看看法定人數見證的類型。
仲裁見證類型
故障轉移叢集支援三種類型的仲裁見證：
- 雲端見證 - 叢集的所有節點都可以存取 Azure 中的 Blob 儲存體。 其會在 witness.log 檔案中維護叢集資訊，但不會儲存叢集資料庫的複本。
- 檔案共用見證 – 在執行 Windows Server 的檔案伺服器上設定的 SMB 檔案共用。 其會在 witness.log 檔案中維護叢集資訊，但不會儲存叢集資料庫的複本。
- 磁碟見證 - 位於叢集可用儲存體群組中的小型叢集磁碟。 此磁碟具有高可用性，並且可以在節點之間進行故障轉移。 其中包含叢集資料庫的複本。 磁碟見證不支援儲存空間直接存取。
集區仲裁概觀
我們剛剛談到叢集仲裁，它在叢集層級運作。 現在，讓我們深入探討池仲裁，這是在儲存池層級運作的機制（也就是說，即使損失節點和硬碟，儲存池依然能夠維持運行）。 儲存池被設計用於叢集和非叢集方案，這就是它們有不同仲裁機制的原因。
下表概述每個案例的集區仲裁結果：
| 伺服器節點 | 可以承受一個伺服器節點失敗 | 可以承受一個伺服器節點失敗，然後再承受另一個節點失敗 | 可以承受兩個同時發生的伺服器節點失敗 |
|---|---|---|---|
| 2 | Yes | No | No |
| 2 + 證人 | Yes | No | No |
| 3 | Yes | No | No |
| 3 + 見證 | Yes | No | No |
| 4 | Yes | No | No |
| 4 + 證人 | Yes | Yes | Yes |
| 5 (含) 個以上 | Yes | Yes | Yes |
資源池法定人數的運作方式
當磁碟機發生故障時，或當磁碟機的某些子集與另一個子集失去聯繫時，託管中繼資料的倖存磁碟機需要驗證它們是否構成集區的 大部分 才能保持線上。 如果他們無法驗證，他們將會離線。 存儲池是根據是否有足夠的磁碟達到法定人數（50% + 1）來決定離線或保持線上的實體。 只要叢集本身是引號，叢集資料庫就可以是 +1。
但集區仲裁的運作方式與叢集仲裁的運作方式不同，方式如下：
- 集區會從每個節點中選擇一部分硬碟來裝載元數據。
- 集區會使用叢集資料庫來打破僵局
- 集區沒有動態仲裁
- 集區不會實作自己的投票移除方法
Examples
具有對稱式配置的四個節點
每個 16 個硬碟都有一票，節點二也有一票（因為它是該資源池的擁有者）。 多數票是從總共 16 票中確定的。 如果節點三和四失敗，倖存的子集有8個磁碟驅動器和集區資源擁有者，也就是擁有9/16的投票權。 因此，游泳池倖存下來。
- 可以在一次伺服器故障中倖存下來： 是的。
- 可以在一次伺服器故障後倖存下來，然後在另一台伺服器故障中倖存下來： 是的。
- 可以同時承受兩個伺服器故障： 是的。
四個節點具有對稱佈局並出現驅動故障
每個磁碟驅動器中的16個都有一個投票權，節點2也有一票（因為它是集區資源擁有者）。 多數票是從總共 16 票中確定的。 首先，驅動器 7 停止運作。 如果節點三和四發生故障，倖存的子集有 7 個磁碟驅動器，其集區資源擁有者擁有 8/16 的票數。 因此，游泳池沒有多數，下降。
- 可以在一次伺服器故障中倖存下來： 是的。
- 可以在一次伺服器故障後倖存下來，然後在另一台伺服器故障中倖存下來： 不可以。
- 可以同時承受兩個伺服器故障： 不可以。
集群法定人數建議
- 請確定叢集中的每個節點都是對稱的（每個節點都有相同的磁碟驅動器數目）
- 啟用三向鏡像或雙同位，讓您可以容忍兩個節點失敗，並讓虛擬磁碟保持上線。
- 如果兩個以上的節點關閉，或兩個節點和另一個節點上的磁碟已關閉，磁碟區可能無法存取其數據的所有三個複本，因此會脫機且無法使用。 建議將伺服器帶回，或快速取代磁碟，以確保磁碟區中所有數據的復原能力最高。