WSFC動態仲裁容易被忽略的兩點

   能夠看到老王在仲裁這個部分，花了三個篇幅去講，老王認爲是值得的，由於在老王看來管理WSFC羣集無非是架構設計要設計好，而後平常維護羣集的可用，執行羣集細部管理，細部日誌分析，更新遷移等等，其中維護羣集持續可用是咱們在管理羣集中最多見到的，而羣集到底可不可用，和仲裁，見證，投票這些是有直接關係的

   不少時候可能若是你不清楚仲裁是怎麼回事，羣集停了你也不知道是怎麼回事，所以老王多花了一些篇幅來仔細把仲裁技術刨開來說，力圖讓你們理解透徹，又花了兩個篇幅以場景的形式把2012動態仲裁技術和羣集其它仲裁技術結合，重如今一些場景下的操做，相信認真看過的朋友都會有收穫

   那麼看過的朋友可能都會以爲，動態仲裁是一項好技術啊，幫助咱們自動調整投票，確保羣集能夠站立到最後一個節點，絕大部分人也都會說，2012開始有了動態仲裁，羣集就必定能夠支持到最後一個節點，必定嗎？實際上是不必定的，咱們仍須要冷靜的看待，通過老王的研究，發現這裏有兩種場景下，動態仲裁是不會支持到最後一個節點的

   第一種場景，老王在動態仲裁第一篇中也有所提到，並附了圖片說明，假設當前羣集還剩下兩個節點運行，無見證磁盤，採用多數節點仲裁，啓用動態仲裁，默認動態仲裁隨機挑選一個節點去掉投票

這時就分爲如下三種狀況

狀況1.若是非投票節點斷電，羣集能夠正常運行

狀況2.投票節點操做系統正常關機，票數能夠正常交換，羣集能夠正常運行

狀況3.投票節點斷電，羣集不能運行，票數來不及交換，須要強制仲裁啓動

一旦趕上了狀況3，事實上老王感受狀況會很常見，一旦這時候節點1被選中有投票，節點2沒投票，突然節點1斷電，節點2由於沒有交換過來節點投票，也會下線，整個羣集關閉，這時候只有強制啓動才能夠

所以在這種多數節點，無見證磁盤的狀況下，羣集到底能不能挺到最後一個節點，是有必定概率的，百分之66左右的概率你趕上狀況1和狀況2，羣集正常運行，若是趕上狀況3，則失去了站立至最後一個節點的效果，仍須要使用強制仲裁

 

微軟確定也發現了這個問題，因而微軟在2012R2開始，在動態仲裁技術裏面也把動態見證的技術加了進去，即見證在的狀況下，咱們始終能夠根據節點變化，動態調整見證的投票，來確保羣集始終是奇數，這時候不管是什麼狀況，即便像是上面說的狀況3，剩下兩個節點，其中一個節點突然斷電，但只要另一個節點能夠和見證聯繫，羣集就依然能夠站立到最後一個節點。

這樣提及來也沒錯，見證若是始終在的話，羣集確實能夠支持到最後一個節點，可是若是結合實際環境去考慮，萬一咱們使用了共享見證或者磁盤見證，就須要也保證它們的可用性，若是突然見證聯繫不上了會發生什麼呢，個人羣集是否還能夠支撐到最後一個節點

根據老王的實際測試發現了一個很容易被忽視的問題

我經過實際的測試來爲你們呈現出來

時間節點1：羣集四個節點 + 共享見證 所有存活，共計五票

時間節點2 宕機一個節點，動態見證自動去掉一票，共計三票

時間節點3 再宕機一個節點 動態見證自動加上一票，共計三票

這時發生一個網絡故障，共享見證也沒法鏈接，咱們直接取消共享見證的共享狀態

這時若是在存活的兩個節點上面運行查看投票數命令，能夠看到，依然仍是2個節點+1個見證投票

儘管這時日誌中已經報錯說共享見證資源沒法訪問，此時兩個節點的事件管理器都會被文件共享失敗的日誌塞爆

時間節點4 剩餘兩個節點宕機一個

能夠看到這時整個羣集都已經關閉

這時只有強制仲裁啓動羣集節點

強制啓動羣集以後，節點1和節點2正常通訊上線，能夠看到如今羣集仍是被文件共享沒法聯機的日誌淹沒，咱們能夠嘗試把羣集仲裁模式配置爲無見證即多數節點模式進行緩解

