WSFC資源死鎖案例

發(fā)布時間：2020-06-03 15:42:02 來源：網(wǎng)絡(luò) 閱讀：3384 作者：老收藏家欄目：建站服務(wù)器

之前在WSFC日志分析進(jìn)階篇中曾經(jīng)提到過一些關(guān)于WSFC底層原理，例如Resource.dll，RHS，RCM，了解這些組件對于我們后期做群集排錯有莫大的幫助，本文我們就通過一個實(shí)際的資源死鎖的案例，來幫助大家加深下印象

首先，Resource.dll是干嘛的呢，Resouce.dll是每個群集資源所賴以生存的組件，只有有Resouce.dll，群集資源才可以正常運(yùn)作，resource.dll里面包括了對于群集資源的檢測Look alive 和is alive的檢測函數(shù)定義，以及資源的操作調(diào)用定義

RHS是群集資源主機(jī)子系統(tǒng)，以進(jìn)程的方式運(yùn)作，負(fù)責(zé)監(jiān)視群集資源的運(yùn)行情況是否正常，RHS會根據(jù)資源resource.dll里面定義的Look alive 和is alive方法對群集資源進(jìn)行監(jiān)視

當(dāng)經(jīng)過is alive方法測試后，確認(rèn)該資源失敗，則RHS報(bào)告失敗給RCM資源控制管理器組件，RCM會把資源按照資源故障故障策略定義對資源進(jìn)行重啟重試，故障轉(zhuǎn)移。

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

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

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

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

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

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

針對單個資源級別

(Get-ClusterResource“資源名稱”).DeadlockTimeout=300000

針對資源類型級別

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

下一層保護(hù)是當(dāng)集群發(fā)出終止RHS進(jìn)程的請求時，它將等待四次DeadlockTimeout值（默認(rèn)等于20分鐘），以使RHS進(jìn)程終止，如果RHS在20分鐘內(nèi)沒有終止，則集群將認(rèn)為服務(wù)器有一些嚴(yán)重的健康問題，并會檢查服務(wù)器以強(qiáng)制故障轉(zhuǎn)移和恢復(fù)，這段時間群集資源可能會停止訪問，錯誤檢查代碼將為Stop 0x0000009E（Parameter1，Parameter2，0x0000000000000005，Parameter4）。注意：如果RHS進(jìn)程未能終止，則Parameter3將始終為0x5的值

WSFC 2008R2時代之后

群集IP，群集網(wǎng)絡(luò)名稱，仲裁資源單獨(dú)在一個RHS監(jiān)視進(jìn)程工作

群集可用磁盤，CSV 單獨(dú)在一個RHS監(jiān)視進(jìn)程工作

其它群集資源在專用RHS監(jiān)視進(jìn)程工作

通過這也可以避免以前所有資源都在一個RHS進(jìn)程托管的弊病，2008R2之前，群集資源都在同一個RHS進(jìn)程托管，只要其中一個群集資源崩潰，那么整個RHS進(jìn)程可能會失敗，并且托管的所有資源都將失敗。

隔離開了之后，如果單個群集資源無響應(yīng)導(dǎo)致RHS崩潰，群集服務(wù)將認(rèn)為特定的資源可疑，并且需要被隔離。群集服務(wù)將自動設(shè)置資源公共屬性SeparateMonitor 以將該資源標(biāo)記為在其自己的專用RHS進(jìn)程中運(yùn)行，以便在資源再次無響應(yīng)的情況下; 它不會影響其它群集資源進(jìn)程

在2008R2時×××始，一旦發(fā)生了我們上面講的資源死鎖，即應(yīng)用不響應(yīng)is alive請求，將會生成WER報(bào)告，在控制面板中可以看到，并收集到該死鎖RHS進(jìn)程的dump，WSFC2016時代，這項(xiàng)功能更進(jìn)一步，可以顯示更多資源死鎖的細(xì)部信息，幫助排錯人員Zero Downtime Debugging

WSFC資源死鎖案例

OK，上面基本的信息交代完成后，下面我們來看這次的資源死鎖案例

有時候在一些場景下會遇到很多莫名奇妙的問題，尤其是你在做變更的時候，一起變更好多內(nèi)容，忽然出問題了，你也不知道是哪個變更操作導(dǎo)致的問題，這是最頭痛的，這時就需要好好坐下來深入的看看問題

本次的問題大概是一次更新變更，某地針對一個批次的群集節(jié)點(diǎn)進(jìn)行補(bǔ)丁更新，其中兩臺節(jié)點(diǎn)的群集更新完成后重啟機(jī)器，機(jī)器運(yùn)行緩慢，群集服務(wù)無法啟動，嘗試在兩個群集節(jié)點(diǎn)上面分別執(zhí)行強(qiáng)制仲裁，無果，強(qiáng)制仲裁之后，群集又立刻失敗，見證磁盤和群集磁盤始終無法聯(lián)機(jī)。

最初懷疑是由于系統(tǒng)更新補(bǔ)丁導(dǎo)致，卸載補(bǔ)丁后發(fā)現(xiàn)問題依舊，開始進(jìn)行群集層面排錯，首先檢查群集到存儲之間是否正常，對于鏈路確認(rèn)無問題，接下來從群集事件日志開始看起

查看群集事件日志

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.

大部分群集事件日志表明群集磁盤無法上線，并且出現(xiàn)deadlock以及RHS進(jìn)程超時

查看clusterlog看到，群集磁盤2出現(xiàn)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)

目前日志表明群集問題和群集磁盤在兩個節(jié)點(diǎn)都無法上線相關(guān)，群集磁盤無法訪問，并出現(xiàn)RHS deadlock.表明群集磁盤IO沒有得到及時回應(yīng)

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

但是目前我們還是沒辦法判斷問題到底是因?yàn)槭裁磳?dǎo)致的，根據(jù)bugcheck指示，進(jìn)一步我們還需要查看dump文件，來查看導(dǎo)致資源死鎖的原因，dump可以是WER里面的進(jìn)程dump，最好可以是一個完整的memory dump，本案例我們以完整memory.dmp為例

從dump中得到發(fā)生deadlock的RHS進(jìn)程是fffffab030cce600，進(jìn)程中有三個線程，其中兩個線程等待在系統(tǒng)線程fffffab0`30f0a6d0，callstack如下,此系統(tǒng)線程在等待TmXPFlt.sys驅(qū)動

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進(jìn)程中的另外一個線程fffffab0`30ef2b50同樣是等待在TmXPFlt.sys驅(qū)動上