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/hh213151(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分区时，分站点根本没有资格造成群集

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

本文思惟导图