WSFC 強制仲裁影響討論

     強制仲裁是WSFC羣集管理中一個經常使用操做，到底什麼狀況下應該執行強制仲裁，強制仲裁以後是否會對羣集形成影響，本篇文章老王將與你們細緻討論，爲了便於理解，我會將強制仲裁涉及到的羣集數據庫，仲裁概念進行簡單複習，以便你們更好的理解思考強制仲裁

     首先先來看下羣集數據庫，不少朋友可能不知道這個概念，老王在前面有篇文章專門講解，故這裏只作精要概述，簡單來講，羣集數據庫，是微軟WSFC運做的配置數據庫，存在於每一個節點註冊表，以及見證磁盤中。

     羣集數據庫主要用途

1. 羣集各節點啓動時，檢測羣集數據庫註冊表配置單元是否完整，若是完整才能夠容許該節點正常啓動羣集服務，如不完整需與其餘節點同步完整後纔可正常提供服務

2. 羣集運做過程元數據實時同步，以維護各節點羣集信息的一致性，並做爲故障轉移參照，WSFC正常運做過程時，會把羣集節點狀態，羣集狀態，羣集角色狀態等配置數據，記錄在各節點註冊表，羣集運做過程當中，每一個節點上修改了羣集的信息，都會把修改後的數據同步到各個節點，羣集見證磁盤，同步時使用羣集通訊網絡，其中也會將各節點當前承載的羣集角色同步，讓每一個節點和見證磁盤，都知道對方上面承載了什麼服務，發生故障轉移時，其它節點會檢測註冊表單元，將宕機節點原承載的羣集角色進行掛載聯機。

     自WSFC 2008開始，羣集數據庫開始引入paxos標記機制，每一個羣集節點自己均可以保存羣集數據庫最新副本，若是某個節點修改羣集數據，則該節點paxos標記增長，隨後各節點感應到有更新的paxos標記，會自動與其同步羣集數據庫內容，確保paxos始終與最新標記保持一致，當羣集節點宕機恢復後，會對比自身paxos標記與磁盤見證paxos標記，若是磁盤見證paxos標記更新，則與其同步後上線，若是磁盤見證檢測到羣集節點有更新paxos標記的羣集數據庫也會與其同步。

   那麼羣集數據庫和強制仲裁有什麼關係呢？

   正常羣集運做狀況下，羣集數據庫的複製同步應該是多主的，任何一個節點修改了數據，均可以和其它節點同步，便是說我在任何一個節點上面修改羣集信息均可以，我內心知道，我修改的會是正確的。可是在強制仲裁場景下則發生變化，例如，發生50/50腦裂，我須要強制啓動其中一方提供服務，我但願羣集接下來由被我強制啓動的站點提供服務，可是在之前舊版本的狀況下，即使是強制啓動了一方，若是沒作阻止仲裁的操做，另一方也會嘗試啓動羣集，若是另外方修改了羣集數據，則我強制啓動的也會被他覆蓋掉。所以，羣集數據庫引入了一種黃金副本的機制，當節點發生受權恢復操做 或 forcequorum強制仲裁操做後，即提高該節點羣集數據庫副本爲黃金副本，paxos優先級爲最高，其它節點必須與黃金副本羣集數據庫節點同步，同步後的節點能夠正常提供服務。

   關於強制仲裁的概念老王后面會再次進行介紹，此處單表羣集數據庫與強制仲裁關係，能夠看到，自WSFC 2008開始引入了這種黃金副本機制，經過這種機制，能夠幫咱們在一個災難恢復強制仲裁的場景，明確的告訴羣集，當前應該以哪一個站點數據爲準，其它節點在未與黃金副本同步前，沒法提供服務，或者說不該該對外提供服務。

  接下來咱們再看羣集仲裁的概念，簡單來講，仲裁是一種維護羣集可用性的協定，根據咱們選擇的仲裁模型，來規定羣集能夠接受的最少工做節點，其中仲裁模型使用投票機制，正常狀況下每一個節點各有一票，羣集見證會有一票，仲裁根據票數來判斷是否符合仲裁模型協定，若是票數違反了仲裁模型能夠接受的工做節點，則認定羣集當前失去維護可用性資格，關閉羣集。

  仲裁在羣集中起到兩個用途

  1.跟蹤羣集當前運做票數是否符合仲裁模型協定，若是低於最低工做節點，則決定關閉羣集

  2.當發生分區時，維持確保多數節點一方獲勝，所以咱們須要始終確保羣集爲奇數票數，當發生分區時，始終由多數一方負責接管羣集提供服務，少數票數方將關閉

