建设工作站服务器

王先生看了仲裁的这一部分，花了三个篇幅，王先生认为很有价值。 因为，在小王看来，管理WSFC集群只是体系结构的设计。 维护群集的日常可用性，并执行群集细节管理、细节日志分析、更新迁移等。 其中保持集群的可持续使用是我们管理集群最常见的，集群不可用与仲裁、投票直接相关

在很多情况下，仲裁怎么样了，即使集群停了，也可能不知道发生了什么。 为此，小王将仲裁技术切得很细致，试图让大家彻底了解。 同时，将2012年动态仲裁技术与集群其他仲裁技术以场景的形式相结合，再现了一些场景下的操作。 我想认真看过的朋友一定会得到的

那么，看过的朋友可能会认为动态仲裁是个好技术吧。 我们会自动调整投票，让集群可以站到最后一个节点。 大多数人也表示，如果从2012年开始有动态仲裁，集群可以支持到最后一个节点。 一定吗？ 其实也不一定。 我们需要冷静地看。 经过王先生的研究，我发现这里有两个场景。 动态仲裁不支持到最后一个节点

第一种情况下，王先生还提到了动态仲裁的第一篇，并附有图片说明，假设当前集群中还有两个节点，有无目击者的磁盘，采用多节点仲裁，启用动态仲裁，默认动态仲裁是随机的

在这种情况下，可以分为以下三种情况

情况1 .如果非投票节点断电，群集将正常运行

情况2 .投票节点操作系统正常关闭，票数正常交换，集群正常运行

情况3 .投票节点断电，集群无法运行，票数交换不及时，需要开始强制仲裁

遇到情况3，实际上小王觉得情况很常见。 此时，节点1已被选中并有投票，节点2未投票。 节点1的电源突然关闭，节点2未被更换，因此节点投票也将离线，整个群集将关闭。 这个时候必须强制启动

因此，在这样多个节点上，如果是没有目击者的磁盘，集群能否坚持到最后一个节点，概率是一定的。 约有66%的概率遇到情况1和情况2，集群运行正常。 如果遇到情况3，站到最后节点的效果就会丧失，需要使用强制仲裁

微软一定也发现了这个问题。 因此微软从2012R2开始，在动态调停技术中加入了动态目击技术。 也就是说，如果有目击，我们可以总是根据节点的变化动态调整目击投票，保证集群总是奇数。 此时，无论在什么情况下，如上面的情况3所示，如果剩下两个节点，其中一个节点突然停电，而另一个节点可以与证人联系，则集群将

这么说也没错。 如果始终有目击者，则群集可以支持到最后一个节点。 但是，结合实际环境考虑，万一使用了共享证人或磁盘证言，也需要保证它们的可用性。 如果突然有目击者联系不上了会怎么样呢？ 我的集群能支持到最后一个节点吗

通过对小王的实际测试，发现了一个容易被忽视的问题

我会通过实际测试展示给大家

时间节点1 :集群4个节点共享证人全部生存，共5票

时间节点2下降到1个节点，动态目击自动排除1票，共计3票

时间节点3在另一个节点的动态目击中自动加1票，共计3票

此时，发生了网络故障，共享证人也无法连接，直接解除了共享证人的共享状态

此时，如果在存活的2个节点上执行查看投票数的命令，则可知仍然在2个节点上进行1个证人投票

此时，日志中报告了无法访问共享见证资源的错误，但文件共享失败的日志会导致两个节点上的事件管理器爆胎

时间节点4的其余两个节点下移一个

您可以看到整个集群都已关闭

只有强制仲裁才能引导群集节点

强制引导群集后，节点1和节点2可以正常通信并联机，您可以看到群集当前正在填充无法通过文件共享联机的日志。 尝试将群集仲裁设置为无凭证方，即多个节点模式，以尝试缓解

尝试配置大多数节点将失败，表明群集无法形成仲裁

此时，只有在另一个节点参加的情况下，才能正常地形成多个仲裁，可以作为多个节点仲裁模型进行配置

如果第三个节点再次关闭，群集将动态仲裁并选择这两个节点中的一个节点，以确保群集始终为奇数投票。 以前的共享证人失效引起的问题已经解决。 此时，两个节点在不使用强制仲裁的情况下能够坚持到最后一个节点的概率为66%左右。

