WSFC動態(tài)仲裁容易被忽略的兩點

   可以看到老王在仲裁這個部分，花了三個篇幅去講，老王認為是值得的，因為在老王看來管理WSFC群集無非是架構設計要設計好，然后日常維護群集的可用，執(zhí)行群集細部管理，細部日志分析，更新遷移等等，其中維護群集持續(xù)可用是我們在管理群集中最常見到的，而群集到底可不可用，和仲裁，見證，投票這些是有直接關系的

   很多時候可能如果你不清楚仲裁是怎么回事，群集停了你也不知道是怎么回事，因此老王多花了一些篇幅來仔細把仲裁技術刨開來講，力圖讓大家理解透徹，又花了兩個篇幅以場景的形式把2012動態(tài)仲裁技術和群集其它仲裁技術結合，重現在一些場景下的操作，相信認真看過的朋友都會有收獲

   那么看過的朋友可能都會覺得，動態(tài)仲裁是一項好技術啊，幫助我們自動調整投票，確保群集可以站立到最后一個節(jié)點，絕大部分人也都會說，2012開始有了動態(tài)仲裁，群集就一定可以支持到最后一個節(jié)點，一定嗎？其實是不一定的，我們仍需要冷靜的看待，經過老王的研究，發(fā)現這里有兩種場景下，動態(tài)仲裁是不會支持到最后一個節(jié)點的

   第一種場景，老王在動態(tài)仲裁第一篇中也有所提到，并附了圖片說明，假設當前群集還剩下兩個節(jié)點運行，無見證磁盤，采用多數節(jié)點仲裁，啟用動態(tài)仲裁，默認動態(tài)仲裁隨機挑選一個節(jié)點去掉投票

這時就分為以下三種情況

情況1.如果非投票節(jié)點斷電，群集可以正常運行

情況2.投票節(jié)點操作系統(tǒng)正常關機，票數可以正常交換，群集可以正常運行

情況3.投票節(jié)點斷電，群集不能運行，票數來不及交換，需要強制仲裁啟動

一旦遇上了情況3，事實上老王感覺情況會很常見，一旦這時候節(jié)點1被選中有投票，節(jié)點2沒投票，忽然節(jié)點1斷電，節(jié)點2因為沒有交換過來節(jié)點投票，也會下線，整個群集關閉，這時候只有強制啟動才可以

因此在這種多數節(jié)點，無見證磁盤的情況下，群集到底能不能挺到最后一個節(jié)點，是有一定幾率的，百分之66左右的幾率你遇上情況1和情況2，群集正常運行，如果遇上情況3，則失去了站立至最后一個節(jié)點的效果，仍需要使用強制仲裁

微軟肯定也發(fā)現了這個問題，于是微軟在2012R2開始，在動態(tài)仲裁技術里面也把動態(tài)見證的技術加了進去，即見證在的情況下，我們始終可以根據節(jié)點變化，動態(tài)調整見證的投票，來確保群集始終是奇數，這時候不論是什么情況，即使像是上面說的情況3，剩下兩個節(jié)點，其中一個節(jié)點忽然斷電，但只要另外一個節(jié)點可以和見證聯系，群集就依然可以站立到最后一個節(jié)點。

這樣說起來也沒錯，見證如果始終在的話，群集確實可以支持到最后一個節(jié)點，但是如果結合實際環(huán)境去考慮，萬一我們使用了共享見證或者磁盤見證，就需要也保證它們的可用性，如果忽然見證聯系不上了會發(fā)生什么呢，我的群集是否還可以支撐到最后一個節(jié)點

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

我通過實際的測試來為大家呈現出來

時間節(jié)點1：群集四個節(jié)點 + 共享見證 全部存活，共計五票

時間節(jié)點2 宕機一個節(jié)點，動態(tài)見證自動去掉一票，共計三票

時間節(jié)點3 再宕機一個節(jié)點 動態(tài)見證自動加上一票，共計三票

這時發(fā)生一個網絡故障，共享見證也無法連接，我們直接取消共享見證的共享狀態(tài)

這時如果在存活的兩個節(jié)點上面運行查看投票數命令，可以看到，依然還是2個節(jié)點+1個見證投票

盡管這時日志中已經報錯說共享見證資源無法訪問，此時兩個節(jié)點的事件管理器都會被文件共享失敗的日志塞爆

時間節(jié)點4 剩余兩個節(jié)點宕機一個

可以看到這時整個群集都已經關閉

這時只有強制仲裁啟動群集節(jié)點

強制啟動群集之后，節(jié)點1和節(jié)點2正常通信上線，可以看到現在群集還是被文件共享無法聯機的日志淹沒，我們可以嘗試把群集仲裁模式配置為無見證即多數節(jié)點模式進行緩解

嘗試配置多數節(jié)點會出現失敗，提示我們現在群集無法形成仲裁

