在上一篇中老王以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群集的时候，不论是奇数节点或是偶数节点，都要始终为群集配置见证磁盘
下篇文章中，我们还将继续介绍动态仲裁，模拟一个多站点四节点的动态仲裁场景