WSFC真实场景仲裁处理

  在本篇文章中，老王将从实际应用的角度来为大家讲解下群集仲裁在真实情况下的呈现，以及出现不同点数的节点宕机应该如何处理，在老王本篇文章中以及以后的文章中，我并不会去讲如何去安装一个群集，后面我们也将主要专注于群集的深入知识，概念理解，架构设计，迁移优化。

  本篇文章分为以下几个场景

  场景1.两个站点，三个节点的群集，假设北京站点两个节点，保定站点一个节点，群集采用多数节点方式，我们将依次测试重现，群集坏掉1个节点会发生什么，应该如何处理，群集坏掉两个节点会发生什么，应该如何处理。

  场景2.两个站点，四个节点的群集，假设北京站点两个节点，保定站点两个节点，群集采用磁盘仲裁的方式，我们将依次测试重现，群集见证磁盘活着时候，坏掉一个节点时群集会发生什么，应该如何处理，坏掉两个节点时群集会发生什么，应该如何处理，当见证磁盘不在，会发生什么情况，应该如何处理。

 场景1环境介绍

 北京站点

 Node1 

 管理网卡 10.0.0.3 网关10.0.0.1 DNS10.0.0.2

 存储网卡 40.0.0.3 网关40.0.0.1

 心跳网卡 18.0.0.1

 Node2 

 管理网卡 10.0.0.4 网关10.0.0.1 DNS10.0.0.2

 存储网卡 40.0.0.4 网关40.0.0.1

 心跳网卡 18.0.0.2

 08DC

 lan1 10.0.0.2 网关10.0.0.1

 网关服务器 

 10.0.0.1

 20.0.0.1

 30.0.0.1

 40.0.0.1

 保定站点

 管理网卡 20.0.0.5 网关20.0.0.1 DNS10.0.0.2

 存储网卡 30.0.0.5 网关30.0.0.1

 心跳网卡 18.0.0.3

 此次设计上，并没有采取一些最佳实践，老王只是为了重现出这样一个多站点的场景，把两个站点间管理网卡和存储网卡的网络分开，在之后的实验08DC也会承担ISCSI Server角色，严格来说，网关服务器和存储应该要放在一个相对来说比较稳定安全的地方，防止由于网关或存储导致群集出现单点故障，另外

   大家看到我在心跳卡上面两个站点的用的是同一个网端，这在实际企业环境里面不会这样，通常情况下是打通一个大VLAN这样去做，但是要注意，群集节点网卡，一定要至少有一块网卡，不配置网关，因为群集在创建的时候会去利用启发性算法来查找，群集默认会找没有配置网关的网卡来作为心跳网卡，如果全部网卡都配置上网关，你会发现群集出现故障，因此，如果心跳网卡也需要跨越网段，可以采取在节点上面用route -p的方式，手动添加路由表进行解决

   参考 https://blogs.technet.microsoft.com/timmcmic/2009/04/26/windows-2008-multi-subnet-clusters-and-using-static-routes/ 

  另外也需要考虑跨站点DNS缓存的问题，由于环境有限，所以在这里老王只用了一台DNS服务器，严格来说，应该是各站点有自己的DNS服务器的，例如，当前群集角色testdtc在北京站点的群集联机地址是10.0.0.9，但是北京DNS就会记录这个VCO是这个10网段的地址，然后每隔一段时间复制到保定的DNS服务器，这个复制时间就是个时间差，跨站点故障转移时间实际也需要考虑到DNS服务器复制的缓存和客户端的客户端的缓存，因为在北京没复制到保定之前，保定从北京或得到testdtc就是10网段的地址，就会cache下来，客户端来请求就都返回这个地址，但是当群集应用转移到保定，保定是20网段，因此就需要CNO重新注册VCO的DNS记录，然后群集资源名称才可以正常联机对外使用，通常这种跨子网的群集应用我们会设置绑定多个IP地址，然后依赖关系设置为or，即只要其中一个IP可以活着 绑定注册DNS就可以，群集请求DNS更新了VCO的地址，这时候VCO可以正常联机了，但是客户端能不能访问了呢，还不一定，因为客户端还有dns cache，针对于跨站点群集VCO的DNS缓存和记录生命周期，后面老王会单独写一篇深入介绍多站点群集的博客，在里面会指出一些最佳实践，其中网络部分会深入讲解，这里只是简单带过

首先可以看到节点服务器目前都是正常的状态，以及按照预定规划的多站点群集网络架构

我们创建了一个群集DTC应用，可以看到当前是主运行在node1节点上

直接将node1进行断电关机，可以看到群集DTC已经转移至node2继续提供服务

打开node2服务器系统日志可以看到关于检测node1已经离线了的日志

这时虽然群集还可以运作，但是已经仲裁已经提示警告，意思就是提醒你一下，你之前和我签订的仲裁协议是多数节点的3节点群集，现在你坏了一台了，不能再坏了，再坏群集就要关了，真实场景下如果三节点群集坏了一个节点，应该立刻修复节点重新上线，不然再坏一台群集将不再对外提供服务。

