云計算平臺下資源監控系統的設計與開發

陳燕

摘 要： 傳統的集群監控軟件無法識別虛擬機虛擬化層的存在，同時，環境的伸縮、虛擬機的頻繁增減也對監控系統提出新的需求。針對上述問題設計并實現了CloudMonitor，即一種面向云計算環境的監控系統，提出了一種多級監控服務器結構，解決主機之間不能相互訪問的問題；另外，每個機群都有一個機群監控服務器，機群監控服務器負責處理機群中節點的監控信息，減輕了中心服務器的負擔，有效增加了整個監控系統的監控規模。系統在開源監控系統Nagios的基礎上結合傳統機群監控軟件的優點和虛擬化技術的特點，可以監控云計算環境下的各類資源。CloudMonitor已在實驗性云基礎平臺上集成運行，并驗證了其設計目標。

關鍵詞： 云計算； 資源監控； 機群管理； 虛擬機群

中圖分類號： TN911?34； TM417 文獻標識碼： A 文章編號： 1004?373X（2016）09?0057?04

Abstract： The traditional cluster monitoring system can′t identify the virtualization level of the virtual machine， so the new requirement for monitoring system is put forward due to the change of environment and virtual machine quantity. For the above problems， CloudMonitor， a monitoring system based on cloud computing environment was designed and implemented. A multistage monitoring server structure is proposed to solve the mutual access problem among host computers. Each machine cluster has a cluster monitoring server to deal with the node monitoring information in the cluster， which can alleviate the burden of the center server， and effectively enlarge the monitoring scale of the whole monitoring system. On the basis of the open?source monitoring system Nagios， the advantages of the traditional cluster monitoring software and virtualization technology are integrated in the system to monitor various sources in cloud computing environment. The CloudMonitor was operated on the cloud computing platform， and its design target was verified.

Keywords： cloud computing； resource monitoring； cluster management； virtual cluster

0 引 言

云計算作為全新的計算模式，是下一代信息技術的焦點，具有不言而喻的重要性，將給整個產業乃至全社會帶來重大變革。在國內產業界，中興在實踐中開發了一種海量數據云存儲技術，以較低的成本 解決了高速、海量的數字內容存儲以及后續運算的問題[1]。目前在中興內部，培訓系統、 人員檔案甚至MTV存儲都使用這樣的技術。云計算對網絡架構提出了新的要求，其中虛擬化交換、統一交換、透明化交換、超高速交換將是未來網絡架構發展的四個方面[2]。

成為“合格”的云應用，服務架構自身的體質是最重要的，可擴展性，或者說彈性、可伸縮性，追求的是當服務節點規模增加時，服務能力也可以線性或近似線性地提升[3]。這就需要服務請求可以被良好地、互不干擾地分配到多個節點上執行[4]。結合虛擬機的特點，基于Nagios監控框架，構建一套云計算環境下物理機群和虛擬機群監控系統CloudMonitor。系統不同于傳統監控系統之處在于可以監控部署物理機上的虛擬機以及虛擬機群，并給出物理機虛擬機性能數據的對應關系[5]。

1 系統需求分析

1.1 問題概述

云計算平臺中虛擬網絡保證了虛擬機群網絡的高效構建，給用戶帶來了極大的便利。但是對監控系統提出了新的問題[6]：

（1） 網絡無法互通問題。不同的虛擬網之間由于網絡隔離等需要常常是無法通信的，如果無法通信，就無法獲取被監控節點的監控信息，這對監控系統的監控信息傳輸提出了新的要求。

（2） 被監控機器頻繁變動問題。這造成了在一個虛擬網絡內部節點的數目可能會經常變動。用戶常常是一次性創建或銷毀一個虛擬網絡以及網絡內的全部機器。

1.2 物理機監控需求

云計算平臺的監控系統需求可以從兩個方面闡述：物理機監控需求和虛擬機監控需求。其中物理機監控與傳統機群監控類似，虛擬機監控需求則有一些新特性[7]。

從監控的角度看，云計算平臺的物理機基礎設施與傳統的機群系統沒有太大差別。基礎設施都是物理機，相對于虛擬機來說，數目不會過于頻繁的改變。僅需要將物理機所屬的區標記出來即可。云計算平臺的基礎設施圖就可以簡化成如圖1所示。圖1中表示了所有的被監控物理機，其數量、配置及IP設置等都基本不變[8]。

