一種全面高效的ＨＰＣＳ監控體系

摘要：分析了以超級計算中心聯想深騰6800為主的HPCS監控需求，比較了大量的監控實現技術，給出監控系統評估特征和指標，提出了一種集系統、性能、應用程序、進程監控于一體的改進策略，討論了利用信息流水、過濾、雙重傳輸模式減少監控數據傳輸量，減輕監控資源消耗，提高綜合監控的性能和效率。

關鍵詞：HPCS； 監控； Clumon+； 過濾； 雙重傳輸模式

中圖分類號：TP311．5文獻標志碼：A

文章編號：1001－3695(2007)07－0024－04

0引言

關于HPCS(High Performance Computing Systems)的監控，國內外有許多研究機構和商業團體提出了許多有效的監控實現技術，如N層監控樹、RRD（Round Robin Database）等；產生了不少優秀的監控軟件，如早期的CARD[1]，Java和C/S技術實現的Parmon[2]，樹型結構能夠監控集群簇的Supermon[3]，世界范圍內廣泛應用的分布式監控軟件Ganglia[4，5]，國內的Ganglia+[6，7]（在Ganglia的基礎上達到了更高的可靠性和安全性），以及著名商業化異種集群分布式監控軟件BigBrother，Berkeley大學系統管理工具Now，使用接近/proc實現的Dproc，同批處理系統緊密結合的Clumon（+Open PBS）[8]、NWPerf[9]、PerfMiner(+Easy)[10]，其他如MonALISA、IMPuLSE、HiFi、Astrolabe、Lemon等。

基于上述監控軟件的分析發現，大部分工具只具備單一的功能，未能把多個監控領域綜合起來實現。如系統監控軟件Swatch只探測可能發生的系統事件，通知管理員以及完成部分管理功能如重新啟動進程或者加載文件系統等；常見的Ganglia等均屬于性能監控范疇；應用程序監控只有少量研究簡單涉及（如Clumon），通常還局限于特定的批處理系統；進程監控較少體現在實際工具中，卻非常必要；國內的研究更是處于起步階段，還有很多工作有待于進一步開展。

為此，需要建立一種集性能、應用程序、系統、進程監控于一體的全面的監控體系，它不僅應該診斷硬件、內核、服務等系統不同層次的狀態（包括：①各節點的CPU 負載信息， CPU使用率; ②各節點內存使用率，Cache、Buffer、Swap信息等；③各節點的磁盤輸入/輸出狀況，即硬盤用量和空間; ④網絡狀況， 負載和利用率等，用于系統管理員查看和分析，從而調整優化系統的性能和資源分配（即性能監控）），還應該能收集到應用程序、作業等運行信息，利于查看批處理系統實際應用性能、工作負載和吞吐量等（即應用程序監控）；同時，也可以相當于一個虛擬的系統操作員，監視一切體現潛在的系統故障的事件，且以郵件或者信息的方式通知系統管理員，并自動采取一些應對管理措施，保證其計算環境的可靠性（即系統監控）；且能掃描運行在系統平臺上的進程，對外來的可疑進程或占有系統資源較多的“霸道”進程等有一定的判別能力，如硬盤利用率超過95%，CPU平均負載過高，某些重要進程僵死，一些特殊的IP地址連接不上，以及某些服務關閉等，然后由管理員采取一定措施（如清除一些僵死的進程，重啟或者扼殺一些混亂的進程等）以保障系統的安全（即進程監控）。

但是，因為將幾方面的監控整合于一體，系統占用的計算、存儲等資源也必然隨之增加。系統監控可能一個小時運行幾次，性能消耗還不算太大，性能監控一分鐘運行多次，將要占用驚人的系統資源，故其本身更要采用高性能的設計。因此，也要改進現有監控軟件實現的模式，利用信息流水、過濾、雙重傳輸等技術等加快數據收集的速度，減少傳輸數據量，提高數據表示、傳送的效率，減輕監控系統本身的資源損耗，從而獲得更高的監控性能。

1監控系統特性

對于運行于HPC以及HPCS上的監控系統而言，必須具備以下八個特性：

（1）全面性——主要體現在兩個方面，一是監控對象的全面性，即應該能夠監控到HPCS的各個部分，如上面提到的系統、性能、應用程序和進程一體化；二是監控信息的全面性，即對每個部分的監控信息都要全面。

（2）低延遲——即實時性，監控數據盡可能反映系統當前狀態和短時間內的變化。

（3）可擴展——監控消耗的CPU等系統資源數量和節點數之間要大大低于線性關系。

