WSFC仲裁模型優化方案選型

WSFC仲裁模型優化方案選型

生產環境某系統數據庫高可用環境描述

生產環境某系統部署爲主、備、災備三節點SQL Server 2014 AlwaysOn AG，操做系統爲Windows Server 2012 Standard，環境基於域（Domain）和Windows故障轉移集羣（WSFC）。無見證磁盤，採用多數節點仲裁。主、備都有投票權，災備無投票權。默認啓用了動態仲裁，默認動態仲裁隨機挑選一個節點去掉投票權。生產環境當前投票在備節點。

第1部分：測試環境資源描述

Windows故障轉移羣集、AlwaysOn AG資源和角色描述：

說明：

原環境仲裁見證爲無見證，新增共享磁盤僅附加到TEST-GS-ZHXT1和TEST-GS-ZHXT2，用於方案4的配置磁盤見證。

關注點：

1. 檢查WSFC和AG是否能正常對外提供服務。

2. 當前投票的數量和移動狀況。

3. 檢查投票來不及交換狀況（當前投票都爲0），執行強制仲裁後WFSC和AG的狀態，以及AG是否能成功執行Failover、副本是否能Resume。

第2部分：模擬生產環境帳戶系統當前配置測試

場景1：備節點宕機
目的：模擬備節點投票權來不及交換的狀況下，強制衝裁。
宕機後，投票來不及交換，WSFC崩潰，AG爲Resolving狀態。

維護操做：

1)       主節點執行強制仲裁
以管理員打開cmd，執行如下命令

       net stop clussvc

       net stop clussvc /FQ

       WSFC能對外提供服務。
在主節點上get-clusternode顯示主節點爲Up狀態、投票爲1，災備節點爲Up狀態，投票爲0，備節點狀態爲Down狀態，投票爲0。

2)       檢查AG是否能正常運行，或爲Resolving狀態

AG爲Resolving狀態

3)       若爲Resolving，是否能強制Failover

在主節點，打開實例執行 ALTER AVAILABILITY GROUP testag FORCE_FAILOVER_ALLOW_DATA_LOSS

可強制Failover，AG能對外提供服務

遺留問題：

在執行完以上操做後，當備節點也故障恢復起來

在備節點上get-clusternode顯示備節點 爲Up狀態、投票爲1，主、災備節點爲Down狀態，投票爲0。

備節點沒有按預期從新加入到主節點的集羣。

須要在備節點執行

net stop clussvc

net start clussvc

重啓集羣備節點

WSFC恢復，AG輔助副本可手工resume

第3部分：當前仲裁模型可優化方案測試

方案1：修改羣集參數值LowerQuorumPriorityNodeID爲備節點ID

目的：讓當前投票移動到主節點。

場景1：備節點宕機

備節點宕機後：

    WSFC正常，AG主副本正常，災備節點輔助副本正常。

備節點輔助副本Down，AG能正常對外提供服務。

備節點恢復後：

    WSFC正常，AG主副本正常，災備節點輔助副本正常。

若是備節點恢復時間短，備節點數據庫自動恢復；

若是備節點恢復時間較長，備節點輔助副本狀態爲未同步，數據庫沒法訪問，手工resume數據庫後，數據庫能夠訪問；

若是備節點恢復時間巨長，主節點早前日誌被日誌備份截斷，日誌不足，沒法用於備節點同步，須要重建備節點AG副本。

場景2：災備節點宕機

現象同場景1

場景3：主節點宕機

主節點宕機後：

投票來不及交換，WSFC崩潰，AG爲Resolving狀態。

備節點執行強制仲裁，WSFC恢復。

備節點AG強制Failover到備節點後，AG主副本正常，災備節點須要手工resume數據庫後，數據庫能夠訪問。

主節點恢復後：

測試4次，有2種不一樣結果：

    a)主節點未加入備節點的集羣，重啓集羣主節點clussvc服務後正常。

    b)主節點自動加入了備節點的集羣。

方案2： 讓3個節點都有投票權，修改羣集參數值LowerQuorumPriorityNodeID爲災備節點ID

目的：當任意1節點故障時，能有1個投票保持WSFC正常。

場景1：備節點宕機

備節點宕機後：

WSFC、AG均正常

備節點恢復後：

WSFC投票恢復正常，AG正常。

場景2：災備節點宕機

現象同場景1

場景3：主節點宕機

主節點宕機後：

WSFC正常，AG爲Resolving狀態，在備節點執行強制Failover，AG可對外提供服務，手工resume災備節點數據庫。

主節點恢復後：

WSFC投票恢復正常，數據庫手工resume後，與新的主節點數據同步，可訪問。

場景4：主節點和備節點同時宕機

主節點和備節點同時宕機後：

    WSFC崩潰，在災備節點執行強制仲裁，WSFC能提供服務。

    AG爲Resolving狀態，執行強制Failover，AG能對外提供服務。

主節點和備節點恢復後：

WSFC投票恢復正常，數據庫手工resume後，與新的主節點數據同步，可訪問。

場景5：備節點和災備節點同時宕機

備節點和災備節點同時宕機後：

    WSFC崩潰，在主節點執行強制仲裁，WSFC能提供服務。

    AG爲Resolving狀態，執行強制Failover，AG能對外提供服務。

備節點和災備節點恢復後：

WSFC投票恢復正常，數據庫手工resume後，與新的主節點數據同步，可訪問。

方案3：增長1個仲裁節點，給予投票權

目的：讓當前投票總數爲3票，基於節點大多數仲裁。

場景1：備節點宕機

備節點宕機後：

WSFC、AG均正常。

備節點恢復後：

WSFC投票恢復正常，AG正常，備節點數據庫手工resume後可訪問。

場景2：備節點和災備節點同時宕機

