WSFC資源死鎖案例

發布時間：2020-06-03 15:42:02 來源：網絡閱讀：3384 作者：老收藏家欄目：建站服務器

之前在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方法對群集資源進行監視

當經過is alive方法測試后，確認該資源失敗，則RHS報告失敗給RCM資源控制管理器組件，RCM會把資源按照資源故障故障策略定義對資源進行重啟重試，故障轉移。

基本上Resource.dll負責定義應該怎么看病，看病的操作步驟，RHS遵循Resource.dll的看病方法和操作步驟看病，RHS判斷出病情后，交由RCM護士，RCM護士決定應該按照策略去打針，還是住院。

今天我們主要關注的是RHS看的這個階段，正常情況下來說，RHS要不就是看好，要不就是不好，好就報告正常，接著循環檢測，不好RCM就開始按照策略做處理。

但是除了這兩種情況，還有另外一種常見的情況，即資源死鎖

什么是資源死鎖呢，就是說RHS給群集資源發送is alive檢測信號，但是群集資源遲遲不給響應，那你不響應的話，群集怎么知道你到底存不存活呢，群集不會一直等待你資源的響應的，群集一定要準確確認每個資源可不可用，經過一段時間后，群集就會判定資源進入Deadlock死鎖，RHS會把你這個不響應的群集資源放在一個單獨隔離的RHS進程中，然后RHS嘗試重新啟動該資源，創建死鎖WER報告。

對于資源死鎖的時間，WSFC 2008R2開始默認情況下群集會等待5分鐘，如果5分鐘內，資源還是沒有響應，則資源死鎖，群集會把該資源單獨RHS進程中進行重啟嘗試。

在2008R2時×××始Deadlock資源死鎖的時間可以通過以下命令更改

針對單個資源級別

(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

WSFC資源死鎖案例

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驅動上