WSFC動態仲裁及投票調整2

  OK~ WSFC 2012 R2 年度盛宴開始~ 在本文中，老王將用一系列的場景，把動態仲裁，動態見證，票數調整，LowerQuorumPriorityNodeID，阻止仲裁等羣集仲裁技術串起來，完成一個又一個複雜的場景，本篇文章可能並不太適合對於WSFC不瞭解的朋友，適合對於WSFC羣集仲裁技術及2012動態仲裁技術有必定初步瞭解的朋友，若是您還不瞭解WSFC，建議您去先看下老王寫過的博客，或者其它地方相關的資料，若是您對於WSFC仲裁，動態仲裁技術已經有了初步的瞭解，相信跟着老王這篇文章中的場景會幫助您更加深刻的理解羣集投票，動態仲裁等知識，話很少說，咱們如今就開始，跟着老王上車吧，過山車開了~滴

 

 開始以前先介紹環境，爲了準備此次的博客，老王一共開了七臺虛擬機，主要是爲了重現一些真實的分區場景，以前在2008R2的時候，咱們用了六臺服務器，兩邊各兩個節點，一臺域控+ISCSI，一臺路由服務器，可是隻有一側有域控，另一側沒有域控，所以發生分區時，沒有域控的一方是沒辦法上線聯機搶奪羣集的，雖然效果是同樣的，最終兩端出現分區，羣集都沒法使用，咱們強制選擇其中一方啓動，在此次的環境裏面老王特意用了七臺服務器，兩端都有域控，均可以造成羣集的一個場景

  環境介紹

  北京站點

   HV01

   MGMET：80.0.0.2  GW：80.0.0.254 DNS：80.0.0.1 100.0.0.20 

   ISCSI：90.0.0.2

   CLUS：70.0.0.2

   HV02

   MGMET：80.0.0.3  GW：80.0.0.254 DNS：80.0.0.1 100.0.0.20

   ISCSI：90.0.0.3

   CLUS：70.0.0.3

   BJDC&ISCSI

   Lan：80.0.0.1 GW：80.0.0.254

   ISCSI：90.0.0.1

  佛山站點

   HV03

   MGMET：100.0.0.4  GW：100.0.0.254 DNS：100.0.0.20 80.0.0.1

   ISCSI：90.0.0.4

   CLUS：70.0.0.4

   HV04

   MGMET：100.0.0.5  GW：100.0.0.254 DNS：100.0.0.20 80.0.0.1

   ISCSI：90.0.0.5

   CLUS：70.0.0.5

   FSDC

   Lan：100.0.0.20 GW：100.0.0.254

 Router 

   

    03Route

    Beijing:80.0.0.254

    Fuosha:100.0.0.254

 

   首先咱們先來看一道開胃小菜，在這個場景中咱們將模擬，一個四個節點的跨站點羣集，在見證磁盤始終在線的狀況下節點逐個宕機的場景，如下是老王已經組建起來的一個多站點羣集，其中的羣集名稱和羣集IP，可能在後面的圖會變，由於實驗過程當中老王拆了又建了幾回羣集，不過其餘架構都按照規劃好的不會改變。

