在群集日誌分析基礎篇中，老王為大家介紹了幾種群集日誌的位置和用途，例如事件管理器系統日誌中可以告訴我們，當群集出現故障時，大體是什麽原因導致的，給出一個方向，應用程序日誌裏面的FailoverClustering - Manager -Diagnostic日誌可以幫助我們在事件發生後回溯執行過那些操作，FailoverClustering - Operational日誌可以幫助我們了解群集資源，網絡檢測，安全的基本變化情況是否正常，還有群集管理器中的匯總日誌，這些日誌，通常情況下可以為我們指出一些明確的方向，告訴我們應該去看什麽的問題，可以看見一些基本的資源變化信息和操作記錄，幫助我們回溯一部分問題。

但是在一些情況下，可能出現的問題，在這些日誌中並沒有給出明確的解釋，或者我們認為可能並不是事件日誌裏面所說的問題，我們仍需要更加詳細的信息，這時候我們就可以去看群集診斷日誌，什麽是群集診斷日誌，簡單來說，群集診斷就是記錄群集運行過程中的所有內部執行過程，你能想到的，資源上線下線遷移，運行狀況檢測，等等，幾乎所有和群集運行有關的東西都會被記錄在這個診斷日誌中，2012時代開始默認情況可以在事件管理中看到，群集一邊運行著，這個事件日誌就會不斷的更新增長

診斷日誌和其它日誌最大的不同就是，其它的群集相關日誌也會記錄群集的運行狀況，資源變化，但是呈現在事件日誌中都相對友好一些，基本上不會出現很多底層的語言，讓我們看到基本上就可以看懂，而診斷日誌則不同，在診斷日誌中，會把群集中的一些核心組件也呈現出來，例如RHS,RCM,NetFT等核心組件的運作也會呈現出來，因此診斷日誌也最為深入和詳細，不論是對於群集做深入的排錯，還是希望了解群集內部的運作原理，學會看診斷日誌是最佳的選擇。

在看診斷日誌的時候，您可能會看到裏面有很多群集核心組件的縮寫，例如下圖這些，初學者如果看不懂縮寫的意思，可以復制下來，去網上搜索，然後記下來，這裏老王挑選三個我認為比較主要的核心組件來和大家解釋

RHS：中文 資源主機子系統，實際運作時會呈現成一個個的系統進程，這個組件幹嘛的呢，它會根據Resource.dll裏面定義的檢測規則，以及我們定義的檢測策略，去實時監控各種群集對象的運行狀況，例如群集磁盤，群集IP地址，群集網絡名稱，應用程序，RHS實際檢測的時候主要是依據當前已經加載的群集資源對象Resource.dll中兩個參數來判斷群集資源的存活與否狀態，分別是looksalive check，is alive check

顧名思義looksalive check就是說，資源看起來是活著的，因此，在looksalive check過程中，通常情況下RHS會執行相對來說簡單的檢測操作，例如每隔3秒檢測群集磁盤是否接受預留請求請求。如果通過looksalive check並不能有效的檢測出資源是否存活，RHS還會嘗試使用is alive check的方式進行具體的檢測，相比較looksalive來說is alive則會從更加深入的角度去檢測資源的存活狀態，例如，is alive對於群集磁盤的檢測會實際要求執行一個Dir命令，針對於SQL的檢測，會實際執行一個查詢來確認SQL群集資源的存活，因此lookalive的檢測通常是基本化的，is alive檢測通常是徹底的深入的，如果is alive的檢測也失敗，則RHS會報告資源的狀態為失敗，然後反饋給RCM組件進行進一步的資源處理

RHS，不論是對於任何的一個群集資源都會去嘗試執行looksalive check，is alive check的檢測操作，但是針對於不同的群集資源對象，檢測的方法都會不同，針對於一部分群集默認資源，例如群集IP，群集資源，群集網絡名稱，RHS會通過加載默認的ClusRes.DLL去進行檢測，不同的群集對象可能會用到不同的Resource.dll，開發人員可以把自己的程序與WSFC集成，編寫自己程序的Resouce.dll融入到群集中

