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时代仲裁发生的变化！