備節點和災備節點同時宕機後：

WSFC、AG均正常。

備節點和災備節點恢復後：

WSFC投票恢復正常，AG正常。

場景3：主節點宕機

主節點宕機後：

    WSFC正常，AG爲Resolving狀態，沒法提供服務。

備節點AG強制Failover後，可對外提供服務，災備節點數據庫手工resume後，與新的主節點數據同步。

主節點恢復後：

WSFC投票恢復正常，數據庫手工resume後，與新的主節點數據同步，可訪問。

場景4：主節點和備節點同時宕機

主節點和備節點同時宕機後：

    WSFC崩潰，在災備節點執行強制服務，WSFC能提供服務。

    AG爲Resolving狀態，執行強制Failover，AG能對外提供服務。

主節點和備節點恢復後：

WSFC投票恢復正常，數據庫手工resume後，與新的主節點數據同步，可訪問。

方案4：增長磁盤見證，附加到主、備節點

目的：基於動態仲裁，磁盤見證利用Windows Server 2012 R2動態見證行爲。

說明：

共享磁盤僅附加到主節點和備節點也能配置仲裁見證爲磁盤見證；

由於主、備節點各有1票，磁盤見證爲保持羣集奇數票，也投了1票。

場景1：備節點宕機

備節點宕機後：

WSFC、AG均正常。

備節點恢復後：

WSFC投票恢復正常，AG正常。

場景2：備節點和災備節點同時宕機

備節點和災備節點同時宕機後：

WSFC、AG均正常。

備節點和災備節點恢復後：

WSFC投票恢復正常，AG正常。

場景3：主節點宕機

主節點宕機後：

WSFC正常，AG爲Resolving狀態，沒法提供服務。

備節點AG強制Failover後，可對外提供服務，災備節點數據庫手工resume後，與新的主節點數據同步。

主節點恢復後：

WSFC投票恢復正常，數據庫手工resume後，與新的主節點數據同步，可訪問。

場景4：主節點和備節點同時宕機

主節點和備節點同時宕機後：

    WSFC崩潰，在災備節點執行強制服務，WSFC能提供服務。

    AG爲Resolving狀態，執行強制Failover，AG能對外提供服務。

主節點和備節點恢復後：

從新加入了集羣，兩節點數據庫手工resume後，與新的主節點數據同步，可訪問。

第4部分：優化方案評估

下表爲4種方案各場景的測試狀況彙總：

說明：綠色場景不是本次測試重點，是從理論上得出的結論。

在WSFC崩潰的狀況下，強制衝裁可提供服務。

在WSFC可提供服務後，AG爲Resolving狀態下，強制Failover可提供服務。

方案3和方案4能知足備節點、災備節點中任意一個或同時宕機時WSFC正常、AG正常。

方案3配置簡單，用1臺虛擬機做爲羣集節點，給予投票權，參與仲裁。

方案3中，仲裁節點宕機時，即與線上配置一致，此時備節點宕機，也就出現WSFC崩潰、AG沒法提供服務的狀況。

進一步優化方案，結合方案1和方案3的優勢，在方案3的基礎上修改羣集參數值LowerQuorumPriorityNodeID爲備節點ID。

因而，孕育出了方案5：增長1個仲裁節點，給予投票權，並修改羣集參數值LowerQuorumPriorityNodeID爲備節點ID。

進一步測試，結果以下：

測試代表，前5種場景下，與方案3表現相同。

先仲裁節點宕機，接着備節點宕機的場景下，表現穩定，優於方案3。

引用：

「在使用動態仲裁的時候須要考慮到如下兩點可能會碰見但容易被忽略的問題：

1. 純粹使用多數節點，動態仲裁調整節點數，當剩下2節點時，有百分之66左右的概率羣集能夠正常存活至最後一個節點，當被選中投票節點突然斷電宕機，則羣集關閉，須要手動強制啓動羣集。

2. 使用見證加節點投票數，動態仲裁+動態見證，當3剩2場景下，見證突然失聯，見證並不會去掉自身的一票，動態仲裁也並不會自動調整至1票，若是再宕機一個節點，羣集將關閉，這時須要手動強制啓動一個節點，當其它兩個節點恢復時，能夠手動切換至多數節點仲裁模型，這樣當再次出現3剩2場景下，會自動調整至1票，自動堅持至百分之66左右概率存活到最後一個節點場景，而後因爲咱們是強制啓動的羣集，所以即使當見證之後再恢復，強制啓動的羣集數據庫也會蓋過見證磁盤的數據庫。」

啓示：

①建立WSFC時選擇節點的順序很重要。

WSFC在有投票權的節點中投票發生交換時，會選擇節點ID值較大的那一個。

咱們應該儘可能保持在各類場景下主節點上有投票。那麼就要保持主節點的ID值最大。

在建立WSFC的過程當中，節點ID是遞增的。

根據重要性依次遞增，應該將沒有投票權的節點先創建集羣，再加入有投票權的仲裁節點，再加入有投票權的備節點，最後加入主節點。

（若是建立WSFC時，批量添加節點，那麼節點的ID是不可控的。）

②優化節點在投票發生交換時的選擇優先級。

因爲LowerQuorumPriorityNodeID是集羣的全局參數，只能設置爲某一個節點ID，並不能爲多節點設置權重或者說優先級。

應在①的基礎上，再去根據須要調整該參數。

第5部分：優化方案評估

基於成本和受益考慮，針對方案1和方案5，模擬投票節點宕機的不一樣場景，作進一步測試，測試結果以下：

從結果來看，方案5在場景②④⑤下，WSFC正常，AG須要強制Failover，帶來的收益是從分鐘級別恢復提高到秒級恢復，考慮到主庫宕機只會作手工切換，從收益上考慮，經討論後，選擇方案1。