上篇文章提到了WSFC群集出现时间分区时,使用磁盘见证和共享见证处理的方式会不一样,老王实作了一下,看国内目前还没这方面的博客,心血来潮决定把这篇番外博客写出


  首先我们先来看出现时间分区时共享见证的处理,所谓时间分区即是说,当你修改一个节点的资源状态时,另外一个节点不在线,然后修改的节点又宕机,另外一个节点上线时同步面临的群集数据库同步问题


我们假设这样一个场景


时间节点1:节点1和节点2同时存活,节点1上面添加DTC群集角色,群集数据库自动同步至节点2

时间节点2:节点1宕机,节点2查找群集数据库上线群集1承载DTC角色

时间节点3:节点2添加SOFS角色

时间节点4:节点2宕机

时间节点5:节点1上线 


当实际出现了这种场景的时候,你会发现共享见证下节点1无论如何也没办法进行正常的工作


打开事件管理器 - 系统,你会看到 Event ID 1561的错误,内容提示已经很清楚,由于该节点不具备群集数据库最新版本,因此无法启动,无法形成群集

WSFC时间分区场景实作_第1张图片


这正是老王上篇文章提到的,当你使用共享见证作的情况下,出现时间分区时,共享见证是没办法处理的,因为共享见证里面没有存群集数据库


WSFC时间分区场景实作_第2张图片


然后这时你在节点1打开群集管理器,你会发现无论如何也连接不上CNO,你试图ping群集CNO VCO域名可以ping通,但是当你访问他们,使用VCO名称,会发现连接不上


WSFC时间分区场景实作_第3张图片


WSFC时间分区场景实作_第4张图片


  这时候只有等节点2修复完成,当节点2加入群集后,节点1可以和节点2同步最新的群集数据库之后,节点1群集管理器才可以正常打开,可以重新加入群集工作。


  即使这时你的节点1可以打开,也千万不要执行强制仲裁,因为一旦执行了强制仲裁会覆盖paxos标签,提升节点1的paxos标签为最新,共享见证又只承认拥有最新paxos的一方,导致的结果就是让群集以为节点1的群集数据库才是最新的,然后这时候如果节点2修复打开了,之前修改的内容也将完全丢失,因为节点2要以节点1的群集数据库为准了,因此共享见证情况下出现时间分区了,只有等权威节点修复完成上线,或通过恢复群集权威数据库方式


我们再来看下同样的时间分区场景在磁盘见证下的效果


时间节点1:节点1和节点2同时存活,节点1上面添加DTC群集角色,群集数据库自动同步至节点2

时间节点2:节点1宕机,节点2查找群集数据库上线群集1承载DTC角色

时间节点3:节点2添加SOFS角色

时间节点4:节点2宕机

时间节点5:节点1上线 


节点1不在线情况下节点2新增SOFS角色

WSFC时间分区场景实作_第5张图片


节点2宕机,节点1上线


WSFC时间分区场景实作_第6张图片


节点1可以同步使用SOFS角色信息,并正常提供群集应用服务


WSFC时间分区场景实作_第7张图片

      

   同样的情况下,节点2在节点1不在的情况下,新增了SOFS角色,之后节点2宕机,节点1上线,可以看到,节点1依然是可以正常启动的,群集管理器也可以正常打开,群集应用也可以正常对外提供服务


  为什么会是这样呢,因为群集磁盘会存着最新的群集数据库,当我们使用磁盘见证的时候,当新增或删除了群集资源,除了会把状态同步到节点本身的群集数据库注册表,也会同步一份到见证磁盘中,当出现时间分区时,会发生的只是节点1联系到见证磁盘,与见证磁盘同步到最新的群集数据库,然后正常启动服务。


  因此,大家可以看出,共享见证在一些场景下还是会有问题,老王建议能使用磁盘见证尽量一定要用磁盘见证


  2016新推出的Cloud blob见证我还没有试过时间分区的场景,不知道是类似共享见证的效果,还是磁盘见证的效果,关键在于里面会不会有最新的群集数据库,后续有时间我会去验证一下,也欢迎大家去验证下然后告诉我答案