WSFC 强制仲裁影响讨论

     强制仲裁是WSFC群集管理中一个常用操作，到底什么情况下应该执行强制仲裁，强制仲裁之后是否会对群集造成影响，本篇文章老王将与大家细致讨论，为了便于理解，我会将强制仲裁涉及到的群集数据库，仲裁概念进行简单复习，以便大家更好的理解思考强制仲裁

     首先先来看下群集数据库，很多朋友可能不知道这个概念，老王在前面有篇文章专门讲解，故这里只做精要概述，简单来说，群集数据库，是微软WSFC运作的配置数据库，存在于每个节点注册表，以及见证磁盘中。

     群集数据库主要用途

1. 群集各节点启动时，检测群集数据库注册表配置单元是否完整，如果完整才可以允许该节点正常启动群集服务，如不完整需与其他节点同步完整后才可正常提供服务

2. 群集运作过程元数据实时同步，以维护各节点群集信息的一致性，并作为故障转移参照，WSFC正常运作过程时，会把群集节点状态，群集状态，群集角色状态等配置数据，记录在各节点注册表，群集运作过程中，每个节点上修改了群集的信息，都会把修改后的数据同步到各个节点，群集见证磁盘，同步时使用群集通信网络，其中也会将各节点当前承载的群集角色同步，让每个节点和见证磁盘，都知道对方上面承载了什么服务，发生故障转移时，其它节点会检测注册表单元，将宕机节点原承载的群集角色进行挂载联机。

     自WSFC 2008开始，群集数据库开始引入paxos标记机制，每个群集节点本身都可以保存群集数据库最新副本，如果某个节点修改群集数据，则该节点paxos标记增加，随后各节点感应到有更新的paxos标记，会自动与其同步群集数据库内容，确保paxos始终与最新标记保持一致，当群集节点宕机恢复后，会对比自身paxos标记与磁盘见证paxos标记，如果磁盘见证paxos标记更新，则与其同步后上线，如果磁盘见证检测到群集节点有更新paxos标记的群集数据库也会与其同步。

   那么群集数据库和强制仲裁有什么关系呢？

   正常群集运作情况下，群集数据库的复制同步应该是多主的，任何一个节点修改了数据，都可以和其它节点同步，即是说我在任何一个节点上面修改群集信息都可以，我心里知道，我修改的会是正确的。但是在强制仲裁场景下则发生变化，例如，发生50/50脑裂，我需要强制启动其中一方提供服务，我希望群集接下来由被我强制启动的站点提供服务，但是在以前旧版本的情况下，即便是强制启动了一方，如果没做阻止仲裁的操作，另外一方也会尝试启动群集，如果另外方修改了群集数据，则我强制启动的也会被他覆盖掉。因此，群集数据库引入了一种黄金副本的机制，当节点发生授权恢复操作 或 forcequorum强制仲裁操作后，即提升该节点群集数据库副本为黄金副本，paxos优先级为最高，其它节点必须与黄金副本群集数据库节点同步，同步后的节点可以正常提供服务。

   关于强制仲裁的概念老王后面会再次进行介绍，此处单表群集数据库与强制仲裁关系，可以看到，自WSFC 2008开始引入了这种黄金副本机制，通过这种机制，可以帮我们在一个灾难恢复强制仲裁的场景，明确的告诉群集，当前应该以哪个站点数据为准，其它节点在未与黄金副本同步前，无法提供服务，或者说不应该对外提供服务。

  接下来我们再看群集仲裁的概念，简单来说，仲裁是一种维护群集可用性的协定，根据我们选择的仲裁模型，来规定群集可以接受的最少工作节点，其中仲裁模型使用投票机制，正常情况下每个节点各有一票，群集见证会有一票，仲裁根据票数来判断是否符合仲裁模型协定，如果票数违反了仲裁模型可以接受的工作节点，则认定群集当前失去维护可用性资格，关闭群集。

  仲裁在群集中起到两个用途

  1.跟踪群集当前运作票数是否符合仲裁模型协定，如果低于最低工作节点，则决定关闭群集

  2.当发生分区时，维持确保多数节点一方获胜，因此我们需要始终确保群集为奇数票数，当发生分区时，始终由多数一方负责接管群集提供服务，少数票数方将关闭

那么怎么确保群集投票数始终是奇数呢，一方面我们可以利用群集现有的技术，一方面是架构设计人员的设计理念要准确，如果是偶数节点，那么你就一定要设计成磁盘见证或共享见证或云见证，否则就会出现脑裂各自为政的情况

所谓脑裂即是说在一种50/50分区场景下，群集无法做出决策，到底应由哪一方获胜提供服务，因此会发生两端都以为自己获胜，抢夺资源，导致群集不正常工作，无法对外提供服务，因此群集引入了见证机制，磁盘见证，文件共享见证，云见证，都可以解决此问题。引入见证后，群集投票还是以群集票数为主，但又加入见证票数一票，当发生这种50/50分区时，那个分区可以访问到见证设备，则那个分区可以获得见证票数，最终接管群集服务，以此来确保多数获胜原则。

