WSFC2016 跨站点运行情况检测

以前在WSFC基础知识奠定篇曾经为你们介绍过微软WSFC故障转移的过程，咱们来重温一下

1.按照要求部署配置群集节点，确保群集服务器利用了冗余技术消除了服务器，网络，存储的单一故障点

2.保证群集内全部节点均可以访问到共享存储

3.群集应用将应用数据写入到群集共享存储

4.管理员新增节点1服务器上面功能角色，新增完成后节点1服务器群集数据库记录新增的角色功能以及相关联的信息，稍后会把信息同步至其它节点2，及群集仲裁磁盘

5.群集节点之间按照预约的心跳检测频率进行全网握手检测

6.节点1出现故障服务器突然关机，这时节点2心跳检测频率达到阈值，断定节点1已经离线

7.节点2断定节点1已经离线后，会根据已经同步的群集数据库信息，查看节点1服务器当前承载的群集应用，从新将群集应用与关联IP地址，群集磁盘在节点2进行上线

8.客户端正常访问群集名称，使用群集服务，但原有节点1的群集应用，现已由节点2提供，故障转移结束

本篇咱们将主要关注与群集故障转移的发生，你们能够看到从第五步开始，群集开始进行运行情况检测，随后以运行情况检查结果，来决定群集节点是否应执行故障转移

这在任何一个高可用群集里面都是必须的，只要群集是高可用性质，那么必定会有一种节点运行情况检测的机制，这种机制能够是ping检测，握手检测，API探测检测，总之咱们须要一种机制来准确确保节点的健康与否

针对于节点的运行情况检测机制是否准确，是一个群集的核心，真正能够被使用的群集运行情况检测机制，应该是准确能够反应节点健康与否状态的，同时能够根据实际状况灵活更改健康监测的阈值。

节点的运行情况检测是故障转移里面执行节点故障转移的依据，针对于节点的运行情况检测若是达到了必定阈值，群集就会断定该节点故障，随之会致使节点上面全部承载的群集资源进行failover操做，而failover操做有时又会产生停机时间，所以，群集节点运行情况的检测频率，和决定要进行故障检测的阈值，必定是要进行环境评估的。

群集中健康检测分为两大类，一类是节点检测，一类是资源检测，节点的检测更为简单，不须要置备不少重试逻辑，只要我群集规定的运行情况检测方式，你在规定时间，规定次数里面没有让群集检测到，群集就认为你是出现故障的，没法再提供服务，须要对你进行全部应用的failover

而资源检测相对于节点检测，则更为复杂一些，能够把节点检测理解为外层的检测，针对于一个节点level的检测，若是节点检测失败，则节点上全部资源failover，资源检测则更关注资源级别的运行情况，正如老王在日志排错进阶篇讲解到的，群集里面每一个资源都会有本身的resource.dll，群集正常运做过程当中，RHS会按照每一个资源的resource.dll定义对资源进行lookalive和isalive的检测，针对于每一个资源的lookalive和isalive检测方式都会不一样，lookalive只是粗略检测，isalive则更为深刻，isalive检测的结果会报告给RCM，RCM会再根据资源的故障策略，进行失败重试，在机器上尝试屡次启动资源，或把资源转移到其余节点运行。

总结来讲，节点的运行情况检测结果，决定了节点上面全部应用是否要被故障转移，资源的运行情况检测结果，决定了单个资源是否要被按照故障策略进行操做。资源检测更为复杂，要根据resource dll定义的检测方法，考虑多种状况，来进行lookalive和isalive的检测。管理员针对一些资源也能够收到设置故障策略，例如不尝试重启，直接出现失败就转移到其余节点，或重启资源尝试三次失败，再转移到其余节点。

在过去单个资源的RHS检测失败，可能还会影响到其它群集资源，2008以后，大多数程序都已经被隔离到单独的RHS进程中进行检测，所以不多会出现单个资源检测影响到其它资源的场景。

节点运行情况检测结果影响面更大，资源运行情况检测影响面只是单个资源。你们只须要这样记住就能够了

介绍了一些基本的理论以后，咱们再来专一于节点的运行情况检测

在WSFC 2012时×××始，微软针对于节点的运行情况发生了改变，再也不简单的执行一个ping操做，而是会执行一个真正的握手

例如，当前群集里面有2个节点，默认状况下他们每间隔一秒作一次全网检测，每一个节点与节点以前都会进行检测，若是此次握手检测为节点1发起，实际上它会执行一个握手，经过UDP 3343端口发送134byte的检测信号，询问节点2你在吗，节点回复，我在，那么你呢，你在吗，节点1回复我也在。到这里一个检测结束，WSFC的节点运行情况检测，是每隔一秒，会在全部节点之间都执行这种运行情况检测，确保没有节点会被遗漏，节点运行情况检测主要是经过UDP 3343端口