通常情況下，Resource.dll會起到以下兩個主要作用，一個起到應用程序與群集之間的代理作用，當我們在故障群集管理器上面針對於群集對象聯機，脫機，啟用，禁用等操作時，實際上要求會直接發給資源對應的Resource.dll，再由Resource.dll去通知資源進行狀態變化，因此如果要自己編寫Resource.dll，首先要確保dll可以對相應的資源對象能夠執行管理操作感知

另外Resource.dll還應該明確定義出，針對於特定資源類型的looksalive check和is alive check的檢測方法，當is alive檢測失敗時候應該返回False參數，RHS收到False參數後會把資源標記為ClusterResourceFailed狀態

RHS檢測系統會根據所有的定義在群集中的Resource.dll裏面的looksalive check和is alive check規則去檢測群集資源的存活，通常情況下，如果要把自定義開發的應用與群集化，建議還是編寫好Resource.dll，這樣群集可以進行更加深入的檢測，否則只能通過默認ClusRes.DLL去檢測應用進程的基本狀況

例如微軟的SQL和Hyper-V群集化了之後，RHS都會通過它們自身單獨的Resource.dll規則去進行檢測，SQL Server群集化了之後會在群集中產生特定的SQL服務資源對象，同時也有自身特定的檢測方式，RHS可以實際上發出一個真實的查詢去is alive檢測SQL的存活，Hyper-V群集化了之後也會調用自身特定的Resource.dll，實現可以通過我們定義的高級策略來檢測來賓OS是否藍屏，來賓OS裏面的服務是否存活等等，當根據我們定義的檢測策略和is alive檢測，檢測到資源當前不存活，過陣子會在RHS中標記資源為失敗狀態並報告給RCM，然後RCM看到RHS的標記則會根據資源的故障轉移策略對資源嘗試執行故障轉移，重啟啟動等操作。

在之前2003時代，群集裏面所有資源都在一個RHS進程下面托管著，這樣子如果當一個資源對象因為檢測失敗，也會導致其它群集資源一起出現崩潰或重啟的情況，因此在2008時代開始，微軟將一部分群集自身的資源對象，例如，群集IP，群集名稱，群集磁盤等可以被群集共享的資源放在一個單獨的RHS進程中，我們在群集中創建的群集應用可以在單獨的RHS進程中工作，這樣一旦單個群集應用的RHS檢測失敗或進程出現問題，並不會影響到群集其它資源的工作，可以通過 cluster . res /prop命令來查看群集資源的所有屬性

其中幾個和RHS有關的關鍵參數

MonitorProcessID： 群集資源關聯的RHS進程ID，可以通過查看這個參數來判斷分析那些群集資源當前處在同一進程中

SeparateMonitor： 指示資源是否已被放置在單獨的監視器中（0：否，1：是）

IsAlivePoleInterval： 默認值如圖所示，表示它正在使用該特定資源類型的默認設置。

LooksAlivePollInterval： 默認值如圖所示，表示它正在使用該特定資源類型的默認設置。

DeadlockTimeout： 默認設置，表示5分鐘。

2008R2時代開始群集資源已經不是都在同一個RHS進程下面運作，針對於關鍵群集資源和群集應用實際上已經分開了不同的進程，來避免因為單個群集應用崩潰而導致其它群集資源崩潰的情況，但是默認情況下大部分群集資源仍在一個共享配置的監視器中運作，當RHS檢測到一個群集資源失敗或dll崩潰，則會把它放置在一個獨立監視器中進行檢測，徹底防止它影響到其它群集資源，在針對群集進行resource.dll的調試時，你也需要把SeparateMonitor值設置為1，否則會因為調試可能時會讓共享監視器中其它資源失敗。

#設置群集資源在單獨的監視器中工作

(Get-ClusterResource “Resource Name”).SeparateMonitor = 1

例如在2008R2時代的虛擬化群集場景，默認情況下所有虛擬機都在同一個共享監視器下運行，一旦發生單個虛擬機發生資源死鎖情況，可能會導致上面所有虛擬機都無法使用，因此可以把出現問題的虛擬機單獨放在隔離監視器中運行，在實際使用中，對於隔離監視器的使用需要謹慎，因為有時候啟用單獨的隔離監視器就會出現單獨的RHS進程，每個進程都要占用CPU和內存資源，因此需要在考慮服務器資源的情況下啟用該高級功能。

