訓練
認證
Microsoft Certified: Azure Database Administrator Associate - Certifications
使用 Microsoft PaaS 關聯式資料庫供應項目管理用於雲端、內部部署和混合關聯式資料庫的 SQL Server 資料庫基礎結構。
適用於: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 |
當節點失敗,或當某些節點子集失去與另一個子集的接觸時,倖存的節點必須確認它們是否構成 大部分 的叢集,才能維持在在線。 如果他們無法確認,他們將會脫機。
但是,大部分的概念只有在叢集中的節點總數是奇數時才能完全運作(例如,五個節點叢集中的三個節點)。 那麼,具有偶數節點的叢集呢?(例如,四個節點叢集)?
叢集有兩種方式可以讓 總票 數變得奇數:
每當倖存的節點成功驗證它們為多數時,多數的定義就會更新為只是倖存者之一。 這可讓叢集失去一個節點、另一個節點、另一個節點等等。 在連續失敗后調整的投票總數的概念稱為動態仲裁。
動態見證會切換見證的投票,以確保 總票 數是奇數。 如果有奇數的選票,證人沒有投票。 如果有偶數票數,證人有投票權。 動態見證可大幅降低叢集因為見證失敗而關閉的風險。 叢集會決定是否根據叢集中可用的投票節點數目來使用見證投票。
動態仲裁會以下列方式與動態見證搭配運作。
動態仲裁可讓您動態將投票指派給節點,以避免失去多數票數,並允許叢集以一個節點執行(稱為最後一個節點)。 讓我們以四節點叢集為例。 假設仲裁需要 3 票。
在此情況下,如果您遺失兩個節點,叢集就會關閉。
不過,動態仲裁可防止這種情況發生。 仲裁 所需的投票 總數現在會根據可用的節點數目來決定。 因此,使用動態仲裁時,即使失去三個節點,叢集仍會維持不變。
上述案例適用於未啟用 儲存空間直接存取的一般叢集。 不過,啟用 儲存空間直接存取 時,叢集只能支援兩個節點失敗。 這會在集區仲裁一節中進一步說明。
一個節點的投票是零的,因此 多數 票被確定為總共 1票。 如果非投票節點意外關閉,則倖存者有 1/1,而叢集仍可存留。 如果投票節點意外關閉,則倖存者有 0/1,叢集會關閉。 如果投票節點正常關閉,投票會傳輸到另一個節點,而叢集會倖存下來。 這就是為什麼設定見證很重要的原因。
這兩個節點都投票,加上證人的選票,因此 多數票 總數 由3票決定。 如果任一節點關閉,則倖存者有 2/3,而叢集仍可存留。
所有節點都投票,因此 多數票 由總共 3票決定。 如果有任何節點關閉,倖存者會是 2/3,而叢集會倖存下來。 叢集會變成兩個沒有見證的節點 ,此時您位於案例 1。
所有節點都會投票,因此見證一開始不會投票。 多數 票 由總共 3票決定。 一次失敗之後,叢集有兩個具有見證的節點,也就是回到案例 2。 因此,現在兩個節點和見證投票。
一個節點的投票是零的,因此 多數票 由總共 3票決定。 一次失敗之後,叢集會變成三個節點,而您位於案例 3。
所有節點都投票和見證投票,因此 多數票 總數 由5票決定。 一次失敗之後,您位於案例 4。 在兩個同時失敗之後,您跳到案例 2。
所有節點都投票,或除了一票,任何使總奇數。 儲存空間直接存取 無論如何都無法處理兩個以上的節點,因此此時不需要或有用的見證。
既然我們瞭解仲裁的運作方式,讓我們看看仲裁見證的類型。
故障轉移叢集支援三種類型的仲裁見證:
我們剛剛談到叢集仲裁,其運作於叢集層級。 現在,讓我們深入瞭解集區仲裁,這會在集區層級上運作(也就是您可以失去節點和磁碟驅動器,並讓集區保持運作)。 存放集區的設計用於叢集和非叢集案例,這就是為什麼它們有不同的仲裁機制。
下表概述每個案例的集區仲裁結果:
伺服器節點 | 可以承受一個伺服器節點失敗 | 可以承受一個伺服器節點失敗,然後再承受另一個節點失敗 | 可以承受兩個同時發生的伺服器節點失敗 |
---|---|---|---|
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 票。 因此,游泳池沒有多數,下降。
訓練
認證
Microsoft Certified: Azure Database Administrator Associate - Certifications
使用 Microsoft PaaS 關聯式資料庫供應項目管理用於雲端、內部部署和混合關聯式資料庫的 SQL Server 資料庫基礎結構。