一種多云環(huán)境的資源及應(yīng)用監(jiān)控方法SEPQMS

朱華旻， 周振吉， 吳禮發(fā)， 王海波

(1.解放軍理工大學(xué) 指揮信息系統(tǒng)學(xué)院 江蘇 南京 210007；2.牡丹江醫(yī)學(xué)院 教育技術(shù)與信息中心 黑龍江 牡丹江 157011)

一種多云環(huán)境的資源及應(yīng)用監(jiān)控方法SEPQMS

朱華旻1， 周振吉1， 吳禮發(fā)1， 王海波2

(1.解放軍理工大學(xué) 指揮信息系統(tǒng)學(xué)院 江蘇 南京 210007；2.牡丹江醫(yī)學(xué)院 教育技術(shù)與信息中心 黑龍江 牡丹江 157011)

資源及應(yīng)用監(jiān)控是云資源規(guī)劃調(diào)度、彈性提供、服務(wù)質(zhì)量評價等的前提.基于多云監(jiān)控需求，提出了一種可擴展、適應(yīng)資源彈性、平臺獨立并提供傳輸質(zhì)量控制的多云監(jiān)控方法.采用以插件方式安裝指標(biāo)探測器的監(jiān)控代理，實施對資源及應(yīng)用相關(guān)指標(biāo)的收集.遵循對象管理組織的數(shù)據(jù)分發(fā)服務(wù)標(biāo)準(zhǔn)規(guī)范，設(shè)計了多云環(huán)境的發(fā)布/訂閱式監(jiān)控數(shù)據(jù)分發(fā)模型框架.原型系統(tǒng)實驗表明：本方法只引入了較小的監(jiān)控開銷，能夠跨平臺實施彈性的多云監(jiān)控，按需訂制監(jiān)控指標(biāo)，動態(tài)部署和自治管理監(jiān)控代理適應(yīng)監(jiān)控資源增減和遷移，并能按需控制監(jiān)控數(shù)據(jù)傳輸質(zhì)量.

多云監(jiān)控； 發(fā)布/訂閱模式； 擴展性； 彈性適應(yīng)； 服務(wù)質(zhì)量

0 引言

云監(jiān)控是對云對象狀態(tài)和表現(xiàn)的指標(biāo)持續(xù)系統(tǒng)地收集、分析和評價[1]，是有效管理云資源及應(yīng)用的前提，按監(jiān)控視角可分為面向提供商的監(jiān)控和面向用戶的監(jiān)控，按監(jiān)控對象層級可分為物理層監(jiān)控和虛擬層監(jiān)控，虛擬層又可分為基礎(chǔ)設(shè)施層、平臺層、應(yīng)用層[2].云資源規(guī)模龐大、動態(tài)性強、監(jiān)控視角和對象層級多樣，使云監(jiān)控面臨嚴(yán)峻挑戰(zhàn).特別在由經(jīng)紀(jì)人按需組合多個提供商資源的多云環(huán)境，云監(jiān)控需同時服務(wù)于經(jīng)紀(jì)人和各租戶，跨提供商獲取相關(guān)監(jiān)控指標(biāo)，面臨跨域、跨平臺、跨網(wǎng)絡(luò)等諸多挑戰(zhàn).

