可以看到老王在仲裁这个部分，花了三个篇幅去讲，老王认为是值得的，因为在老王看来管理WSFC群集无非是架构设计要设计好，然后日常维护群集的可用，执行群集细部管理，细部日志分析，更新迁移等等，其中维护群集持续可用是我们在管理群集中最常见到的，而群集到底可不可用，和仲裁，见证，投票这些是有直接关系的
很多时候可能如果你不清楚仲裁是怎么回事，群集停了你也不知道是怎么回事，因此老王多花了一些篇幅来仔细把仲裁技术刨开来讲，力图让大家理解透彻，又花了两个篇幅以场景的形式把2012动态仲裁技术和群集其它仲裁技术结合，重现在一些场景下的操作，相信认真看过的朋友都会有收获
那么看过的朋友可能都会觉得，动态仲裁是一项好技术啊，帮助我们自动调整投票，确保群集可以站立到最后一个节点，绝大部分人也都会说，2012开始有了动态仲裁，群集就一定可以支持到最后一个节点，一定吗？其实是不一定的，我们仍需要冷静的看待，经过老王的研究，发现这里有两种场景下，动态仲裁是不会支持到最后一个节点的
第一种场景，老王在动态仲裁第一篇中也有所提到，并附了图片说明，假设当前群集还剩下两个节点运行，无见证磁盘，采用多数节点仲裁，启用动态仲裁，默认动态仲裁随机挑选一个节点去掉投票
这时就分为以下三种情况
情况1.如果非投票节点断电，群集可以正常运行
情况2.投票节点操作系统正常关机，票数可以正常交换，群集可以正常运行
情况3.投票节点断电，群集不能运行，票数来不及交换，需要强制仲裁启动
一旦遇上了情况3，事实上老王感觉情况会很常见，一旦这时候节点1被选中有投票，节点2没投票，忽然节点1断电，节点2因为没有交换过来节点投票，也会下线，整个群集关闭，这时候只有强制启动才可以
因此在这种多数节点，无见证磁盘的情况下，群集到底能不能挺到最后一个节点，是有一定几率的，百分之66左右的几率你遇上情况1和情况2，群集正常运行，如果遇上情况3，则失去了站立至最后一个节点的效果，仍需要使用强制仲裁
微软肯定也发现了这个问题，于是微软在2012R2开始，在动态仲裁技术里面也把动态见证的技术加了进去，即见证在的情况下，我们始终可以根据节点变化，动态调整见证的投票，来确保群集始终是奇数，这时候不论是什么情况，即使像是上面说的情况3，剩下两个节点，其中一个节点忽然断电，但只要另外一个节点可以和见证联系，群集就依然可以站立到最后一个节点。
这样说起来也没错，见证如果始终在的话，群集确实可以支持到最后一个节点，但是如果结合实际环境去考虑，万一我们使用了共享见证或者磁盘见证，就需要也保证它们的可用性，如果忽然见证联系不上了会发生什么呢，我的群集是否还可以支撑到最后一个节点
根据老王的实际测试发现了一个很容易被忽视的问题
我通过实际的测试来为大家呈现出来
时间节点1：群集四个节点 + 共享见证 全部存活，共计五票
时间节点2 宕机一个节点，动态见证自动去掉一票，共计三票
时间节点3 再宕机一个节点 动态见证自动加上一票，共计三票
这时发生一个网络故障，共享见证也无法连接，我们直接取消共享见证的共享状态
这时如果在存活的两个节点上面运行查看投票数命令，可以看到，依然还是2个节点+1个见证投票
尽管这时日志中已经报错说共享见证资源无法访问，此时两个节点的事件管理器都会被文件共享失败的日志塞爆
时间节点4 剩余两个节点宕机一个
可以看到这时整个群集都已经关闭
这时只有强制仲裁启动群集节点
强制启动群集之后，节点1和节点2正常通信上线，可以看到现在群集还是被文件共享无法联机的日志淹没，我们可以尝试把群集仲裁模式配置为无见证即多数节点模式进行缓解
尝试配置多数节点会出现失败，提示我们现在群集无法形成仲裁
这时只有再有一个节点加入时，可以正常形成多数仲裁，才可以配置为多数节点仲裁模型
这时当第三个节点再次宕机，群集会动态仲裁选择两节点的其中一票，确保群集始终是奇数投票，之前共享见证失效导致的问题已经解决，这时候两个节点在不使用强制仲裁就有百分之66左右的几率可以坚持到最后一个节点。
我们可以看到，这里的关键在于时间节点三，3节点变成2节点，之后共享见证突然失效，在一个理想的情况下这时应该群集动态仲裁会感应到共享见证失效，然后重新调整群集投票数，随机选择一票存活
然而实际情况是当共享见证忽然失效时，群集仲裁并没有感应到，然后做动态仲裁调整，查看命令会发现还是2个节点票+1个见证票，其实这时候共享见证已经不在了，查看日志可以看到共享见证已经失败
但群集并没有去掉见证的投票，也没有动态调整至1票，因此这时如果再宕机一个节点群集将关闭，老王猜想这里的关键在于共享见证失效时，状态是“失败”所导致的，群集没有去掉该见证的投票，也没有动态调整节点投票。这就很危险，在这种不正常工作的情况下，再坏一个节点就要强制启动群集
因此老王在想会不会是动态仲裁偏袒磁盘见证，不重视共享见证呢？难道共享见证除了时间分区还有这个问题吗？于是很快老王又尝试了磁盘见证
时间节点3 ：磁盘见证情况下 群集还剩下三个节点存活，这时宕机一个节点，紧接着群集磁盘也禁用
这时虽然见证磁盘已经禁用，但是群集并不会立刻感知到，可见状态还是联机
经过一段时间后状态会变成联机挂起，仲裁磁盘会根据故障策略逐个尝试在各个节点挂起，但这是见证票数和节点票数依然没有动态调整
最终见证磁盘变成失败状态，但是依然没有调整见证投票数和节点投票数
因此可以看出，当见证磁盘忽然发生故障无法访问的时候，这时候开始群集的动态仲裁就已经非正常工作，不论见证磁盘变成联机挂起或是失败，只要坏掉其中一个节点，经过一会群集一定会判定当前55无法形成仲裁而关闭群集
最后一个节点尝试形成群集，但过数秒后失败，因为没有不能进行仲裁操作，不存在多数一方投票
因此大家可以看出，不论是共享见证还是磁盘见证都面临这个问题
即在从3节点剩到2节点时，群集见证忽然失联，群集将不会动态调整投票，这时1个节点再宕机时，群集会关闭，需要手动强制仲裁，并应切换为多数节点仲裁模式，防止再次发生
共享见证失联后，在这种情况下会直接在日志中不断写入共享见证失败，但动态仲裁一直不会调整见证和节点的投票
磁盘见证则是会根据磁盘策略，先尝试联机挂起，之后状态失败，但动态仲裁同样在群集磁盘失联后，始终不会动态调整见证和节点的投票
除非磁盘见证状态会变成脱机，在一个理想的情况下，磁盘见证失效会是脱机状态，然后释放出投票，群集感知到见证票数失去，动态再调整一个节点的票数，现在群集是奇数一票
但根据老王的观察，在3剩2，磁盘见证再忽然失效的情况下，磁盘见证的状态会始终是失败的，并不会变成脱机
如果磁盘见证的情况使脱机的，老王尝试，发现只有在磁盘处于正常状态时候，可以手动将状态改为脱机，在磁盘见证正常脱机的情况下，会按照我我们预想的去掉见证的投票，再随机去掉一个节点的投票
因此当发生这种见证忽然失联的场景时，共享见证和磁盘见证所面临的问题是一致的，并不存在偏袒关系，老王感觉这应该是动态仲裁检测机制的一个bug，当见证忽然失联时候，可以置为失败状态，但是应该可以动态去掉失败状态见证的票数，重新动态调整节点投票，不应该因为一个见证的失联而导致整个动态仲裁接下来的都非正常的工作。
所以，在使用动态仲裁的时候需要考虑到以下两点可能会遇见但容易被忽略的问题
- 纯粹使用多数节点，动态仲裁调整节点数，当剩下2节点时，有百分之66左右的几率群集可以正常存活至最后一个节点，当被选中投票节点忽然断电宕机，则群集关闭，需要手动强制启动群集。
- 使用见证加节点投票数，动态仲裁+动态见证，当3剩2场景下，见证忽然失联，见证并不会去掉自身的一票，动态仲裁也并不会自动调整至1票，如果再宕机一个节点，群集将关闭，这时需要手动强制启动一个节点，当其它两个节点恢复时，可以手动切换至多数节点仲裁模型，这样当再次出现3剩2场景下，会自动调整至1票，自动坚持至百分之66左右几率存活到最后一个节点场景，然后由于我们是强制启动的群集，因此即便当见证以后再恢复，强制启动的群集数据库也会盖过见证磁盘的数据库。