这时候我们将node2也直接断电关机，我们失去了整个北京站点，之后打开群集管理器可以看到，群集状态已经变成了下移，这时候实际上群集已经不再对外提供服务，CNO和VCO都将无法访问

打开事件管理器系统日志可以看到，群集服务因为仲裁协议违反，已经被迫停止

针对于群集的分析，主要分为系统日志，群集详细分析日志，群集验证报告，cluster目录日志，cluster.log日志，其中系统日志和详细分析日志相对比较容易理解，建议大家可以先从这方面的日志看起，后面会有文章专门介绍群集日志分析

这时群集由于连续的节点崩溃已经只剩下最后一个节点，这时候群集也关闭了，不再对外提供服务，但是我们也可以通过强制启动的方式把最后一个节点的群集服务启动起来，让群集继续对外提供服务，虽然一个节点能承载的负载有限，但是可以访问一部分总比什么也访问不到强

直接运行命令 

net stop clussvc

net start clussvc /FQ

即可，把群集服务先停止，然后强制启动起来

   执行完成强制启动后可以看到群集已经使用，但是群集有提示我们，当前是在forcequorum状态运行，群集配置可能会丢失

   老王猜想是因为，这是使用多数节点仲裁的原因，或者共享见证时会遇到的问题，因为这类仲裁模式，群集数据库只存在本地节点间互相同步，假设现在只有Node3强制启动了，其它节点都不在，我们修改了群集资源，然后节点3下，其它节点上，会因为时间分区的原因导致无法启动等类似原因

    因此建议大家强制启动只能是作为实在没办法下的最后一道手段，能让群集短暂的起死回生，但是回生之后应该立即修复其它节点加入群集，解除ForceQuorum模式。

可以看到强制启动之后 群集DTC服务已经在保定站点正常启动了起来，群集名称对应的IP地址现在是保定那边的20网段

如果大家点击一个群集角色的依赖报告可以看到类似下面的这种图，理解依赖关系对于多站点群集应用上线很重要，AND则代表，虽有关联的子资源必须联机，父资源才可以联机，OR则代表选项中的几个子资源有一个活着，父资源就可以启动，例如网络名称需要绑定IP，如果10可以绑定注册就绑定10网段，如果10子网无法绑定，那么20网段可以绑定注册，网络名称也可以上线联机。

以上我们实际看了三节点多数节点仲裁情况下，节点依次宕机时的处理

接下来我们再看第二个场景 

场景2环境介绍

 北京站点

 Node1 

 管理网卡 10.0.0.3 网关10.0.0.1 DNS10.0.0.2

 存储网卡 40.0.0.3 网关40.0.0.1

 心跳网卡 18.0.0.1

 Node2 

 管理网卡 10.0.0.4 网关10.0.0.1 DNS10.0.0.2

 存储网卡 40.0.0.4 网关40.0.0.1

 心跳网卡 18.0.0.2

 08DC

 lan1 10.0.0.2 网关10.0.0.1

 lan2 20.0.0.2 网关10.0.0.1

 lan3 30.0.0.2 网关30.0.0.1

 网关服务器 

 10.0.0.1

 20.0.0.1

 30.0.0.1

 40.0.0.1

 保定站点

 Node3

 管理网卡 20.0.0.5 网关20.0.0.1 DNS10.0.0.2

 存储网卡 30.0.0.5 网关30.0.0.1

 心跳网卡 18.0.0.3

 Node4

 管理网卡 20.0.0.6 网关20.0.0.1 DNS10.0.0.2

 存储网卡 30.0.0.6 网关30.0.0.1

 心跳网卡 18.0.0.4

可以看到群集已经新增至四个节点，同时也已经配置了磁盘见证

依旧部署一个群集DTC，目前托管在北京node2节点

我们直接将node2断电，可以看到现在DTC群集应用已经自动转移至本站点的node1服务器

接下来我们把Node1也直接断电，模拟我们失去了整个北京站点的节点，可以看到，由于我们采用了磁盘见证，因此我们可以接受一半的节点坏掉，群集依然可以正常工作，但是提示我们了，在当前的情况下，只要再坏掉一个节点或者群集磁盘宕机，都会导致群集关闭，这时应该抓紧时间修复北京站点，尽快上线，不要让这种情况持续太久

假设这时没抢救好北京站点，保定站点又坏了一个节点，群集则会变成下移关闭状态，所有群集服务也将都无法访问

这时由于群集宕机节点数已经违背了仲裁协议中的节点数，因此也只能使用强制启动的方式把群集启动起来，但是这种状态同样也不要持续太久，还是应该尽快修复其它节点上线

