Windows Server 群集節點和資源監視

群集節點監視

如果將群集資源類比為雞蛋，那么群集節點類似于裝有雞蛋的籃子，籃子本身的完整決定著里面所裝的雞蛋的安全性。群集節點首先要決定自己是否存活，所以群集節點之間定期使用心跳來判斷所有群集節點是否處于健康狀態。群集的可用性目標因提供的服務的要求而異，不同服務等級要求的應用對故障恢復時間要求也不同，對健康檢測嚴格要求也不同。同理，可用性要求越高的服務，對檢測節點故障和采取后續行動進行恢復的速度越快，可用性要求不高的服務，對于故障恢復時間的容忍也相對要長。鑒于此，Windows Server群集初始具有兩類嚴格程度不同的默認檢測策略：

嚴格監控（Aggressive Monitoring）：提供最快速的檢測和恢復策略，保障最大的可用性。群集故障容忍度低，即使短暫的故障也要避免，以至于群集節點出現短暫的網絡故障時，群集也會該節點上的應用遷出到正常的節點。

寬松監控(Relaxed Monitoring)： 提供相對寬松的檢查策略，群集故障容忍度相對嚴格監控要高，允許短暫的群集節點故障。

嚴格監控和寬松監控都是相對的，可以使用兩個具體的參數來測量，一個參數是心跳頻率（Delay），一個參數是心跳失敗閾值（Threshold）。

心跳間隔(Delay)：定義在節點之間發送心跳檢測信號的時間間隔，以秒為單位。

心跳失敗閾值(Threshold)?：定義在群集采取恢復動作之前能容忍的心跳次數失敗的次數，比如心跳檢測失敗一次，群集不會立即采取恢復措施，而是繼續發送下一個心跳檢測信號，直到發送的次數達到設定值。

Windows Server不同版本的群集默認心跳頻率和心跳失敗閾值匯總如下：

參數

Windows Server 2012 R2

Windows Server 2016

最大

SameSubnetDelay

1 秒

1 秒

2 秒

SameSubnetThreshold

5 次心跳

10 次心跳

120 次心跳

CrossSubnetDelay

1 秒

1 秒

4 秒

CrossSubnetThreshold

5 次心跳

20 次心跳

120 次心跳

CrossSiteDelay

N/A

1 秒

4 秒

CrossSiteThreshold

N/A

20 次心跳

120 次心跳

可使用命令PS C:\>Get-Cluster |fl*Subnet* 查詢跨子網和相同子網的心跳間隔和嘗試閾值，命令輸出的結果的心跳間隔的單位為毫秒，結果如下示例所示。

PS?C:\>?Get-Cluster?|fl?*subnet*? CrossSubnetDealy??????????：1000 CrossSubnetThreshold??????：20 PlumbAllCrossSubnetRoutes?：0 SameSubnetDelay???????????：1000 SameSubnetThreshold???????：10

調整心跳檢測

嚴格的檢查手段適用于一些高服務等級要求的應用，這些群集通常在一個高速連接的子網內。由于Windows Server 群集支持節點跨子網和站點部署，在群集節點相隔數公里而且的連接不怎么穩定的子網里，可以考慮稍微寬松的設置。同樣，服務器硬件的冗余程度不斷提高，操作系統也逐漸成熟，服務器節點本身的可用性已經非常可靠，服務器整體故障幾率大為降低，這種情況下也可以按照實際情況將檢測策調整得寬松點。

可以使用如下PowerShell命令調整相同子網的心跳間隔，如下示例所示，將心跳間隔時間調整為2秒：

PS?C:\>?(get-cluster).SameSubnetDelay=2000

使用如下PowerShell命令調整相同子網的心跳失敗閾值，如下示例所示，將心跳失敗閾值設置為20次：

PS?C:\>?(get-cluster).SameSubnetThreshold=20

群集資源監視

