本篇文章主要介绍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/