了解叢集和集區仲裁

發行項
03/08/2024

適用於：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	No	否
2 個 + 見證	是	No	否
3	是	50/50	No
3 個 + 見證	是	是	否
4	是	是	50/50
4 個 + 見證	是	Yes	是
5 (含) 個以上	是	Yes	是

叢集仲裁建議

如果您有兩個節點，則需要見證。
如果您有三個或四個節點，則強烈建議使用見證。
如果您有五個以上的節點，則不需要見證且不會提供額外的復原。
如果您可以存取網際網路，請使用雲端見證。
如果您在具有其他機器和檔案共用的 IT 環境中，請使用檔案共用見證。

叢集仲裁的運作方式

當節點失敗時，或某些節點子集失去與另一個子集的聯繫時，存活的節點必須確認其可構成叢集的「多數」，才能保持在線上。如果無法確認，則這些節點會離線。

但是「多數」的概念只有在叢集中的節點總數是奇數時，才會完全正常運作 (例如，五個節點叢集中的三個節點)。那麼，如果叢集的節點數目是偶數呢 (例如四個節點的叢集)？

有兩種方式可讓叢集將「投票總數」變成奇數：

首先，可以藉由新增「見證」來「增加」一個投票數。這需要使用者設定。
或者，可以藉由將一個不幸的節點清空來「減去」投票數 (這會在有需要時自動發生)。

每當存活節點成功確認它們多數時，多數的定義就會更新為只存留者。這可讓叢集失去一個節點，然後再失去另一個節點，依此類推。「投票總數」在連續失敗之後自動進行調整的概念稱為「動態仲裁」。

動態見證

動態見證會切換見證的投票資格，以確保「投票總數」為奇數。如果投票數為奇數，則見證就不會有投票資格。如果有偶數的投票，見證會有投票。動態見證可大幅降低叢集因為見證失敗而關閉的風險。叢集會根據叢集中可用的投票節點數目，決定是否要使用見證投票。

動態仲裁會以下面所述的方式與動態見證搭配運作。

動態仲裁行為

如果您的節點數目為偶數，而且沒有見證，則「其中一個節點會將其投票資格清除」。例如，四個節點中只有三個可投票，因此「投票總數」為三個，而可投票的兩個存活節點則視為多數。
如果您的節點數目為奇數，而且沒有見證，則「這些節點都可投票」。
如果有偶數數目的節點再加上見證 (見證投票)，則節點總計為奇數。
如果有奇數數目的節點再加上見證，則「見證不會投票」。

動態仲裁可讓您以動態方式指派選票給節點，以避免失去多數選票，並且可允許叢集以一個節點執行 (也就是「存活到最後的節點」)。讓我們以四個節點的叢集作為範例。假設仲裁需要 3 個投票數。

在此情況下，如果您失去兩個節點，叢集就會停止。

不過，動態仲裁可防止這種情況發生。仲裁所需的「投票總數」現在會根據可用的節點數目來決定。因此，使用動態仲裁時，即使您遺失三個節點，叢集仍會保持運作狀態。

上述情況適用於未啟用儲存空間直接存取的一般叢集。不過，啟用儲存空間直接存取時，叢集只能支援兩個節點失敗。這會在集區仲裁區段中詳細說明。

範例

兩個節點，沒有見證

一個節點的投票資格已清空，因此「多數」投票會由總數為 1 的票數所決定。如果非投票節點意外停止，存活的節點會有 1/1，而叢集可繼續生存。如果投票節點意外停止，存活的節點會有 0/1，而叢集也會停止。如果投票節點正常關閉，則投票會轉移至另一個節點，而叢集可繼續生存。 這就是設定見證非常重要的原因。

可以承受一個伺服器失敗：50% 的機率。
可以承受一個伺服器失敗，然後再承受另一個伺服器失敗：否。
可以承受同時發生兩個伺服器失敗：否。

兩個節點和一個見證

這兩個節點都可投票，再加上見證投票，因此「多數」會由總數為 3 的票數來決定。如果其中一個節點停止運作，存活的節點會有 2/3，則叢集可繼續生存。

可以承受一個伺服器失敗：是。
可以承受一個伺服器失敗，然後再承受另一個伺服器失敗：否。
可以承受同時發生兩個伺服器失敗：否。

三個節點，沒有見證

所有節點都可投票，因此「多數」會由總數為 3 的票數來決定。如果任何節點停止運作，存活的節點會有 2/3，而叢集可繼續生存。叢集會變成兩個節點且沒有見證 – 此時，您屬於案例 1 的情況。

可以承受一個伺服器失敗：是。
可以承受一個伺服器失敗，然後再承受另一個伺服器失敗：50% 的機率。
可以承受同時發生兩個伺服器失敗：否。

三個節點和一個見證

所有節點都可投票，因此見證不會在一開始進行投票。「多數」會由總數為 3 的票數所決定。在一個節點失敗之後，叢集會有兩個節點和一個見證，也就是回到案例 2 的情況。因此，現在會由兩個節點和見證進行投票。

可以承受一個伺服器失敗：是。
可以承受一個伺服器失敗，然後再承受另一個伺服器失敗：是。
可以承受同時發生兩個伺服器失敗：否。