那么进行这个UDP 3343端口的检测，是在群集里面那块网卡进行呢，答案是全部已被勾选用于群集通讯的网络，在WSFC 2008时代以后，群集只有三种网络类型，分别是 

0 无群集通讯 

1 启用客户端和群集通讯

3 仅用做群集通讯

默认状况下，在咱们建立群集，或添加群集时，群集内部会有一个网络拓扑生成器来帮咱们自动去启发网卡的群集网络类型，生成群集内网络通讯拓扑。

例如

若是检测到网卡上面跑了ISCSI Initiator，那么自动启发它为类型0无群集通讯，确保存储网络只用来交换存储数据

若是检测到网卡上面配置了网关，那么拓扑生成器会觉得你这块卡是要与外面客户端通讯提供服务的，所以会自动把设置了网关的网卡设置为群集网络类型3

若是检测到网卡上面没有设置网关，那么拓扑生成器会觉得你这块卡只是要作内部群集通讯的，不须要对外提供服务，会被设置为群集群集网络类型1

须要注意，群集里面群集通讯这种流量下面会作三件事 

1.执行群集内全部节点的运行情况全网检测 

2.执行群集数据库的更新同步 

3.执行群集CSV元数据的同步

这三种操做都对网络质量的要求极高，尤为是CSV元数据和群集数据库，若是由于网络质量很差，频繁丢包，会致使群集数据库更新慢，可能会体现为操做执行下去好久返回结果，或CSV操做写入数据效率低下

所以建议对于群集网络类型3的群集网卡，规划好网络质量，确保不会出现丢包现象，默认状况下针对于这三种流量会由群集网络类型3的网卡来作，若是一旦群集网络类型3的网卡失败，那么群集会经过网络拓扑生成器从新规划流量群集通讯流量由网络类型1执行，但必定不会让网络类型0执行。

群集网络类型3的网卡咱们一般须要额外配置一些东西，例如不要设置网卡DNS 服务器、WINS 服务器或默认网关，取消群集类型3网卡DNS注册，禁用Netbios，调整网卡顺序，让群集类型1网卡最前，确保群集类型3网卡在后面，这些设置大都是为了确保故障转移后，应用联机DNS能够直接快速使用群集类型1进行注册，确保出站网络链接时始终是网络类型1优先级最高，确保访问AD进行身份验证时对外网卡优先级最高，在WSFC 2012以后对于网卡顺序开始变得再也不重要，WSFC 2016时代已经取消了网卡访问顺序设置，所以大部分场景只须要去掉群集类型3网卡的DNS和Netbios注册便可

若是WSFC 2016群集是依赖于AD的群集，例如基于域验证的SQL Server群集，您担忧不设计网卡顺序，当进行AD域验证时万一挑选由群集类型3网卡进行，会由于网卡联系不到AD而超时，影响依赖于AD的群集应用程序性能，那么您能够选择经过Powwershell命令修改网卡接口度量值，以达到之前控制网卡顺序优先级的目的

配置命令以下，度量值越低优先级越高

Set-NetIPInterface -InterfaceAlias“LAN”-InterfaceMetric 1  

Set-NetIPInterface -InterfaceAlias“CLUS”-InterfaceMetric 2

Set-NetIPInterface -InterfaceAlias“ISCSI”-InterfaceMetric 3

若是群集应用不依赖于AD，或群集部署为工做组模型，那么彻底不必进行设置。

针对于咱们本文提到的节点运行情况检测，会由NetFT这个组件进行构建检测拓扑，NetFT一般指的是Failover Cluster Virtual Adapter，当咱们安装群集以后，在设备管理器里面显示隐藏设备能够看到有这样一个虚拟网络适配器，用ipconfig /all也能够看到这块网卡，可是并无配置IP地址，这个群集虚拟网络适配器的主要做用是帮助咱们构建一个群集中网络通讯的高可用拓扑，例如，咱们群集节点与节点之间要进行心跳检测，每隔一段时间，NetFT就会去帮咱们从新构建这个拓扑，例如节点1和节点2，分别有两块网卡，一块专用于群集网络，一块用于群集网络+管理网络，那么当NetFT检测到若是专用的群集网络不能执行心跳检测，就会动态切换至另一块网卡帮助咱们进行心跳检测，NetFT的功能主要就是帮助管理员自动构建群集先有的通讯拓扑，在最大程度的帮咱们确保群集网络均可以正常的通讯。