目前，工業(yè)界已經(jīng)有了提供商專用的監(jiān)控服務(wù)[3-4]和獨立的云監(jiān)控服務(wù)[5-7].學(xué)術(shù)界提出了不少云監(jiān)控方法[1, 8-11]，但這些方法大多針對單云環(huán)境設(shè)計.部分學(xué)者展開了多云監(jiān)控研究，例如Dastjerdi等[12]選擇提供商專用監(jiān)控服務(wù)或獨立云監(jiān)控服務(wù)進(jìn)行多云監(jiān)控，但這些外部監(jiān)控未必能提供所需指標(biāo)，也將引入更多指標(biāo)時延.Tovarňák等[1]提出了適用單云和多云的事件驅(qū)動監(jiān)控模型，基于收集指標(biāo)生成簡單事件，由各事件處理代理分別對簡單事件進(jìn)行關(guān)聯(lián)，產(chǎn)生多種復(fù)雜事件供訂閱，僅考慮了租戶監(jiān)控需求.Kertész等[13]提出了一個基于分布式經(jīng)紀(jì)人的多云協(xié)作框架，使用一個輕量級云指標(biāo)監(jiān)控服務(wù)，方法僅適用于文中提出的多云框架.Smit 等[14]提出了一個多云應(yīng)用級監(jiān)控框架，指標(biāo)被推送到系列流處理器產(chǎn)生監(jiān)控數(shù)據(jù)流，數(shù)據(jù)流被傳輸?shù)酱鎯σ妗⑼ǜ嬉婧途酆弦嫣幚懋a(chǎn)生高級指標(biāo)，框架僅服務(wù)于租戶并完全使用第三方監(jiān)控服務(wù).文獻(xiàn)[11]基于OMG DDS中間件設(shè)計了多云監(jiān)控框架，在被監(jiān)控VM相同位置物理機實例化一個發(fā)布者，利用libvirt庫訪問物理機獲取VM指標(biāo)，需要獲取物理機訪問權(quán)限，因此框架具有較大局限.總之，現(xiàn)有方法或者不能訂制指標(biāo)、或者不能滿足多方監(jiān)控需求、或者僅適用特定多云平臺、或者并非專為多云設(shè)計，不能較好滿足多云監(jiān)控需求.本文基于多云監(jiān)控需求分析，提出了一種可擴展、自適應(yīng)資源彈性、平臺獨立并提供傳輸服務(wù)質(zhì)量(QoS)支持的多云監(jiān)控方法SEPQMS(scalable, elastic-adaptive, platform-independent and QoS-enabled monitoring solution).主要工作及貢獻(xiàn)如下：1) 使用監(jiān)控代理實施對云資源及應(yīng)用監(jiān)控指標(biāo)的收集和推送，實現(xiàn)了監(jiān)控指標(biāo)的靈活訂制和監(jiān)控裝置的動態(tài)部署.2) 基于對象管理組織(OMG)的實時應(yīng)用數(shù)據(jù)分發(fā)服務(wù)(DDS)標(biāo)準(zhǔn)規(guī)范OMG DDS[15]，提出了多云監(jiān)控方法SEPQMS的主體框架.3) 選擇基于自適應(yīng)通信環(huán)境(adaptive communication environment, ACE)[16]、ACE對象請求代理(the ACE ORB, TAO)[16]和Open DDS中間件，實現(xiàn)了SEPQMS的原型.

1 多云環(huán)境的資源及應(yīng)用監(jiān)控需求

多云環(huán)境與單云環(huán)境在結(jié)構(gòu)及運行管理上的差異，使多云監(jiān)控具有許多獨特的需求特征.監(jiān)控主體及其指標(biāo)需求：監(jiān)控主體包括經(jīng)紀(jì)人和租戶，經(jīng)紀(jì)人需監(jiān)控掌握多云資源分布、資源類型數(shù)量細(xì)節(jié)及資源使用信息，以便實施費用管理和彈性提供資源等；租戶需監(jiān)控部署組件及依賴資源相關(guān)指標(biāo)，掌握組件性能表現(xiàn)并推斷其根源.監(jiān)控指標(biāo)傳輸QoS需求：來自不同提供商資源及部署組件的監(jiān)控指標(biāo)，需利用公網(wǎng)傳輸，傳輸QoS控制是需考慮的問題.同時滿足多方需求的統(tǒng)一監(jiān)控體系：若分別為經(jīng)紀(jì)人、租戶獨立構(gòu)建監(jiān)控系統(tǒng)，將產(chǎn)生許多重疊監(jiān)控設(shè)施，而租戶和經(jīng)紀(jì)人監(jiān)控的資源對象是重疊的，建設(shè)統(tǒng)一的監(jiān)控體系是合理選擇，將大大減小建設(shè)開銷、降低維護(hù)難度.平臺無關(guān)性：多云監(jiān)控涉及多個提供商資源，很可能使用不同虛擬系統(tǒng)， VM支持的操作系統(tǒng)往往也不同，這要求多云監(jiān)控體系必須滿足平臺無關(guān)性、安全性、可擴展性.彈性適應(yīng)和自治能力：需安全隔離各租戶監(jiān)控數(shù)據(jù)流，具備良好擴展性，能適應(yīng)或大或小的應(yīng)用和資源規(guī)模，并能夠按需訂制監(jiān)控指標(biāo)，另外，還需具備較好彈性適應(yīng)性，自動適應(yīng)監(jiān)控對象動態(tài)增減，且應(yīng)具備較強自治性，減少系統(tǒng)維護(hù)管理任務(wù).

