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

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

0 引言

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

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

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

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

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

2.1 OMG DDS概述

OMG發(fā)布的分布式實(shí)時(shí)應(yīng)用數(shù)據(jù)分發(fā)服務(wù)標(biāo)準(zhǔn)OMG DDS[15](簡稱DDS)，已被廣泛接受采用.對(duì)于分布式應(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í)體有：數(shù)據(jù)域，是數(shù)據(jù)流分隔范圍，僅限同一域內(nèi)實(shí)體間才可相互通信；主題，發(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ù)寫入器，唯一對(duì)應(yīng)一個(gè)發(fā)布主題，主題樣本生成時(shí)，它通過發(fā)布者將數(shù)據(jù)傳輸給訂閱者；數(shù)據(jù)讀取器，唯一對(duì)應(yīng)一個(gè)訂閱主題，當(dāng)訂閱者獲得主題數(shù)據(jù)后，將其轉(zhuǎn)發(fā)給相應(yīng)數(shù)據(jù)讀取器.

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

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

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

1) 概述.SEPQMS多云監(jiān)控方法主體框架如圖1所示.主要包含注冊(cè)匹配服務(wù)器Cen_ Reg_ Match_ Server、訂閱者Subscriber、發(fā)布應(yīng)用PublishApp、監(jiān)控代理Mon_Agent等設(shè)施.PublishApp與Mon_Agent部署結(jié)構(gòu)如圖2所示.在第三方BROKER中，部署冗余設(shè)計(jì)的注冊(cè)匹配服務(wù)器，為每個(gè)應(yīng)用部署一個(gè)Subscriber，分配一個(gè)數(shù)據(jù)域dom，實(shí)例化應(yīng)用管理、資源彈性、費(fèi)用管理3個(gè)訂閱實(shí)體.為每個(gè)應(yīng)用組件部署一個(gè)PublishApp，當(dāng)組件部署于多個(gè)VM時(shí)，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ā)布/訂閱主題注冊(cè)匹配及監(jiān)控?cái)?shù)據(jù)分發(fā)流程.如時(shí)序圖3所示.新發(fā)布者和訂閱者主動(dòng)向服務(wù)器提交主題注冊(cè)請(qǐng)求.服務(wù)器收到請(qǐng)求后分別在發(fā)布主題表和訂閱主題表加入新主題；對(duì)新發(fā)布主題遍歷訂閱主題表進(jìn)行匹配，對(duì)新訂閱主題遍歷發(fā)布主題表進(jìn)行匹配，然后返回注冊(cè)匹配結(jié)果.

圖3 發(fā)布/訂閱主題注冊(cè)匹配及監(jiān)控?cái)?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)管理組件對(duì)推送的指標(biāo)，按主題指標(biāo)訂閱規(guī)則進(jìn)行過濾、聚合等生成主題樣本，提交給數(shù)據(jù)寫入器，數(shù)據(jù)寫入器通過發(fā)布者與訂閱者連接通信傳輸主題數(shù)據(jù)，訂閱者接收發(fā)布者的主題數(shù)據(jù)并轉(zhuǎn)發(fā)給訂閱實(shí)體.

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

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

3 基于ACE、TAO、OpenDDS中間件實(shí)現(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)用、注冊(cè)匹配應(yīng)用.底層ACE屏蔽了OS差異，向TAO、OpenDDS和應(yīng)用程序提供通信功能接口.TAO是CORBA標(biāo)準(zhǔn)中間件，它使用ACE提供的組件和框架構(gòu)建了對(duì)象請(qǐng)求代理(ORB)，具有很高性能和可靠性，原型采用TAO實(shí)現(xiàn)發(fā)布者和訂閱者的主題注冊(cè)服務(wù).OpenDDS是Object Computing公司遵循DDS標(biāo)準(zhǔn)的開源中間件，實(shí)現(xiàn)了DDS DCPS核心層及QoS控制，使用ACE和TAO提供的框架和接口，提供“可插拔傳輸層”實(shí)現(xiàn)監(jiān)控?cái)?shù)據(jù)傳輸.基于OpenDDS實(shí)現(xiàn)了監(jiān)控?cái)?shù)據(jù)發(fā)布/訂閱功能層，并與原型其他組件如監(jiān)控代理等實(shí)現(xiàn)對(duì)接.

1) 監(jiān)控代理與指標(biāo)探測(cè)器：使用Java代理開發(fā)平臺(tái)JADE開發(fā)監(jiān)控代理，結(jié)構(gòu)如圖5所示.它部署啟動(dòng)后，發(fā)布應(yīng)用連接器立即向發(fā)布應(yīng)用請(qǐ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)控配置并啟動(dòng)相關(guān)Probe測(cè)量.Probe收集指標(biāo)送至指標(biāo)隊(duì)列，之后由監(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)控代理，處理其連接請(qǐng)求和心跳包、對(duì)監(jiān)控代理進(jìn)行參數(shù)配置等.指標(biāo)管理組件負(fù)責(zé)對(duì)匹配主題實(shí)施指標(biāo)訂閱，獲得監(jiān)控配置參數(shù)，并在收到監(jiān)控指標(biāo)后按訂閱規(guī)則將其映射為高級(jí)指標(biāo)，生成主題樣本提交給數(shù)據(jù)寫入器，后者通過發(fā)布者與訂閱者建立通信，按主題QoS約束將數(shù)據(jù)傳送給訂閱者，訂閱者接收主題數(shù)據(jù)并轉(zhuǎn)發(fā)給相應(yīng)數(shù)據(jù)讀取器保存.

4 實(shí)驗(yàn)及分析

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

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

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

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

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

4.2 實(shí)施多云部署，進(jìn)行跨平臺(tái)性、監(jiān)控?cái)U(kuò)展能力及QoS支持能力、監(jiān)控開銷的檢驗(yàn)評(píng)價(jià)

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

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

5 結(jié)論

本文在深入分析多云資源及應(yīng)用監(jiān)控需求基礎(chǔ)上，提出了一種可擴(kuò)展、能適應(yīng)資源彈性、與平臺(tái)無關(guān)、并支持傳輸QoS控制的多云監(jiān)控方法SEPQMS，實(shí)現(xiàn)了系統(tǒng)原型，搭建真實(shí)多云環(huán)境，部署SEPQMS原型進(jìn)行了實(shí)驗(yàn)，驗(yàn)證了SEPQMS的功能及擴(kuò)展性、平臺(tái)無關(guān)性、彈性適應(yīng)性及自治性等主要屬性.對(duì)監(jiān)控設(shè)施開銷的分析表明，引入SEPQMS對(duì)多云應(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]楊明輝, 郭肇德. 基于擴(kuò)展的 BNF 文法的通用語法分析算法[J]. 軟件學(xué)報(bào), 1992, 3(3): 24-32.

[19]蔡宏果, 元昌安, 羅錦光, 等.基于server session約束的序列模式增長挖掘研究[J].鄭州大學(xué)學(xué)報(bào)(理學(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é)基金項(xiàng)目(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