那麼怎麼確保羣集投票數始終是奇數呢，一方面咱們能夠利用羣集現有的技術，一方面是架構設計人員的設計理念要準確，若是是偶數節點，那麼你就必定要設計成磁盤見證或共享見證或雲見證，不然就會出現腦裂各自爲政的狀況

所謂腦裂便是說在一種50/50分區場景下，羣集沒法作出決策，到底應由哪一方獲勝提供服務，所以會發生兩端都覺得本身獲勝，搶奪資源，致使羣集不正常工做，沒法對外提供服務，所以羣集引入了見證機制，磁盤見證，文件共享見證，雲見證，均可以解決此問題。引入見證後，羣集投票仍是以羣集票數爲主，但又加入見證票數一票，當發生這種50/50分區時，那個分區能夠訪問到見證設備，則那個分區能夠得到見證票數，最終接管羣集服務，以此來確保多數獲勝原則。

隨着仲裁模型的演變，到WSFC 2012時，羣集再也不主要強調運做過程必須遵循仲裁模型協定，更多的是強調維持羣集應用的連續性，2012引入了動態仲裁的機制，能夠動態調整節點票數，在多數節點仲裁模型的狀況下，羣集有百分之六十六的概率能夠堅持到最後一個節點，偶數節點加見證磁盤，見證磁盤在線的狀況下能夠存活至最後一個節點，奇數節點加見證磁盤，至多存活到兩個節點。2012R2引入了動態見證的機制，能夠動態調整見證票數，所以，在2012R2開始，不論奇數節點或是偶數節點，都始終建議爲羣集配置一個見證，2012R2在見證設備在線的狀況下，能夠確保羣集真正存活至最後一個節點

那麼什麼是強制仲裁呢

簡單來講，強制仲裁，是爲了在腦裂場景或不符合羣集仲裁協定的場景下，依然想要強制啓動其中一方羣集提供服務

強制仲裁主要應用場景

1. 災難恢復：例如主站點兩個節點，備站點一個節點，主站點所有崩潰，備站點票數雖然不符合羣集仲裁協定，但依然強制啓動備站點提供服務

2. 腦裂分區：羣集發生50 50分區，羣集停擺，強制啓動其中一方提供服務
   

你們可能會常在微軟的視頻中聽到強制啓動一個站點，不少朋友能夠能會納悶，怎麼強制啓動站點，是要在該站點上面每一個節點都運行一下強制啓動的命令嗎

其實不用，強制仲裁這條命令，咱們只須要在備站點其中一個節點上面運行便可，執行以後便可啓動羣集，其它同站點內或不一樣站點，都會感知到這裏存在強制仲裁

隨着技術的演變，強制仲裁的應用場景如今已經很少

例如，2012開始引入動態仲裁，若是羣集當前四個節點，動態仲裁會自動去掉一個節點的票數，當發生分區時，2節點票數一方獲勝，2012R2開始能夠經過LowerQuorumPriorityNodeID命令指定每次要去掉那個節點的票數。

除非羣集動態仲裁被誤配置中止，四個節點沒有自動去掉一個節點票數，致使發生腦裂分區，羣集停擺，這時須要經過強制啓動

還有一種少有人提起的場景，即2012R2，見證失效場景，當羣集剩下3節點加動態見證，見證設備若是失效，羣集將在壞掉一個節點後關閉，這時須要強制啓動羣集

除此以外，事實上2012R2以後 強制仲裁主要只是爲了處理災難恢復場景下，強制啓動少數站點節點使用