2 多云監(jiān)控方法SEPQMS

2.1 OMG DDS概述

OMG發(fā)布的分布式實時應(yīng)用數(shù)據(jù)分發(fā)服務(wù)標(biāo)準(zhǔn)OMG DDS[15](簡稱DDS)，已被廣泛接受采用.對于分布式應(yīng)用，面向消息的數(shù)據(jù)分發(fā)模型，特別是發(fā)布/訂閱模型，與C/S模式相比，提供了更好的性能和靈活性.DDS正是以數(shù)據(jù)為中心，使用發(fā)布/訂閱模型的數(shù)據(jù)分發(fā)標(biāo)準(zhǔn)，支持傳輸QoS控制.DDS結(jié)構(gòu)包含核心層，即發(fā)布/訂閱層(DCPS)和可選的數(shù)據(jù)本地重構(gòu)層(DLRL).DCPS模型主要實體有：數(shù)據(jù)域，是數(shù)據(jù)流分隔范圍，僅限同一域內(nèi)實體間才可相互通信；主題，發(fā)布者和訂閱者通過主題通告發(fā)布和接收信息，主題使用唯一名稱和數(shù)據(jù)類型，可附加QoS約束控制分發(fā)；發(fā)布者，管理所屬數(shù)據(jù)寫入器，負(fù)責(zé)發(fā)布主題，按QoS約束建立數(shù)據(jù)通信通道；訂閱者，管理所屬數(shù)據(jù)讀取器，負(fù)責(zé)發(fā)布訂閱主題，接收主題數(shù)據(jù)并轉(zhuǎn)發(fā)；數(shù)據(jù)寫入器，唯一對應(yīng)一個發(fā)布主題，主題樣本生成時，它通過發(fā)布者將數(shù)據(jù)傳輸給訂閱者；數(shù)據(jù)讀取器，唯一對應(yīng)一個訂閱主題，當(dāng)訂閱者獲得主題數(shù)據(jù)后，將其轉(zhuǎn)發(fā)給相應(yīng)數(shù)據(jù)讀取器.

2.2 SEPQMS監(jiān)控方法設(shè)計原則

1) 采用DDS發(fā)布/訂閱模型.多云資源及應(yīng)用組件數(shù)量多、動態(tài)性強、布局分散， DDS模型能夠適應(yīng)發(fā)布者和接收者的動態(tài)變化以及較大規(guī)模監(jiān)控布局，可提供傳輸質(zhì)量支持滿足如實時性、完整性等需求.已有的一些高質(zhì)量開源DDS標(biāo)準(zhǔn)中間件，能夠簡化系統(tǒng)實現(xiàn)，增強穩(wěn)定性和可靠性.2) 冗余設(shè)計的集中式主題注冊匹配模式.分布式主題注冊匹配模式全局廣播主題信息，通信信道的不充分可靠，很可能造成部分節(jié)點信息不完整，主題廣播還會增加網(wǎng)絡(luò)流量.集中式模式使用綁定固定IP的注冊匹配服務(wù)器，發(fā)布者、訂閱者主動提交主題注冊，服務(wù)器執(zhí)行注冊和匹配并返回結(jié)果，能保證信息完整并減少流量開銷，性能瓶頸、單點故障可通過服務(wù)器冗余設(shè)計等方法解決.3) 用插件式監(jiān)控代理收集指標(biāo).安裝監(jiān)控代理是廣泛采用的指標(biāo)收集方式[2, 8-9,17]，監(jiān)控代理以插件方式容納、管理數(shù)個指標(biāo)探測器(Probe)，可動態(tài)部署，按需安裝和配置Probe并處理和推送收集的指標(biāo).Probe實施指標(biāo)收集，內(nèi)置通用功能并對外提供可自定義擴展的抽象接口.4) 監(jiān)控數(shù)據(jù)安全隔離和發(fā)布者、訂閱者的部署.將各租戶的應(yīng)用、資源及相關(guān)實體劃分到單獨DCPS數(shù)據(jù)域，保證租戶應(yīng)用安全.發(fā)布者、訂閱者是框架核心實體，如果讓一個發(fā)布者管理太多監(jiān)控代理，將承受過大通信及處理壓力，而部署太多發(fā)布者必導(dǎo)致系統(tǒng)出現(xiàn)過多節(jié)點和大量連接需要維護(hù).權(quán)衡考量，以應(yīng)用組件為單位部署發(fā)布者，而訂閱實體類型相對較少，以應(yīng)用為單位部署訂閱者即可.

