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，當見證忽然失聯時候，可以置為失敗狀態，但是應該可以動態去掉失敗狀態見證的票數，重新動態調整節點投票，不應該因為一個見證的失聯而導致整個動態仲裁接下來的都非正常的工作。
所以，在使用動態仲裁的時候需要考慮到以下兩點可能會遇見但容易被忽略的問題
純粹使用多數節點，動態仲裁調整節點數，當剩下2節點時，有百分之66左右的幾率群集可以正常存活至最後一個節點，當被選中投票節點忽然斷電宕機，則群集關閉，需要手動強制啟動群集。
使用見證加節點投票數，動態仲裁+動態見證，當3剩2場景下，見證忽然失聯，見證並不會去掉自身的一票，動態仲裁也並不會自動調整至1票，如果再宕機一個節點，群集將關閉，這時需要手動強制啟動一個節點，當其它兩個節點恢復時，可以手動切換至多數節點仲裁模型，這樣當再次出現3剩2場景下，會自動調整至1票，自動堅持至百分之66左右幾率存活到最後一個節點場景，然後由於我們是強制啟動的群集，因此即便當見證以後再恢復，強制啟動的群集數據庫也會蓋過見證磁盤的數據庫。
本文出自 “老王的微軟技術研究樂園” 博客，請務必保留此出處http://wzde2012.blog.51cto.com/6474289/1953438
WSFC動態仲裁容易被忽略的兩點