WSFC资源死锁案例

时间 2019-11-11

标签 wsfc 资源死锁案例繁體版

原文原文链接

以前在WSFC日志分析进阶篇中曾经提到过一些关于WSFC底层原理，例如Resource.dll，RHS，RCM，了解这些组件对于咱们后期作群集排错有莫大的帮助，本文咱们就经过一个实际的资源死锁的案例，来帮助你们加深下印象服务器

首先，Resource.dll是干吗的呢，Resouce.dll是每一个群集资源所赖以生存的组件，只有有Resouce.dll，群集资源才能够正常运做，resource.dll里面包括了对于群集资源的检测Look alive 和is alive的检测函数定义，以及资源的操做调用定义网络

RHS是群集资源主机子系统，以进程的方式运做，负责监视群集资源的运行状况是否正常，RHS会根据资源resource.dll里面定义的Look alive 和is alive方法对群集资源进行监视ide

当通过is alive方法测试后，确认该资源失败，则RHS报告失败给RCM资源控制管理器组件，RCM会把资源按照资源故障故障策略定义对资源进行重启重试，故障转移。函数

基本上Resource.dll负责定义应该怎么看病，看病的操做步骤，RHS遵循Resource.dll的看病方法和操做步骤看病，RHS判断出病情后，交由RCM护士，RCM护士决定应该按照策略去打针，仍是住院。测试

今天咱们主要关注的是RHS看的这个阶段，正常状况下来讲，RHS要不就是看好，要不就是很差，好就报告正常，接着循环检测，很差RCM就开始按照策略作处理。this

可是除了这两种状况，还有另一种常见的状况，即资源死锁spa

什么是资源死锁呢，就是说RHS给群集资源发送is alive检测信号，可是群集资源迟迟不给响应，那你不响应的话，群集怎么知道你到底存不存活呢，群集不会一直等待你资源的响应的，群集必定要准确确认每一个资源可不可用，通过一段时间后，群集就会断定资源进入Deadlock死锁，RHS会把你这个不响应的群集资源放在一个单独隔离的RHS进程中，而后RHS尝试从新启动该资源，建立死锁WER报告。线程

对于资源死锁的时间，WSFC 2008R2开始默认状况下群集会等待5分钟，若是5分钟内，资源仍是没有响应，则资源死锁，群集会把该资源单独RHS进程中进行重启尝试。
3d

在2008R2时×××始Deadlock资源死锁的时间能够经过如下命令更改rest

针对单个资源级别

(Get-ClusterResource“资源名称”).DeadlockTimeout=300000

针对资源类型级别

(Get-ClusterResourceType“Virtual Machine”).DeadlockTimeout=300000

下一层保护是当集群发出终止RHS进程的请求时，它将等待四次DeadlockTimeout值（默认等于20分钟），以使RHS进程终止，若是RHS在20分钟内没有终止，则集群将认为服务器有一些严重的健康问题，并会检查服务器以强制故障转移和恢复，这段时间群集资源可能会中止访问，错误检查代码将为Stop 0x0000009E（Parameter1，Parameter2，0x0000000000000005，Parameter4）。注意：若是RHS进程未能终止，则Parameter3将始终为0x5的值

WSFC 2008R2时代以后

群集IP，群集网络名称，仲裁资源单独在一个RHS监视进程工做

群集可用磁盘，CSV 单独在一个RHS监视进程工做

其它群集资源在专用RHS监视进程工做

经过这也能够避免之前全部资源都在一个RHS进程托管的弊病，2008R2以前，群集资源都在同一个RHS进程托管，只要其中一个群集资源崩溃，那么整个RHS进程可能会失败，而且托管的全部资源都将失败。

隔离开了以后，若是单个群集资源无响应致使RHS崩溃，群集服务将认为特定的资源可疑，而且须要被隔离。群集服务将自动设置资源公共属性SeparateMonitor 以将该资源标记为在其本身的专用RHS进程中运行，以便在资源再次无响应的状况下; 它不会影响其它群集资源进程