2.3 SEPQMS監(jiān)控方法的主體框架結(jié)構(gòu)

1) 概述.SEPQMS多云監(jiān)控方法主體框架如圖1所示.主要包含注冊匹配服務(wù)器Cen_ Reg_ Match_ Server、訂閱者Subscriber、發(fā)布應(yīng)用PublishApp、監(jiān)控代理Mon_Agent等設(shè)施.PublishApp與Mon_Agent部署結(jié)構(gòu)如圖2所示.在第三方BROKER中，部署冗余設(shè)計的注冊匹配服務(wù)器，為每個應(yīng)用部署一個Subscriber，分配一個數(shù)據(jù)域dom，實例化應(yīng)用管理、資源彈性、費用管理3個訂閱實體.為每個應(yīng)用組件部署一個PublishApp，當(dāng)組件部署于多個VM時，PublishApp部署于負(fù)載平衡器，否則部署在組件相同VM中.PublishApp包含發(fā)布者Publisher、監(jiān)控代理管理Mon_Admin和監(jiān)控指標(biāo)管理Metrics_Admin組件.

圖1 SEPQMS的主體框架結(jié)構(gòu)

圖2 發(fā)布應(yīng)用與監(jiān)控代理部署結(jié)構(gòu)圖

2) 發(fā)布/訂閱主題注冊匹配及監(jiān)控數(shù)據(jù)分發(fā)流程.如時序圖3所示.新發(fā)布者和訂閱者主動向服務(wù)器提交主題注冊請求.服務(wù)器收到請求后分別在發(fā)布主題表和訂閱主題表加入新主題；對新發(fā)布主題遍歷訂閱主題表進(jìn)行匹配，對新訂閱主題遍歷發(fā)布主題表進(jìn)行匹配，然后返回注冊匹配結(jié)果.

圖3 發(fā)布/訂閱主題注冊匹配及監(jiān)控數(shù)據(jù)分發(fā)流程

發(fā)布應(yīng)用收到主題匹配結(jié)果，首先更新本地訂閱主題表，然后按照訂閱主題及附加QoS需求，由監(jiān)控指標(biāo)管理組件定義指標(biāo)訂閱規(guī)則，生成監(jiān)控代理配置調(diào)整參數(shù)，例如監(jiān)控代理ID、指標(biāo)類型、更新周期等，監(jiān)控代理管理組件根據(jù)配置參數(shù)配置調(diào)整監(jiān)控代理.監(jiān)控代理按照更新的監(jiān)控配置，配置調(diào)用Probe執(zhí)行指標(biāo)收集，然后匯集Probe監(jiān)控指標(biāo)進(jìn)行結(jié)構(gòu)處理后向發(fā)布應(yīng)用推送，指標(biāo)管理組件對推送的指標(biāo)，按主題指標(biāo)訂閱規(guī)則進(jìn)行過濾、聚合等生成主題樣本，提交給數(shù)據(jù)寫入器，數(shù)據(jù)寫入器通過發(fā)布者與訂閱者連接通信傳輸主題數(shù)據(jù)，訂閱者接收發(fā)布者的主題數(shù)據(jù)并轉(zhuǎn)發(fā)給訂閱實體.

3) 主題數(shù)據(jù)模型及指標(biāo)訂閱規(guī)則語言.按DDS規(guī)范使用主題及數(shù)據(jù)類型管理監(jiān)控數(shù)據(jù)，根據(jù)VM和應(yīng)用組件相關(guān)指標(biāo)，定義了常用指標(biāo)數(shù)據(jù)類型，例如VM的CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤使用信息等，如表1所示.

表1 常用的VM監(jiān)控指標(biāo)類型及主題規(guī)劃