因此，對于基礎設施的監控需求就是監控物理機的各個物理資源指標及機器上運行的服務和系統的運行情況，并對異常情況進行預警。

1.3 虛擬機監控需求

虛擬化技術主要是一種隔離與監視技術，讓不同的虛擬機分享同一套物理機（主要指CPU/內存子系統）而彼此隔離、互不干擾，同時，為虛擬機代理訪問網絡、磁盤I/O等共享的外部資源。由于虛擬化技術對CPU/內存子系統工作的干擾很少，因此，計算能力方面很少有開銷，相比之下，I/O性能受到的影響會略大一些，但也可以接受。虛擬機和虛擬機群的出現對監控系統也提出了新的問題：虛擬機隨用戶的操作經常性的建立和銷毀；不同應用類型的虛擬機有不同的服務；用戶定制的虛擬機個性化強，并不限于一種操作系統。

結合上述特點得出監控系統需求：計算環境中各個分節點部署獨立的監控系統。

1.4 系統功能需求

數據采集模塊運行在所有的被監控節點上，包括物理機和虛擬機。在創建出新的虛擬機時，自動將采集模塊安裝到新建的虛擬機中，采集模塊支持Windows和Linux操作系統。本模塊需要解決數據跨域傳輸的問題和數據安全性和及時性的問題。

監控數據存儲模塊接收監控數據并進行結構化存儲。監控系統一方面向用戶提供監控視圖，另一方面提供監控數據API，供其他應用模塊使用。系統還應提供預警功能，系統出現錯誤時，通知用戶。同時，監控模塊應具有較強的穩定性，長時間（兩個月）運行不崩潰。可以在Linux常見版本和Windows系統上運行。可以靈活地添加和刪除監控項。如果要添加另外的特殊監控項，也可以通過更改系統配置實現。在所有節點上的監控代理，平均每5 min讀一次系統性能數據，對系統性能及網絡帶寬的影響不能超過5%。

2 系統總體設計

2.1 功能模塊設計

系統從功能上可以分為5個功能模塊：監控數據獲取模塊、監控數據傳輸模塊、監控數據管理模塊、預警模塊、系統管理模塊，如圖2所示。

2.2 系統架構設計

系統為分布式架構，分為監控服務器和監控代理。監控代理用于收集本地信息，與監控服務器通信。監控服務器用于接收監控代理發來的數據，存儲管理數據，執行預警策略，提供監控數據訪問接口。監控代理部署在每一個被監控物理機和虛擬機上，每個被監控域中指定一臺作為監控服務器，在上面部署監控服務器程序。在被監控系統中的計算設備層和公共計算資源層中的所有服務節點和存儲節點等設備上部署監控代理。具體的，在設備上收集虛擬機監控信息、主機監控信息、虛擬網絡監控信息、虛擬存儲監控信息、公共服務監控信息等。在服務器端收集監控代理傳來的信息，最后呈現給管理員。

2.3 系統層次設計

系統分為四層，自下而上分別是數據采集層，數據處理層，數據匯集層和監控應用層。圖3為云計算平臺的系統層次結構圖。

在數據采集層系統的所有節點上，包括物理機虛擬機和系統的各個應用服務器上部署監控代理，監控代理用于在本地收集機器的監控信息。在監控數據處理層，由于網絡防火墻等原因可能出現主機之間不能直接訪問的情況，因此監控模塊中加入了本層，同一機群的機器監控數據先在機群頭節點上收集，最后再傳遞到總監控服務器上。

監控應用層包括監控展示界面和監控數據API。監控展示界面提供區視圖、物理機視圖、虛擬機視圖三個視圖的監控界面。向用戶展示實時監控信息和歷史監控信息。

3 系統詳細設計

3.1 監控數據采集模塊

Windows環境下，系統使用GetSystemTimes通過APT獲取CPU占用率，使用GlobalMemoryStatusEx和GetPerformanceInfo獲取內存使用情況，使用 GetProcessMemoryInfo獲取某一個程序的內存占用情況。使用 Win32_PerfFormattedData_PerfDisk_LogicalDisk獲取磁盤監控數據。在Linux環境下，在/proc/對應的文件中獲取數據，在/proc/meminfo中獲取內存使用情況，cat/proc/meminfo；從/proc文件系統獲取CPU使用情況，cat/proc/stat；從/proc文件系統獲取網絡使用情況，cat/proc/net/dev。另外，還使用一些系統工具獲取資源使用情況，如用iostat獲取磁盤I/O情況。