這時只有再有一個節(jié)點加入時，可以正常形成多數仲裁，才可以配置為多數節(jié)點仲裁模型

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

    我們可以看到，這里的關鍵在于時間節(jié)點三，3節(jié)點變成2節(jié)點，之后共享見證突然失效，在一個理想的情況下這時應該群集動態(tài)仲裁會感應到共享見證失效，然后重新調整群集投票數，隨機選擇一票存活

   然而實際情況是當共享見證忽然失效時，群集仲裁并沒有感應到，然后做動態(tài)仲裁調整，查看命令會發(fā)現還是2個節(jié)點票+1個見證票，其實這時候共享見證已經不在了，查看日志可以看到共享見證已經失敗

    但群集并沒有去掉見證的投票，也沒有動態(tài)調整至1票，因此這時如果再宕機一個節(jié)點群集將關閉，老王猜想這里的關鍵在于共享見證失效時，狀態(tài)是“失敗”所導致的，群集沒有去掉該見證的投票，也沒有動態(tài)調整節(jié)點投票。這就很危險，在這種不正常工作的情況下，再壞一個節(jié)點就要強制啟動群集

    因此老王在想會不會是動態(tài)仲裁偏袒磁盤見證，不重視共享見證呢？難道共享見證除了時間分區(qū)還有這個問題嗎？于是很快老王又嘗試了磁盤見證

時間節(jié)點3 ：磁盤見證情況下 群集還剩下三個節(jié)點存活，這時宕機一個節(jié)點，緊接著群集磁盤也禁用

這時雖然見證磁盤已經禁用，但是群集并不會立刻感知到，可見狀態(tài)還是聯機

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

最終見證磁盤變成失敗狀態(tài)，但是依然沒有調整見證投票數和節(jié)點投票數

因此可以看出，當見證磁盤忽然發(fā)生故障無法訪問的時候，這時候開始群集的動態(tài)仲裁就已經非正常工作，不論見證磁盤變成聯機掛起或是失敗，只要壞掉其中一個節(jié)點，經過一會群集一定會判定當前55無法形成仲裁而關閉群集

最后一個節(jié)點嘗試形成群集，但過數秒后失敗，因為沒有不能進行仲裁操作，不存在多數一方投票

因此大家可以看出，不論是共享見證還是磁盤見證都面臨這個問題

即在從3節(jié)點剩到2節(jié)點時，群集見證忽然失聯，群集將不會動態(tài)調整投票，這時1個節(jié)點再宕機時，群集會關閉，需要手動強制仲裁，并應切換為多數節(jié)點仲裁模式，防止再次發(fā)生

共享見證失聯后，在這種情況下會直接在日志中不斷寫入共享見證失敗，但動態(tài)仲裁一直不會調整見證和節(jié)點的投票

磁盤見證則是會根據磁盤策略，先嘗試聯機掛起，之后狀態(tài)失敗，但動態(tài)仲裁同樣在群集磁盤失聯后，始終不會動態(tài)調整見證和節(jié)點的投票

除非磁盤見證狀態(tài)會變成脫機，在一個理想的情況下，磁盤見證失效會是脫機狀態(tài)，然后釋放出投票，群集感知到見證票數失去，動態(tài)再調整一個節(jié)點的票數，現在群集是奇數一票

但根據老王的觀察，在3剩2，磁盤見證再忽然失效的情況下，磁盤見證的狀態(tài)會始終是失敗的，并不會變成脫機

如果磁盤見證的情況使脫機的，老王嘗試，發(fā)現只有在磁盤處于正常狀態(tài)時候，可以手動將狀態(tài)改為脫機，在磁盤見證正常脫機的情況下，會按照我我們預想的去掉見證的投票，再隨機去掉一個節(jié)點的投票

因此當發(fā)生這種見證忽然失聯的場景時，共享見證和磁盤見證所面臨的問題是一致的，并不存在偏袒關系，老王感覺這應該是動態(tài)仲裁檢測機制的一個bug，當見證忽然失聯時候，可以置為失敗狀態(tài)，但是應該可以動態(tài)去掉失敗狀態(tài)見證的票數，重新動態(tài)調整節(jié)點投票，不應該因為一個見證的失聯而導致整個動態(tài)仲裁接下來的都非正常的工作。

所以，在使用動態(tài)仲裁的時候需要考慮到以下兩點可能會遇見但容易被忽略的問題

1. 純粹使用多數節(jié)點，動態(tài)仲裁調整節(jié)點數，當剩下2節(jié)點時，有百分之66左右的幾率群集可以正常存活至最后一個節(jié)點，當被選中投票節(jié)點忽然斷電宕機，則群集關閉，需要手動強制啟動群集。

   
   

2. 使用見證加節(jié)點投票數，動態(tài)仲裁+動態(tài)見證，當3剩2場景下，見證忽然失聯，見證并不會去掉自身的一票，動態(tài)仲裁也并不會自動調整至1票，如果再宕機一個節(jié)點，群集將關閉，這時需要手動強制啟動一個節(jié)點，當其它兩個節(jié)點恢復時，可以手動切換至多數節(jié)點仲裁模型，這樣當再次出現3剩2場景下，會自動調整至1票，自動堅持至百分之66左右?guī)茁蚀婊畹阶詈笠粋€節(jié)點場景，然后由于我們是強制啟動的群集，因此即便當見證以后再恢復，強制啟動的群集數據庫也會蓋過見證磁盤的數據庫。