在2008R2时×××始，一旦发生了咱们上面讲的资源死锁，即应用不响应is alive请求，将会生成WER报告，在控制面板中能够看到，并收集到该死锁RHS进程的dump，WSFC2016时代，这项功能更进一步，能够显示更多资源死锁的细部信息，帮助排错人员Zero Downtime Debugging

OK，上面基本的信息交代完成后，下面咱们来看此次的资源死锁案例

有时候在一些场景下会遇到不少莫名奇妙的问题，尤为是你在作变动的时候，一块儿变动好多内容，突然出问题了，你也不知道是哪一个变动操做致使的问题，这是最头痛的，这时就须要好好坐下来深刻的看看问题

本次的问题大概是一次更新变动，某地针对一个批次的群集节点进行补丁更新，其中两台节点的群集更新完成后重启机器，机器运行缓慢，群集服务没法启动，尝试在两个群集节点上面分别执行强制仲裁，无果，强制仲裁以后，群集又马上失败，见证磁盘和群集磁盘始终没法联机。

最初怀疑是因为系统更新补丁致使，卸载补丁后发现问题依旧，开始进行群集层面排错，首先检查群集到存储之间是否正常，对于链路确认无问题，接下来从群集事件日志开始看起

查看群集事件日志

Log Name: System

Source: Microsoft-Windows-FailoverClustering

Date:

Event ID: 1573

Task Category: Quorum Manager

Level: Error

Keywords:

User: SYSTEM

Computer:

Description:

Node 'ZQ1' failed to form a cluster. This was because the witness was not accessible. Please ensure that the witness resource is online and available.

Log Name: System

Source: Microsoft-Windows-FailoverClustering

Date:

Event ID: 1069

Task Category: Resource Control Manager

Level: Error

Keywords:

User: SYSTEM

Computer:

Description:

Cluster resource '群集磁盘 1' in clustered role 'wlc' failed.

Log Name: System

Source: Microsoft-Windows-FailoverClustering

Date:

Event ID: 1230

Task Category: Resource Control Manager

Level: Error

Keywords:

User: SYSTEM

Computer:

Description:

A component on the server did not respond in a timely fashion. This caused the cluster resource '群集磁盘 1' (resource type '', DLL 'clusres.dll') to exceed its time-out threshold. As part of cluster health detection, recovery actions will be taken. The cluster will try to automatically recover by terminating and restarting the Resource Hosting Subsystem (RHS) process that is running this resource. Verify that the underlying infrastructure (such as storage, networking, or services) that are associated with the resource are functioning correctly.

大部分群集事件日志代表群集磁盘没法上线，而且出现deadlock以及RHS进程超时

查看clusterlog看到，群集磁盘2出现deadlock

