閱讀英文

共用方式為


了解叢集和集區仲裁

適用於: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 環境中,請使用檔案共用見證。

叢集仲裁的運作方式

當節點失敗,或當某些節點子集失去與另一個子集的接觸時,倖存的節點必須確認它們是否構成 大部分 的叢集,才能維持在在線。 如果他們無法確認,他們將會脫機。

但是,大部分的概念只有在叢集中的節點總數是奇數時才能完全運作(例如,五個節點叢集中的三個節點)。 那麼,具有偶數節點的叢集呢?(例如,四個節點叢集)?

叢集有兩種方式可以讓 總票 數變得奇數:

  1. 首先,它可以增加一個證人與額外的投票。 這需要用戶設定。
  2. 或者,它可以 以零一個不幸的節點投票來下降 一個(視需要自動發生)。

每當倖存的節點成功驗證它們為多數時,多數的定義就會更新為只是倖存者之一。 這可讓叢集失去一個節點、另一個節點、另一個節點等等。 在連續失敗后調整的投票總數的概念稱為動態仲裁

動態見證

動態見證會切換見證的投票,以確保 總票 數是奇數。 如果有奇數的選票,證人沒有投票。 如果有偶數票數,證人有投票權。 動態見證可大幅降低叢集因為見證失敗而關閉的風險。 叢集會決定是否根據叢集中可用的投票節點數目來使用見證投票。

動態仲裁會以下列方式與動態見證搭配運作。

動態仲裁行為

  • 如果您有 數節點且沒有見證, 則一個節點會將其投票零。 例如,四個節點中只有三個獲得選票,因此 總票數為三張,而有選票的 兩名倖存者則被視為多數票。
  • 如果您有 數的節點,而且沒有見證, 它們都會得到投票
  • 如果您有 數節點加上見證, 則見證會投票,因此總計為奇數。
  • 如果您有 數節點加上見證, 則見證不會投票

動態仲裁可讓您動態將投票指派給節點,以避免失去多數票數,並允許叢集以一個節點執行(稱為最後一個節點)。 讓我們以四節點叢集為例。 假設仲裁需要 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票。 因此,游泳池倖存下來。

集區仲裁 1。

  • 可以倖存一部伺服器失敗:
  • 可以倖存一部伺服器失敗,然後是另一個:
  • 一次可以倖存兩個伺服器失敗:

對稱配置和磁碟驅動器失敗的四個節點

每個16個磁碟驅動器都有一個投票,節點2也有一票(因為它是集區資源擁有者)。 多數 總共 16票決定。 首先,驅動器 7 下車了。 如果節點三和四個向下,倖存的子集有 7 個磁碟驅動器和集區資源擁有者,也就是 8/16 票。 因此,游泳池沒有多數,下降。

集區仲裁 2。

  • 可以倖存一部伺服器失敗:
  • 可以倖存一部伺服器失敗,然後是另一個:
  • 一次可以存留兩個伺服器失敗:

集區仲裁建議

  • 請確定叢集中的每個節點都是對稱的(每個節點都有相同的磁碟驅動器數目)
  • 啟用三向鏡像或雙同位,讓您可以容忍兩個節點失敗,並讓虛擬磁碟保持上線。
  • 如果兩個以上的節點關閉,或兩個節點和另一個節點上的磁碟已關閉,磁碟區可能無法存取其數據的所有三個複本,因此會脫機且無法使用。 建議將伺服器帶回,或快速取代磁碟,以確保磁碟區中所有數據的復原能力最高。

下一步