能夠看到咱們在羣集中跑了一個DTC應用，當前DTC應用綁定了兩個IP地址，它們之間是OR關係

  

   在多站點羣集的設計規劃中有不少須要考慮的地方，例如存儲複製，網絡檢測，加密處理，AD的同步，DNS的緩存等都會影響到多站點的故障轉移時間，後續會單獨寫博客來詳細講，這裏簡單講兩個影響客戶端直接訪問的地方

   默認狀況下在多站點羣集中，例如咱們的DTC應用當前在北京站點運行，它的聯機地址會是80.0.0.89，當它轉移到佛山站點，聯機地址會是100.0.0.89，可是這時候，客戶端能不能訪問DTC服務呢，不必定

    設想一下，北京和佛山站點作了AD多站點，它們的DNS會相互同步，當DTC在北京站點時它是80.0.0.89，通過一段時間它同步到了佛山站點，佛山的DNS也知道了DTC是80.0.0.89這個地址，那麼當北京站點宕機，轉移到佛山站點了，雖然這時候DTC應用已經聯機，可是當客戶端訪問DTC，會返回80.0.0.89這個地址，並不會返回100.0.0.89的可用地址，這也致使了停機時間的延遲

    緣由是由DNS的緩存機制致使，默認狀況下羣集應用聯機後註冊的主機記錄都是會有1200秒的TTL，便是說，客戶端若是請求了這個VCO的主機記錄，1200秒之內，不會再從新請求了，會使用緩存中的地址

    2008時代WSFC新增了用於多站點的HostRecordTTL屬性，使咱們能夠設置VCO記錄註冊到DNS時的TTL，TTL生命週期如今能夠進行縮短，微軟建議縮短爲300秒，即五分鐘以後從新請求DNS新的地址

    打開佛山站點的客戶端，輸入ipconfig /display能夠看到被緩存的VCO記錄和生存時間(TTL)

    

   另一個2008時代新增用於多站點的屬性則是RegisterAllProvidersIP，正常狀況下，咱們的VCO即便你設計了多個地址，它們默認會是OR的關係，即始終只註冊一個羣集IP地址，當前在北京站點就是80網段的地址，當聯機到佛山站點，則會有CNO替VCO去註冊更新成100網段的地址，同一時間VCO默認只有一個站點的地址在線，經過RegisterAllProvidersIP屬性咱們可讓CNO去幫咱們註冊全部的VCO地址，可是這就要求羣集應用支持地址重試

   一個完美的場景應該是羣集應用默認鏈接到80網段的地址，當80網段不可用，自動重試鏈接到100網段聯機使用，由於全部地址都已經註冊至DNS，因此能夠減小因爲DNS緩存致使的停機時間，在羣集應用支持自動重試的話，可使用這個屬性 ，SQL Server 2012開始支持在鏈接字符串加入MultiSubnetFailover=True參數和RegisterAllProvidersIP配合使用，當鏈接其中一個地址不通，會自動鏈接另一個

 

這裏咱們遵循微軟的建議，配置DTC應用的HostRecordTTL爲300

設置方法以下

#獲取羣集應用資源名稱 

Get-ClusterResource | Select Name, ResourceType

#獲取羣集應用資源屬性

Get-ClusterResource "devtestdtc" | Get-ClusterParameter

#修改HostRecordTTL屬性，脫機再聯機能夠看到設置已經生效

Get-ClusterResource "devtestdtc" | Set-ClusterParameter HostRecordTTL 300

輔菜說完，下面來看咱們的正菜，能夠看到目前咱們是四個節點的羣集，見證磁盤能夠正常參與投票

#查看節點投票數

Get-ClusterNode | ft ID, NodeName, NodeWeight, DynamicWeight, State -AutoSize

#查看見證投票數

(Get-Cluster).WitnessDynamicWeight 

這兩個命令後面咱們會常常用到

當前羣集DTC正常運行在HV01

咱們直接將HV01進行斷電操做，能夠看到羣集應用自動轉移至HV02，HV01已下線因此去掉了它的投票，同時因爲如今是4票，因此自動去掉了見證磁盤的一票，始終保證投票數爲奇數。

直接將HV02也斷電，咱們完全失去了北京站點，能夠看到如今又自動加上了見證磁盤的一票，如今羣集仍是三票，我直接強制DNS服務器更新，而後在客戶端ipconfig /flushdns了，此時再嘗試聯devtestdtc則會返回100網段的地址，若是不清除DNS緩存，能夠等300秒時間到了，再次請求自動更新至100網段

DTC當前在HV03上面運行，咱們再把HV03也斷電，如今羣集只剩下HV04，能夠看到如今羣集會顯示三票，但其實已經不重要了，由於咱們只剩下一個節點，他能夠和見證磁盤聯繫，所以能夠存活至最後。

以上是咱們的第一道小菜，怎麼樣，還算簡單開胃把，能夠看出在見證磁盤在狀況下，羣集節點逐步宕機，WSFC2012R2會始終動態的調整羣集投票，確保羣集投票始終是奇數，即始終一方能夠存活，最後能夠只剩下一個節點和見證存活。

接下來咱們來模擬第二個場景，北京站點和佛山站點的管理網絡失去聯繫，即80網絡和100網絡不通，咱們直接關掉路由服務器，爲了防止其中一方聯繫到見證磁盤獲勝，咱們也模擬見證磁盤失去聯繫

這時候咱們能夠看到，羣集檢測到見證磁盤失效，已經自動調整三個節點投票數爲奇數

另外能夠看到咱們把管理網絡斷開了，羣集依然能夠正常工做，爲何呢，由於羣集內置的網絡拓撲生成器會實時自動生成調整全網檢測的拓撲，管理網絡既能夠對外訪問也能夠作心跳檢測，心跳網絡只能夠作心跳檢測，所以只要不影響羣集節點之間心跳檢測，是不會有任何反應的。

 