除了要保證裝雞蛋的籃子的完整和可靠性，雞蛋自身也會因各種因素變壞，因此群集除了要監視群集節點的健康狀態，還需要監控構成群集及應用的資源健康狀況。群集里通常有若干資源和資源組，群集運行并處理著不同的資源，有時候群集資源發生故障，雖然可以通過群集事件進行分析，但是對于深入的問題，必須通過分析DUMP日志這個“黑匣子”才能找到根本原因。如果你對群集資源故障了解不夠深入解決起來會無從下手，但是作為維護人員，無論如何，需要為你的群集資源故障分析留一道門，這道門通往更加深入的資源監視通道，這道監視通道將幫助我們獲取深入故障分析報告，將故障分析報告提交給微軟讓微軟幫助定位問題所在。那么群集是怎樣檢測群集資源并報告事件給系統呢？接下來我們將帶著這個疑問介紹群集的資源管理系統以及工作方式。

資源主機子系統

群集資源主機子系統（Resources Host Subsystem-RHS）負責監視群集資源，一個群集化的應用是以資源組形式存在的。群集里可以運行多個資源，這些資源同時被群集監視系統監控，群集監視系統除了RHS，還有資源控制管理器（Resource Control Manager，簡稱為RCM），RCM和RHS協調工作對完成群集資源的監視和操作，如圖1所示。RHS和RCM都是群集服務的一部分，主要職責就是監視群集資源的狀態。

圖1 RHS和RCM

資源控制管理器

具體來說，RCM具有兩個關鍵職責：一個是為群集服務執行故障轉移機制和策略，另外的一個職責是建立和維護每個資源的依賴關系。以高可用文件服務器為例說明，群集文件服務器資源和磁盤以及訪問名稱、訪問IP地址處于同一個資源組的依賴關系樹，這個依賴關系樹由RCM維護著，如圖2所示。RCM維持單個資源和資源組的在線、離線、失敗、在線掛起、離線掛起等各種狀態，并負責資源組的移動、故障轉移的操作。

圖2 文件服務器資源依賴關系

資源監視器檢測

為了保證群集應用正常工作，RHS時刻監視著資源情況并定期檢查群集資源的健康狀態。每個不同的資源的檢查頻率略有不同，檢查頻率由不同的群集資源DLL定義。RHS采用IsAlive和LooksAlive兩個探測器進行周期性資源健康檢測，LooksAlives檢查比較粗糙，但是檢查頻率較高，默認情況下每5秒鐘進行一次檢查，而IsAlive檢查更為仔細，但是檢查頻率較低，默認情況下每60秒檢查一次。LooksAlives不停檢查資源健康情況，一旦資源返回失敗結果給LooksAlive，考慮到資源會出現“假死”狀態，這時候，RHS會立即啟用更全面的檢查并調用 IsAlive檢查資源是否真正出現問題。

在檢測到群集資源故障后，RHS便會等待資源響應，如果在既定時間內沒有響應，則會按照策略執行恢復操作。由于RHS只能判斷資源不響應但是不能判斷具體發生了什么故障，唯一的辦法就是通過重啟RHS進程嘗試恢復資源。這個等待時間在群集資源的DeadLockTimeout屬性里定義等待一次為300000毫秒，也就是5分鐘，可以使用PowerShell命令查看和修改DeadLockTimeout值。

使用以下PowerShell命令查看群集資源的RHS等待時間。下面以Hyper-V群集（配置了群集復制代理角色）為例，命令輸出的結果如下。

PS?C:\>?Get-ClusterResource?|ft?Name,?ResourceType,?DeadlockTimeOut

Name

ResourceType

DeadLockTimeout

----

------------

----------

Cluster IP Address

IP Address

300000

Cluster Name

Network Name

300000

File Share Witness

File Share Witness

300000

Cluster-HRB

Network Name

300000

IP Address 192.168.1.5

IP Address

300000

Hyper-V Replica Broker Cluster-HRB

Virtual Machine Replication Broker

300000

要修改某個群集資源的DeadlockTimeout時間可以參考如下命令，這個命令修改類型為Network Name的DeadlockTimeout為10分鐘。

PS?C:\>?(Get-ClusterResourceType?“Network?Name”).DeadlockTimeout?=?1000000

雖然可以任意定義DeadlockTimeout時間，但是不建議將這個值改成比5分鐘更大，試想IsAlive和LookAlive檢查時間往往在幾百毫秒內完成，而DeadlockTimeout的時間為5分鐘，已經大大超出了IsAlive和LookAlive檢查時間。