（4）健壯性——在不同的節點或網絡故障的情況下，監控仍能正常進行，且盡可能準確。

（5）可延伸——系統能以便利的方式，如用戶模塊化添加對新節點或新部件的監控。

（6）易管理——監控所花費的成本與HPCS的規模也要大大低于線性關系，盡可能避免人工安裝配置，用簡潔清晰的圖形Web界面表現系統的狀態，支持本地和遠程管理。

（7）可移植——HPCS軟/硬件仍有很大的變化空間，監控系統要能適應不同的處理器體系機構，也可移植在不同操作系統上。

（8）低消耗——監控系統所引起的資源需求如CPU、內存、I/O，以及網絡負載均應該比較低，以便盡可能減少對被監控系統產生的影響。這點對HPC來說尤其重要。

本文提出的Clumon+監控體系集性能、應用程序、系統、進程監控于一體，可很好地滿足全面性，但其余七個特性還要靠改進監控實現技術以及提高系統本身的性能和效率來達到。

2現有的監控技術

2．1體系結構

現有的監控體系結構主要有兩種：集中式監控和分布式監控。集中式監控需要一臺專用的監控主機，中央監控節點的負載高、延遲大、效率低，且無容錯性，故一般采用分布式監控，把監控任務分布到各個節點機上，從而增強可靠性和提高效率。

分布式監控又分單層和N層的樹型結構。前者比較簡單，多個MA(Monitoring Agent)運行于各個節點上收集各部件狀態，唯一的SMA(System Management Agent)只在某特定的監控節點上，匯聚來自所有MA的信息。容易崩潰，且不具備可擴展能力，無法對多個HPCS或者網格進行監控。增加系統可擴展性的一個最直接的辦法就是加深監控樹的層次（圖1）。

多個SMA分布在不同的層次上，功能也多樣化：首先是通過一系列API連接Client；其次，作為一個信息路由器均勻分擔監控負載。Client可以是上層的HPCS管理工具，或者設計成Web方式的客戶端。監控數據要依權限查看，只有根Client才可以看到所有HPCS的統一視圖，其余層次只可以訪問到有限的信息。Ganglia、Supermon，以及本文的Clumon+等都是N層監控樹的結構。

2．2數據收集

遵循的準則是一次監控數據的采集在計算節點上的資源占有率達到最小，可以基于Pull或Push協議。Pull協議如輪流檢測由接收端向數據源發出請求，數據以一次檢測為間隔進行有規則的更換，總在需要時到達，更新和網絡負載之間有一個平衡；但請求信息及數據變化緩慢或沒有規律時空的輪詢會浪費網絡帶寬；而Push協議不限時間，有超出一定門限的顯著事件發生，數據源主動向監控模塊發送數據，同時允許接收端有選擇地接收，數據調度比較理想，不需要請求數據包，降低了消耗的網絡帶寬。

收集工具也各有其優缺點：①系統調用，使用特殊的系統命令，如ps、top用于進程，netstat、ping用于網絡，iostat、vmstat用于外設，Ganglia便是采用這樣的方法；②標準或非標準工具，如SNMP、rstatd、sysctl， SNMP存在嚴重的安全隱患，rstatd提供的信息有限，sysctl建立了一個登錄條目，一次便可取得所有需求信息，大大提高了速度，但效率較低；③直接讀取內核模塊數據，但主內核改變時，代碼必須保持一致；④直接讀取分析/proc文件，快速高效，存在的問題較少，比較常用，但必須保持代碼分析與/proc 文件改變同步；⑤混合方式，用內核模塊收集數據，用/proc作為接口。

2．3數據合并

多源異種數據需要合并后傳往高層的SMA。合并有兩種方式，一是合并不同節點的同種數據；二是合并不同種類的數據。合并可以發生在節點、監控主機或者兩者上，一般只采用在節點上的合并。因為節點是數據的收集與提供者，多個同時的數據請求不會引起多于一次的系統調用，而是將第一次請求獲得的數據緩存，并提供給第二次請求調用。這種方法減少了操作系統的負擔，加快了監控系統的響應，而且多個數據源的數據可以以相互獨立的收集速率結合，從而減少靜態和低頻數據的傳輸，提高傳輸效率。

2．4數據傳輸

將監控信息進行有效編碼，采用高效的傳輸協議送往上層SMA。有二進制、XML、S－Expressions、文本幾種數據格式，各種格式各有利弊。二進制容易壓縮，但可移植性、可擴展性和可組合性都不太好；XML彌補了上述不足，但解析復雜，數據規模會急劇膨脹，且依賴于操作系統；Supermon采用的S－Expressions也可以表達樹型結構的數據，有自包含的數據描述，且不需要RPC編譯器和XDR工具，比較優異；但文本形式更適合于/proc，避免了傳輸前向二進制轉換，且平臺獨立、易讀，也能有效壓縮。

