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