那麼強制仲裁後會對羣集形成哪些影響呢

事實上強制仲裁這個功能很是單純，若是羣集停擺，你須要強制啓動羣集提供服務，在想要的一方運行這條命令就好，執行強制仲裁後，背後將發生兩個操做

1.強制啓動該節點羣集服務，進而啓動羣集

2.提高該節點羣集數據庫paxos爲黃金副本

啓動以後，其它未通過強制仲裁的節點，要想加入羣集，必需要和強制啓動的黃金副本羣集節點同步羣集數據庫

此操做稱爲阻止仲裁，在2012R2以前，若是在少數節點方執行了強制仲裁，則當故障主站點恢復後，您須要儘快在故障主站點手動執行阻止仲裁命令，告訴主站點，當前羣集環境存在強制仲裁節點，你須要和他同步羣集數據庫後上線，不然主站點也將嘗試造成羣集，容易發生羣集數據庫覆蓋操做，當時微軟還建議主站點恢復後，一臺一臺啓動同步。

2012R2開始，引入強制仲裁彈姓，羣集具備內置的邏輯來跟蹤強制啓動分區，其它分區檢測到強制啓動分區後，會自動執行阻止仲裁操做，直到與其同步完成羣集數據庫後再行上線。

強制啓動自己來說，它不懂羣集上層的應用，因此只要應用沒有額外設定，強制啓動後不會有額外的宕機時間，例如，當前三節點羣集，兩節點北京，一節點天津，北京站點宕機，強制啓動添加天津站點，啓動後應用能夠在天津站點聯機上線，北京站點恢復後，完成阻止仲裁後加入天津分區羣集，這時候事實上羣集是能夠正常工做的，全部節點paxos標記都已經同步爲最新，理論上來講黃金副本效應已經消除，又能夠多主更新，老王認爲這時羣集已經恢復了正常運做，若是您仍是擔憂黃金副本效應沒有消失，能夠把應用從天津站點在線移動至北京站點，而後針對於天津站點節點以正常啓動的方式再次啓動一次羣集服務。因此理論上，只要上層應用不須要執行強制仲裁後的操做，不會由於強制仲裁而產生後來額外的宕機時間。

老王所知道的，對於SQL AG，須要在強制仲裁執行後執行數據庫跟蹤操做

SQL AG強制啓動後處理操做

https://technet.microsoft.com/en-us/library/hh213151(v=sql.110).aspx

https://blogs.msdn.microsoft.com/alwaysonpro/2014/03/04/manual-failover-of-availability-group-to-disaster-recovery-site-in-multi-site-cluster/

根據老王的經驗在使用強制仲裁過程當中，還有兩點須要額外注意的地方

1.2012R2場景下強制仲裁啓動了備用站點，主站點恢復後，羣集服務沒法啓動加入到羣集，即沒有執行阻止仲裁過程，其緣由多是阻止仲裁過程當中主節點與強制仲裁備節點網絡抖動不穩，致使同步羣集數據庫失敗，或者主站點與備站點機器配置更新補丁不一樣，實際場景中災難恢復後，應確保網絡穩定，全部站點節點系統更新配置一致後再行加入羣集，若是仍是不行，則請嘗試手動在主節點執行手動阻止仲裁操做，再觀察cluster log日誌。

2.正確理解與使用強制仲裁，在2008R2羣集運做過程當中，仲裁會盡量讓羣集維持一種多數節點存活的模型，我這樣說的意思是，當一個羣集主站點有3節點，分站點有2節點，羣集使用多數節點仲裁模型，當主站點宕機時，即使分站點剩下四個節點又能力承擔羣集應用，仲裁也會脫機分站點兩個節點，讓羣集對外脫機，中止工做，並阻止以正常方式啓動分站點節點，這時候咱們就使用強制仲裁，強制啓動分站點兩個節點提供服務，雖然分站點當前節點少，不符合羣集最少票數，可是有兩個節點能對外提供服務，總比都宕機強，強制仲裁主要就是用於處理這種，不符合羣集仲裁票數容許的最低票數狀況下，仍然要讓羣集啓動對外提供服務的場景，或者說是在腦裂場景，決出一方對外服務