咱们已经知道了节点运行情况检测是基于UDP 3343端口发起的实际握手检测，可是每隔多少秒检测一次，检测的时间和阈值，是能够进行配置修改的。最终，咱们是要结合实际场景来修改更为合适的阈值。

例如，若是场景的需求是要求应用必须达到高可用，节点和应用很是重要必定不能出现问题，没有瞬时中断的状况，网络情况很是好，那么咱们就能够设置节点检测严格一些，例如每隔一秒检测一次，五次检测失败，就标记节点为故障状态，故障转移上面全部的资源应用。

若是场景就是避免不了瞬时中断的状况，例如客户的网卡就是不太稳定 会突然断掉又立刻好了，系统很慢，检测信号maybe不会那么快响应，这时候您也能够把检测阈值设置的宽松一些，例如针对这种瞬时中断的场景，设置当20次检测失败时才触发故障转移操做

微软的建议首先是检测时间不要更改，始终保持每隔一秒进行一次全网心跳检测，其次是检测失败次数不要改的过于宽松，最长建议设置为20次，若是设置的超过20次，设置次数过多，会致使应用宕机好久才会被发现，延迟宕机时间，上面全部应用都会受到影响，所以微软建议宽松的阈值最高为20次。

其实更改这样一个节点检测的阈值很简单，一条命令的事情，但更多的是咱们要思考应用的运行情况，来选择最适合的阈值

若是说您的环境，对于应用的可用性要求的很严格，一旦节点出现问题，应用须要马上被故障转移到其它节点上，且您的环境中网络质量很高，不会出现丢包，瞬时中断的状况，那么您能够设置检测阈值为5或10，这样带来的好处是应用始终在最可靠的节点运行，只要应用当前运做节点5次检测lost，马上failover到其它节点，但随之带来的问题是，必定要确保网络环境无瞬时中断，一旦出现瞬时中断的状况，应用会频繁的进行failover，所以设置检测阈值严格的前提，必定是对于应用可用性要求严格，网络环境足够稳定。

若是说您的环境，网络质量不高，确实会存在瞬时中断，检测信号有时不会及时响应，那么您能够选择设置检测阈值宽松一些，最高建议设置到20次信号丢失，再进行故障转移，这是个微软的最佳实践。设置检测阈值宽松，带来的好处是，确保节点正常状况下不会被故障转移，允许20次信号检测失败，maybe是由于节点距离远，或者有瞬时中断的状况。带来的坏处是，若是设置的阈值过于宽松，将会延迟宕机时间，例如，若是节点确实宕机了，可是却在60次检测后才触发故障转移，本来5次检测后就该故障转移的，所以这额外的55次检测的过程就是额外的宕机时间。

对于设置节点检测阈值宽松这件事情，一个层面是解决跨子网检测的状况，例如北京2节点，广州2节点，这样一个四节点跨地域跨子网的群集，因为网络链路过于复杂，5次检测有时确实会由于网络链路而致使检测失败，触发故障转移，所以您应该调整他们的检测阈值，但最多不要超过20，另一点，调整检测阈值宽松，也是为了应对瞬时中断的问题，若是网络环境质量不高，不够稳定，会出现没法避免的丢包，但又不想频繁的故障转移，那么也能够调整检测阈值为20。

针对于瞬时中断的状况，WSFC 2016里面已经有了新的技术，即VM弹性，默认状况下该功能被开启，对于虚拟化群集来说，微软默认认为环境会存在瞬时中断的问题，所以对于虚拟机资源新增了两个状态，若是240秒内出现瞬时故障，则节点进入隔离状态，虚拟机会处于无监视状态，虚拟机仍然能够正常运行或暂停。若是1小时内节点三次被隔离，则群集认为节点存在问题，须要被完全排查，所以会被置为检疫状态，实时迁移全部虚拟机到其它节点，到达7200秒时间以前，检疫节点会被排查，不会正常加入群集。

WSFC 2016里面的VM弹性技术，主要提出的是一种新的思路，微软知道对于虚拟化群集瞬时中断比较多，常常由于网络质量而致使故障转移，因此新增了隔离到检疫到正常修复加入的流程。可是这项功能仅针对于VM资源有效，且默认的隔离时间过长，若是要使用这项功能，首先你须要了解它，老王在前面博客有详细写，而后须要调整这些阈值，240秒，3次隔离进检疫，检疫7200秒。若是不想要这项功能，也能够直接关闭。则群集又回到之前彻底参照运行情况检测阈值设定进行故障转移，须要注意，运行情况检测针对于节点生效，一旦运行情况检测阈值达到，全部节点资源将会被failover，而VM弹×××，则隔离状态下，只有虚拟机会被置为未监视状态。所以你们能够根据实际场景选择要是用的功能。