發(fā)布應(yīng)用需根據(jù)訂閱主題配置監(jiān)控代理實施指標(biāo)收集，為此定義了一種指標(biāo)訂閱規(guī)則語言，將訂閱主題高級指標(biāo)與監(jiān)控指標(biāo)及其監(jiān)控代理進(jìn)行關(guān)聯(lián).例如數(shù)據(jù)類型為CPUInfo的主題包含avg_cpuUtil等高級指標(biāo)，avg_cpuUtil等于組件各VM的 CPU平均利用率，用三元組{Filter, Members, Period}描述指標(biāo)訂閱規(guī)則.用Filter將高級指標(biāo)映射為一套低級指標(biāo)，可組合使用算術(shù)運算符號(+、-、*、/等)和組函數(shù)(AVG、SUM、MIN、MAX等)，對低級指標(biāo)進(jìn)行過濾聚合；用Members指定相關(guān)監(jiān)控代理ID；用Period指定指標(biāo)收集聚合周期.使用BNF格式[18-19]描述了訂閱規(guī)則語言.

4) 兩級心跳監(jiān)控機制.使用兩級心跳監(jiān)控對監(jiān)控節(jié)點實施?；罟芾?，采用被動心跳監(jiān)控以減小開銷，即由發(fā)布應(yīng)用和訂閱者主動向服務(wù)器周期發(fā)送心跳包，而監(jiān)控代理也周期地向?qū)?yīng)發(fā)布應(yīng)用發(fā)送心跳包.服務(wù)器持續(xù)收到心跳包則維護(hù)節(jié)點狀態(tài)為UP，若連續(xù)未收到心跳包達(dá)指定最大次數(shù)，即認(rèn)為該節(jié)點失效，將狀態(tài)置為DEAD.為自動感知節(jié)點位置遷移，在心跳包中嵌入了節(jié)點地址信息.

3 基于ACE、TAO、OpenDDS中間件實現(xiàn)原型

圖4 SEPQMS原型的分層結(jié)構(gòu)圖Fig.4 Layered structure diagram of SEPQMS prototype

SEPQMS原型軟件分層結(jié)構(gòu)如圖4所示.操作系統(tǒng)之上依次是開源中間件ACE、TAO和OpenDDS[16]，及最上層的發(fā)布應(yīng)用、訂閱應(yīng)用、注冊匹配應(yīng)用.底層ACE屏蔽了OS差異，向TAO、OpenDDS和應(yīng)用程序提供通信功能接口.TAO是CORBA標(biāo)準(zhǔn)中間件，它使用ACE提供的組件和框架構(gòu)建了對象請求代理(ORB)，具有很高性能和可靠性，原型采用TAO實現(xiàn)發(fā)布者和訂閱者的主題注冊服務(wù).OpenDDS是Object Computing公司遵循DDS標(biāo)準(zhǔn)的開源中間件，實現(xiàn)了DDS DCPS核心層及QoS控制，使用ACE和TAO提供的框架和接口，提供“可插拔傳輸層”實現(xiàn)監(jiān)控數(shù)據(jù)傳輸.基于OpenDDS實現(xiàn)了監(jiān)控數(shù)據(jù)發(fā)布/訂閱功能層，并與原型其他組件如監(jiān)控代理等實現(xiàn)對接.

1) 監(jiān)控代理與指標(biāo)探測器：使用Java代理開發(fā)平臺JADE開發(fā)監(jiān)控代理，結(jié)構(gòu)如圖5所示.它部署啟動后，發(fā)布應(yīng)用連接器立即向發(fā)布應(yīng)用請求連接，隨后發(fā)送其ID、IP、收集指標(biāo)等元數(shù)據(jù)并等待監(jiān)控指令.發(fā)布應(yīng)用根據(jù)匹配的訂閱主題，生成相應(yīng)的監(jiān)控配置參數(shù)發(fā)送給相關(guān)監(jiān)控代理，而后Probe控制器完成監(jiān)控配置并啟動相關(guān)Probe測量.Probe收集指標(biāo)送至指標(biāo)隊列，之后由監(jiān)控代理封裝為消息，陸續(xù)推送給發(fā)布代理.

