云計算平臺下資源監(jiān)控系統(tǒng)的設計與開發(fā)

陳燕

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

關鍵詞： 云計算； 資源監(jiān)控； 機群管理； 虛擬機群

中圖分類號： 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 引 言

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

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

1 系統(tǒng)需求分析

1.1 問題概述

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

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

（2） 被監(jiān)控機器頻繁變動問題。這造成了在一個虛擬網(wǎng)絡內部節(jié)點的數(shù)目可能會經(jīng)常變動。用戶常常是一次性創(chuàng)建或銷毀一個虛擬網(wǎng)絡以及網(wǎng)絡內的全部機器。

1.2 物理機監(jiān)控需求

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

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

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

1.3 虛擬機監(jiān)控需求

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

結合上述特點得出監(jiān)控系統(tǒng)需求：計算環(huán)境中各個分節(jié)點部署獨立的監(jiān)控系統(tǒng)。

1.4 系統(tǒng)功能需求

數(shù)據(jù)采集模塊運行在所有的被監(jiān)控節(jié)點上，包括物理機和虛擬機。在創(chuàng)建出新的虛擬機時，自動將采集模塊安裝到新建的虛擬機中，采集模塊支持Windows和Linux操作系統(tǒng)。本模塊需要解決數(shù)據(jù)跨域傳輸?shù)膯栴}和數(shù)據(jù)安全性和及時性的問題。

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

2 系統(tǒng)總體設計

2.1 功能模塊設計

系統(tǒng)從功能上可以分為5個功能模塊：監(jiān)控數(shù)據(jù)獲取模塊、監(jiān)控數(shù)據(jù)傳輸模塊、監(jiān)控數(shù)據(jù)管理模塊、預警模塊、系統(tǒng)管理模塊，如圖2所示。

2.2 系統(tǒng)架構設計

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

2.3 系統(tǒng)層次設計

系統(tǒng)分為四層，自下而上分別是數(shù)據(jù)采集層，數(shù)據(jù)處理層，數(shù)據(jù)匯集層和監(jiān)控應用層。圖3為云計算平臺的系統(tǒng)層次結構圖。

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

監(jiān)控應用層包括監(jiān)控展示界面和監(jiān)控數(shù)據(jù)API。監(jiān)控展示界面提供區(qū)視圖、物理機視圖、虛擬機視圖三個視圖的監(jiān)控界面。向用戶展示實時監(jiān)控信息和歷史監(jiān)控信息。

3 系統(tǒng)詳細設計

3.1 監(jiān)控數(shù)據(jù)采集模塊

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

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

3.2 監(jiān)控數(shù)據(jù)傳輸模塊

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

3.3 監(jiān)控數(shù)據(jù)管理模塊

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

3.4 預警模塊

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

3.5 系統(tǒng)管理模塊

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

3.6 監(jiān)控代理和監(jiān)控服務器

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

4 實驗測試與結果分析

4.1 監(jiān)控服務器響應測試

監(jiān)控服務器： CPU@2.0 GHz/2GMemory/160GHD，被監(jiān)控機器： CPU@2.0 GHz/2GMemory/160GHD。

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

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

4.2 應用規(guī)模及系統(tǒng)占用資源測試

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

測試環(huán)境同上，在監(jiān)控服務器上添加100個被監(jiān)控主機，每個監(jiān)控主機有五個監(jiān)控項，監(jiān)控項總數(shù)是502項，如圖5所示。

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

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

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

5 結 論

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

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

參考文獻

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

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

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

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

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

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

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

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