WSFC 強制仲裁影響讨論

     強制仲裁是WSFC群集管理中一個常用操作，到底什麼情況下應該執行強制仲裁，強制仲裁之後是否會對群集造成影響，本篇文章老王将與大家細緻讨論，為了便于了解，我會将強制仲裁涉及到的群集資料庫，仲裁概念進行簡單複習，以便大家更好的了解思考強制仲裁

     首先先來看下群集資料庫，很多朋友可能不知道這個概念，老王在前面有篇文章專門講解，故這裡隻做精要概述，簡單來說，群集資料庫，是微軟WSFC運作的配置資料庫，存在于每個節點系統資料庫，以及見證磁盤中。

     群集資料庫主要用途

群集各節點啟動時，檢測群集資料庫系統資料庫配置單元是否完整，如果完整才可以允許該節點正常啟動群集服務，如不完整需與其他節點同步完整後才可正常提供服務

群集運作過程中繼資料實時同步，以維護各節點群集資訊的一緻性，并作為故障轉移參照，WSFC正常運作過程時，會把群集節點狀态，群集狀态，群集角色狀态等配置資料，記錄在各節點系統資料庫，群集運作過程中，每個節點上修改了群集的資訊，都會把修改後的資料同步到各個節點，群集見證磁盤，同步時使用群集通信網絡，其中也會将各節點目前承載的群集角色同步，讓每個節點和見證磁盤，都知道對方上面承載了什麼服務，發生故障轉移時，其它節點會檢測系統資料庫單元，将當機節點原承載的群集角色進行挂載聯機。

     自WSFC 2008開始，群集資料庫開始引入paxos标記機制，每個群集節點本身都可以儲存群集資料庫最新副本，如果某個節點修改群集資料，則該節點paxos标記增加，随後各節點感應到有更新的paxos标記，會自動與其同步群集資料庫内容，確定paxos始終與最新标記保持一緻，當群集節點當機恢複後，會對比自身paxos标記與磁盤見證paxos标記，如果磁盤見證paxos标記更新，則與其同步後上線，如果磁盤見證檢測到群集節點有更新paxos标記的群集資料庫也會與其同步。

   那麼群集資料庫和強制仲裁有什麼關系呢？

   正常群集運作情況下，群集資料庫的複制同步應該是多主的，任何一個節點修改了資料，都可以和其它節點同步，即是說我在任何一個節點上面修改群集資訊都可以，我心裡知道，我修改的會是正确的。但是在強制仲裁場景下則發生變化，例如，發生50/50腦裂，我需要強制啟動其中一方提供服務，我希望群集接下來由被我強制啟動的站點提供服務，但是在以前舊版本的情況下，即便是強制啟動了一方，如果沒做阻止仲裁的操作，另外一方也會嘗試啟動群集，如果另外方修改了群集資料，則我強制啟動的也會被他覆寫掉。是以，群集資料庫引入了一種黃金副本的機制，當節點發生授權恢複操作 或 forcequorum強制仲裁操作後，即提升該節點群集資料庫副本為黃金副本，paxos優先級為最高，其它節點必須與黃金副本群集資料庫節點同步，同步後的節點可以正常提供服務。

   關于強制仲裁的概念老王後面會再次進行介紹，此處單表群集資料庫與強制仲裁關系，可以看到，自WSFC 2008開始引入了這種黃金副本機制，通過這種機制，可以幫我們在一個災難恢複強制仲裁的場景，明确的告訴群集，目前應該以哪個站點資料為準，其它節點在未與黃金副本同步前，無法提供服務，或者說不應該對外提供服務。

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

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

  1.跟蹤群集目前運作票數是否符合仲裁模型協定，如果低于最低工作節點，則決定關閉群集

  2.當發生分區時，維持確定多數節點一方獲勝，是以我們需要始終確定群集為奇數票數，當發生分區時，始終由多數一方負責接管群集提供服務，少數票數方将關閉

那麼怎麼確定群集投票數始終是奇數呢，一方面我們可以利用群集現有的技術，一方面是架構設計人員的設計理念要準确，如果是偶數節點，那麼你就一定要設計成磁盤見證或共享見證或雲見證，否則就會出現腦裂各自為政的情況

所謂腦裂即是說在一種50/50分區場景下，群集無法做出決策，到底應由哪一方獲勝提供服務，是以會發生兩端都以為自己獲勝，搶奪資源，導緻群集不正常工作，無法對外提供服務，是以群集引入了見證機制，磁盤見證，檔案共享見證，雲見證，都可以解決此問題。引入見證後，群集投票還是以群集票數為主，但又加入見證票數一票，當發生這種50/50分區時，那個分區可以通路到見證裝置，則那個分區可以獲得見證票數，最終接管群集服務，以此來確定多數獲勝原則。

那麼什麼是強制仲裁呢

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

強制仲裁主要應用場景

災難恢複：例如主站點兩個節點，備站點一個節點，主站點全部崩潰，備站點票數雖然不符合群集仲裁協定，但依然強制啟動備站點提供服務