2) 發(fā)布應(yīng)用和訂閱應(yīng)用.發(fā)布應(yīng)用包含監(jiān)控代理管理、監(jiān)控指標(biāo)管理和OpenDDS發(fā)布者、數(shù)據(jù)寫入器等組件.監(jiān)控代理管理組件管理所屬監(jiān)控代理，處理其連接請求和心跳包、對監(jiān)控代理進(jìn)行參數(shù)配置等.指標(biāo)管理組件負(fù)責(zé)對匹配主題實施指標(biāo)訂閱，獲得監(jiān)控配置參數(shù)，并在收到監(jiān)控指標(biāo)后按訂閱規(guī)則將其映射為高級指標(biāo)，生成主題樣本提交給數(shù)據(jù)寫入器，后者通過發(fā)布者與訂閱者建立通信，按主題QoS約束將數(shù)據(jù)傳送給訂閱者，訂閱者接收主題數(shù)據(jù)并轉(zhuǎn)發(fā)給相應(yīng)數(shù)據(jù)讀取器保存.

4 實驗及分析

為了對SEPQMS的功能以及主要特性進(jìn)行檢驗和評價，選擇在幾個公有云部署如下代表性應(yīng)用，搭建真實多云環(huán)境.Cassandra DB[20]，是一個NoSQL分布式存儲系統(tǒng)，采用無中心架構(gòu)，客戶端讀寫數(shù)據(jù)時，系統(tǒng)隨機調(diào)度訪問任一節(jié)點并同步節(jié)點數(shù)據(jù)，施加較大負(fù)載時簇節(jié)點CPU利用率增加，這里基于CPU使用率決策資源升級.YCSB[21]是由Yahoo針對NoSQL系統(tǒng)開發(fā)的性能測試框架，能產(chǎn)生6種不同負(fù)載，利用YCSB產(chǎn)生對Cassandra的負(fù)載，任選部署YCSB的A、C、E這3種負(fù)載.

圖5 監(jiān)控代理結(jié)構(gòu)圖

選擇在3個公有云安排如下：分別部署10個VM，8個部署Cassandra數(shù)據(jù)庫，2個部署YCSB客戶端，3個云分別部署YCSB的A、C、E負(fù)載，使用規(guī)格不一、操作系統(tǒng)各異的VM.具體如下：在Amazon新加坡數(shù)據(jù)中心，部署10個m1.small(使用CentOS)EC2實例，實施YCSB A負(fù)載；在Rackspace香港數(shù)據(jù)中心，部署10個General1-2實例(使用Debian)，實施 YCSB C負(fù)載；在Linode新加坡數(shù)據(jù)中心，部署10個Linode2GB實例(使用Ubuntu)，實施YCSB E負(fù)載；選擇Cassandra簇和YCSB客戶端的任一VM部署發(fā)布應(yīng)用；部署在YCSB VM的監(jiān)控代理安裝VM及YCSB應(yīng)用相關(guān)Probe，部署在Cassandra VM的監(jiān)控代理，安裝VM及Cassandra應(yīng)用相關(guān)Probe.在本地一臺服務(wù)器(聯(lián)想i7、Intel 4核處理器、8 GB內(nèi)存)實例化2個VM，分別部署主題注冊匹配服務(wù)器和訂閱應(yīng)用.開發(fā)了幾個Probes分別對如表1所示常用15個VM指標(biāo)，以及Cassandra讀寫延遲、YCSB吞吐量和延遲指標(biāo)進(jìn)行測量.

4.1 檢驗SEPQMS對監(jiān)控資源彈性的適應(yīng)能力

3個云中監(jiān)控設(shè)施對資源彈性適應(yīng)過程完全相似，因此只在一個云中進(jìn)行實驗.在Amazon的10個VM的2個VM部署Cassandra簇，2個部署YCSB，生成不斷增大負(fù)載，導(dǎo)致Cassandra VM的CPU使用率不斷增大，設(shè)定當(dāng)簇CPU平均使用率達(dá)75%，即新添1個VM加入Cassandra簇，Cassandra為應(yīng)付逐漸加大的負(fù)載，動態(tài)添加更多節(jié)點，直到8個VM全部添加.監(jiān)控代理隨新添加VM一同部署，訂閱應(yīng)用對YCSB和Cassandra組件的CPU_Info、Memory_Info、YCSBInfo、CassandraInfo等主題進(jìn)行訂閱.監(jiān)控代理一經(jīng)部署初始化后，即與其發(fā)布應(yīng)用連接，接受參數(shù)配置，隨后開始指標(biāo)收集和推送.實驗顯示SEPQMS能夠較好滿足應(yīng)用資源彈性提供環(huán)境的監(jiān)控需求.

4.2 實施多云部署，進(jìn)行跨平臺性、監(jiān)控擴展能力及QoS支持能力、監(jiān)控開銷的檢驗評價