随着仲裁模型的演变，到WSFC 2012时，群集不再主要强调运作过程必须遵循仲裁模型协定，更多的是强调维持群集应用的连续性，2012引入了动态仲裁的机制，可以动态调整节点票数，在多数节点仲裁模型的情况下，群集有百分之六十六的几率可以坚持到最后一个节点，偶数节点加见证磁盘，见证磁盘在线的情况下可以存活至最后一个节点，奇数节点加见证磁盘，至多存活到两个节点。2012R2引入了动态见证的机制，可以动态调整见证票数，因此，在2012R2开始，不论奇数节点或是偶数节点，都始终建议为群集配置一个见证，2012R2在见证设备在线的情况下，可以确保群集真正存活至最后一个节点

那么什么是强制仲裁呢

简单来说，强制仲裁，是为了在脑裂场景或不符合群集仲裁协定的场景下，依然想要强制启动其中一方群集提供服务

强制仲裁主要应用场景

1. 灾难恢复：例如主站点两个节点，备站点一个节点，主站点全部崩溃，备站点票数虽然不符合群集仲裁协定，但依然强制启动备站点提供服务

2. 脑裂分区：群集发生50 50分区，群集停摆，强制启动其中一方提供服务
   

大家可能会常在微软的视频中听到强制启动一个站点，很多朋友可以能会纳闷，怎么强制启动站点，是要在该站点上面每个节点都运行一下强制启动的命令吗

其实不用，强制仲裁这条命令，我们只需要在备站点其中一个节点上面运行即可，执行之后即可启动群集，其它同站点内或不同站点，都会感知到这里存在强制仲裁

随着技术的演变，强制仲裁的应用场景现在已经不多

例如，2012开始引入动态仲裁，如果群集当前四个节点，动态仲裁会自动去掉一个节点的票数，当发生分区时，2节点票数一方获胜，2012R2开始可以通过LowerQuorumPriorityNodeID命令指定每次要去掉那个节点的票数。

除非群集动态仲裁被误配置停止，四个节点没有自动去掉一个节点票数，导致发生脑裂分区，群集停摆，这时需要通过强制启动

还有一种少有人提起的场景，即2012R2，见证失效场景，当群集剩下3节点加动态见证，见证设备如果失效，群集将在坏掉一个节点后关闭，这时需要强制启动群集

除此之外，事实上2012R2之后 强制仲裁主要只是为了处理灾难恢复场景下，强制启动少数站点节点使用

那么强制仲裁后会对群集造成哪些影响呢

事实上强制仲裁这个功能非常单纯，如果群集停摆，你需要强制启动群集提供服务，在想要的一方运行这条命令就好，执行强制仲裁后，背后将发生两个操作

1.强制启动该节点群集服务，进而启动群集

2.提升该节点群集数据库paxos为黄金副本

启动之后，其它未经过强制仲裁的节点，要想加入群集，必须要和强制启动的黄金副本群集节点同步群集数据库

此操作称为阻止仲裁，在2012R2之前，如果在少数节点方执行了强制仲裁，则当故障主站点恢复后，您需要尽快在故障主站点手动执行阻止仲裁命令，告诉主站点，当前群集环境存在强制仲裁节点，你需要和他同步群集数据库后上线，否则主站点也将尝试形成群集，容易发生群集数据库覆盖操作，当时微软还建议主站点恢复后，一台一台启动同步。

2012R2开始，引入强制仲裁弹姓，群集具有内置的逻辑来跟踪强制启动分区，其它分区检测到强制启动分区后，会自动执行阻止仲裁操作，直到与其同步完成群集数据库后再行上线。

强制启动本身来讲，它不懂群集上层的应用，所以只要应用没有额外设定，强制启动后不会有额外的宕机时间，例如，当前三节点群集，两节点北京，一节点天津，北京站点宕机，强制启动添加天津站点，启动后应用可以在天津站点联机上线，北京站点恢复后，完成阻止仲裁后加入天津分区群集，这时候事实上群集是可以正常工作的，所有节点paxos标记都已经同步为最新，理论上来说黄金副本效应已经消除，又可以多主更新，老王认为这时群集已经恢复了正常运作，如果您还是担心黄金副本效应没有消失，可以把应用从天津站点在线移动至北京站点，然后针对于天津站点节点以正常启动的方式再次启动一次群集服务。所以理论上，只要上层应用不需要执行强制仲裁后的操作，不会因为强制仲裁而产生后来额外的宕机时间。

老王所知道的，对于SQL AG，需要在强制仲裁执行后执行数据库跟踪操作

SQL AG强制启动后处理操作

https://technet.microsoft.com/en-us/library/hh313151(v=sql.110).aspx

https://blogs.msdn.microsoft.com/alwaysonpro/2014/03/04/manual-failover-of-availability-group-to-disaster-recovery-site-in-multi-site-cluster/

根据老王的经验在使用强制仲裁过程中，还有两点需要额外注意的地方

