WSFC動態仲裁及投票調整1

    在上一篇中老王以2008R2WSFC為例，介紹了仲裁發生時的變化處理，到了2012時×××始，這發生了很大的變化，甚至我們要重新去思考仲裁

    2008及以前時代的仲裁比較死板，就好像你和群集說好了，3個節點的多數仲裁模型，我至少有兩個節點運行，那么一旦當你的群集剩下最后一個節點的時候，群集一定會是關閉的，因為08時代的群集主要強調的遵循仲裁模型，你與群集訂好的仲裁協議不可以被違反，即使你剩下的這個節點可以提供服務，但是群集也會把它關閉掉，除非你使用強制仲裁啟動群集，所以在08時代強制仲裁可以說是經常要用到

   到了2012時×××始，過去的仲裁模式已經發生了變化，不再那么死板，想象一下，就好比你與群集已經混熟了，你們達成了很好的智能化協議，群集不再強勢的要求你必須遵循仲裁協議，或者說，仲裁協議已經發生了改變，2012時×××始，仲裁主要以為了保持群集持續可用為主，不再強調群集必須遵循仲裁模型，而是主要為了保證群集可以生存下去。

  微軟在2012開始注入了動態投票的技術，2012開始，WSFC可以根據節點狀態變化動態調整投票，例如，當前是3個節點的群集，多數節點的仲裁模型，當壞掉一個節點時，正常情況下應該是兩票，在2008時代如果這時候再壞掉一個節點，群集就會關閉，因為沒有遵循仲裁模型，你違反協議了

   而2012則不會，2012會動態調整節點的投票數，確保群集投票數始終奇數，這樣可以在出現分區時，始終讓多數一方可用，當3個節點壞掉1個節點，2012群集會再拿掉一票，這樣只有群集里面只有一個節點有投票數，這時如果群集再壞掉一個節點，群集部分時間依然會是可用的，至于為什么我會說部分，后面會為大家解答，不過在一定的幾率下，是可以支撐到最后一個節點的。

  這相對來說就是種新的思維了，以前在08時代，如果出現了這種情況，群集是會關閉的，我們只有在最后那個節點上面強制啟動群集才可以，而2012則不用，因為會動態幫我們去調整投票數，到了2012R2時代則更加智能，可以動態調整見證的投票，實現真正的群集支持至最后一個節點

  理論的地方不再多說，因為很多人都說動態仲裁的概念看了很多，但是還是不理解到底什么效果，接下來我們就來實際的看看效果

 可以看到，老王現在在2012R2環境下面創建一個群集，3個節點，并沒有配置磁盤見證和共享見證

2016年我的好朋友張俊森配置群集時，問我，2012里面多數節點仲裁去哪了，應該怎么配置仲裁呢，有些不認得了，的確，在2012開始，群集仲裁的UI發生了變化

變成了下面這樣，微軟的良苦用心，老王是理解的，微軟知道，大家覺得仲裁的概念不好理解，不好設計，所以微軟設計了智能化的動態節點投票和動態見證，由群集來自動幫助大家確定最適合的仲裁模型，正常情況下我們選擇默認仲裁配置就可以，別的都不需要管了，如果群集檢測到當前有適合見證磁盤，會最優先選擇見證磁盤作為群集仲裁，其次才是多數節點

很多朋友可能會問，多數節點仲裁去哪了，其實在2012時×××始，多數節點仲裁已經變成了“無” ，或者說是 不配置仲裁見證，當我們在選擇仲裁界面下，選擇第二項 選擇仲裁見證，就可以看到下面的界面，即由我們手動去配置群集的見證，如果希望改為多數節點仲裁，選擇不配置仲裁見證即可，如果我們選擇默認的話，即讓群集自己去決定群集仲裁模型，那么群集檢測到沒有見證可用也會自動配置為多數節點模式。