羣集並不會知道你的管理網絡故障，由於在北京站點管理網絡能夠正常訪問，在佛山站點管理網絡也能夠正常訪問，羣集就覺得它是好的，心跳檢測還有其它卡能夠進行嘛

  假設如今這家公司的員工都從佛山出差來北京辦公，即全部的用戶都要在北京80網段的客戶端訪問，可是若是這時候羣集DTC突然漂移佛山去了，雖然它在佛山也能夠正常工做，可是北京站點的用戶都訪問不到那邊，由於咱們知道佛山站點100網段已經和外界失去聯繫

   默認若是不作調整羣集應用，DTC是應用是隨機漂移的，不必定會漂到那個節點去，可能看那個節點內存多，它就過去哪裏了，一旦漂到佛山站點的服務器就慘了

   這時咱們能夠經過如下手段進行控制，首先設置DTC的習慣節點爲HV01，HV02，這樣若是當前DTC託管在北京，當它發生故障轉移的時候，會優先考慮轉移到HV01或HV02

   可是僅僅設置首選全部者仍是不夠的，由於設置首選全部者，只是在沒有發生分區的狀況下會有用，當發生了一個網絡分區，HV01 HV02沒辦法與HV03 HV04聯繫，這時因爲HV01沒有投票數，而HV03 HV04一方有投票數，因此應用仍是會轉移到佛山站點運行

   應對這種場景，咱們能夠完全去掉HV03，HV04站點的投票數，這樣作了以後，即使發生一個網絡分區，北京站點剩下一票，佛山站點兩票，但由於咱們去掉了佛山站點兩臺服務器的投票數，因此佛山站點會嘗試造成羣集，可是始終是沒辦法成功的，由於他們沒有合法的票數。

   便是說咱們經過手動去掉投票數，讓佛山的兩個節點永遠也沒辦法造成羣集，要否則就訪問北京的節點，北京的節點一旦沒法啓動，羣集應用就中止訪問或強制啓動。

#手動去掉羣集投票數

(Get-ClusterNode -Name hv03).NodeWeight = 0

(Get-ClusterNode -Name hv04).NodeWeight = 0

在2008和2008R2中能夠經過添加一個Hotfix來得到手動控制節點的投票的功能，2012及以後則WSFC自帶

   以上是手動調整羣集投票數的場景之一，即咱們知道一方的站點已經沒法對外提供訪問服務，須要讓該站點始終中止對外服務，直到網絡恢復再從新賦予投票數

   手動調整投票數老王認爲是頗有用處的一項技術，除了這種已知站點沒法對外提供的場景，在其它不少場景下也都有用武之地

   例如在一個徹底手動故障的場景，有北京，天津，河北三個站點，只有北京站點的節點有投票，手動取消了天津和河北的投票，由於當故障發生時，可能要舉行一個災難恢復會議，商討一下，當前由那個站點繼續承擔羣集更合適，例如商討天津站點當前更合適承擔羣集，手動賦予天津站點節點票數，節點檢測到當前有投票，因而天津站點啓動造成羣集，繼續對外提供服務

   或者還有一個場景，假設當前有北京站點，河北站點兩個站點，兩個節點各有兩個節點，當前羣集一共四個節點，我手動去掉了河北站點其中一個節點的投票，讓它始終不參與羣集投票，這時假設羣集發生了故障，北京站點和河北站點的三個節點都已經沒法啓動提供服務，咱們能夠強制啓動去掉投票的節點，從新賦予它票數，讓它繼續對外提供服務，或者北京站點宕機，強制仲裁後全部業務都跑到河北站點的一個節點運行，已經把機器的負載跑滿，這時候能夠把去掉投票的節點從新賦予投票，一塊兒承擔負載，這樣做爲一個災備節點來使用。

    接下來咱們假設當前羣集是動態仲裁，羣集見證磁盤先失效，繼而管理網絡也失效，心跳網絡也失效，出現一個分區時的場景

   針對網絡分區，咱們到時除了把路由服務器關了，也把HV03 HV04的心跳網卡直接改了個網絡

    針對見證磁盤失效，咱們仍是依舊採用直接ISCSI上面禁用磁盤的方式，能夠看到大概過了30秒左右，仲裁檢測到了見證磁盤已經處於非聯機狀態，因而自動去掉了它的票數，同時也隨機去掉了一個節點的票數，如今羣集變成了三票