RCM：Resource Control Manager ，資源控制管理器，顧名思義，這個組件是幫助我們去管理群集資源的，小到群集磁盤，大到一個群集組，都是通過RCM來幫助我們進行操作管理，可以說，RHS的功能主要是進行檢測，發生問題，然後報告問題，而RCM則是實際做處理的，它會根據我們對於群集的操作指令，或者RHS檢測到的結果，來進行資源的上線，離線，掛起嘗試，故障切換等操作

RCM在執行操作的時候會考慮兩點，一點是依賴關系，例如我們要聯機上線一個群集組，群集組依賴於群集網絡名稱，網絡名稱又依賴於網絡IP，因此RCM在處理我們這個聯機請求的時候，會先去嘗試構建出依賴關系，然後按照依賴關系邏輯逐步完成資源的聯機，例如會先去嘗試聯機網絡IP，網絡IP聯機之後嘗試聯機網絡名稱，最終依賴的資源都已經聯機成果，才聯機整個群集組。

另外一點，當RCM執行操作的時候，默認情況會使用資源定義的故障策略，以及高級策略來進行評估，最終做出合適的操作，例如，當RHS報告群集資源失敗，RCM會按照故障轉移策略每隔一段時間嘗試聯機掛起，經過一段時間無法掛起，會把資源置為失敗狀態，一段時間依然嘗試重啟啟動該資源，如果始終無法重現啟動成功，還會嘗試把資源移動至其它節點進行嘗試，如果都無法成功，會把資源置為失敗狀態。

由此可以看出，RCM組件主要的作用就是用於執行群集資源的管理操作，以及當群集資源，群集組出現故障時，評估依賴關系，故障策略，高級策略來對資源進行嘗試，故障轉移，狀態確認。

NetFT：NetFT通常指的是Failover Cluster Virtual Adapter，當我們安裝群集之後，在設備管理器裏面顯示隱藏設備可以看到有這樣一個虛擬網絡適配器，用ipconfig /all也可以看到這塊網卡，但是並沒有配置IP地址，這個群集虛擬網絡適配器的主要作用是幫助我們構建一個群集中網絡通信的高可用拓撲，例如，我們群集節點與節點之間要進行心跳檢測，每隔一段時間，NetFT就會去幫我們重新構建這個拓撲，例如節點1和節點2，分別有兩塊網卡，一塊專用於群集網絡，一塊用於群集網絡+管理網絡，那麽當NetFT檢測到如果專用的群集網絡不能執行心跳檢測，就會動態切換至另外一塊網卡幫助我們進行心跳檢測，NetFT的功能主要就是幫助管理員自動構建群集先有的通信拓撲，在最大程度的幫我們確保群集網絡都可以正常的通信。

介紹了幾個重要的理論後，我們來實際看下群集的診斷日誌，到底長什麽樣子呢，默認情況下在2012時代診斷日誌可以在事件管理器中看到，但是由於是實時增長的，看起來不太直觀，我們很難在裏面快速找到自己想要的信息，所以除了事件管理器，我們也可以通過Powershell命令Get-ClusterLog來生成群集的診斷日誌，和事件管理器中的診斷日誌不同，當我們使用Get-Clusterlog獲取診斷群集日誌時，不論是2008還是2012，都會把事件管理器，或ETL文件裏面的診斷日誌合並，然後篩檢一部分，去掉無用的信息，只保留下來真正有用的診斷信息，形成一個log文件，便於管理員分析。

默認情況下如果我們直接在powershell中執行 Get-CluserLog就可以輸出群集的診斷日誌，打開之後就可以看到，但是，默認情況下2012R2裏面診斷日誌最大是300MB，一旦超過這個大小，則當日誌再出現時，會覆蓋掉之前日誌，2008時代是100MB的限制

如果直接執行Get-ClusterLog，將會輸出從群集開始到現在所有的Log，假設你的群集日誌沒有達到過300MB，沒有發生過覆蓋，會生成出所有的log，但是有時候生成這麽大的日誌會花費一些時間，而且Get-ClusterLog這條命令一旦執行下去，不單單是生成當前節點的診斷日誌，也會去讓其它節點也生成cluster.log到report目錄，因此，使用Get-ClusterLog時有一些參數可以配合使用

