WSFC日志分析進階篇

在群集日志分析基礎篇中，老王為大家介紹了幾種群集日志的位置和用途，例如事件管理器系統日志中可以告訴我們，當群集出現故障時，大體是什麼原因導緻的，給出一個方向，應用程式日志裡面的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：資源死鎖響應等待時間，預設為五分鐘。

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：資源失敗

Failed：群集組失敗

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

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

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，把魚竿的用法和基本技巧告訴了大家，如果希望能夠掌握分析技術還需要不斷的看log練習才可以，在cluster log裡面會真正涉及到很多群集底層元件的詳細運作過程，如果你能夠把這些底層元件的工作原理都搞清楚，老王相信不論是對于你進行排錯，或者學習都會有一個不一樣的境界。

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

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

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

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

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

本文轉自老收藏家 51CTO部落格，原文連結:http://blog.51cto.com/wzde2012/1954118

WSFC日志分析進階篇

繼續閱讀

set define off關閉替代變量功能

報錯：'mysql' 不是内部或外部指令，也不是可運作的程式或批處理檔案。

Linxu常用指令技巧彙總

ERROR 1 (HY000): Can't create/write to file '/tmp/#sql_4188_1.MYI' (Errcode: 28)

艱難安裝LDAP,SSL認證

《Linux指令行與Shell腳本程式設計大全第2版.布盧姆》pdf

MySQL的4種隔離級别？出現問題

XX系統實施過程問題總結

無元件上傳圖檔到資料庫中，最完整解決方案

【MySQL資料庫】資料庫索引事務1.索引2.事務

neo4j之cypher使用文檔

NOSQL安全攻擊

mybatis_入門程式Mybatis入門

登入plsql 報錯 the account is locked --使用者被鎖

sqlServer根據經緯查距離

SequoiaDB巨杉資料庫C++驅動概述