圖6 主要監(jiān)控實體CPU及內(nèi)存使用率分布Fig.6 CPU and memory usage distribution of monitoring entities

在3個云分別部署YCSB負(fù)載A、C、E，各云均包含YCSB和Cassandra組件，將3個云中的6個組件均劃分到同一個租戶監(jiān)控數(shù)據(jù)域，實例化一個訂閱實體對6個組件的VM及應(yīng)用指標(biāo)主題進(jìn)行訂閱.每個云開始時初始化2個YCSB VM和1個Cassandra VM，然后每10分鐘從剩下的7個VM中任選一個初始化加入到Cassandra簇，直到所有Cassandra VM全部初始化并開始收集.為評價監(jiān)控框架擴展能力，考慮訂閱實體作為監(jiān)控數(shù)據(jù)匯集點，隨VM規(guī)模升級，將承受越來越大的處理壓力，特別測量了訂閱實體的archiving時間，即處理及保存監(jiān)控數(shù)據(jù)的平均時間.升級多云應(yīng)用拓?fù)溆?個VM到30個VM時，觀察到archiving平均時間從20 ms上升到40 ms，呈現(xiàn)很緩慢的上升.另外，實驗中觀察到Y(jié)CSB和Cassandra節(jié)點VM監(jiān)控代理，以及發(fā)布應(yīng)用、訂閱應(yīng)用的CPU和內(nèi)存使用率分布如圖6所示.YCSB節(jié)點監(jiān)控代理CPU及內(nèi)存最大使用率分別是0.7%、2.0%，Cassandra的該值分別為0.3%、1.6%，發(fā)布應(yīng)用的該值分別為1%、2.5%，訂閱應(yīng)用的該值分別為1.5%和3.5%，可以看出，監(jiān)控設(shè)施的資源開銷還是比較小的.此外，3個云中VM均采用不同操作系統(tǒng)，SEPQMS有效實現(xiàn)了跨平臺監(jiān)控.實驗中還對訂閱主題附加了不同的更新周期、最大數(shù)據(jù)延遲、傳輸協(xié)議配置等QoS選項，實驗表明SEPQMS有效實現(xiàn)了對傳輸QoS的控制.

5 結(jié)論

本文在深入分析多云資源及應(yīng)用監(jiān)控需求基礎(chǔ)上，提出了一種可擴展、能適應(yīng)資源彈性、與平臺無關(guān)、并支持傳輸QoS控制的多云監(jiān)控方法SEPQMS，實現(xiàn)了系統(tǒng)原型，搭建真實多云環(huán)境，部署SEPQMS原型進(jìn)行了實驗，驗證了SEPQMS的功能及擴展性、平臺無關(guān)性、彈性適應(yīng)性及自治性等主要屬性.對監(jiān)控設(shè)施開銷的分析表明，引入SEPQMS對多云應(yīng)用環(huán)境的影響很小.

[3] AMAZON. Amazon cloudwatch[DS/OL].[2016-09-08].http://aws.amazon.com/cn/cloudwatch/.

[4] MICROSOFT. Microsoft azure[DS/OL].[2016-09-08].https://azure.microsoft.com/en-in/marketplace/partners/paraleap/azurewatch/.

[5] VMWARE. VRealize hyperic[DS/OL].[2016-09-08].http://www.cloudstatus.com/.

[6] MONITIS. All-in-one application monitoring platform[DS/OL].[2016-09-08].http://www.monitis.com/.

[7] LOGIC MONITOR. Monitor on-premise,cloud and hybrid datacenters from a single platform[DS/OL].[2016-09-08].http://www.logicmonitor.com/.

[8] AVERSA R, TASQUIER L,VENTICINQUE S. Agents based monitoring of heterogeneous cloud infrastructures [C]//Proceedings of the 10th International Conference on Ubiquitous Intelligence and Computing, and the 10th International Conference on Autonomic and Trusted Computing(UIC/ATC). Vietri sul Mare, 2013: 527-532.

[9] TRIHINAS D, PALLIS G, DIKAIAKOS M D. JCatascopia: monitoring elastically adaptive applications in the cloud [C]//Proceedings of the 14th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing. Chicago,2014: 226-235.