如果我們在配置仲裁向導下選擇高級仲裁配置，除了能手動選擇群集仲裁模型，還可以在GUI界面手動選擇節點的投票數，可以在這里指定某些節點始終沒有票數，這在以前只能通過命令去執行，如果要設置群集仲裁模型為僅磁盤也需要在高級仲裁配置下選擇

以上先簡單為大家介紹下2012時×××始，新群集仲裁向導的變化，幫助大家先熟悉下基本的環境，可以看到，多數節點，磁盤見證，共享見證，僅磁盤，這幾個仲裁模型都還在，只不過是換了一下位置，其中僅磁盤的仲裁模式在2012時代已經不再被推薦使用，因為磁盤成為了單一故障點，也無法完整利用動態仲裁的優勢。

在2012R2開始，當我們創建一個多數節點的群集時，經常會看到類似下面的提示和警告

原因是2012R2開始，WSFC會希望你始終配置一個見證磁盤，以保證群集的最高可用性，因為2012時代的動態節點票數還是有一點風險，2012R2中不論你是奇數節點還是偶數節點，只要有見證磁盤在，就可以保證讓你的群集支撐到最后一個節點，例如3節點+見證磁盤，群集會自動去掉見證磁盤的一票，現在群集是三個投票，如果壞掉一個節點，群集是2個投票，群集會自動再加上見證的一票，現在群集又是三票，還是奇數，這時候如果再壞一個節點，還剩下最后一個節點和見證，群集依然可以存活

下面我們就來實際看下效果，首先先來看3節點多數仲裁的情況

現在我們3個節點都在同一個子網內，故意沒配置見證磁盤

2012R2直接可以在群集GUI界面看到節點的投票數，可以看到當前每個節點都要一票，且都正常工作著

我們依舊創建了一個群集DTC應用，現在托管在HV02節點上

直接斷電HV02，群集DTC自動轉移至HV01運行，可以看到這時群集已經利用了2012新增的動態投票技術，自動去掉了兩個節點中的一票，始終確保群集投票是奇數，之前在2008時代，如果3節點多數節點仲裁中，壞了一個節點，群集立刻開始提示了，不能再壞了，再壞一個節點，群集就關了，2012時×××始則沒有這個提示，因為群集不再主要看中仲裁模型是否遵守，而是始終維持群集可用。

這時我們再把HV01也斷電，現在群集只剩下HV03，可以看到群集DTC已經轉移至HV03上面正常提供服務！歡呼吧！我們在3節點多數仲裁模型下面現在也可以挺到最后一個節點了，這在一定程度上可以增加群集應用的可用性，之前我們需要強制啟動最后一個節點，現在不需要了，動態仲裁通過調整群集節點的投票數自動幫我們完成了，幫我們確保了群集的持續可用。

這時HV01 HV02逐步恢復，加入群集節點了，可以看到節點逐步再加入，群集也在動態的幫助我們去調整節點投票數，HV02加入進來，兩個節點的情況下群集隨機把投票給了節點2

節點1上線正在加入群集，群集又將動態調整投票數

節點1完全上線加入群集后，群集又恢復奇數三個投票

在整個過程中群集應用時持續可用的，停機時間只是群集應用群集組從各節點離線再上線的時間

到這里，看起來很美，群集自動幫助我們調整節點投票，在三個節點的情況下也可以挺到最后一臺，但其實這種多數節點動態調整節點投票數的方式也是有一點瑕疵的，上面老王說過三個節點的情況下，群集部分時間是可以挺到最后一個節點的，這里就來解釋下為什么是部分

我們假設這樣一個場景，假設現在群集3個節點，壞掉一個節點，還剩下兩個節點，到底WSFC2012R2里面兩個節點多數節點可不可以做群集，答案是可以，但是風險很高

在還剩下兩個節點的情況下，群集會隨機選擇一個節點，賦予一票，再去掉另外一個節點的投票

這時如果HV03斷電，OK，群集不care你，因為你又不是被選中的投票節點，你壞掉群集依然可以正常運作