仲裁磁盤會按照故障轉移策略，在各個節點嘗試聯機掛起

都嘗試失敗後會顯示爲失敗狀態，過一段時間會在嘗試聯機掛起，但始終不會成功

能夠看到如今因爲見證磁盤失敗，仲裁已經動態的調整了投票數，又隨機去掉了一個節點的投票數，如今羣集仍是奇數三個投票

  若是這時一個網絡分區發生，北京站點與佛山站點沒辦法心跳檢測，沒有網卡能夠用於檢測，這時候佛山的站點會獲勝，繼續對外提供服務，而北京站點則會關閉

  由於北京站點被選中去掉了一個投票，只有一票，而佛山站點有兩票，因此佛山站點能夠造成羣集，造成羣集後佛山站點又自動去了一票，如今佛山站點也是奇數投票數

  你們能夠看到，這裏的核心在於，羣集選擇去掉那個站點的投票，被去掉投票的站點，當發生投票時會被關閉，默認狀況下羣集會根據各個節點的狀態變化，網絡監測狀況，不斷的去調整票數，每次都會隨機選擇去掉投票站點的節點是誰，這有點像是每次都要隨機抓一個倒黴蛋，反正都是抓，那麼咱們可不能夠控制每次固定抓一我的呢，答案是能夠的

  經過2012R2裏面新增的LowerQuorumPriorityNodeID屬性，咱們能夠控制在偶數節點下，讓動態仲裁始終去掉指定節點的投票，實現當發生50/50網絡分區時始終是咱們想要的站點獲勝，或者在兩個節點的狀況下，最終動態仲裁要隨機去掉一個節點的投票，咱們也能夠根據狀況事前指定，始終去掉指定節點的投票。

#查看當前LowerQuorum節點，默認是0，即每次發生變化時隨機調整

(Get-Cluster).LowerQuorumPriorityNodeID

 #獲取節點ID，手動設置每次偶數投票數時丟棄HV04節點投票，每次都確保北京站點獲勝

(Get-Cluster).LowerQuorumPriorityNodeID=3

當再次發生網絡分區時能夠看到，佛山站點關閉，北京站點存活下來，並自動調整爲奇數投票

羣集應用也始終正常運行着

以上爲老王給朋友們上來的第二道菜和第三道菜

    第二道菜咱們在一個已知站點故障的狀況下，手動取消了該站點的投票，阻止應用遷移到上面提供服務，這裏咱們是假設的一個沒有分區的場景，由於兩端仍是能夠經過心跳網卡互相作心跳檢測的，咱們在北京站點設置取消佛山站點的投票，佛山站點是能夠知道的，若是是心跳網卡也發生了故障，即兩邊沒辦法進行進行心跳檢測，這時候就要分狀況來看，若是分區以前咱們已經設置好了取消投票的站點，那麼很好，羣集會選擇沒被設置取消投票的站點啓動，若是已經出現分區以後，那麼只有強制啓動須要的少數站點，啓動以後再設置取消另外站點的投票，當另外站點上線時會以強制仲裁方爲主。

    第三道菜呢，默認狀況下在見證磁盤失效的動態仲裁場景中，當發生偶數投票節點的狀況下會動態隨機爲咱們去掉一個節點的票數，咱們能夠經過LowerQuorumPriorityNodeID屬性來手動降低一個站點，確保當中間網絡分區發生時，始終是本身想要的站點獲勝

   所以你們能夠看出，在動態仲裁存在的場景下，咱們幾乎不多會用到強制仲裁，由於咱們有不少新的技術能夠選擇，例如LowerQuorumPriorityNodeID，事前手動調整投票數，強制仲裁在一些場景下也或許有用，尤爲是2012R2以後，阻止仲裁技術發生了改變，多數節點一方檢測到少數節點一方存在仲裁會自動執行阻止仲裁操做，即確保認可強制仲裁一方爲羣集，與其羣集數據庫同步至最新後，纔會啓動自身羣集服務，在以前2008時代，若是遇到強制仲裁的場景下，大多數時間都須要手動去執行阻止仲裁，不然會出現羣集數據庫覆蓋等狀況，到了2012R2則會自動幫助咱們作這件事

   因此老王給你們的建議是，按照場景選擇合適的技術，能經過手動調整投票解決或者經過LowerQuorumPriorityNodeID解決就儘可能不用強制仲裁，2012R2以前使用強制仲裁須要考慮阻止仲裁問題，2012R2不須要考慮。

   實際上在動態仲裁啓動的狀況下，絕大部分場景動態仲裁都能幫助咱們保證羣集的可用性，始終讓羣集保持奇數投票，即使動態仲裁默認選擇的站點你不滿意，也能夠用LowerQuorumPriorityNodeID，票數調整，強制仲裁等技術切換到滿意的站點，像是之前50/50的腦裂分區場景，在動態仲裁的狀況下是很難見到了，所以若是想看到腦裂場景最好的辦法就是關閉動態仲裁

    在第四道菜中，咱們將模擬一個腦裂場景，北京佛山兩個站點，關閉動態仲裁的狀況下，禁用見證磁盤，兩端出現網絡分區時心跳網絡和管理網絡都已關閉，沒辦法進行站點間心跳檢測

     