00001148.00001158::2017/09/15-20:24:36.365 ERR [RHS] RhsCall::DeadlockMonitor: Call ONLINERESOURCE timed out for resource 'èoˉ′ì 2'.
00001148.00001158::2017/09/15-20:24:36.365 ERR [RHS] Resource èoˉ′ì 2 handling deadlock. Cleaning current operation.
00001148.00001158::2017/09/15-20:24:36.365 ERR [RHS] About to send WER report.
0000084c.0000159c::2017/09/15-20:24:36.365 WARN [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'èoˉ′ì 2', gen(0) result 5018.
0000084c.0000159c::2017/09/15-20:24:36.365 INFO [RCM] TransitionToState(èoˉ′ì 2) OnlinePending-->ProcessingFailure.
0000084c.0000159c::2017/09/15-20:24:36.365 ERR [RCM] rcm::RcmResource::HandleFailure: (èoˉ′ì 2)

目前日志代表群集问题和群集磁盘在两个节点都没法上线相关，群集磁盘没法访问，并出现RHS deadlock.代表群集磁盘IO没有获得及时回应

The computer has rebooted from a bugcheck. The bugcheck was: 0x0000009e (0xfffffab030cce600, 0x00000000000004b0, 0x0000000000000000, 0x0000000000000000). A dump was saved in: C:\Windows\MEMORY.DMP

可是目前咱们仍是没办法判断问题究竟是由于什么致使的，根据bugcheck指示，进一步咱们还须要查看dump文件，来查看致使资源死锁的缘由，dump能够是WER里面的进程dump，最好能够是一个完整的memory dump，本案例咱们以完整memory.dmp为例

从dump中获得发生deadlock的RHS进程是fffffab030cce600，进程中有三个线程，其中两个线程等待在系统线程fffffab0`30f0a6d0，callstack以下,此系统线程在等待TmXPFlt.sys驱动

00 fffff880`08d92420 fffff800`01ad3142 nt!KiSwapContext+0x7a

01 fffff880`08d92560 fffff800`01ad596f nt!KiCommitThreadWait+0x1d2

02 fffff880`08d925f0 fffff880`056880e4 nt!KeWaitForSingleObject+0x19f

03 fffff880`08d92690 fffff880`05680838 TmXPFlt+0xb0e4

04 fffff880`08d926f0 fffff880`05670be2 TmXPFlt+0x3838

05 fffff880`08d927e0 fffff880`0148c0f7 TmPreFlt!TmpQueryFullName+0xb66

06 fffff880`08d928a0 fffff880`0148ea0a fltmgr!FltpPerformPreCallbacks+0x50b

07 fffff880`08d929b0 fffff880`014aa2a3 fltmgr!FltpPassThroughInternal+0x4a

08 fffff880`08d929e0 fffff800`01dd22bb fltmgr!FltpCreate+0x293

09 fffff880`08d92a90 fffff800`01dcddde nt!IopParseDevice+0x14e2

0a fffff880`08d92bf0 fffff800`01dce8c6 nt!ObpLookupObjectName+0x784

0b fffff880`08d92cf0 fffff800`01dd06bc nt!ObOpenObjectByName+0x306

0c fffff880`08d92dc0 fffff800`01d7316b nt!IopCreateFile+0x2bc

0d fffff880`08d92e60 fffff880`014b1f60 nt!IoCreateFileEx+0xfb

0e fffff880`08d92f00 fffff880`014bdc61 fltmgr!FltpCreateFile+0x194

0f fffff880`08d92ff0 fffff880`014e3506 fltmgr!FltCreateFileEx+0x91

10 fffff880`08d93080 fffff880`014de40e dfsrro!DfsrRopLoadPrefixEntriesFromFile+0x416

11 fffff880`08d93250 fffff880`014b00c6 dfsrro!DfsrRoNewInstanceCallback+0x2e2

12 fffff880`08d932b0 fffff880`014af0cb fltmgr!FltpDoInstanceSetupNotification+0x86

13 fffff880`08d93310 fffff880`014afe81 fltmgr!FltpInitInstance+0x27b

14 fffff880`08d93380 fffff880`014b0d5b fltmgr!FltpCreateInstanceFromName+0x1d1

15 fffff880`08d93450 fffff880`014aed6c fltmgr!FltpEnumerateRegistryInstances+0x15b

16 fffff880`08d934f0 fffff880`014aa3f0 fltmgr!FltpDoFilterNotificationForNewVolume+0xec

17 fffff880`08d93560 fffff800`01dd22bb fltmgr!FltpCreate+0x3e0

18 fffff880`08d93610 fffff800`01dcddde nt!IopParseDevice+0x14e2

19 fffff880`08d93770 fffff800`01dce8c6 nt!ObpLookupObjectName+0x784

1a fffff880`08d93870 fffff800`01dd06bc nt!ObOpenObjectByName+0x306

1b fffff880`08d93940 fffff800`01ddbd34 nt!IopCreateFile+0x2bc

1c fffff880`08d939e0 fffff800`01acd0d3 nt!NtCreateFile+0x78

1d fffff880`08d93a70 00000000`76fac28a nt!KiSystemServiceCopyEnd+0x13

1e 00000000`0219f748 00000000`00000000 0x76fac28a

RHS进程中的另一个线程fffffab0`30ef2b50一样是等待在TmXPFlt.sys驱动上