如何选择WSFC仲裁模型优化方案

这期内容当中小编将会给大家带来有关如何选择WSFC仲裁模型优化方案，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

WSFC仲裁模型优化方案

生产环境某系统数据库高可用环境描述

生产环境某系统部署为主、备、灾备三节点SQL Server 2014 AlwaysOn AG，操作系统为Windows Server 2012 Standard，环境基于域（Domain）和Windows故障转移集群（WSFC）。无见证磁盘，采用多数节点仲裁。主、备都有投票权，灾备无投票权。默认启用了动态仲裁，默认动态仲裁随机挑选一个节点去掉投票权。生产环境当前投票在备节点。

第1部分：测试环境资源描述

Windows故障转移群集、AlwaysOn AG资源和角色描述：

说明：

原环境仲裁见证为无见证，新增共享磁盘仅附加到TEST-GS-ZHXT1和TEST-GS-ZHXT2，用于方案4的配置磁盘见证。

关注点：

1. 检查WSFC和AG是否能正常对外提供服务。

2. 当前投票的数量和移动情况。

3. 检查投票来不及交换情况（当前投票都为0），执行强制仲裁后WFSC和AG的状态，以及AG是否能成功执行Failover、副本是否能Resume。

第2部分：模拟生产环境账户系统当前配置测试

场景1：备节点宕机
目的：模拟备节点投票权来不及交换的情况下，强制冲裁。
宕机后，投票来不及交换，WSFC崩溃，AG为Resolving状态。

维护操作：

1)       主节点执行强制仲裁
以管理员打开cmd，执行以下命令

       net stop clussvc

       net stop clussvc /FQ

       WSFC能对外提供服务。
在主节点上get-clusternode显示主节点为Up状态、投票为1，灾备节点为Up状态，投票为0，备节点状态为Down状态，投票为0。

2)       检查AG是否能正常运行，或为Resolving状态

AG为Resolving状态

3)       若为Resolving，是否能强制Failover

在主节点，打开实例执行 ALTER AVAILABILITY GROUP testag FORCE_FAILOVER_ALLOW_DATA_LOSS

可强制Failover，AG能对外提供服务

遗留问题：

在执行完以上操作后，当备节点也故障恢复起来

在备节点上get-clusternode显示备节点 为Up状态、投票为1，主、灾备节点为Down状态，投票为0。

备节点没有按预期重新加入到主节点的集群。

需要在备节点执行

net stop clussvc

net start clussvc

重启集群备节点

WSFC恢复，AG辅助副本可手工resume

第3部分：当前仲裁模型可优化方案测试

方案1：修改群集参数值LowerQuorumPriorityNodeID为备节点ID

目的：让当前投票移动到主节点。

场景1：备节点宕机

备节点宕机后：

    WSFC正常，AG主副本正常，灾备节点辅助副本正常。

备节点辅助副本Down，AG能正常对外提供服务。

备节点恢复后：

    WSFC正常，AG主副本正常，灾备节点辅助副本正常。

如果备节点恢复时间短，备节点数据库自动恢复；

如果备节点恢复时间较长，备节点辅助副本状态为未同步，数据库无法访问，手工resume数据库后，数据库可以访问；

如果备节点恢复时间巨长，主节点早前日志被日志备份截断，日志不足，无法用于备节点同步，需要重建备节点AG副本。

场景2：灾备节点宕机

现象同场景1

场景3：主节点宕机

主节点宕机后：

投票来不及交换，WSFC崩溃，AG为Resolving状态。

备节点执行强制仲裁，WSFC恢复。

备节点AG强制Failover到备节点后，AG主副本正常，灾备节点需要手工resume数据库后，数据库可以访问。

主节点恢复后：

测试4次，有2种不同结果：

    a)主节点未加入备节点的集群，重启集群主节点clussvc服务后正常。

    b)主节点自动加入了备节点的集群。

方案2： 让3个节点都有投票权，修改群集参数值LowerQuorumPriorityNodeID为灾备节点ID

目的：当任意1节点故障时，能有1个投票保持WSFC正常。

场景1：备节点宕机

备节点宕机后：

WSFC、AG均正常

备节点恢复后：

WSFC投票恢复正常，AG正常。

场景2：灾备节点宕机

现象同场景1

场景3：主节点宕机

主节点宕机后：

WSFC正常，AG为Resolving状态，在备节点执行强制Failover，AG可对外提供服务，手工resume灾备节点数据库。

主节点恢复后：

WSFC投票恢复正常，数据库手工resume后，与新的主节点数据同步，可访问。

场景4：主节点和备节点同时宕机

主节点和备节点同时宕机后：

    WSFC崩溃，在灾备节点执行强制仲裁，WSFC能提供服务。

    AG为Resolving状态，执行强制Failover，AG能对外提供服务。

主节点和备节点恢复后：

WSFC投票恢复正常，数据库手工resume后，与新的主节点数据同步，可访问。

场景5：备节点和灾备节点同时宕机

备节点和灾备节点同时宕机后：

    WSFC崩溃，在主节点执行强制仲裁，WSFC能提供服务。

    AG为Resolving状态，执行强制Failover，AG能对外提供服务。

备节点和灾备节点恢复后：

WSFC投票恢复正常，数据库手工resume后，与新的主节点数据同步，可访问。

方案3：增加1个仲裁节点，给予投票权

目的：让当前投票总数为3票，基于节点大多数仲裁。

场景1：备节点宕机

备节点宕机后：

WSFC、AG均正常。

备节点恢复后：

WSFC投票恢复正常，AG正常，备节点数据库手工resume后可访问。

场景2：备节点和灾备节点同时宕机

备节点和灾备节点同时宕机后：

