一種多云環境的資源及應用監控方法SEPQMS

朱華旻， 周振吉， 吳禮發， 王海波

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

一種多云環境的資源及應用監控方法SEPQMS

朱華旻1， 周振吉1， 吳禮發1， 王海波2

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

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

多云監控； 發布/訂閱模式； 擴展性； 彈性適應； 服務質量

0 引言

云監控是對云對象狀態和表現的指標持續系統地收集、分析和評價[1]，是有效管理云資源及應用的前提，按監控視角可分為面向提供商的監控和面向用戶的監控，按監控對象層級可分為物理層監控和虛擬層監控，虛擬層又可分為基礎設施層、平臺層、應用層[2].云資源規模龐大、動態性強、監控視角和對象層級多樣，使云監控面臨嚴峻挑戰.特別在由經紀人按需組合多個提供商資源的多云環境，云監控需同時服務于經紀人和各租戶，跨提供商獲取相關監控指標，面臨跨域、跨平臺、跨網絡等諸多挑戰.

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

1 多云環境的資源及應用監控需求

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

2 多云監控方法SEPQMS

2.1 OMG DDS概述

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

2.2 SEPQMS監控方法設計原則

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

2.3 SEPQMS監控方法的主體框架結構

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

圖1 SEPQMS的主體框架結構

圖2 發布應用與監控代理部署結構圖

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

圖3 發布/訂閱主題注冊匹配及監控數據分發流程

發布應用收到主題匹配結果，首先更新本地訂閱主題表，然后按照訂閱主題及附加QoS需求，由監控指標管理組件定義指標訂閱規則，生成監控代理配置調整參數，例如監控代理ID、指標類型、更新周期等，監控代理管理組件根據配置參數配置調整監控代理.監控代理按照更新的監控配置，配置調用Probe執行指標收集，然后匯集Probe監控指標進行結構處理后向發布應用推送，指標管理組件對推送的指標，按主題指標訂閱規則進行過濾、聚合等生成主題樣本，提交給數據寫入器，數據寫入器通過發布者與訂閱者連接通信傳輸主題數據，訂閱者接收發布者的主題數據并轉發給訂閱實體.

3) 主題數據模型及指標訂閱規則語言.按DDS規范使用主題及數據類型管理監控數據，根據VM和應用組件相關指標，定義了常用指標數據類型，例如VM的CPU、內存、網絡、磁盤使用信息等，如表1所示.

表1 常用的VM監控指標類型及主題規劃

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

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

3 基于ACE、TAO、OpenDDS中間件實現原型

圖4 SEPQMS原型的分層結構圖Fig.4 Layered structure diagram of SEPQMS prototype

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

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

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

4 實驗及分析

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

圖5 監控代理結構圖

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

4.1 檢驗SEPQMS對監控資源彈性的適應能力

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

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

圖6 主要監控實體CPU及內存使用率分布Fig.6 CPU and memory usage distribution of monitoring entities

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

5 結論

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

[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]. 軟件學報, 1992, 3(3): 24-32.

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

(責任編輯：王海科)

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

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

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

TP393.09

A

1671-6841(2017)03-0045-07

10.13705/j.issn.1671-6841.2016317