#確認羣集動態仲裁狀態，默認爲1，修改成0

(Get-Cluster).DynamicQuorum = 0

緊接着咱們觸發網絡分區，修改HV03和HV04心跳網卡爲其它網段，而後暫停路由服務器，讓兩端管理網絡和心跳網絡都不能互相作站點間的心跳檢測，可是在各自站點內又均可以正常和AD通訊

這時打開各個節點上面能夠看到日誌，提示羣集網絡已分區

運行查看投票數節點命令，能夠看到當前全部節點，都在各自站點嘗試造成加入羣集

可是這種狀態僅維持不到20秒，再次運行命令就會看到羣集服務已經中止

在每一個節點的事件管理器均可以看到關於羣集服務中止的系統日誌

可見當出現腦裂分區時，羣集會出現短暫的爭奪階段，緊接着羣集仲裁會檢測到當前發生分區，以後會關閉全部羣集節點，老王並無看到網上說的發生仲裁時各個分區各自生成羣集，而後爭奪寫入羣集磁盤的場景，或許時間過短了沒有看到，或許是2012開始針對於腦裂分區作了優化，檢測到腦裂會自動關閉，不過老王實際看到的效果就是這樣，我感受這樣都關了也好，誰也別搶，讓管理員手動選擇

假設這時管理員斷定當前權威站點應該是北京站點，手動在HV01上面執行強制啓動命令

#強制啓動HV01

net stop clussvc

net start clussvc /FQ

HV01上面首先運行查看節點投票數命令，首先會看到HV01的投票，緊接着HV02因爲和HV01是一個分區內，檢測到這一方發生強制仲裁，他會優先融入進來，狀態會先是Joining，最終變成Up

實際上在這一步的時候，老王是但願看到一個東西的效果，什麼呢，就是阻止仲裁的效果，老王在10/90這種比例下，強制仲裁了10的一方以後，當剩下的90網絡聯機以後，能夠在日誌看到阻止仲裁的日誌，可是在50/50比例下，當各節點網絡恢復正常後，老王沒看到這個日誌

可是當老王嘗試用命令查看節點阻止仲裁狀態的時候卻能夠看到

#查看各阻止仲裁狀態 1表明節點目前須要阻止仲裁，0表明節點當前不須要阻止仲裁

(Get-ClusterNode -Name HV02).NeedsPreventQuorum

(Get-ClusterNode -Name HV03).NeedsPreventQuorum

(Get-ClusterNode -Name HV04).NeedsPreventQuorum

能夠看到節點2已經去掉了阻止仲裁的狀態，3和4節點仍須要阻止仲裁

什麼是阻止仲裁呢，在上面老王也提到過一點，阻止仲裁簡單來說，就是讓其它節點遵照強制仲裁分區的技術，咱們用強制仲裁以後，會把強制仲裁節點的paxos標記提至最高，即成爲羣集內最權威的存活節點，大家其它全部節點的羣集數據庫都要以個人爲準，阻止仲裁就是爲了配置強制仲裁的這個目標，當其它節點網絡連通後能夠和強制仲裁節點通訊，節點會檢測到當前環境內存在強制仲裁的節點，我應該以他爲首，我不該該造成羣集，即便我是多數節點的一方，而後羣集服務會暫時中止，直到能夠阻止仲裁節點的羣集數據庫徹底和強制仲裁一方同步一致以後，才能夠從新加入強制仲裁啓動節點造成的羣集分區