腦裂分區：群集發生50 50分區，群集停擺，強制啟動其中一方提供服務

大家可能會常在微軟的視訊中聽到強制啟動一個站點，很多朋友可以能會納悶，怎麼強制啟動站點，是要在該站點上面每個節點都運作一下強制啟動的指令嗎

其實不用，強制仲裁這條指令，我們隻需要在備站點其中一個節點上面運作即可，執行之後即可啟動群集，其它同站點内或不同站點，都會感覺到這裡存在強制仲裁

随着技術的演變，強制仲裁的應用場景現在已經不多

例如，2012開始引入動态仲裁，如果群集目前四個節點，動态仲裁會自動去掉一個節點的票數，當發生分區時，2節點票數一方獲勝，2012R2開始可以通過LowerQuorumPriorityNodeID指令指定每次要去掉那個節點的票數。

除非群集動态仲裁被誤配置停止，四個節點沒有自動去掉一個節點票數，導緻發生腦裂分區，群集停擺，這時需要通過強制啟動

還有一種少有人提起的場景，即2012R2，見證失效場景，當群集剩下3節點加動态見證，見證裝置如果失效，群集将在壞掉一個節點後關閉，這時需要強制啟動群集

除此之外，事實上2012R2之後 強制仲裁主要隻是為了處理災難恢複場景下，強制啟動少數站點節點使用

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

事實上強制仲裁這個功能非常單純，如果群集停擺，你需要強制啟動群集提供服務，在想要的一方運作這條指令就好，執行強制仲裁後，背後将發生兩個操作

1.強制啟動該節點群集服務，進而啟動群集

2.提升該節點群集資料庫paxos為黃金副本

啟動之後，其它未經過強制仲裁的節點，要想加入群集，必須要和強制啟動的黃金副本群集節點同步群集資料庫

此操作稱為阻止仲裁，在2012R2之前，如果在少數節點方執行了強制仲裁，則當故障主站點恢複後，您需要盡快在故障主站點手動執行阻止仲裁指令，告訴主站點，目前群集環境存在強制仲裁節點，你需要和他同步群集資料庫後上線，否則主站點也将嘗試形成群集，容易發生群集資料庫覆寫操作，當時微軟還建議主站點恢複後，一台一台啟動同步。

2012R2開始，引入強制仲裁彈姓，群集具有内置的邏輯來跟蹤強制啟動分區，其它分區檢測到強制啟動分區後，會自動執行阻止仲裁操作，直到與其同步完成群集資料庫後再行上線。

強制啟動本身來講，它不懂群集上層的應用，是以隻要應用沒有額外設定，強制啟動後不會有額外的當機時間，例如，目前三節點群集，兩節點北京，一節點天津，北京站點當機，強制啟動添加天津站點，啟動後應用可以在天津站點聯機上線，北京站點恢複後，完成阻止仲裁後加入天津分區群集，這時候事實上群集是可以正常工作的，所有節點paxos标記都已經同步為最新，理論上來說黃金副本效應已經消除，又可以多主更新，老王認為這時群集已經恢複了正常運作，如果您還是擔心黃金副本效應沒有消失，可以把應用從天津站點線上移動至北京站點，然後針對于天津站點節點以正常啟動的方式再次啟動一次群集服務。是以理論上，隻要上層應用不需要執行強制仲裁後的操作，不會因為強制仲裁而産生後來額外的當機時間。

老王所知道的，對于SQL AG，需要在強制仲裁執行後執行資料庫跟蹤操作

SQL AG強制啟動後處理操作

<a href="https://technet.microsoft.com/en-us/library/hh213151(v=sql.110).aspx">https://technet.microsoft.com/en-us/library/hh213151(v=sql.110).aspx</a>

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

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

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，然後手動移動群集資源過去

參考連結 

<a href="https://blogs.msdn.microsoft.com/alwaysonpro/2014/03/04/manual-failover-of-availability-group-to-disaster-recovery-site-in-multi-site-cluster/" target="_blank">https://blogs.msdn.microsoft.com/alwaysonpro/2014/03/04/manual-failover-of-availability-group-to-disaster-recovery-site-in-multi-site-cluster/</a>

<a href="https://technet.microsoft.com/en-us/library/mt607084(v=office.16).aspx" target="_blank">https://technet.microsoft.com/en-us/library/mt607084(v=office.16).aspx</a>

<a href="https://msdn.microsoft.com/en-us/library/jj191711.aspx" target="_blank">https://msdn.microsoft.com/en-us/library/jj191711.aspx</a>

這樣手動控制之後，雖然故障轉移時需要管理者手動操作，但可以避免出現腦裂場景，因為沒有資格，是以50/50分區時，分站點根本沒有資格形成群集

也可以避免由于網絡品質不穩定的問題，不會因為檢測信号而導緻的故障轉移帶來的當機時間

本文思維導圖

本文轉自 老收藏家 51CTO部落格，原文連結:http://blog.51cto.com/wzde2012/2087748