OK，涉及到的理论都讲清楚了，接下来看操做命令就简单多了

调整运行情况检测阈值涉及到的参数以下

Delay为检测频率，Threshold为咱们说的检测阈值

除了下表中列出的，在2012时代还有一种状况，即节点添加Hyper-V角色做为Hyper-V群集，那么SameSubnetThreshold会被自动设置为10，CrossSubnetThreshold会被自动设置为20，猜测多是由于微软考虑Hyper-V上面虚拟机可能不少，5会致使频繁故障转移，故障转移时间也较长，并且也考虑到瞬时中断状况，所以虚拟化场景下，10和20为最佳

参数	WSFC2012R2	WSFC2016	最大值
SameSubnetDelay	1秒	1秒	2秒
SameSubnetThreshold	5心跳	10个心跳	120心跳
CrossSubnetDelay	1秒	1秒	4秒
CrossSubnetThreshold	5心跳	20个心跳	120心跳
CrossSiteDelay	NA	1秒	4秒
CrossSiteThreshold	NA	20个心跳	120心跳

在WSFC 2016以前，当咱们要调整节点运行情况检测阈值时只有相同子网和跨子网，这四个选项能够设置，CrossSite是新增的功能

这里的Site是依据咱们经过定义故障域，定义出来的站点为基准，所以跨站点心跳检测能够被归置到站点感知功能下

在WSFC 2016中，若是咱们分别对这三种场景，同子网，跨子网，跨站点进行了设置，不一样的场景下它们的生效优先级也不同

若是集群节点在同一个站点和相同的子网中，则相同子网的阈值生效

若是集群节点在同一个站点和两个不一样的子网中，则跨子网阈值生效

若是集群节点位于不一样的站点和不一样的子网中，则跨站点阈值将覆盖跨子网阈值

若是集群节点位于不一样的站点和相同的子网中，则跨站点阈值将覆盖相同子网的阈值

这里和以前最大的不一样点，在于多了不一样站点的概念，若是你定了节点在不一样站点，那么群集就会认为，他们之间离得很远，须要被应用不一样站点的检测阈值，那怕它们在同一个子网

这很适合stretch vlan的场景，即有的群集节点虽然离得很远，可是存在同一个子网下，所以你没办法控制，说其它节点对于这个远程节点要进行比较宽松的信号检测，由于都在一个子网，因此只会被应用SameSubnetThreshold，但这个节点上面也会承载应用，若是就是由于网络链路过长，或瞬时中断，致使信号检测失准，发生故障转移，那咱们也没办法控制，最终只能要求更改子网，但在WSFC 2016，咱们能够把该节点逻辑定义到另一个Site，这样，虽然仍是同子网，可是一旦对于远程节点进行运行情况检测，会应用上跨Site的宽松检测策略

#获取WSFC节点运行情况检测相关设置

Get-Cluster | fl *delay*

Get-Cluster | fl *threshold*

#调整同子网心跳检测阈值为15

(Get-Cluster).SamSubnetThreshold = 15

#调整跨子网心跳检测阈值为15

(Get-Cluster).CrossSubnetThreshold = 15

当前环境继续延续上篇博客，HV01 HV02 属于北京站点，HV03, HV04属于上海站点

查看ClusterLog，能够看到由NETFT构建的运行情况检测拓扑

针对于同子网同站点，应用SamSubnetThteshold检测策略

针对于不一样子网跨站点，应用CrossSiteThteshold检测策略

针对相同子网不一样Site，应用CrossSiteThteshold检测策略

#手动移动HV01至上海站点

再次查看发现从18.0.0.9 到 18.0.0.10 已经应用CrossSiteThteshold检测标准！

针对不一样子网，但其中一个节点退出Site，应用跨Site节点检测策略

针对相同站点，但其中一个节点移动为跨子网，应用跨子网节点检测策略

移动HV01回北京站点

修改HV01为上海子网IP

查看ClusterLog发现其它节点到HV01节点的运行情况检测已经应用CrossSubnetThreshold

一旦18.0.0.0网段没法经过心跳检测，NetFT会从新路由其它网络进行运行情况检测，这时一旦选择了跨子网的网段，又在同一个Site，那么将会应用跨子网的运行情况检测策略。