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左右幾率存活到最后一個節點場景，然后由于我們是強制啟動的群集，因此即便當見證以后再恢復，強制啟動的群集數據庫也會蓋過見證磁盤的數據庫。