可是在一個WSFC運做過程當中，節點羣集服務的宕機，也可能會是因爲系統配置，驅動，第三方軟件而致使羣集服務的沒法啓動，這種狀況下就並不適用於強制仲裁，強制仲裁主要用於處理仲裁致使的羣集沒法正常啓動的狀況，在其它場景下利用反而會有反作用，舉個例子，例如當前羣集有五個節點，主站點四個，分站點一個，羣集爲自動故障轉移，羣集目前由主站點對外提供應用服務，可是分站點羣集服務忽然沒法啓動，這時候，若是你強制啓動了分站點，那麼好了，假設你真的重啓成功了，分站點的羣集數據庫將徹底蓋過主站點，假設分站點沒有和總站點同步最新的羣集數據庫，便是說分站點落後主站點配置，例如落後了10個paxos標記版本，那麼強制仲裁後將會由落後的分站點羣集數據庫副本，蓋過主站點羣集數據庫副本，由於強制仲裁後會提高羣集數據庫黃金副本，嚴重一點將會致使主站點的羣集配置回退失效，所以，在出現羣集服務沒法啓動時，必定先要經過事件日誌，cluster log， dump日誌確認問題後再執行修復操做。

總結一下，強制仲裁自己並不會形成羣集宕機，它只是一個處理仲裁致使的羣集沒法正常啓動的操做，強制啓動羣集節點爲UP狀態，主要用於腦裂和災難場景

可能會帶來的影響

1.上層依附於羣集的應用，可能會須要執行強制啓動後的額外操做，和應用機制有關。

2.強制仲裁後，其它節點須要有阻止仲裁過程才能啓動加入羣集，其它節點若是想要加入強制仲裁分區，請確保再次加入時系統配置一致，網絡穩定。

3.不要盲目的使用強制仲裁，僅用於羣集沒法啓動仲裁協定不足場景，盲目使用將會致使羣集數據庫錯誤覆蓋影響

最後再來談一個災難恢復場景下的強制仲裁操做

以SQL Always on FCI爲例，按照微軟官網的建議是，正常狀況下，因此主副本節點，給予正常投票資格，去掉輔助副本節點投票資格

投票資格，便是說各節點參與到羣集仲裁的資格，能夠在節點正常的狀況下，去掉該節點的投票，被去掉投票的節點也能夠承載羣集應用，可是一旦主站點宕機，除非手動強制啓動分站點，不然分站點全部無投票節點將沒法聯機，羣集也將脫機

自WSFC 2012開始，羣集開始支持GUI調整各節點投票資格

手動調整各節點投票資格比較主流的場景是災難恢復時避免自動故障轉移帶來的額外宕機時間，由於SQL 故障轉移時間較長，若是是跨站點就更長了，咱們但願每次故障轉移都是可控的，這時就能夠將羣集控制爲手動故障轉移模型

具體控制方法，將全部備站點投票資格均改成0，這樣當主站點發生災難後，應用不會自動故障轉移至備站點，由於備站點投票資格爲0，因此備站點失去造成羣集的資格，所以這時候的操做應該是手動強制啓動備節點，而後賦予投票資格，聯機上線羣集應用，並將主站點投票資格設置爲0，當主站點恢復後，再設置投票資格爲1，而後手動移動羣集資源過去

參考連接 

https://blogs.msdn.microsoft.com/alwaysonpro/2014/03/04/manual-failover-of-availability-group-to-disaster-recovery-site-in-multi-site-cluster/

https://technet.microsoft.com/en-us/library/mt607084(v=office.16).aspx

https://msdn.microsoft.com/en-us/library/jj191711.aspx

這樣手動控制以後，雖然故障轉移時須要管理員手動操做，但能夠避免出現腦裂場景，由於沒有資格，因此50/50分區時，分站點根本沒有資格造成羣集

也能夠避免因爲網絡質量不穩定的問題，不會由於檢測信號而致使的故障轉移帶來的宕機時間

本文思惟導圖