數據協議要具備兩個特征，即可擴展性和可組合性?？蓴U展性是指數據結構上不用改變傳輸層程序而加入新的元素；可組合性是指來自不同數據源的監控數據可以組成單一的整體。Ganglia、Hawkeye使用的XML相關協議，標準但比較復雜；PerfMC、Supermon使用的SNMP，簡單但會引起額外的網絡負擔；也可以使用其他的非標準協議如Parmon采用的簡單傳輸機制，傳輸層使用TCP /IP套接字流，而應用層使用信息字符流，客戶端用消息交換方式從服務器獲取監控數據，服務器答復一系列的字符流。

2．5超時設定和心跳信息

如果超時設定的節點崩潰，MA利用心跳信息來設置時間界限，每一次心跳信息包含一個代表著MA起始的時間戳，任意MA重啟，它的時間戳改變很快被其他MA發現；如果MA在時間界限內沒有應答就會被認為是宕掉。這樣，重啟或者是新添加的主機，數據的發布便不用遵守前面超時設定的限制。只有在MA超過10 min沒有響應才啟用重新設置機制，避免集群中所有MA同時重啟引起多播風暴。

2．6數據存儲

數據存儲有集中式和分布式兩種不同的存儲策略。集中存儲發生在SMA所在的節點，分布式存儲是在各SMA、MA所在的本地節點，很好地實現了冗余。但在存儲資源非常珍貴的HPCS中，這種冗余并不需要，故一般都采用集中存儲。

引入的數據庫可以是RRD，以固定的規模和面向時間的方式保存數據，正好符合周期性輸出的特點；但精確性不夠，不可升級，且操作復雜，依賴于系統平臺；關系數據庫，如Perf－Miner使用的以Postgres為后臺的，Lemon使用的標準SQL，多個表聯合，通過索引很容易實現高效查詢；增加行列很容易插入新數據且不用改變應用程序，有靈活的適應性、較高的可擴展性和精確性，但隨著數據量的增長，所占用的存儲空間也會無限增大。

2．7數據顯示

數據顯示有文本和圖形界面兩種形式，后者清晰易懂使用得較多。一般是基于Web的訪問界面，分成若干個由XML文件經過XSL轉換的包含圖表和數據的HTML頁面，用戶可以寫一系列XSL轉換文檔過濾和定制HTML外觀。分析顯示工具MRTG用于監視網絡負載和連接，生成包括PNG格式圖片的HTML頁面，使用SNMP協議讀取，簡單且功能強大，但格式固定；RRDtool存儲和顯示時間序列數據，且以緊密方式壓縮，占用的空間不會隨時間增長，但實施復雜，數據庫不可升級，也不獨立于系統平臺；JROBIN，Java版本的RRDTool，可移植性強，獨立于系統平臺，可升級，但與RRDtool一樣復雜。

3一種全面的HPCS監控體系

超級計算中心聯想深騰6800原有的Ganglia監控系統有諸多優勢，如廣泛適用于大多數操作系統和CPU體系結構，直觀的Web動態訪問界面，可以監控多個不同的HPCS，Rocks、OSCAR和Warewulf都可以提供安裝。它也有不足之處，如RRD數據庫比較復雜，容易造成明顯的網絡負擔；監控不夠全面，只能完成CPU、內存、網絡等性能狀態的描述和刻畫，缺少對系統事件的預測和提醒，缺少對應用程序如用戶作業、隊列信息的監控，也沒有進行進程監控來保證HPCS的安全。

為了實現全面高效的監控目標，本文提出了一種基于開源軟件Clumon的全面高效的HPCS監控體系Clumon+。

3．1Clumon分析

Clumon用自身的Clumond進程調用SGI的Performance Co Pilot(PCP)，存儲監控數據于SQL數據庫中，基于Web的動態方式訪問。安裝在各個節點的PCP進程追蹤特定資源的狀態，服務器端Clumond收集來自PCP進程的監控信息并存入RR數據庫中，兩種進程都從PBS服務器中獲取監控數據，并用Web方式表示出來。Clumon比Ganglia系統有所改進，它不僅可以監控到HPCS的性能領域，還可以了解用戶作業的詳細信息，并以圖表方式顯示系統資源使用和客戶端作業調度情況。它也有一定的不足：一是監控領域不全面，雖然比其他軟件多了批處理系統作業信息等應用程序監控功能，但沒有覆蓋到系統、進程等領域的監控；二是用戶程序監控的局限性，因其最初設計便是與OpenPBS緊密結合的，所以不支持其他的JMS。