#日誌不多，可以直接運行Get-ClusterLog，會輸出從集群建立到現在所有的

Get-ClusterLog

#只希望輸出最後五分鐘的日誌

Get-Clusterlog -TimeSpan 5

#只希望指定的節點生成日誌

Get-Clusterlog -Node Nodename

#如果在不指定路徑的情況下，每次生成都會覆蓋Report目錄下已有的log，希望把各個節點的日誌統一生成到一個目錄下，可用利用Destination參數，在目錄中會看到帶有節點名字的各個log

Get-Clusterlog -Destination path

默認情況下cluster log的日誌級別為3，通常情況下Level 3已經足夠詳細，如果在進行一些診斷的時候，你也可以通過 Set-ClusterLog -Level 5 設置級別為5進行高級診斷,需要註意如果設置Level 5 會導致短時間內日誌持續飛速增長，建議診斷完成後及時恢復3

下面我們實際生成一下來看

生成完成的clusterlog默認會存在各節點的Report路徑下

打開之後界面如下

這時候你可能需要一個自己用的習慣的日誌分析用具

可以看到clusterlog似乎與我們其他地方看到的log不太一樣，到底應該如何去理解呢，我們以一個例子來看

進程ID：資源所在的16位RHS進程ID

線程ID：資源16位RHS線程ID

GMT時間：事件發生時的GMT時間，精確至毫秒級別，最初考慮到群集節點可能會是分布在不同的時區，所以使用了GMT，實際看的時候，東半球需要加上8小時，在2016群集中新增了UseLocalTime 參數，生成clusterlog的時候，如果我們確認節點都在同一時區可以使用UseLocalTime生成本地時間戳記

日誌級別：通常有INFO，ERR , WARN，DBG等狀態，其中可以在日誌分析中跟蹤ERR關鍵字

資源類別：是有那個類別的資源類型和群集組件產生的日誌

資源名稱：具體的資源名稱

說明：對於日誌的詳細說明

在Cluster.Log中有一些關鍵的屬性，大家在使用Cluster.Log的時候可以主要關註下，並且設置在分析工具中追蹤

OnlinePending：資源聯機掛起

OfflinePending：資源正在進行離線

Offline：資源離線

ProcessingFailure：資源失敗

通過直接在日誌分析工具中搜索相應的關鍵字，就可以看到附近發生的上下文過程

下面我們以幾個實際的案例來看

NetFT組件嘗試幫助我們構建群集網絡通信拓撲，可以看到這裏詳細的運作過程，發現只會在18網段，10，20網段之間進行嘗試建立3343連接，因為我們設置了30 40網段為存儲網絡，不參與群集通信，因此構建拓撲時NetFT不會考慮這兩個網絡

08R2群集由於當前只有一個節點在運行，群集存儲之前一直是失敗狀態，17:10這個時間節點，我將群集存儲恢復聯機上線，17:11時間節點，禁用ISCSI目標

生成clusterlog可以看到，10分的時候，RHS繼續嘗試檢測群集磁盤1，發現群集資源1的RES資源已經正常掛載，檢測也正常通過，因此RHS將把群集磁盤1狀態變成聯機的情況報告給RCM，RCM變更群集磁盤狀態為聯機

11分的時候RHS針對於群集磁盤1的Is Alive檢測失敗，判定該資源失敗，並將失敗的狀態報告給RCM，RCM變更群集磁盤狀態為失敗，緊接著RCM會按照故障策略對群集磁盤嘗試進行掛起重試操作，在一段時間內一直得到失敗的結果，會標記群集磁盤為失敗狀態，然後隔一段時間後再嘗試聯機

第三個實例我們查看當我們執行LowerQuorumPriorityNodeID時群集內部發生的動作

時間節點1，群集四個節點，見證磁盤失效，當前群集隨機調整去掉一個節點投票

時間節點2 ，使用LowerQuorumPriorityNodeID設置去掉HV04節點的投票

#使用命令輸出所有群集節點最後五分鐘的目錄至統一文件夾

Get-ClusterLog -Destination \\iscsi\clusterlog -TimeSpan 5