这里重要的是时间节点3、3节点变成2节点，之后共享证人突然失效。 理想情况下，集群动态调停应该感知共享证人的无效，重新调整集群票数，随机选择一票生存

但实际上，共享证人突然无效时，未感知到集群仲裁，随后进行动态仲裁调整，查看命令后，仍发现是两个节点票一个证人票，实际上此时共享证人已消失，查看日志

但是，由于集群没有去除证人投票，没有动态调整为一票，此时，如果另一个节点集群关闭，王先生认为这里重要的是共享证人失效的时候，状态是“失败”造成的，集群就是这样这很危险。 在这种无法正常运行的情况下，如果另一个节点断开，则必须强制启动群集

因此，王先生认为动态仲裁可能偏向于盘证，而不重视共享证词。 共享证言除了时间划分以外还有这个问题吗？ 于是很快，王先生又尝试了盘证

时间节点3 :如果磁盘被目击，则群集中仍有三个节点，此时只有一个节点已关闭，并且群集磁盘也被禁用

此时磁盘已禁用，但群集无法立即识别。 可见状态保持在线

经过一段时间后，状态将变为在线挂起，表决磁盘将尝试根据故障策略在每个节点上挂起，这表明投票计数和节点投票计数尚未动态调整

最终证人磁盘失败，但证人票数和节点票数没有调整

因此，如果目击磁盘突然出现故障而无法访问，则此时群集动态仲裁无法正常工作。 无论目击磁盘是否联机或失败，如果其中一个节点已断开，则在一段时间内，群集将确定当前有55个节点无法形成仲裁，然后关闭群集

最后一个节点尝试形成群集，但几秒钟后失败。 没有不能进行仲裁操作，不存在多数投票

因此，可以看出无论是共享证人还是光盘证言都面临着这个问题

也就是说，当从3个节点留在2个节点时，集群的目击会突然丢失，集群将不再动态调整投票。 此时，当一个节点重新关闭时，集群将关闭，必须手动强制仲裁。 此外，还需要切换到多节点仲裁模式，防止再次发生

共享证人丢失后，在这种情况下会继续直接在日志中写入共享证人的失败，但动态仲裁不会协调证人和节点的投票

磁盘监视基于磁盘策略，首先尝试联机锁定，然后状态将失败。 但是，动态仲裁也不会在群集磁盘脱机后动态调整监视和节点投票

理想情况下，磁盘见证禁用将离线并释放投票，除非磁盘见证状态为离线。 集群感知到证人票数丢失，动态重新调整节点的票数。 目前，簇是奇数的票数

但据王先生观察，如果3是剩下2，盘证人突然失效，盘证人状态总是失败，不会离线

如果磁盘见证离线，王先生发现只有磁盘处于正常状态时，才能手动将状态更改为离线。 如果磁盘见证成功脱机，请按我们预期删除见证投票，并随机删除节点投票

因此，当这种证人突然失去联系的场面发生时，共享证人和光盘证人面临的问题是一致的，不存在不公平的关系。 王先生觉得这应该是动态仲裁检测机制的漏洞。 证人突然失去联系时，可以处于失败状态，但应该可以动态消除失败状态的证人票数，动态调整节点投票，即使为一个证人的联系进行动态仲裁也不是正常的工作。

因此，在使用动态仲裁时，有必要考虑以下两点可能遇到但容易被忽视的问题

纯粹使用多个节点，动态仲裁调整节点数，对于剩下的2个节点，集群可以正常生存到最后一个节点的概率约为66%。 如果选定的投票节点突然停电并关闭，群集将关闭，必须手动强制启动群集。

使用证人加节点票数进行动态调解的动态调解。 3在剩下的两个场景中，证人突然失去了联系。 证人不会去除自己的一票，动态调解也不会自动调整为一票。 如果关闭另一个节点，群集将关闭。 在这种情况下，必须手动强制启动一个节点。 当其他两个节点恢复时，可以手动切换到多个节点仲裁模型。 这样，再次发生3剩下2个场景时，自动调整为1票，以约66%的概率自动生存到最后的节点场景。 之后，因为我们是强制启动的集群，所以即使目击后恢复，强制启动的集群数据库也会覆盖证人磁盘的数据库。

详情请访问云服务器、域名注册、虚拟主机的问题，请访问西部数码代理商官方网站： www.chenqinet.cn