可擴充套件整合化雲平臺監控機制的設計論文
可擴充套件整合化雲平臺監控機制的設計論文
1引言
過去幾年，隨著雲計算技術的不斷髮展，對於雲平臺監控的需求越來越迫切.作為雲計算資料中心的運維人員，需要隨時關注伺服器的效能指標，避免伺服器效能降低甚至當機的風險.。透過雲平臺資源的特點，可以知道雲平臺監控的主要難點集中在被監控的資源的多樣性、動態性及規模巨大這幾個方面:
1)資源的多樣性—雲平臺上的資源是多種多樣的，從作業系統上分，包括windows，linux，unix等不同的操作平臺;從系統架構上分，包括如cpu、記憶體、硬碟等底層的硬體;還包括如mysql資料庫、apache等各種應用程式和服務.如何將這些複雜的資源進行抽象分類，從而簡化監控任務，是雲平臺監控的一個重大挑戰.
2)資源的動態性—雲平臺上的資源不是固定不變的，雲平臺的節點可以動態的增加或減少，雲平臺上的應用及服務也可以動態的安裝或解除安裝.如何讓雲平臺監控動態適應雲平臺變化，是雲平臺監控一個重大挑戰.
3)資源的規模巨大—雲平臺往往包括成千上萬計算節點，而每個節點上執行著各種應用軟體和服務，造成雲平臺資源規模巨大，這就給監控系統帶來很大的負擔，同時影響雲平臺的效能.如何提供一種對雲平臺影響較小，且監控效率較高的系統，是雲平臺監控的一個重大挑戰.單一的監控軟體往往無法滿足雲平臺被監控資源的動態性、多樣性以及資源規模巨大的需求.為全面監控雲平臺資源，往往需要安裝多種監控軟體，在查詢時需頻繁切換不同軟體，不利於實時監控，同時增加了運維人員的工作量.文獻[2]提出一種基於Ganglia與MDS結合的網格監控體系研究，但該體系不具備可擴充套件介面，當現有軟體需要升級或需要增加新的監控軟體時，只能透過手工修改程式碼來完成.針對上述問題，提出一種可擴充套件整合化雲平臺監控機制，可以靈活整合多種監控軟體，以滿足對雲平臺資源的監控需求，並有效減輕運維人員的工作壓力，提高工作效率.
2相關工作
隨著雲平臺的發展，人們越來越關注雲平臺上資源的執行和使用情況，以滿足雲平臺監控使用者及時掌握雲平臺的執行狀態，因此，對雲平臺監控的研究也逐漸發展起來.下面從學術界和工業界兩方面討論雲平臺監控的相關工作.學術研究方面，在雲計算技術發展之前，叢集技術以其高性價比、易於擴充與易於裁減等諸多優點已經成為高效能計算常見的解決方案，對叢集監控的研究也逐漸受到研究人員的重視.隨後對網格計算的研究，研究人員針對於網格環境中的監控問題做了大量的研究工作，.整合化雲平臺監控機制針對在雲平臺監控中遇到的被監控的資源的動態性、多樣性及規模巨大等難題，提出了一種可擴充套件整合化雲平臺監控機制，下面將從監控系統框架、監控模型和監控軟體整合方法三個方面進行介紹.
3監控系統框架
我們提出一種可擴充套件整合化雲平臺監控體制，可以在雲平臺監控系統的底層動態的增加監控軟體，以適應雲平臺資源的多樣性和動態性的特點，這些操作對於使用者來說是透明的.圖1是監控系統框架圖，將從雲平臺資源、監控資料的提取及儲存、監控服務這三個方面介紹系統的框架.
3.1.1雲平臺資源根據雲平臺資源的特點，可以知道雲平臺被監控節點具有多樣性，根據不同的劃分方法對被監控節點進行分類，具體分類如下:
1)作業系統不同—根據作業系統的不同分類可以將監控節點分為window系統監控節點和類linux系統監控節點.2)應用和服務不同—由於被監控節點上執行著不同的應用程式及服務，如對mysql資料庫、apache等應用服務以及hadoop分散式框架進行監控，不同的監控軟體對於服務和程式的支援不同.
3.1.2監控資料的提取及儲存首先對監控資料的完整性進行定義:監控資料的完整性是指對監控軟體的資料進行即時儲存，並保證對所有的監控資料進行準確儲存，而不淘汰任何老資料.一般情況下，監控軟體會將監控資料存放在監控服務端的RRD資料庫中，RRD資料庫最大的特點是以迴圈格式來儲存資料，在持續插入新資料的過程中不斷淘汰老資料，因此RRD檔案大小保持在一定的範圍內.這樣不利於監控資料的完整儲存，所以需要採用一定的方法將監控資料儲存到可保證資料完整性的資料庫(如mysql，mongodb等)中，並進行持久儲存.
1)讀取特定埠取資料—被監控的節點將監控資料透過特定的埠傳輸到服務節點，按照一定的時間間隔去讀該埠並獲取xml資料，然後利用解析工具取得監控資料，最終存入可保證資料完整性的資料庫.2)透過指令碼轉存資料—對於不易透過埠獲取資料的監控軟體，則需要透過執行python或shell指令碼將監控資料從RRD資料庫轉存到可保證資料完整性的資料庫中，相比於上一種方法，這種轉存方式效率較低，實時性較差.
3.1.3監控服務在介紹監控服務之前首先要明確監控服務的使用者，使用者定義如下:
監控服務的使用者主要包括運維人員以及最終使用者.運維人員是需持續關注雲平臺資源的使用情況，並根據監控資料進行作業排程，任務遷移等操作的相關人員，另外運維人員還負責新增監控軟體，並進行相應配置.最終使用者是指需要檢視雲平臺資源的狀態，以及需要關注特定資源使用情況的相關人員.基於監控資料完整性儲存模組，雲平臺監控系統提供了配置引擎、查詢引擎、統計引擎和報警引擎四種功能引擎，並向上提供相應的功能介面.1)配置引擎:當現有的監控系統無法滿足著雲平臺資源的監控需求時，則可部署新的滿足條件的監控軟體，並透過配置引擎建立或修改監控軟體指標集與監控類屬性集間的對映關係.2)查詢引擎:系統預設向用戶提供給定時間段的查詢;另外系統還提供使用者自己定義時間段，監控系統透過一定的演算法實現在這個時間段內的監控狀態查詢.3)統計引擎:系統向用戶提供了監控叢集以及自定義子監控叢集整體負載的統計.4)報警引擎:系統向用戶提供系統設定閾值的報警，也提供使用者自定義指標的監控報警.
3.2監控模型
定義1.監控模型.可擴充套件整合化的雲平臺監控模型可以定義為一個三元組:MM=(MC，MS，MR)，其中:1)MC表示監控類，監控類可定義為一個二元組:MC=(ON，OP)，其中:(a)ON表示監控類的名稱(b)OP表示監控類的屬性集2)MS表示監控軟體，監控軟體可定義為一個二元組:MS=(SN，SV)，其中:(a)SN表示監控軟體的名稱(b)SV表示軟體監控的指標集3)MR表示對映關係，定義如下:
設mc是集合MC中一個監控類，對於衟1∈mc.OP，鰉s∈MS，鰒∈ms.SV，鰉r∈MR，滿足mr(p1)=v，且對於衟2∈mc.OP，p1≠p2，滿足mr(p2)≠v.定義2.監控物件MO=(ON，OP，OV，OT，MN)，其中:
(a)ON表示監控類的名稱(b)OP表示監控類的屬性集(c)OV表示監控物件的屬性值(d)MT表示取得監控資料的時間(e)MN表示監控資料屬於哪個節點定義3.監控類例項化.設mc為集合MC中一個監控類，mo為集合MO中一個監控物件，對於衟1∈mc.OP，鰌2∈mo.OP，且p1=p2，對於衟3∈mo.OP，鰌4∈mc.OP，且p3=p4，則可稱mo是mc的例項化，記為mo≤mmc.定理1.如果某個監控類的屬性與某監控軟體的指標之間存在對映關係，且一個監控物件是這個監控類的例項化，則這個監控物件的屬性與該監控軟體的指標之間存在對映關係.證明:設mc為集合MC中一個監控類，mo為集合MO中一個監控物件，根據定義3，mo≤mmc，對於衟1∈mo.OP，鰌2∈mc.OP，則p1=p2，又根據定義1，鰒∈ms.SV，鰉s∈MS，滿足mr(p2)=v，所以mr(p1)=v;又根據定義3，衟3∈mo.OP，且p1≠p3，鰌4∈mc.OP，則p3=p4，p1≠p4，p2≠p4.根據定義1，mr(p4)≠v，所以mr(p3)≠v.透過定義抽象的'監控類以及監控類和監控物件之間的例項化關係，使運維人員只需對監控類屬性和監控軟體指標之間的對映關係進行配置，不需要配置每個監控物件屬性與監控軟體指標之間的對映關係.定義了監控類例項化後，可以根據例項化關係自動生成監控物件與監控軟體之間的對映關係，大大減少了運維人員的工作量，也保證了對映關係的準確性.
3.3監控軟體整合方法
對於雲平臺來說，決不能假設它是一成不變的，對於雲平臺資源的動態變化或資源出現故障的情況，需要雲平臺能及時採取措施，做到對高層使用者透明或者儘可能減少使用者的損失.當現有的監控系統無法滿足雲平臺資源的動態增加而產生有些監控指標監控不到的時候，則需要考慮整合新的監控軟體，結合使用多種監控軟體對雲平臺資源進行監控.新增新的監控軟體時，首先將要增加的軟體註冊並部署到雲平臺，在軟體集合MS中增加ms.透過配置引擎建立或修改監控類屬性集OP與ms指標集SV間的對映關係mr.對於原監控軟體監控不到，而新增加的軟體可提供的指標項，直接增加新的軟體的指標項;對於原軟體與新軟體都可提供的指標項，可以從監控資料的實時性和準確性等角度綜合考慮是否要調整原有的對映關係.對映關係確定後，可推導得到監控物件的屬性與監控軟體指標集裡的元素形成的一對一對映關係.監控資料提取模組將根據新的對映關係提取監控資料，完成監控軟體的整合.監控資料存放在保證監控資料完整性的儲存模組，用來向上層提供業務服務.
透過上述對整合化的雲平臺監控機制的論述可表明，該機制的創新性主要體現在可以靈活的增加、刪除多種監控軟體，運維人員只需對監控類屬性和監控軟體指標之間的對映關係進行配置，繼而根據監控物件的例項化關係自動生成監控物件與監控軟體之間的對映關係，提高了監控軟體接入效率，也保證了對映關係的準確性.該機制還可將監控資料提取到可保證資料完整性的資料庫中進行持久儲存，以及封裝成相應的介面，以方便運維人員更好的對雲平臺進行監控管理.
4實驗及分析
4.1實驗環境設定
為了驗證這種可擴充套件整合化的雲平臺監控機制是否適應雲平臺的資源的多樣性、動態性及規模巨大的特點，我們搭建了一個雲平臺監控實驗系統.該實驗選擇4臺伺服器組成小型叢集，其中一臺win-dowsserver08的伺服器，三臺centos5.7的伺服器，軟體採用Ganglia-3.1.7，Cacti-0.8.8a.硬體環境均為2G記憶體，20G硬碟.一臺centos的伺服器作為監控頭結點，剩餘三臺伺服器作為實驗系統的代理節點.透過資料完整性提取方法將監控資料存到mysql資料庫中，並向使用者提供業務服務，實驗系統物理部署如圖3所示，其中.1)代理節點a:windows伺服器，開啟了snmp服務.2)代理節點b:Linux伺服器，開啟了snmp服務，且部署了hadoop分散式框架.3)代理節點c:Linux伺服器，開啟了snmp服務，且安裝了mysql資料庫服務.
4.2實驗結果與分析
實驗環境配置完成後，需要代理節點b上的hadoop框架進行監控，而Cacti對hadoop的指標監控不完整，所以需要整合Ganglia這款新的監控軟體，透過實驗系統提供的配置引擎，並遵循監控軟體的整合方法，將Ganglia整合到實驗系統並進行實驗.對Ganglia和Cacti共同監控的節點b進行實驗，每隔5分鐘記錄一次資料，並於實驗開始15分鐘後執行計算任務以增加負載和記憶體使用，35分鐘後結束任務，50分鐘後結束實驗.其中，系統真實值是呼叫linux的系統命令uptime、free得到的.圖4，圖5和圖6是從監控的實時性，準確性方面進行對比的.圖4和圖5中的縱座標表示1分鐘和15分鐘的平均負載，單位是個.圖6中的縱座標是空閒記憶體的容量，單位是KB.從實驗結果可以看出，雲平臺監控系統的監控數值與系統真實值更為接近，說明雲平臺監控系統的實時性和準確性較高.同時，我們還對監控指標的完整性進行了比較，在監控指標的完整性方面，雲平臺監控系統比Ganglia、Cacti單獨監控的指標更完整，從而保證了監控指標的完整性.透過以上的比較，可以發現搭建的雲平臺監控實驗系統在實時性、準確性及監控指標完整性方面要優於Ganglia或Cacti單獨監控，該雲平臺監控系統可以在一定程度上適應雲平臺資源規模巨大，動態性和多樣性方面的特點.
5結語
提出一種可擴充套件整合化的雲平臺監控機制，確定了新增新監控軟體的流程，並定義了兩種監控資料完整性提取和儲存方法.根據這種機制搭建了整合Ganglia和Cacti的雲平臺監控實驗系統，實驗表明，該系統具有良好的可擴充套件性，滿足對雲平臺動態變化資源的監控，可以有效減輕運維人員的工作壓力，提高工作效率.同時也驗證了該機制可以適應雲平臺表現出的特點，是解決雲平臺監控難題的一種有效途徑.