3．2Clumon+的體系結構

Clumon+的設計便要針對以上兩點不足進行合理的改進，形成一種全面的監控機制，其體系結構如圖2所示。

3．2．1Checksys實現系統監控

Checksys是NCSA編寫的一個Perl腳本，采用模塊化設計，面向整個HPCS的主腳本調用和設置運行在每個主機上的子程序；主腳本從Cron程序中每十分鐘運行一次，多數子程序也是，少數子程序一個小時或者一天運行一次，具體由主程序的配置文件指定。主控程序在給定的主機上運行Cron任務，讀取所示節點的配置文件，了解哪個子程序將要在這個主機上運行。運行指定的子程序的過程中，Checksys主控程序再次訪問所在主機的配置文件，取得子程序運行所需的參數，分析和預測將要發生的系統事件。

除了進行事件監控，Checksys也完成部分管理工作。當進程運行失誤，或者運行的副本數目與配置文件不符時，負責重啟；重新加載本地和遠程的文件系統；通過E－mail通知管理員相關的事件以及要采取的措施；將在系統日志中保留一條消息；提示監視系統通過生成文件或者事件來傳送一個特殊的信息。Checksys是一個主動而非被動的監控系統，它持有一些正確的狀態，通過替換原有的表示狀態完好的標志文件來提示監視器記下警告消息。

3．2．2Appmon中間層

增加一個Appmon的中間層代理作為Clumond+與JMS的接口，屏蔽不同的JMS中數據調用接口的差異，使其可以與OpenPBS以外的主流JMS（如LSF）結合，讀取作業調度器中系統、用戶程序有關的作業信息，并以一個單獨的表格形式存入SQL DB中。在Web客戶端就可以直接訪問數據庫中相應表格來向不同層次的用戶展現作業信息。對于用戶來說，提供有關最新提交的作業性能信息，不改變用戶應用環境而以某個確定的方式運行；對于系統管理員和服務支持人員來說，則可以看出哪個用戶消耗的計算周期最多，以便于理解系統被不同用戶的使用情況，可以集中于解決問題的硬件所在。

3．2．3Promon進程監控

進程監控與安全關系反映最明顯，入侵者最少需要運行一些進程才可以進入集群節點。一些非預期進程是安全危機的指示。增加Promon進程監控，也是一個安全分析模塊，安裝在HPCS監控主機上與Clumond通信，分析監控信息，查找安全事件，利于監控的可靠性和執行的便利性，增加了從可信任位置送往網絡的數據正確性校驗。

Promon進程監控模塊從SQL DB中獲取進程信息，分析并放回。用戶通過中央管理節點基于Web訪問進程安全信息。模塊化的設計，更容易加入這個功能?？梢允褂肅lumond收集到的性能數據，Promon模塊集中于分析和視圖工作。有四種進程要提出警告：不該運行的進程、可疑進程、資源超過限制進程、該運行而未運行的進程。

4提高監控系統的效率

功能全面的同時勢必也將帶來額外的系統負載，因此要設法提高監控系統的運行效率，從而對HPCS平臺上的用戶作業程序產生盡可能小的影響。為達到這個目標，有兩個基本的思想：一是減少在單個主機節點上收集和傳送的監控數據量，從而減少占用的計算節點的資源，減輕網絡負擔；二是增加數據傳輸時的并行性，使不同主機以及監控節點之間傳輸間隔達到最小?？梢杂靡韵聨追N措施來實現。

4．1使用更高效的數據收集算法

例如混和Push/Pull協議，監控進程發送SQL請求給一個設有計數器和時間間隔限制的中轉代理，計數達到要求時，由中轉代理來執行這個請求，從而抑制過于頻繁的更新請求。計數器設置為1，即為普通的Pull協議；設置為無窮大，即為Push協議。時間間隔限制應答SQL數據請求，從而減少了Push協議中傳送的非接收端感興趣的數據信息，而多播協議中只能選擇多播的地址，而不能選擇特定數據源的數據包。

也可以使用信息流水技術，增加數據收集和傳輸時的并行性，縮短系統延遲。所有的請求信息和監控信息都可以沿著系統結構方向以流水線來傳送，即信息處理和信息傳送時間以及不同段之間的傳送時間的重疊，如限制系統必須在1min間隔內用0．6s完成數據的收集和傳輸，以減少監控程序對計算資源的消耗。