嘗試配置多數節點會出現失敗，提示咱們如今羣集沒法造成仲裁

這時只有再有一個節點加入時，能夠正常造成多數仲裁，才能夠配置爲多數節點仲裁模型

這時當第三個節點再次宕機，羣集會動態仲裁選擇兩節點的其中一票，確保羣集始終是奇數投票，以前共享見證失效致使的問題已經解決，這時候兩個節點在不使用強制仲裁就有百分之66左右的概率能夠堅持到最後一個節點。

    咱們能夠看到，這裏的關鍵在於時間節點三，3節點變成2節點，以後共享見證忽然失效，在一個理想的狀況下這時應該羣集動態仲裁會感應到共享見證失效，而後從新調整羣集投票數，隨機選擇一票存活

   然而實際狀況是當共享見證突然失效時，羣集仲裁併無感應到，而後作動態仲裁調整，查看命令會發現仍是2個節點票+1個見證票，其實這時候共享見證已經不在了，查看日誌能夠看到共享見證已經失敗

    但羣集並無去掉見證的投票，也沒有動態調整至1票，所以這時若是再宕機一個節點羣集將關閉，老王猜測這裏的關鍵在於共享見證失效時，狀態是「失敗」所致使的，羣集沒有去掉該見證的投票，也沒有動態調整節點投票。這就很危險，在這種不正常工做的狀況下，再壞一個節點就要強制啓動羣集

    所以老王在想會不會是動態仲裁偏袒磁盤見證，不重視共享見證呢？難道共享見證除了時間分區還有這個問題嗎？因而很快老王又嘗試了磁盤見證

時間節點3 ：磁盤見證狀況下 羣集還剩下三個節點存活，這時宕機一個節點，緊接着羣集磁盤也禁用

這時雖然見證磁盤已經禁用，可是羣集並不會馬上感知到，可見狀態仍是聯機

通過一段時間後狀態會變成聯機掛起，仲裁磁盤會根據故障策略逐個嘗試在各個節點掛起，但這是見證票數和節點票數依然沒有動態調整

最終見證磁盤變成失敗狀態，可是依然沒有調整見證投票數和節點投票數

所以能夠看出，當見證磁盤突然發生故障沒法訪問的時候，這時候開始羣集的動態仲裁就已經非正常工做，不論見證磁盤變成聯機掛起或是失敗，只要壞掉其中一個節點，通過一會羣集必定會斷定當前55沒法造成仲裁而關閉羣集

最後一個節點嘗試造成羣集，但過數秒後失敗，由於沒有不能進行仲裁操做，不存在多數一方投票

所以你們能夠看出，不管是共享見證仍是磁盤見證都面臨這個問題

即在從3節點剩到2節點時，羣集見證突然失聯，羣集將不會動態調整投票，這時1個節點再宕機時，羣集會關閉，須要手動強制仲裁，並應切換爲多數節點仲裁模式，防止再次發生

共享見證失聯後，在這種狀況下會直接在日誌中不斷寫入共享見證失敗，但動態仲裁一直不會調整見證和節點的投票

磁盤見證則是會根據磁盤策略，先嚐試聯機掛起，以後狀態失敗，但動態仲裁一樣在羣集磁盤失聯後，始終不會動態調整見證和節點的投票

除非磁盤見證狀態會變成脫機，在一個理想的狀況下，磁盤見證失效會是脫機狀態，而後釋放出投票，羣集感知到見證票數失去，動態再調整一個節點的票數，如今羣集是奇數一票

但根據老王的觀察，在3剩2，磁盤見證再突然失效的狀況下，磁盤見證的狀態會始終是失敗的，並不會變成脫機

若是磁盤見證的狀況使脫機的，老王嘗試，發現只有在磁盤處於正常狀態時候，能夠手動將狀態改成脫機，在磁盤見證正常脫機的狀況下，會按照我咱們預想的去掉見證的投票，再隨機去掉一個節點的投票

所以當發生這種見證突然失聯的場景時，共享見證和磁盤見證所面臨的問題是一致的，並不存在偏袒關係，老王感受這應該是動態仲裁檢測機制的一個bug，當見證突然失聯時候，能夠置爲失敗狀態，可是應該能夠動態去掉失敗狀態見證的票數，從新動態調整節點投票，不該該由於一個見證的失聯而致使整個動態仲裁接下來的都非正常的工做。

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

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

   
   

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