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羣集的時候，不管是奇數節點或是偶數節點，都要始終爲羣集配置見證磁盤

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