1.2012R2场景下强制仲裁启动了备用站点，主站点恢复后，群集服务无法启动加入到群集，即没有执行阻止仲裁过程，其原因可能是阻止仲裁过程中主节点与强制仲裁备节点网络抖动不稳，导致同步群集数据库失败，或者主站点与备站点机器配置更新补丁不同，实际场景中灾难恢复后，应确保网络稳定，所有站点节点系统更新配置一致后再行加入群集，如果还是不行，则请尝试手动在主节点执行手动阻止仲裁操作，再观察cluster log日志。

2.正确理解与使用强制仲裁，在2008R2群集运作过程中，仲裁会尽可能让群集维持一种多数节点存活的模型，我这样说的意思是，当一个群集主站点有3节点，分站点有2节点，群集使用多数节点仲裁模型，当主站点宕机时，即便分站点剩下四个节点又能力承担群集应用，仲裁也会脱机分站点两个节点，让群集对外脱机，停止工作，并阻止以正常方式启动分站点节点，这时候我们就使用强制仲裁，强制启动分站点两个节点提供服务，虽然分站点当前节点少，不符合群集最少票数，但是有两个节点能对外提供服务，总比都宕机强，强制仲裁主要就是用于处理这种，不符合群集仲裁票数允许的最低票数情况下，仍然要让群集启动对外提供服务的场景，或者说是在脑裂场景，决出一方对外服务

但是在一个WSFC运作过程中，节点群集服务的宕机，也可能会是由于系统配置，驱动，第三方软件而导致群集服务的无法启动，这种情况下就并不适用于强制仲裁，强制仲裁主要用于处理仲裁导致的群集无法正常启动的情况，在其它场景下利用反而会有副作用，举个例子，例如当前群集有五个节点，主站点四个，分站点一个，群集为自动故障转移，群集目前由主站点对外提供应用服务，但是分站点群集服务突然无法启动，这时候，如果你强制启动了分站点，那么好了，假设你真的重启成功了，分站点的群集数据库将完全盖过主站点，假设分站点没有和总站点同步最新的群集数据库，即是说分站点落后主站点配置，例如落后了10个paxos标记版本，那么强制仲裁后将会由落后的分站点群集数据库副本，盖过主站点群集数据库副本，因为强制仲裁后会提升群集数据库黄金副本，严重一点将会导致主站点的群集配置回退失效，因此，在出现群集服务无法启动时，一定先要通过事件日志，cluster log， dump日志确认问题后再执行修复操作。

总结一下，强制仲裁本身并不会造成群集宕机，它只是一个处理仲裁导致的群集无法正常启动的操作，强制启动群集节点为UP状态，主要用于脑裂和灾难场景

可能会带来的影响

1.上层依附于群集的应用，可能会需要执行强制启动后的额外操作，和应用机制有关。

2.强制仲裁后，其它节点需要有阻止仲裁过程才能启动加入群集，其它节点如果想要加入强制仲裁分区，请确保再次加入时系统配置一致，网络稳定。

3.不要盲目的使用强制仲裁，仅用于群集无法启动仲裁协定不足场景，盲目使用将会导致群集数据库错误覆盖影响

最后再来谈一个灾难恢复场景下的强制仲裁操作

以SQL Always on FCI为例，按照微软官网的建议是，正常情况下，所以主副本节点，给予正常投票资格，去掉辅助副本节点投票资格

投票资格，即是说各节点参与到群集仲裁的资格，可以在节点正常的情况下，去掉该节点的投票，被去掉投票的节点也可以承载群集应用，但是一旦主站点宕机，除非手动强制启动分站点，否则分站点所有无投票节点将无法联机，群集也将脱机

自WSFC 2012开始，群集开始支持GUI调整各节点投票资格

手动调整各节点投票资格比较主流的场景是灾难恢复时避免自动故障转移带来的额外宕机时间，因为SQL 故障转移时间较长，如果是跨站点就更长了，我们希望每次故障转移都是可控的，这时就可以将群集控制为手动故障转移模型

具体控制方法，将所有备站点投票资格均改为0，这样当主站点发生灾难后，应用不会自动故障转移至备站点，因为备站点投票资格为0，所以备站点失去形成群集的资格，因此这时候的操作应该是手动强制启动备节点，然后赋予投票资格，联机上线群集应用，并将主站点投票资格设置为0，当主站点恢复后，再设置投票资格为1，然后手动移动群集资源过去

参考链接 

https://blogs.msdn.microsoft.com/alwaysonpro/2014/03/04/manual-failover-of-availability-group-to-disaster-recovery-site-in-multi-site-cluster/

https://technet.microsoft.com/en-us/library/mt607084(v=office.16).aspx

https://msdn.microsoft.com/en-us/library/jj191711.aspx

这样手动控制之后，虽然故障转移时需要管理员手动操作，但可以避免出现脑裂场景，因为没有资格，所以50/50分区时，分站点根本没有资格形成群集

也可以避免由于网络质量不稳定的问题，不会因为检测信号而导致的故障转移带来的宕机时间

本文思维导图