這時候HV03恢復，HV02依然是被選中的投票節點，我們再嘗試把HV02操作系統正常關機

這時候可以看到，投票數節點被交換到了HV03上面，群集應用也正常運行著，這就好比是，節點2和節點3是同事關系，節點2和節點3說，我要下班了，剩下的活交給你來做吧，節點3說好的，節點3交換了工作后，節點2關機，節點3繼續完成剩下的工作。

最后一種情況，我們假設當前被選中承擔投票的節點忽然斷電

可以看到，由于當前HV02是投票節點，直接斷電，沒有與HV03進行投票交接，因此投票并沒有被交接到HV03

這時群集服務關閉，群集服務也沒辦法訪問，并沒有因為有動態仲裁而支撐群集到最后一個節點

這時只有通過強制啟動群集

因此，在多數節點仲裁，最后只剩下兩個節點的情況下，動態仲裁也要視情況來決定群集是否可以運行

情況1.非投票節點斷電，群集可以正常運行

情況2.投票節點操作系統正常關機，票數可以正常交換，群集可以正常運行

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

   由此大家可以看到，多數節點動態仲裁也只能說是在部分場景下可以存活到最后一個節點，只好祈禱遇到的都是情況1和情況2，但一旦遇到情況3，也只能強制啟動了。

   動態調整節點投票是2012上面的更新的技術，我們已經看到了它，不可否認，是一項好技術，大部分場景下可以幫助管理員智能解決一些問題，但也有它的缺點，即情況3

   到了2012R2時代，微軟在2012動態仲裁的基礎上又新增了動態見證，除了節點，見證也可以自動調整投票，只要有見證在，不論情況1 情況2 情況3，群集都可以正常啟動，可以說，只要有見證在，強制啟動幾乎不再需要了。

  接下來我們在看一個三節點+磁盤見證的場景，之前在08里面老王曾經為大家看過這個場景，可以說很雞肋，08里面3節點+磁盤見證，最多只能壞一個點，剩下兩個節點+磁盤見證，只要壞掉一個，群集就會關閉，在老王看來從計算可用性角度來講，并沒有用處，因為我只有節點可以計算，我要維護兩個計算節點的可用，還要維護一個見證磁盤的可用。

  在2012R2里面這種場景則發生了翻天覆地的變化

 我們新增群集磁盤1，該群集磁盤只有1GB，是所有群集磁盤中，大于512MB，最小的，因此群集如果挑選仲裁磁盤，會優先選擇群集磁盤1

 這里我們驗證一下群集使用默認仲裁配置，是否會總是為我們配置見證磁盤

可以看到，群集自動為我們選擇了群集磁盤1為見證磁盤，我們遵循了最佳實踐，可以看出，不論是奇數節點還是偶數節點，在2012R2中，群集都會建議你配置一個見證磁盤

當前群集DTC在HV03上面運行

直接斷電HV03，現在節點數是兩票，可以看到當前群集自動加上了見證的一票

這時HV01也斷電，我們可以看到這時HV01雖然已經斷電，但是并沒有調整它的票數，因為現在群集只剩下HV02節點和見證磁盤

群集DTC在HV02正常工作

當HV01和HV03節點修復完成，可以看到他們三個節點的投票已經恢復，見證磁盤的票數自動被去掉

  文章到這里，相信大家都對動態仲裁有了個概念，這是種新的思想，群集會自動去幫助我們調整節點和見證的票數，來保證群集的始終可用

  在多數節點的情況下，群集在部分場景都可以堅持到最后一個節點，在擁有磁盤見證的情況下，只要磁盤見證存活可以正常訪問，群集則一定可以堅持到最后一個節點，因此建議大家使用2012R2群集的時候，不論是奇數節點或是偶數節點，都要始終為群集配置見證磁盤

    下篇文章中，我們還將繼續介紹動態仲裁，模擬一個多站點四節點的動態仲裁場景