對于公共服務，使用netstat監控其端口號，看該端口號是否處于監聽狀態，通過調用工具進行模擬訪問，查看返回結果。對于用戶私有服務，監控其進程狀態。將/proc下的所有文件遍歷一變，判斷當中 的哪個進程名與用戶私有服務的進程名相同，然后可以取得對應的進程pid，然后查看該進程的狀態。

3.2 監控數據傳輸模塊

監控數據傳輸使用拉模式，原因是在云計算環境下被監控機的規模無法估計，伸縮性較強，系統設計了彈性監控數據拉取策略。當虛擬機數量正常時，則監控服務器在閾值周期內拉數據；當虛擬機數量很大時，監控服務器根據自己的處理能力，在規定閾值范圍內，自動增長拉數據的周期。這樣設計是為了防止監控數據的傳輸占用太多帶寬。監控服務器周期性的向各個監控代理發送數據請求，監控代理收到請求后執行本機上的監控腳本并將監控腳本的返回內容傳回給監控服務器。使用推模式來推送新添加的被監控節點自動注冊的信息和注銷信息。

3.3 監控數據管理模塊

實時監控數據在本系統中被定義為最近48 h所產生的監控數據。系統使用RRDTool數據庫（RoundRobinDatabase）存放近期的監控數據。監控服務器接收到監控數據后，將數據解析出來，格式化的存儲到數據庫中。監控系統的存儲方式是：為每個被監控節點建一個目錄，在目錄中有多個.rrd文件，每個.rrd文件中存儲一個監控項的數據。監控系統對外提供監控數據接口，外部應用程序可以通過API讀取監控數據。監控數據以兩種方式存在：數據庫中存儲的int型或String型的監控數據值；某一段時間的監控數據繪制的曲線。

3.4 預警模塊

監控服務器中有一個郵件發送模塊，可以使用郵件服務器向指定郵箱發送郵件，機群靜態信息中存有機群管理員的郵件地址。當某個被監控節點的監控項數據超過閾值范圍，調用郵件發送模塊，給管理員發送郵件。預警事件處理模塊，在當某被監控機器出現問題時，服務器可以在被監控機器上運行指定的腳本來恢復預警情況，或者通過重啟被監控機器解決。預警恢復部分預先在被監控機器上寫好事件處理腳本，當監控服務器發現被監控機器出現問題時，通過調用事件處理腳本來恢復預警情況。預警通知子模塊提供郵件通知、短信通知兩種通知方式。

3.5 系統管理模塊

本模塊包括配置文件管理子模塊設計，監控機器自動注冊子模塊設計，監控機器自動注銷子模塊設計。從用戶創建虛擬機群開始，機群中的機器可能會頻繁添加或者減少，這給集群監控服務器的管理提出了新問題。在虛擬機群創建的時候，用戶指定頭節點，頭節點虛擬機在創建的時候自動安裝有監控服務器程序，其他節點安裝有監控代理程序。當某個虛擬機被銷毀時，執行被銷毀虛擬機中的destroy腳本，在集群監控服務器的配置文件中注銷本機。當添加某個虛擬機時，向本機群監控服務器注冊本機及本機監控項。

3.6 監控代理和監控服務器

本模塊包括兩部分：第一部分是客戶端程序，運行于機群監控服務器，負責將本機群的監控數據送到全局服務器上去；另一部分是守護進程，它既可以獨立地運行于守護服務也可以注冊到inetd里作為一個inetd客戶程序提供監聽聯接。從機群服務器收到監控信息后，守護進程將結果提交給全局監控服務器，實際上是模擬了從一臺被監控機器上傳輸監控信息的一個過程，從全局監控服務器的視角看，從機群監控服務器傳來的數據和直接從被監控節點上傳來的數據沒有差別。

4 實驗測試與結果分析

4.1 監控服務器響應測試