4．2過濾技術

依據用戶策略選擇性提取、合并和傳輸監控數據，如不傳送靜態信息或者只傳送某些頻率的動態信息；設定數據粒度，如限制XML數據的遞歸層次，或限制各種數據源數據的收集頻率；使用數據掩碼〈Mask#〉〈name〉〈U〉用于運行時間等沒有范圍限制的數據，反之，如內存使用率類的數據用〈Mask#〉〈name〉〈B〉〈lower－bound〉〈upper－bound〉，以便屏蔽用戶不想知道的信息，只傳送用戶感興趣的監控數據，從而節省了數據處理的時間和資源，以及網絡帶寬。

4．3雙重傳輸模式

使用同步和異步雙重傳輸模式，使主機節點上數據收集與匯集及送往監控服務器的間隔最小。通常是默認的異步模式，監控信息沿著監控樹從MA向SMA傳送，傳送頻率取決于用戶的需要，上層應用程序使用的是緩存數據，因此監控信息只是對系統狀態在某個時間點的估計而不是精確反映。異步模式的目的正是支持系統監控；相反，同步模式是為那些對監控數據精確度和更新速率要求都比較高的系統而設計的，同步模式下，緩存數據采用會話迂回策略，數據請求被送往MA，然后MA響應請求，并把監控數據傳往發出請求的SMA。該模式的目的是為了支持對系統信息正確性要求比較高的批調度系統。

4．4可插入模塊技術

即插即用（Plug－and－play）的監控模塊可以實時加入，允許用戶根據自己的需求編寫遵循一定接口規范的腳本來監控新的資源的信息，或者提供新的性能指標。監控數據和控制信息經過Publish/Subscribe通路傳往其他節點，允許系統本身和應用程序根據當前需要，動態定制、分析和交換數據；本地或遠程監控進程，可以動態部署監控函數，通過過濾器指定復雜的數據定制準則。

5結束語

開展HPCS監控技術的研究是至關重要的，通過分析監控數據可以找出其瓶頸，及時發現并排除故障，為系統性能優化提供可靠的依據。本文提出了這種集系統、性能、用戶程序、進程監控于一體的全面高效的監控體系，并采用過濾、信息流水等技術解決了監控本身的負載問題。但這種方法采用的是單層監控結構，無法像N層監控樹那樣可以同時監控多個HPCS以及網格等。為此，在以后的工作中，要改變增加監控層次，設計成類似Ganglia的N層監控樹的形式，從而用于異種HPCS簇的監控。

參考文獻：

[1]ANDERSON E， DAVE PATTERSON. Extensible， scalable monitoring for clusters of computers: proc.of the 11th Systems Administration Conference[C].[S.l.]:[s.n.]， 1997:1－9，26－31.

[2]BUYYA R. Parmon: a portable and scalable monitoring system for clusters[J]. International Journal on Software， 2000，30:1－17.

[3]SOTTILE M， MINNICH R. Supermon: a high－speed cluster monitoring system: proc.of Cluster Computing[C].[S.l.]:[s.n.]， 2002:1－8.

[4]SACERDOTI F D， KATZ M J， MASSIE M L， et al. Wide area cluster monitoring with Ganglia: proc.of 2003 IEEE International Con－ference[C].Hong Kong， China: IEEE， 2003:1－10.

[5]MASSIE M L， CHUN B N， CULLER D E. The ganglia distributed monitoring system: design， implementation， and experience[J]. Parallel Computing， 2004，30:817－840.

[6]WEI Wenguo， DONG Shoubin， ZHANG Ling. An improved ganglia like clusters monitoring system: proc.of the 2nd International Workshop on Grid and Cooperative Computing[C].Shanghai:[s.n.]， 2003:1－8.

[7]魏文國，張凌，董守斌.一個可靠的集群簇/網格監控系統[J].計算機應用，2004，24(5):143－147.

[8]RONEY T，BAILEY A，FULLOP J.The cluster monitoring system[EB/OL].[2004].http://clumon.ncsa.uiuc.edu/.

[9]MOONEY R， SCHMIDT K， STUPHAM S， et al. NWPerf: a system wide performance monitoring tool[C]. Pittsburg， USA:[s.n.]， 2004:1－11.

[10]MUCCI P J， DANIEL A， JOHAN D， et al. PerfMiner: cluster wide collection， storage and presentation of application level hardware performance data[M]. Heidelberg: Springer Berlin， 2005:124－133.

注：“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”