打開HV03的日誌可以看到，時間節點1，當檢測到群集磁盤離線時，仲裁首先挑選去掉節點1的投票，時間節點2我們手動設置LowerQuorumPriorityNodeID為HV04，群集重新調整動態仲裁，去掉HV04的投票

第四個實例，我們可以看到，當NetFT構建群集內網絡通信拓撲時，會考慮到網絡會子網內還是跨子網，可以根據情況設計不同網絡環境下的運行狀況檢測頻率，NetFT會按照我們的定義來構建不同網絡環境運作狀況檢測的拓撲。

最後一個實例，我們來模擬下當群集四個節點，壞掉三個節點，且最後兩個節點時，投票節點忽然被斷電，強制啟動群集後的阻止仲裁情況

現在群集只剩下HV01節點被強制啟動，我們這時啟動下HV04節點

獲取群集診斷日誌，我們就看最近20分鐘左右的，看看從群集關閉，強制仲裁，再到阻止仲裁到底發生了什麽

Get-ClusterLog -Node HV01,HV04 -Destination \\iscsi\clusterlog -TimeSpan 20

我們先看HV01的日誌

可以看到，時間節點一，HV01強制啟動了群集服務

緊接著初始化各個群集組件，仲裁組件判定HV01已經初始化完畢，提升HV01的paxos標記為權威，這時應標記為FixQuorum狀態，可以看到，雖然不在UI顯示了，但是在後臺運作的時候仍然會指出當前節點正在強制模式下運行

這時HV04試圖上線，但會被阻止，HV01會收到群集環境內有新的加入請求，並告訴我它我是權威的節點，我的paxos標記最高，你應該以我的為準，加入我的分區，同步我的群集數據庫

這時我們再來看看HV04的日誌，因為HV04的ID為3，因此在日誌中會看到Node 3 也就是HV04

時間節點1，Node3 嘗試啟動群集服務，但是啟動之後被終止，

時間節點2 Node3指出，我的仲裁狀態屬於阻止狀態，我試圖加入，我應該先去和那個權威節點同步

時間節點3 Node3收到HV01的響應，以HV01為群集的權威方，按照HV01的paxos標記更新數據庫

時間節點4 Node 3已經將群集數據庫和HV01保持一致，再次加入群集，正常加入，關閉阻止仲裁模式，並且去掉了NeedsPrevent標記！

以上老王通過幾個簡單的實例，來為大家講解了下應該如何去看cluster log，希望能夠引起朋友們的興趣，可以看到cluster log裏面會真正涉及到很多群集底層組件的詳細運作過程，如果你能夠把這些底層組件的工作原理都搞清楚，老王相信不論是對於你進行排錯，或者學習都會有一個不一樣的境界。

在實際的群集排錯中呢，老王認為主要還是通過不斷的學習，實驗，實戰來鞏固自己的知識經驗，排錯時手段占一部分，但是自身的知識和經驗積累也要占很大一部分，例如老王遇到群集的問題，我的思路通常是先獲取下群集節點投票，見證投票，看看見證資格當前是怎麽樣的，接著我會去看系統事件中篩選群集部分，看看網絡和存儲是否有報錯，然後跟著自己的經驗去分析判斷問題

其實老王感覺對於一般的排錯，事件管理器系統，應用程序日誌中旳群集日誌已經可以提供足夠明確的信息，事實上微軟在2008時代改變群集事件的時候就曾經有個願景，希望可以讓更多的管理員通過看事件管理器就能了解解決一部分問題，到了2012時代事件管理器中的日誌確實也達到了微軟的願景，確實很多問題，日誌已經提示的很明確

但是一旦遇到一些問題，事件管理器中給出的提示無法解決，這時我們仍需要直接看cluster log，來從群集的最底層去了解故障的徹底原因。

如果是需要進行一個綜合性的排錯，例如綜合排查三個節點的群集錯誤和虛擬化錯誤，這時候你可以選擇查看群集管理器中的群集事件，來進行一個綜合性的排錯

如果是需要進行群集的健康檢查，看看還有那些最佳實踐沒有執行，可以執行群集驗證報告，群集驗證報告也會提供很多有用，底層的信息。

本文出自 “老王的微軟技術研究樂園” 博客，請務必保留此出處http://wzde2012.blog.51cto.com/6474289/1954118

WSFC日誌分析進階篇