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，來從羣集的最底層去了解故障的完全緣由。

  若是是須要進行一個綜合性的排錯，例如綜合排查三個節點的羣集錯誤和虛擬化錯誤，這時候你能夠選擇查看羣集管理器中的聚合羣集事件，來進行一個綜合性的排錯

  若是是須要進行羣集的健康檢查，看看還有那些最佳實踐沒有執行，能夠執行羣集驗證報告，羣集驗證報告也會提供不少有用，底層的信息。