WSFC、AG均正常。

备节点和灾备节点恢复后：

WSFC投票恢复正常，AG正常。

场景3：主节点宕机

主节点宕机后：

    WSFC正常，AG为Resolving状态，无法提供服务。

备节点AG强制Failover后，可对外提供服务，灾备节点数据库手工resume后，与新的主节点数据同步。

主节点恢复后：

WSFC投票恢复正常，数据库手工resume后，与新的主节点数据同步，可访问。

场景4：主节点和备节点同时宕机

主节点和备节点同时宕机后：

    WSFC崩溃，在灾备节点执行强制服务，WSFC能提供服务。

    AG为Resolving状态，执行强制Failover，AG能对外提供服务。

主节点和备节点恢复后：

WSFC投票恢复正常，数据库手工resume后，与新的主节点数据同步，可访问。

方案4：增加磁盘见证，附加到主、备节点

目的：基于动态仲裁，磁盘见证利用Windows Server 2012 R2动态见证行为。

说明：

共享磁盘仅附加到主节点和备节点也能配置仲裁见证为磁盘见证；

因为主、备节点各有1票，磁盘见证为保持群集奇数票，也投了1票。

场景1：备节点宕机

备节点宕机后：

WSFC、AG均正常。

备节点恢复后：

WSFC投票恢复正常，AG正常。

场景2：备节点和灾备节点同时宕机

备节点和灾备节点同时宕机后：

WSFC、AG均正常。

备节点和灾备节点恢复后：

WSFC投票恢复正常，AG正常。

场景3：主节点宕机

主节点宕机后：

WSFC正常，AG为Resolving状态，无法提供服务。

备节点AG强制Failover后，可对外提供服务，灾备节点数据库手工resume后，与新的主节点数据同步。

主节点恢复后：

WSFC投票恢复正常，数据库手工resume后，与新的主节点数据同步，可访问。

场景4：主节点和备节点同时宕机

主节点和备节点同时宕机后：

    WSFC崩溃，在灾备节点执行强制服务，WSFC能提供服务。

    AG为Resolving状态，执行强制Failover，AG能对外提供服务。

主节点和备节点恢复后：

重新加入了集群，两节点数据库手工resume后，与新的主节点数据同步，可访问。

第4部分：优化方案评估

下表为4种方案各场景的测试情况汇总：

说明：绿色场景不是本次测试重点，是从理论上得出的结论。

在WSFC崩溃的情况下，强制冲裁可提供服务。

在WSFC可提供服务后，AG为Resolving状态下，强制Failover可提供服务。

方案3和方案4能满足备节点、灾备节点中任意一个或同时宕机时WSFC正常、AG正常。

方案3配置简单，用1台虚拟机作为群集节点，给予投票权，参与仲裁。

方案3中，仲裁节点宕机时，即与线上配置一致，此时备节点宕机，也就出现WSFC崩溃、AG无法提供服务的情况。

进一步优化方案，结合方案1和方案3的优点，在方案3的基础上修改群集参数值LowerQuorumPriorityNodeID为备节点ID。

于是，孕育出了方案5：增加1个仲裁节点，给予投票权，并修改群集参数值LowerQuorumPriorityNodeID为备节点ID。

进一步测试，结果如下：

测试表明，前5种场景下，与方案3表现相同。

先仲裁节点宕机，接着备节点宕机的场景下，表现稳定，优于方案3。

引用：

“在使用动态仲裁的时候需要考虑到以下两点可能会遇见但容易被忽略的问题：

1. 纯粹使用多数节点，动态仲裁调整节点数，当剩下2节点时，有百分之66左右的几率群集可以正常存活至最后一个节点，当被选中投票节点忽然断电宕机，则群集关闭，需要手动强制启动群集。

2. 使用见证加节点投票数，动态仲裁+动态见证，当3剩2场景下，见证忽然失联，见证并不会去掉自身的一票，动态仲裁也并不会自动调整至1票，如果再宕机一个节点，群集将关闭，这时需要手动强制启动一个节点，当其它两个节点恢复时，可以手动切换至多数节点仲裁模型，这样当再次出现3剩2场景下，会自动调整至1票，自动坚持至百分之66左右几率存活到最后一个节点场景，然后由于我们是强制启动的群集，因此即便当见证以后再恢复，强制启动的群集数据库也会盖过见证磁盘的数据库。”

启示：

①创建WSFC时选择节点的顺序很重要。

WSFC在有投票权的节点中投票发生交换时，会选择节点ID值较大的那一个。

我们应该尽量保持在各种场景下主节点上有投票。那么就要保持主节点的ID值最大。

在创建WSFC的过程中，节点ID是递增的。

根据重要性依次递增，应该将没有投票权的节点先建立集群，再加入有投票权的仲裁节点，再加入有投票权的备节点，最后加入主节点。

（如果创建WSFC时，批量添加节点，那么节点的ID是不可控的。）

②优化节点在投票发生交换时的选择优先级。

由于LowerQuorumPriorityNodeID是集群的全局参数，只能设置为某一个节点ID，并不能为多节点设置权重或者说优先级。

应在①的基础上，再去根据需要调整该参数。

第5部分：优化方案评估

基于成本和受益考虑，针对方案1和方案5，模拟投票节点宕机的不同场景，做进一步测试，测试结果如下：

从结果来看，方案5在场景②④⑤下，WSFC正常，AG需要强制Failover，带来的收益是从分钟级别恢复提升到秒级恢复，考虑到主库宕机只会做手工切换，从收益上考虑，经讨论后，选择方案1。

上述就是小编为大家分享的如何选择WSFC仲裁模型优化方案了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注亿速云行业资讯频道。