接下来我们来模拟下脑裂的场景，即北京与保定直接发生了网络分区，两边各自为政，实际最佳老王应该模仿是群集四个节点先是失去了到仲裁磁盘的连接，然后变成四个节点，四个投票的情况下，中间产生一个分区，但是由于老王AD和ISCSI模拟在了一起，如果直接把这台机器宕机所有节点别想正常工作了，因此老王这里临时将群集仲裁模型改为了多数节点，即四个节点，四票的一个多数节点架构，脑裂一触即发的架构，哇哈哈

这时我们模拟脑裂分区，将node3和node4直接改到另外一个网络中

So it begin，可以在node2上面看到只有node1和node2活着，node3 node4形成群集，或无法形成

但是如果访问群集名称测试会发现还是不能访问的，因为这是群集已经没办法执行仲裁，两边没有一方是多数的，因此整个群集都将没办法正常工作，都在摸瞎胡中

这时由于域控和存储在北京这边，北京这边可以正常工作，保定那边网络还未修复，因此我们强制启动北京的群集分区，在node2上面运行强制启动命令

可以看到只需要在node2上面运行一下强制启动的命令之后，整个群集就都变得可用了，node1和node2在同一个分区内，node1感觉到node2形成了权威分区于是自动又融入了群集，但这时由于我们是强制启动的群集，群集还处于强制启动状态，不论任何情况下，都不要长时间让群集处于强制启动状态，还是应该尽快的去恢复网络。

可以看到群集DTC现在已经在北京站点正常联机工作

当保定站点网络修复好了后，这一侧的群集分区感应到了北京的权威群集分区，就又会自动融合进去，群集现在又正常工作了，强制启动状态的警告也已经消除

  总结一下，我们看了再多数节点仲裁模型下，群集节点在不停宕机时群集的变化处理，又看了在磁盘见证模型下，磁盘在的情况下，群集节点在不停宕机时群集的变化处理，以及磁盘见证不在，发生网络分区时的变化处理

  简单来说，在群集工作状态中，只要不违背你与群集签订仲裁协议的规则，群集都是可以正常运作的，当达到临界值时，群集会提醒当前已经达到临界值，再宕机一票，群集就要关了，这时候应该要抓紧时间修复群集其它节点

   然后假设出现了连续宕机的情况下，只剩下一个节点，或者只剩下少数节点，如果想让群集起死回生出来提供服务，可以使用强制仲裁的方式，在少数节点的情况下也可以让群集启动起来

  强制仲裁主要就是用于在少数节点的情况下启动起来群集，或者在群集发生脑裂，50 50的情况下，启动起来其中一端出来提供服务，同样强制仲裁状态时间不可以太长，否则会出现配置不同步风险，也要尽快修复节点或网络故障上线才是

  当我们执行强制仲裁命令之后，实际上背后群集会做两件事，确立强制仲裁一方为权威方，提升强制仲裁分区的群集配置Paxos标记提升为最高，类似于AD里面的授权恢复，让强制仲裁的一方为黄金权威方，群集将在权威方进行运作，其它节点的群集配置，将会与强制仲裁一端同步，不可否认强制仲裁，很多时候还是很实用的

  以上就是老王想和大家说的强制仲裁，以及仲裁处理，希望大家看过之后能有收获，当群集出现逐个节点宕机时心里有数该如何处理

  补充几点

1.强制启动起来，只是我们把群集救活了，但是可不可以完整的对外提供服务呢，不一定，因为假设是四个节点的群集，资源都是一致的，那强制启动起来的节点能否承载起来四个节点的负载呢，这是个问题，如果支持不起来负载，一些群集应用也是没办法联机访问的，因此，实际规划时，也需要考虑到这种只剩下最后一个节点的场景，最佳是设计的时候能够做好规划，服务器资源足够，当然最好，也可以通过规划群集应用优先级的方式规划，一旦发生这种情况，那些群集应用优先级比较高，先让这些应用活起来，或者设置一个冷备机，平时不参加群集投票，一旦出现这种只剩下一个节点的情况下，可以再把冷备节点启动来承载负载

 2.上面其实还有一种场景老王没写到，最后上张图把，出于好奇心我在2008R2的群集上面试了下3个节点+见证磁盘的仲裁模型，结果死的很惨，可以看到，当群集坏一个节点，就已经告诉我当前已经达到了临界值，见证磁盘失效或者再坏一个节点节点，群集就关了，这样来看完全没什么优势啊，因为我如果3个节点多数节点，我只需要考虑保证两个节点可用就好了，这样的话，我还要多考虑一个见证磁盘的可用，对于保持群集可用可谓一点用处没有，唯独能想到的可能就是这种场景下，可以避免时间分区的问题，如果最后剩下一个节点和见证磁盘，还可以把配置修改信息同步到见证磁盘，其它节点再上线也可以正常使用，到了2012时代这个就变了，不再鸡肋，3节点配见证磁盘，不需要强制启动的情况下也可以活到最后一个节点，下篇文章我们就来实际测试2012时代仲裁发生的变化！