在2012R2以前，遇到阻止仲裁的場景，尤爲是10/90場景，你強制啓動了少數，是須要手動在其餘站點執行阻止仲裁的，2012R2開始支持這種檢測到強制仲裁，自動阻止仲裁。

能夠看到當佛山節點恢復和北京站點通訊後，通過一段時間，節點的阻止仲裁狀態也變成了0，而且正常上線加入了強制仲裁方造成的羣集分區

最後一道菜咱們來嘗試一個反轉性的場景，假設當前北京站點有1個節點，佛山站點有3個節點，佛山站點發生了網絡故障，雖然佛山內部三個節點能夠通訊，可是它們沒法對外提供服務，咱們須要強制反轉至北京節點提供服務，本場景見證磁盤禁用，羣集啓用動態仲裁

#從新啓用羣集動態仲裁

(Get-Cluster).DynamicQuorum = 1

修改HV02爲100.0.0.3，網關爲100.0.0.254，DNS設置爲100.0.0.20 80.0.0.1

#從新註冊網卡DNS記錄

ipconfig /registerdns

確保兩個站點的DNS上面都記錄了HV02的新地址

直接將HV02 HV03 HV04三個節點的羣集網卡都改到同一個網絡，而後暫停路由服務器

這時候在HV01上面運行查看羣集節點投票數的命令能夠看到羣集服務已中止

若是在HV03上面運行查看羣集投票的命令則能夠看到當前羣集已經在佛山站點順利造成，由於這邊佔據多的投票數，因此北京站點的羣集目前會被關閉

#使用命令強制仲裁啓動北京站點的羣集

net stop clussvc

net start clussvc /FQ

啓動完成後能夠看到，在北京站點如今能夠看到羣集節點投票狀態了，同時也提高了paxos標記，更新HV01的羣集數據庫爲最新

因爲HV02 HV03 HV04尚未和HV01聯網，沒辦法知道北京站點那邊發生了強制仲裁，因此還會嘗試造成羣集，在HV03上面查看羣集投票狀態，能夠看到仍是舊的記錄

這時咱們在北京站點上面須要作一件事，因爲如今北京站點和佛山站點依然均可以訪問存儲，因此當應用在北京站點聯機的時候，可能會出現失敗的狀況，由於佛山有三個節點也在和我搶羣集磁盤，因此當務之急是取消掉佛山站點的投票數，防止和北京站點搶佔資源

#手動取消佛山站點節點投票數

(Get-ClusterNode -Name hv02).NodeWeight = 0

(Get-ClusterNode -Name hv03).NodeWeight = 0

(Get-ClusterNode -Name hv04).NodeWeight = 0

須要注意的一點，這裏若是須要執行去掉節點投票的操做，必定要在強制仲裁方進行，由於一旦在多數節點方執行，當再次網絡通訊的時候也會被強制仲裁方的記錄蓋掉，不會生效。

以後咱們再次將羣集應用聯機，能夠看到這時候實際上HV01已經從佛山站點搶奪過來了羣集磁盤，佛山的三個站點再也沒辦法搶佔羣集資源，由於羣集磁盤已經在權威一方從新上線，如今羣集應用能夠始終在北京站點運行

當佛山三個站點網絡修復完成後，試圖加入北京站點的羣集分區時，能夠在日誌中看到阻止仲裁的日誌，目前節點狀態不會是UP，只有當佛山三個站點認可北京站點爲權威一方，而且羣集數據庫已經和北京站點同步一致後，才能夠正常加入羣集。

通過一段時間後，能夠看到佛山節點已經都完成阻止仲裁，正常加入羣集，最後咱們再從新爲佛山節點賦予投票，讓佛山節點能夠正常參加故障轉移，賦予投票後，羣集仲裁會檢測到當前恢復四個節點，又將根據動態仲裁機制自動選擇節點去掉一票，實現始終奇數投票。

以上爲老王經過實踐得出的一點經驗之談，寫這篇文章時老王的願景是經過不斷的實驗把動態仲裁，動態見證，票數調整，LowerQuorumPriorityNodeID，阻止仲裁這些技術反覆驗證實白，而後經過場景的形式儘量形象的講出來，告訴朋友們具體都是什麼樣的功能，應該如何使用，但願可以用更多的人知道2012R2羣集的這些技術，愈來愈多的人來真正的使用羣集，研究羣集，羣集毫不只是一根心跳線，一個存儲，把節點連起來就完了，裏面不少東西都值得咱們花心思去研究，用心去研究技術，天然會找到樂趣。