四個節點，沒有見證

一個節點的投票資格已清空，因此「多數」會由總數為 3 的票數決定。在一個節點失敗之後，叢集會變成三個節點，也就是案例 3 的情況。

可以承受一個伺服器失敗：是。
可以承受一個伺服器失敗，然後再承受另一個伺服器失敗：是。
可以承受同時發生兩個伺服器失敗：50% 的機率。

四個節點和一個見證

所有節點都可投票，再加上見證投票，因此「多數」會由總數為 5 的票數來決定。在一個節點失敗之後，您就會處於案例 4 的情況中。同時發生兩個失敗之後，您就會跳到案例 2。

可以承受一個伺服器失敗：是。
可以承受一個伺服器失敗，然後再承受另一個伺服器失敗：是。
可以承受同時發生兩個伺服器失敗：是。

五個 (含) 以上的節點

所有節點都可投票，或不讓其中一個投票，無論如何要讓總數變成奇數。儲存空間直接存取仍然無法處理兩個以上的節點，因此此時不需要或有用見證。

可以承受一個伺服器失敗：是。
可以承受一個伺服器失敗，然後再承受另一個伺服器失敗：是。
可以承受同時發生兩個伺服器失敗：是。

現在我們已了解仲裁的運作方式，接著讓我們來看看仲裁見證的類型。

仲裁見證類型

容錯移轉叢集支援三種類型的仲裁見證：

雲端見證 - 叢集的所有節點都可存取 Azure 中的 Blob 儲存體。其會在 witness.log 檔案中維護叢集資訊，但不會儲存叢集資料庫的複本。
檔案共用見證 – 在執行 Windows Server 的檔案伺服器上設定的 SMB 檔案共用。其會在 witness.log 檔案中維護叢集資訊，但不會儲存叢集資料庫的複本。
磁碟見證 - 叢集可用記憶體群組中的小型叢集磁碟。此磁碟具有高可用性，而且可以在節點之間故障轉移。其中包含叢集資料庫的複本。 儲存空間直接存取不支援磁碟見證。

集區仲裁概觀

我們剛才討論了在叢集層級上運作的叢集仲裁。現在，讓我們深入探索在集區層級上運作的集區仲裁 (也就是您可以在遺失節點和磁碟機的情況下讓集區保持啟動狀態)。存放集區已設計成可用於叢集和非叢集案例，這就是為什麼會有不同的仲裁機制。

下表提供每個案例的集區仲裁結果概觀：

伺服器節點	可以承受一個伺服器節點失敗	可以承受一個伺服器節點失敗，然後再承受另一個節點失敗	可以承受兩個同時發生的伺服器節點失敗
2	是	No	否
2 個 + 見證	是	No	否
3	是	No	No
3 個 + 見證	是	No	否
4	是	No	否
4 個 + 見證	是	Yes	是
5 (含) 個以上	是	Yes	是

集區仲裁的運作方式

當磁碟驅動器失敗，或某些磁碟驅動器子集失去另一個子集的接觸時，裝載元數據的磁碟驅動器必須確認它們構成 大部分 的集區，才能保持在線狀態。如果無法確認，則這些節點會離線。集區是根據其磁碟是否足以用於仲裁 (50% + 1) 而決定離線或保持上線狀態的實體。只要叢集本身是商數，叢集資料庫就可以是 +1。

但是集區仲裁的下列運作方式不同於叢集仲裁：

集區會選取每個節點的磁碟驅動器子集來裝載元數據
集區會使用叢集資料庫來中斷系結
集區沒有動態仲裁
集區不會實作自己的移除投票版本

範例

對稱配置的四個節點

16 個磁碟機都各有一票，而節點二也有一票 (因為是集區資源擁有者)。「多數」會由總數為 16 的投票數所決定。如果節點三和四停止運作，則存活的子集會有 8 個磁碟機和集區資源擁有者，也就是 9/16 票。因此，集區可繼續生存。

可以承受一個伺服器失敗：是。
可以承受一個伺服器失敗，然後再承受另一個伺服器失敗：是。
可以承受同時發生兩個伺服器失敗：是。

對稱配置的四個節點和磁碟機失敗

16 個磁碟機都各有一票，而節點 2 也有一個票 (因為是集區資源擁有者)。「多數」會由總數為 16 的投票數所決定。首先，磁碟機 7 停止運作。如果節點三和四停止運作，則存活的子集會有 7 個磁碟機和集區資源擁有者，也就是 8/16 票。因此，集區不具有多數，並且會停止運作。

可以承受一個伺服器失敗：是。
可以承受一個伺服器失敗，然後再承受另一個伺服器失敗：否。
可以承受同時發生兩個伺服器失敗：否。

集區仲裁建議

確定叢集中的每個節點都採對稱配置 (每個節點都有相同數目的磁碟機)
啟用三向鏡像或雙重同位，讓您可以容忍兩個節點失敗，並讓虛擬磁碟保持連線。
如果有兩個以上的節點停止運作，或兩個節點和另一個節點上的磁碟停止運作，則磁碟區可能無法存取其資料的全部三個複本，因而造成離線且無法使用。建議將伺服器恢復或快速取代磁碟，以確保磁碟區中所有數據的復原能力最高。