監控服務器： CPU@2.0 GHz/2GMemory/160GHD，被監控機器： CPU@2.0 GHz/2GMemory/160GHD。

在LoadRunner中，設定25個User，每個User重復訪問服務器讀取監控數據，并進行5次點擊查看操作。運行9 min的過程中，重復了2 031 844次操作，共有2 031 844次成功返回結果。圖4為響應時間曲線，在并發數為20的情況下，最大響應時間為0.004 s。

最后報告成功了21 901 245次，平均19 004.8 /s，失敗1次，系統工作良好。在頻繁查詢的情況下可以正常的返回結果。

4.2 應用規模及系統占用資源測試

測試目的：總監控服務器共可以支持的下級服務器數目，每個下級服務器可以支持監控節點的數目；監控系統對機器性能的影響。監控服務器端性能影響，監控代理對被監控節點的性能影響，此處的性能影響主要是指對節點的CPU負載，內存占用的情況。

測試環境同上，在監控服務器上添加100個被監控主機，每個監控主機有五個監控項，監控項總數是502項，如圖5所示。

CPU占用率不超過3%，內存使用率不超過0.5%，實際間隔為2 min。在監控服務器上添加300個被監控主機，每個監控主機有五個監控項。CPU占用率為3%，峰值不超過7%。內存占用率不超過0.5%。CPU負載較100個節點的時候有所上升：0.9vs.0.5。進程數目增多：160vs.70，實際間隔為5 min。連續工作6天，從其自身的監控數據來看，一切工作正常，監控服務器性能狀況如圖6所示。

在監控服務器上添加500個被監控主機，每個監控主機有5個監控項，監控項總數是2 468項。在此情況下，機器負載有所上升。CPU占用率為3%，峰值不超過10%。內存占用率不超過0.5%。CPU負載較100個節點的時候有所上升：1.45vs.0.5。進程數目增多：240vs.70。定義的監控檢查時間間隔為1 min，但是實際間隔為10 min。

測試結論：CPU占用率在10%以內，內存使用在1%以內，實時性要求較高，則監控規模應控制在100以內。從性能角度來考慮，監控規模應控制在300以內。

5 結 論

基于虛擬機群、基礎設施共享的云計算環境與傳統機群有著不同的特點，現有的機群監控系統不能滿足規模擴展與云互聯的需求。為此，提出了CloudMonitor，一種面向云計算環境的監控系統。系統基于開源監控框架Nagios結合傳統監控系統和云計算環境的新特點，既能準確獲取監控信息又能適應虛擬網絡、虛擬機群的特點。

分析了云計算環境下監控的問題，同時給出了云計算平臺下資源監控系統的總體設計和詳細設計，對監控數據的采集、傳輸、存儲、讀取接口、監控服務器的結構及管理等方面都進行了詳細說明，給出了系統的測試過程和測試結果，證明了系統在功能上的完備性，并通過測試得到了總監控服務器共可以支持的下級服務器數目，每個下級服務器可以支持監控節點的數目以及監控系統對機器性能的影響。本文提出了一種多級監控服務器結構，解決了主機之間不能相互訪問的問題。

參考文獻

[1] 陳康，鄭緯民.云計算：系統實例與研究現狀[J].軟件學報，2009，20（5）：1337?1348.

[2] 許丞，劉洪，譚良，等.Hadoop云平臺的一種新的任務調度和監控機制[J].計算機科學，2013，40（1）：112?117.

[3] 方薇，崔超遠，王儒敬，等.Eucalyptus開源框架下云平臺的構建與性能分析[J].計算機系統應用，2012，21（6）：1?5.

[4] 成靜靜.基于Hadoop的分布式云計算/云存儲方案的研究與設計[J].數據通信，2012（5）：14?18.

[5] 張堯學，周悅芝.一種云計算操作系統TransOS：基于透明計算的設計與實現[J].電子學報，2011，39（5）：985?990.

[6] 馮登國，張敏，張妍，等.云計算安全研究[J].軟件學報，2011，22（1）：71?83.

[7] 羅軍舟，金嘉暉，宋愛波，等.云計算：體系架構與關鍵技術[J].通信學報，2011，32（7）：3?21.

[8] 穆俊.基于云平臺的并行關聯規則挖掘算法分析[J].現代電子技術，2015，38（11）：123?125.