本篇文章主要介紹Windows2012的故障轉移叢集一個新功能“動態仲裁”，預設該功能是開啟的； 動態仲裁能在當前群集投票出現分歧的情況下取消某些節點的投票許可權，比如偶數個節點的群集環境。仲裁見證和動態仲裁有點相似也可以解決群集投票分歧的問題，但是它不能取消節點的投票權，它能保持群集的投票個數保持奇數個數。
SQLServer版本： SQL Server 2016 SP1
Windows版本：Windows Server 2012 DataCenter
群集節點：HD21DB03,HD21DB04,HD21DB05,HD21DB06
一、動態仲裁
當前群集是4個節點的偶數個群集，採用的是多數節點的仲裁投票方式。
1.全部節點正常
當前叢集WSFC26的動態仲裁是開啟的，見證動態投票當前是0；開啟動態仲裁後，由於當前是4個節點的偶數個節點預設把主節點的當前投票給取消了。
2.模擬1個節點故障
當一個節點故障後，動態仲裁把之前的DB03的投票給啟用了，還是保證了有3個節點的投票。
3.模擬2個節點故障
當2個節點故障後，動態仲裁把剩下的DB04節點的投票也取消了，由於當前是2個節點所以只能保證一個節點有投票權，否則會出現投票分歧的情況。
4.模擬3個節點故障
當把3個節點故障後，叢集還是保證正常，同時AlwaysOn也是正常的。
注意：第三個故障節點不能是當前有投票權的節點DB05，否則群集就無法保持正常了，因為當前只有DB05有投票權。
AlwaysOn也正常
二、仲裁見證
再看一下當同時啟用動態仲裁和見證仲裁的情景。
1.全部節點
當前4個節點都有投票，而且見證動態投票也變成了1，當前群集就有5個投票。
2.模擬1個節點故障
當有一個節點故障後，這時見證動態投票也變成了0，保證了當前奇數個投票。當前有3個投票。所以當兩個節點故障後見證動態投票會變成了1
3.模擬2個節點故障
模擬兩個節點故障後，見證動態投票變成 了1，當前還是保證了3個投票。而且這時DB04、DB05都可以故障，不影響整個叢集，而且如果這個兩個節點都是同步提交的話AlwaysOn也能正常切換。比沒有加入見證的動態仲裁叢集存活機率更大。
4.模擬3個節點故障
注意：這裡DB05已經故障了，但是它的當前投票還是為1，而且見證投票也是1，總投票數還是3，可能是個bug；最後的投票數應該只有DB04有且見證投票也應該為0總投票數應該為1。當時整個叢集還是正常的。
這裡故意把DB05節點故障測試AlwaysOn群集轉移情況，事實證明只要群集正常轉移也是沒問題，前提節點得是同步提交支援自動故障轉移。
注意：最後保證只有一個節點群集也正常也是動態仲裁的作用，否則當前群集只能執行2個節點故障。見證投票只是增加了群集的投票機率。
三、關閉動態仲裁
接下來看4個節點且關閉了檔案共享見證的場景。
1.全部節點正常
2.模擬1個節點故障
當前群集和AlwaysOn都正常
3.模擬2個節點故障
整個群叢集集故障無法訪問。
注意：不要存在這種誤區以為偶數個節點就無法投票選舉，如果4個節點都正常或者兩兩處於不同的資料庫中心的情況下有可能會導致投票無法選舉成功。但是當某個節點故障剩下的3個節點還是能選出一個新的主節點，因為剩下的節點可以滿足節點多數。
四、命令
1.檢視動態仲裁和見證投票
Get-Cluster | ft name,DynamicQuorum,WitnessDynamicWeight
2.開啟關閉動態仲裁
--關閉 (Get-Cluster).DynamicQuorum=0 --開啟 (Get-Cluster).DynamicQuorum=1
備註：在其中一個群集節點上執行即可
五、總結
動態仲裁功能可以大大的提高了群集的存活機率，是一個非常有用的功能。反而見證的效果就變的沒那麼重要的，當然對於如果伺服器緊張的情景見證還是可以充當節點投票來使用。以前的大多數節點的投票機制是在整個叢集節點的基礎上，現在引入了動態仲裁後是以每一次群集仲裁正常後為基礎進行仲裁。
參考：http://www.tech-coffee.net/understand-failover-cluster-quorum/
|
備註： 作者：pursuer.chen 部落格：http://www.cnblogs.com/chenmh 本站點所有隨筆都是原創，歡迎大家轉載；但轉載時必須註明文章來源，且在文章開頭明顯處給明連結，否則保留追究責任的權利。 《歡迎交流討論》 |