[10]LEITNER P, INZINGER C, HUMMER W, et al. Application-level performance monitoring of cloud services based on the complex event processing paradigm [C]//Proceedings of the 5th IEEE International Conference on Service-Oriented Computing and Applications. Taipei, 2012: 1-8.

[11]AN K, PRADHAN S, CAGLAR F, et al. A publish/subscribe middleware for dependable and real-time resource monitoring in the cloud [C]// Proceedings of the Workshop on Secure and Dependable Middleware for Cloud Monitoring and Management. New York, 2012: 3.

[12]DASTJERDI A V, TABATABAEI S G H, BUYYA R. A dependency-aware ontology-based approach for deploying service level agreement monitoring services in Cloud [J]. Software practice & experience, 2012, 42(4): 501-518.

[13]KERTéSZ A, KECSKEMETI G, ORIOL M, et al. Enhancing federated cloud management with an integrated service monitoring approach [J]. Journal of grid computing, 2013, 11(4): 699-720.

[14]SMIT M, SIMMONS B, LITOIU M. Distributed, application-level monitoring for heterogeneous clouds using stream processing [J]. Future generation computer systems, 2013, 29(8): 2103-2114.

[15]OMG. Data distribution service[DS/OL].[2016-09-08].http://www.omg.org/spec/DDS/.

[16]WASHINGTON UNIVERSITY. Computer science and engineering[DS/OL].[2016-09-08].http://www.cs.wustl.edu/.

[17]KATSAROS G, KOUSIOURIS G, GOGOUVITIS S V, et al. A self-adaptive hierarchical monitoring mechanism for clouds [J]. Journal of systems and software, 2012, 85(5): 1029-1041.

[18]楊明輝, 郭肇德. 基于擴展的 BNF 文法的通用語法分析算法[J]. 軟件學(xué)報, 1992, 3(3): 24-32.

[19]蔡宏果, 元昌安, 羅錦光, 等.基于server session約束的序列模式增長挖掘研究[J].鄭州大學(xué)學(xué)報(理學(xué)版), 2010, 42(1): 24-28.

[20]LAKSHMAN A, MALIK P. Cassandra:a decentralized structured storage system [J]. ACM SIGOPS operating systems review, 2010, 44(2): 35-40.

[21]ABUBAKAR Y, ADEYI T, AUTA I G. Performance evaluation of No SQL systems using YCSB in a resource austere environment [J]. Performance evaluation, 2014, 7(8):23-27.

(責(zé)任編輯：王海科)

An SEPQMS Approach to Monitoring Resource and Application for Multi-Cloud

ZHU Huamin1, ZHOU Zhenji1, WU Lifa1, WANG Haibo2

(1.InstituteofCommandInformationSystem,PLAUniversityofScienceandTechnology,Nanjing210007,China; 2.CenterofEducationalTechnologyandInformation,MudanjiangMedicalUniversity,Mudanjiang157011,China)

The monitoring of resources and applications was the prerequisite in resource planning, resource scheduling, elastic provision, and service quality evaluation in cloud computing. Based on the demand in multi-cloud monitoring, a scalable, elastic-adaptive, platform-independent and QoS-enabled monitoring solution (SEPQMS) was proposed. A monitoring-agent-based method was used to collect monitoring metrics, by which metric probes could be installed in a plug-in manner. Also, a monitoring data distribution architecture was devised based on the publish/subscribe model according to the specification of object management group data distribution service (OMG DDS). Finally, a prototype of SEPQMS was developed to test. The result showed that SEPQMS could monitor multi-clouds of various sizes in a platform-independent way,and monitoring metrics could be customized as needed. It was also proved that SEPQMS could adapt to the elasticity and migration of cloud resources,and could control the quality of monitoring data transmission. Moreover, SEPQMS had low runtime footprint.

multi-cloud monitoring; publish/subscribe model; scalability; elastic-adaptive; quality of service

2016-11-10

江蘇省自然科學(xué)基金項目(BK20131069).

朱華旻(1978—)，男，四川遂寧人，博士研究生，主要從事網(wǎng)絡(luò)應(yīng)用研究，E-mail: 58656046@qq.com; 通信作者：吳禮發(fā)(1968—)，男，湖北黃岡人，教授，主要從事網(wǎng)絡(luò)與信息安全研究，E-mail: wulifa@vip.163.com.

TP393.09

A

1671-6841(2017)03-0045-07

10.13705/j.issn.1671-6841.2016317