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