除此以外，群集為了做到準確監控，默認啟用了一層保護保護機制，當群集發送結束RHS指令時，不會立即重啟RHS進程，而是等待4次DeadlockTimeout時間（20分鐘），如果資源仍然沒有響應才采取結束RHS進程的措施。如果RHS進程在等待4次（20分鐘）資源仍未響應，群集判斷服務器可能出現嚴重的問題，進而強制重啟群集節點。

最重要的是，RHS產生Windows 錯誤報告給群集系統并把錯誤寫入DUMP文件，因為不同應用的群集涉及的群集資源也是千變萬化的，一般出現嚴重的問題需要進一步的分析，筆者曾經遇到群集節點發生?I/O Request Packet?隊列過多導致服務器使用Bugcheck自動重啟的情況，最后通過分析DUMP發現了問題的根本原因，因此說，RHS打開了一扇通往深入分析群集的門。

資源監視器調整

群集將資源DLL加載到資源主機監控進程（RHS.exe），RHS進程是循環使用的。早期的設計里，默認情況下所有的資源在一個RHS進程里運行，這種情況的問題是如果一個資源故障，那么整個RHS進程和所有由這個RHS加載的資源都會出現故障。考慮到這種設計的不足，在后期Windows Server 群集里做了改良，重要的資源都加載到各自獨立的RHS進程里。但是仍然有可能不同的群集資源加載到了同一個RHS進程里，如果多個資源共享一個RHS進程，那么某個資源出現故障時，群集會重啟RHS進程，這樣其他加載到RHS進程的正常資源也會跟著重啟。

為了避免這類問題發生，可以酌情為不同的資源分配獨立的資源監視器RHS進程。在群集資源里，有一個屬性代表著使用獨立還是共享的RHS進程，這個屬性是SeparateMonitor。這個屬性定義為0或者1，0和1代表False和True，定義為0，代表群集資源使用共享的RHS進程，定義為1，代表群集資源使用獨立的RHS進程。

可使用Get-ClusterResource查看哪些資源使用獨立的RHS進程監控。下面以兩個SQL Server數據庫群集為例，運行如下命令查看RHS監視器情況。

PS?C:\>?Get-ClusterResource?|?ft?name,?SeparateMonitor,?MonitorProcessID

Name

SeparateMonitor

MonitorProcessID

----

------------

----------

Cluster Disk 1

False

3144

Cluster Disk 2

False

3144

Cluster IP Address

False

3020

Cluster Name

False

3020

File Share Witness

False

3020

SQL IP Address 1(MSSQLSERVER）

False

3020

SQL IP Address 2（Test）

False

3020

SQL Network Name（MSSQLSERVER）

False

3020

SQL Network Name（Test）

False

3020

SQL Server

True

3188

SQL Server（Test）

True

3224

SQL Server Agent

True

3272

SQL Server Agent（Test）

True

3308

可以使用Get-ClusterResource修改資源使用獨立的RHS進程監控。下面以數據庫群集磁盤資源為例，將群集磁盤Cluster Disk1設置為使用獨立的監視器，運行如下命令設置Cluster Disk 1使用獨立的RHS監視器。

PS?C:\>?(Get-ClusterResource?“Cluster?Disk?1”).SeparateMonitor?=?1

再次運行如下命令查看群集資源監視器情況。

Name

SeparateMonitor

----

------------

Cluster Disk 1

True

Cluster Disk 2

False

Cluster IP Address

False

Cluster Name

False

File Share Witness

False

SQL IP Address 1(MSSQLSERVER）

False

SQL IP Address 2（Test）

False

SQL Network Name（MSSQLSERVER）

False

SQL Network Name（Test）

False

SQL Server

True

SQL Server（Test）

True

SQL Server Agent

True

SQL Server Agent（Test）

True

要注意的是，如果群集資源過多的情況下啟用為每個資源配置獨立的RHS進程，將會導致系統里同時運行多個RHS進程，因此會過多開銷系統內存和CPU資源。而且群集已經可以把有問題的資源隔離加載到獨立的RHS進程，從而避免有問題的資源影響到其他健康的資源，通常建議為群集資源保持默認設置。

人工智能 軟件開發云 云計算

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。