WSFC动态仲裁容易被忽略的两点

   能够看到老王在仲裁这个部分，花了三个篇幅去讲，老王认为是值得的，由于在老王看来管理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，当见证突然失联时候，能够置为失败状态，可是应该能够动态去掉失败状态见证的票数，从新动态调整节点投票，不该该由于一个见证的失联而致使整个动态仲裁接下来的都非正常的工做。

因此，在使用动态仲裁的时候须要考虑到如下两点可能会碰见但容易被忽略的问题

1. 纯粹使用多数节点，动态仲裁调整节点数，当剩下2节点时，有百分之66左右的概率群集能够正常存活至最后一个节点，当被选中投票节点突然断电宕机，则群集关闭，须要手动强制启动群集。

   
   

2. 使用见证加节点投票数，动态仲裁+动态见证，当3剩2场景下，见证突然失联，见证并不会去掉自身的一票，动态仲裁也并不会自动调整至1票，若是再宕机一个节点，群集将关闭，这时须要手动强制启动一个节点，当其它两个节点恢复时，能够手动切换至多数节点仲裁模型，这样当再次出现3剩2场景下，会自动调整至1票，自动坚持至百分之66左右概率存活到最后一个节点场景，而后因为咱们是强制启动的群集，所以即使当见证之后再恢复，强制启动的群集数据库也会盖过见证磁盘的数据库。