Openstack虛擬化流量平臺監(jiān)控系統(tǒng)①

徐 毅,曾文兵

(電子科技大學(xué) 電子科學(xué)技術(shù)研究院,成都 611731)

云計算[1]是計算機(jī)領(lǐng)域繼八十年代時期大型計算機(jī)向客戶端-服務(wù)器轉(zhuǎn)變后的又一次重要技術(shù)革新,其不但繼承了并行計算、分布式計算、網(wǎng)格計算等以往高效的計算方式的優(yōu)點,同時融入了越發(fā)成熟的虛擬化技術(shù).

面對著信息時代再一次的大力度提速,云計算能夠整合大量普通的基礎(chǔ)設(shè)施,運(yùn)用著虛擬化技術(shù)構(gòu)成一個龐大的資源池,用戶不必要關(guān)心底層具體的實現(xiàn)方式,即可按需獲取計算能力和存儲等各種服務(wù).經(jīng)過接近十年的不斷改革與發(fā)展,云計算已經(jīng)不再是Google、亞馬遜、IBM等公司的專屬產(chǎn)品了,其正在走向普遍化,并且滲透進(jìn)入著各行各業(yè)的發(fā)展之中.構(gòu)建自己的云平臺已經(jīng)成為企業(yè)發(fā)展的必經(jīng)之路.

Openstack是當(dāng)下相當(dāng)流行和優(yōu)秀的云平臺建設(shè)開源項目,Neutron是Openstack中處理網(wǎng)絡(luò)流量的重要模塊.由于自身設(shè)計的局限,當(dāng)Neutron面對過于龐大的網(wǎng)絡(luò)流量和來自客戶對高效性的要求時,其自身的網(wǎng)絡(luò)流量瓶頸也就越發(fā)的明顯.現(xiàn)今成熟的云平臺將面對著成百上千的物理服務(wù)器和更加龐大的虛擬機(jī)群,其日常產(chǎn)生的通信流量將是非常的巨大.如此,解決Neutron的流量瓶頸就變得迫在眉睫.與此同時,合理運(yùn)用對虛擬流量的有效監(jiān)控和對SDN著名的Openflow協(xié)議的有效解讀,將為我們在理論上解決前面的問題提供堅實的基礎(chǔ).

面對著現(xiàn)今越發(fā)龐大的云系統(tǒng)架構(gòu),對于監(jiān)控系統(tǒng)的研究也逐步成為信息計算機(jī)行業(yè)的重點.國內(nèi)外現(xiàn)今較為流行的云監(jiān)控產(chǎn)品十分豐富,國外首當(dāng)其沖的就是亞馬遜的云監(jiān)控服務(wù)CloudWatch,其次還有能夠提供網(wǎng)絡(luò)、服務(wù)、應(yīng)用等多種監(jiān)控的Monitis軟件.國內(nèi)較為知名的云監(jiān)控產(chǎn)品有阿里云監(jiān)控、基于網(wǎng)站綜合性能進(jìn)行監(jiān)控的監(jiān)控寶、以及具有較好伸縮性的CreCloud云網(wǎng)管等等.但是市場上這些具有成熟框架的監(jiān)控產(chǎn)品,大多是基于物理平臺資源的,或則是針對網(wǎng)站性能和特定云平臺進(jìn)行監(jiān)控的.同時對于虛擬化平臺資源的監(jiān)控并沒有形成一個成熟的解決方案,在虛擬化平臺資源和Openstack云平臺的監(jiān)控上,業(yè)內(nèi)學(xué)者也進(jìn)行了相應(yīng)的研究,但在監(jiān)控方面主要是利用以往運(yùn)用在傳統(tǒng)物理平臺上的監(jiān)控軟件進(jìn)行二次配置,如Nagios,MRTG,colledtd等等,但是其中絕大多數(shù)方案都需要通過在被監(jiān)控的虛擬機(jī)上布置監(jiān)控代理等,這無疑將加大虛擬機(jī)的負(fù)載,降低服務(wù)質(zhì)量.

本文系統(tǒng)中通過開源的LibvirtAPI直接部署在計算節(jié)點宿主機(jī)上的方式來獲取虛擬服務(wù)器的狀態(tài)信息,替代了原來需要在各被監(jiān)控虛擬機(jī)上布置插件的方式,由此減輕了虛擬服務(wù)器的壓力,提高了其QoS.同時利用輕量級的開源虛擬交換機(jī)Openswitch對sFlow和Openflow協(xié)議的支持,合理使用了sFlow協(xié)議對于流量信息的監(jiān)控能力和Openflow流表對于數(shù)據(jù)轉(zhuǎn)發(fā)的有效支持,構(gòu)建出了一套新型高效的云平臺虛擬機(jī)監(jiān)控系統(tǒng).

1 Neutron網(wǎng)絡(luò)模塊與SDN以及LibvirtAPI關(guān)鍵技術(shù)介紹

1.1 Neutron[2]模塊概述

Openstack項目中包含有計算(Nova)、存儲(Swift)、網(wǎng)絡(luò)(Neutron)、身份服務(wù)(Keyston)等幾個核心子項目.其中Neutron是整個云架構(gòu)的網(wǎng)絡(luò)組件,在Openstack發(fā)展的初期,虛擬網(wǎng)絡(luò)的創(chuàng)建和管理是由Nova項目來實現(xiàn)的,叫做Nova-network.其可以提供簡單的網(wǎng)絡(luò)服務(wù)和基于L2的網(wǎng)絡(luò)服務(wù).但隨著云計算中對網(wǎng)絡(luò)更為復(fù)雜和高級的要求,社區(qū)中孵化了一個單獨(dú)的網(wǎng)絡(luò)項目,稱為Quantum,后來由于版權(quán)的問題,更名為Neutron.Neutron本身架構(gòu)由三個核心部件構(gòu)成,Neutron Server組件是最核心的一個組件,其中含有守護(hù)進(jìn)程neutron-server.Neutron整體框架組成上可以簡單的定義為Neutron Server+API+Plugin,即提供給外部調(diào)用的功能接口和對內(nèi)部擴(kuò)充時運(yùn)用的插件.最后結(jié)合位于兩者中間的Nertron Server就夠成了我們的Neutron組件.

Neutron中的各個組件在實際部署中通常根據(jù)各自的功能實現(xiàn)的不同,分別布置在Openstack框架中的三個節(jié)點中,分別是用于部署Neutron Server的控制節(jié)點、部署負(fù)責(zé)轉(zhuǎn)發(fā)服務(wù)的L3-agent和提供DHCP服務(wù)的DHCP-agent等插件的網(wǎng)絡(luò)節(jié)點、部署負(fù)責(zé)具體實現(xiàn)的 Plugin-agent(插件代理)的計算節(jié)點.在Neutron部署的網(wǎng)絡(luò)拓?fù)鋱D中還有三個關(guān)鍵的網(wǎng)絡(luò)需要我們認(rèn)識,分別是負(fù)責(zé)Openstack中各個模塊之間交互和連接數(shù)據(jù)庫的管理網(wǎng)絡(luò)(Management Network)、負(fù)責(zé)虛擬機(jī)之間數(shù)據(jù)交互的數(shù)據(jù)網(wǎng)絡(luò)(Data Network)、最后是虛擬機(jī)連接外部或則外部調(diào)用Openstack的API都必須通過的外部網(wǎng)絡(luò)(External Network).

1.2 SDN技術(shù)概述

SDN[3]技術(shù)即軟件定義網(wǎng)絡(luò)技術(shù),最初起源于2006年斯坦福大學(xué)的Clean Slatey研究課題,并于2009年由Mckeown教授提出了核心的SDN概念.不同于傳統(tǒng)控制邏輯耦合在相應(yīng)硬件模塊上的形式,SDN技術(shù)采用控制邏輯和實際工作硬件組相互分開的形式.作為一種新型的網(wǎng)絡(luò)創(chuàng)新架構(gòu),是對傳統(tǒng)分布式網(wǎng)絡(luò)架構(gòu)的一種應(yīng)時更進(jìn).由于現(xiàn)今網(wǎng)絡(luò)更新和創(chuàng)建的速度已經(jīng)達(dá)到了新量級,快速的網(wǎng)絡(luò)業(yè)務(wù)變更直接要求系統(tǒng)更頻繁的更新網(wǎng)絡(luò)設(shè)備的配置(路由器、交換機(jī)、防火墻等).但在傳統(tǒng)分布式網(wǎng)絡(luò)中,網(wǎng)絡(luò)設(shè)備不僅承擔(dān)著網(wǎng)絡(luò)數(shù)據(jù)處理還要承擔(dān)相應(yīng)邏輯控制,所以一旦在業(yè)務(wù)發(fā)生變更后再進(jìn)行配置就將變得相當(dāng)龐雜.SDN將網(wǎng)絡(luò)設(shè)備的控制邏輯從普通網(wǎng)絡(luò)設(shè)備中剝離出來,將其集中化,再形成新的集中控制平臺,使設(shè)備只需要負(fù)責(zé)單純的數(shù)據(jù)處理.同時SDN將向上提供開放的API接口給用戶,既北向接口.向下開發(fā)出接口連接普通網(wǎng)絡(luò)設(shè)備層,既南向接口.同時集中數(shù)據(jù)轉(zhuǎn)發(fā)邏輯與SDN控制器,從而形成高效且不依賴轉(zhuǎn)發(fā)設(shè)備的現(xiàn)代化網(wǎng)絡(luò)架構(gòu).

1.3 LibvirtAPI關(guān)鍵技術(shù)

LibvirtAPI[4]指的是Libvirt虛擬化庫,該虛擬化庫中是一套面向虛擬機(jī)的開源API.LibvirtAPI主要應(yīng)用在基于Linux系統(tǒng)的虛擬機(jī)管理上,現(xiàn)在LibvirtAPI已經(jīng)能夠向KVM、XEN、QEMU、VMWARE等諸多主流虛擬機(jī)提供一套完整通用的API編程接口,通過該接口可以忽略不同Hypervisor的差異實現(xiàn)高效的虛擬機(jī)管理.LibvirtAPI所有API均采用C語言進(jìn)行開發(fā),可以有效地切合Linux系統(tǒng).LibvirtAPI可以根據(jù)其功能分為五個API部分:虛擬機(jī)監(jiān)管程序連接API、域API、網(wǎng)絡(luò)API、存儲卷API和存儲池API.其中虛擬機(jī)監(jiān)管程序連接API是前綴為virConnect的一套API,virConnect是使用LibvirtAPI其它API的基礎(chǔ),既需要首先通過virConnect和Hypervisor建立連接,才能調(diào)用其它API進(jìn)入虛擬機(jī)監(jiān)控信息獲取的使用流程.

LibvirtAPI直接部署在物理機(jī)的Linux操作系統(tǒng)上,同時,對于物理機(jī)上不同的虛擬機(jī),LibvirtAPI為用戶屏蔽了底層Hypervisor的差異,通過對其提供統(tǒng)一的virConnect接口,建立起與虛擬機(jī)群之間的連接.其中,Hypervisor負(fù)責(zé)統(tǒng)計和管理對應(yīng)虛擬機(jī)群和其占有的所有資源.與其建立連接后,通過調(diào)用LibvirtAPI相應(yīng)API接口便可以獲取來自Hypervisor對虛擬機(jī)群所有有價值的資源統(tǒng)計信息.利用LibvirtAPI技術(shù)不僅解除了傳統(tǒng)方法中將虛擬機(jī)當(dāng)作物理機(jī),在每個被監(jiān)控虛擬服務(wù)節(jié)點部署監(jiān)控代理時虛擬機(jī)承受的額外壓力.同時,也使得用戶和運(yùn)維人員可以在單一物理機(jī)上實現(xiàn)對其上多臺和多樣的虛擬服務(wù)器的監(jiān)控管理,有效地提高了相應(yīng)的工作效率.

2 Openstack虛擬化流量監(jiān)控系統(tǒng)主要功能模塊設(shè)計與分析

2.1 系統(tǒng)整體架構(gòu)設(shè)計思想及主要模塊流程分析

本次設(shè)計的主題思想是利用有效的虛擬流量監(jiān)控和建立基于Openflow流表的數(shù)據(jù)轉(zhuǎn)發(fā)機(jī)制,有效地解決開源項目Openstack云平臺上存在的網(wǎng)絡(luò)瓶頸問題.系統(tǒng)將利用SDN技術(shù)中的Openflow協(xié)議與Openstack中的網(wǎng)絡(luò)模塊Neutron進(jìn)行集成,構(gòu)建成系統(tǒng)的流量轉(zhuǎn)發(fā)控制模塊.同時,使用Openflow流表取代網(wǎng)絡(luò)節(jié)點成為唯一的流量轉(zhuǎn)發(fā)標(biāo)準(zhǔn),構(gòu)建基于該流表的Openflow虛擬交換機(jī)模塊進(jìn)行流量轉(zhuǎn)發(fā)和虛擬機(jī)選擇.在計算節(jié)點上布置librvirt和sFlow進(jìn)行虛擬機(jī)普通數(shù)據(jù)和網(wǎng)絡(luò)數(shù)據(jù)的采集,同時構(gòu)建監(jiān)控模塊獲取其對虛擬機(jī)實時性能的采集信息.獲得的數(shù)據(jù)一方面直接通過用戶界面反饋給管理員,另一方面會將數(shù)據(jù)放入內(nèi)存數(shù)據(jù)庫Redis隨時供控制模塊調(diào)用數(shù)據(jù),控制模塊根據(jù)調(diào)用的實時數(shù)據(jù)以及動態(tài)負(fù)載均衡算法制定著合適的轉(zhuǎn)發(fā)流表,從而使整個系統(tǒng)能夠趨向于負(fù)載均衡.

系統(tǒng)整體采用分布式架構(gòu)進(jìn)行設(shè)計,搭建在Openstack云平臺之中.自頂向下的設(shè)計中依次包含五個重要的功能部分,第一個模塊是web用戶模塊,該模塊是基于Openstack的Dashboard模塊設(shè)計的,主要用于與用戶交互.第二個部分是控制模塊,其核心部件是Neutron中的守護(hù)進(jìn)程N(yùn)eutron-server和Openflow控制器,控制模塊主要負(fù)責(zé)向上提供API接收用戶的請求,向下關(guān)聯(lián)著流表,接收虛擬交換機(jī)模塊的反饋消息進(jìn)行處理.第三個功能模塊是虛擬交換機(jī)模塊,其負(fù)責(zé)提取來自虛擬機(jī)的數(shù)據(jù)包并且維護(hù)流表,比較數(shù)據(jù)包是否能匹配到對應(yīng)的流表項,若沒有匹配到則向控制模塊進(jìn)行反饋.第四個功能部分是虛擬服務(wù)器模塊,在此所有的虛擬服務(wù)器都是由Nova進(jìn)行創(chuàng)建,Nova是Openstack中的計算組件,其負(fù)責(zé)虛擬機(jī)的創(chuàng)建和資源的調(diào)度等.第五個功能模塊是監(jiān)控模塊,其負(fù)責(zé)通過Livirt API和sFlow[5]進(jìn)行虛擬機(jī)群的信息監(jiān)控收集,獲得的數(shù)據(jù)通過josn的格式存儲在Redis數(shù)據(jù)庫中.控制模塊和用戶可以從數(shù)據(jù)庫中獲得必要的信息分別進(jìn)行負(fù)載均衡和及時向用戶反饋.

圖1是整個系統(tǒng)的架構(gòu)圖,從圖中可以看到各個模塊之間的基本聯(lián)系.整個系統(tǒng)是SDN技術(shù)與Openstack的一個集成,分別將Openflow控制器集成到Openstack的網(wǎng)絡(luò)組件Neutron中形成控制模塊,控制模塊向上提供給客戶API,相當(dāng)于北向集成.控制模塊根據(jù)來自監(jiān)控模塊的數(shù)據(jù)進(jìn)行流表的制定,以期達(dá)到負(fù)載均衡.同時,虛擬交換機(jī)模塊橋接著計算組件Nova中的虛擬機(jī)群,虛擬機(jī)群的所有交互流量都需要

通過虛擬交換機(jī)模塊的處理,虛擬交換機(jī)模塊同時也維護(hù)著流表,如果一段數(shù)據(jù)包并沒有匹配到流表項,則虛擬交換機(jī)模塊將會反饋到控制模塊,控制模塊會進(jìn)行處理后制定新的流表完成數(shù)據(jù)包的轉(zhuǎn)發(fā).監(jiān)控模塊為了獲取虛擬機(jī)群的實時性能信息將采用Livirt API和sFlow協(xié)議,Libvirt API負(fù)責(zé)獲取物理信息,sFlow負(fù)責(zé)獲取虛擬機(jī)群網(wǎng)絡(luò)運(yùn)行狀態(tài).數(shù)據(jù)會存儲在Redis數(shù)據(jù)庫進(jìn)行保存,Redis[6]數(shù)據(jù)庫是一種基于內(nèi)存的數(shù)據(jù)庫,存儲效率優(yōu)秀.

圖1 系統(tǒng)整體架構(gòu)圖

2.2 控制模塊分析

控制模塊是基于Openstack的網(wǎng)絡(luò)組件Neutron和Openflow協(xié)議而集成的[7],是系統(tǒng)中最為核心的功能模塊.Neutron負(fù)責(zé)整個Openstack的組網(wǎng)模式,將Openflow控制器集成于其中而形成的控制模塊向上對用戶提供API接口,使得用戶的數(shù)據(jù)包能夠到達(dá)控制模塊,向下連接著虛擬交換機(jī)模塊以便間接控制流量轉(zhuǎn)發(fā).同時控制模塊負(fù)責(zé)制定轉(zhuǎn)發(fā)流表,每當(dāng)需要根據(jù)Openflow協(xié)議制定流表時,都會從監(jiān)控模塊中提取虛擬服務(wù)器負(fù)載數(shù)據(jù)并且使用相關(guān)負(fù)載均衡算法進(jìn)行 流表制定.下層的虛擬交換機(jī)模塊將根據(jù)流表分發(fā)用戶請求和進(jìn)行虛擬機(jī)群數(shù)據(jù)流量轉(zhuǎn)發(fā),以期系統(tǒng)性能達(dá)到最佳.

圖2是控制模塊的結(jié)構(gòu)圖,從圖中可以看到控制模塊的基本工作流程.其在北向連接上層用戶,南向下發(fā)流表給虛擬交換機(jī)模塊控制數(shù)據(jù)轉(zhuǎn)發(fā).控制模塊在北向接口接收到來自用戶的請求后,其會首先提取用戶數(shù)據(jù)包中的源MAC地址,同時與所維護(hù)流表進(jìn)行匹配操作,如果存在有流表項與該數(shù)據(jù)包匹配,則說明該條用戶請求是一條舊的請求,則由原虛擬機(jī)服務(wù)器繼續(xù)未完成服務(wù).同時為了能順利區(qū)分新舊用戶請求,控制模塊會自行維護(hù)一張已提供服務(wù)流表項表用于匹配,以期達(dá)到虛擬服務(wù)器對外提供服務(wù)期間的完整性.在整個服務(wù)期間,由于虛擬交換機(jī)模塊工作于二層協(xié)議,虛擬機(jī)的IP是不會暴露給用戶的,所以整個后臺服務(wù)的處理程序?qū)τ诳蛻魜碚f都是透明的,用戶并不會知道為其提供服務(wù)的是哪一臺虛擬機(jī).如果虛擬服務(wù)器沒有該源地址MAC的記錄信息,則說明該條用戶請求是新的,控制模塊將根據(jù)來自Redis數(shù)據(jù)庫的監(jiān)控信息和負(fù)載均衡算法[8]為用戶選擇合適的虛擬服務(wù)器.

圖2 控制模塊結(jié)構(gòu)圖

控制模塊在南向與虛擬交換機(jī)模塊相聯(lián)系,虛擬交換機(jī)模塊直接與計算組件Nova構(gòu)建的計算節(jié)點群相橋接.Nova創(chuàng)建的虛擬機(jī)分布于各個計算節(jié)點上,虛擬機(jī)相互之間產(chǎn)生的數(shù)據(jù)流量包和與外界交互的數(shù)據(jù)流量包都直接通過虛擬交換機(jī)模塊進(jìn)行轉(zhuǎn)發(fā),而不用再去創(chuàng)立單一的網(wǎng)絡(luò)節(jié)點.每當(dāng)虛擬交換機(jī)模塊接收到來自底層虛擬機(jī)群的數(shù)據(jù)包的時候,首先會提取數(shù)據(jù)包,并且嘗試匹配到相應(yīng)的流表項,如果匹配到相應(yīng)的流表項,則根據(jù)流表項中的目的地址進(jìn)行下一步的數(shù)據(jù)轉(zhuǎn)發(fā).如果沒有能匹配到相應(yīng)的流表項,則將該來自虛擬機(jī)的數(shù)據(jù)包發(fā)往控制模塊處理.控制模塊將提取數(shù)據(jù)包中相關(guān)信息,并且為其定制相應(yīng)流表并且下發(fā)新建流表到虛擬交換機(jī)模塊進(jìn)行再一次的數(shù)據(jù)包轉(zhuǎn)發(fā).

2.3 虛擬交換機(jī)模塊分析

Openvswitch[9]是一款十分優(yōu)秀的開源虛擬交換機(jī),Openswitch虛擬交換機(jī)已經(jīng)完全實現(xiàn)了傳統(tǒng)物理交換機(jī)的功能,并且Openswitch已經(jīng)提供了對sFlow和Openflow協(xié)議的支持.這些特性使得該虛擬交換機(jī)能夠在Openflow的支持下作為Openflow交換機(jī)進(jìn)行基于流表轉(zhuǎn)發(fā)數(shù)據(jù),且與控制邏輯層解耦的新一代交換機(jī),相對于此,將轉(zhuǎn)發(fā)邏輯融合在內(nèi)的傳統(tǒng)物理交換機(jī)就顯得沉重緩慢.同時,Openswitch主要是通過C語言實現(xiàn),因此對于在大多數(shù)平臺上進(jìn)行部署都會較好移植.

基于Openflow和Openswitch實現(xiàn)的虛擬交換機(jī)模塊兼具著良好的控制性和擴(kuò)展性,具體的數(shù)據(jù)轉(zhuǎn)發(fā)控制策略都是由控制模塊進(jìn)行制定,因此也就實現(xiàn)了數(shù)據(jù)轉(zhuǎn)發(fā)和邏輯控制的分離.這種低耦合也是SDN技術(shù)的核心思想,系統(tǒng)中各模塊在這種低耦合的體系中,只需要專注處理好自身的任務(wù)便可,從而能成倍的提高運(yùn)行效率.

圖3是虛擬交換機(jī)模塊在系統(tǒng)中的工作流程圖,從圖中可以了解到虛擬交換機(jī)模塊處在控制模塊與虛擬服務(wù)器之間,負(fù)責(zé)的任務(wù)就是基于流表的數(shù)據(jù)轉(zhuǎn)發(fā).在系統(tǒng)中,虛擬交換機(jī)模塊只是負(fù)責(zé)實現(xiàn)普通虛擬交換機(jī)的數(shù)據(jù)轉(zhuǎn)發(fā)功能,對于數(shù)據(jù)包如何進(jìn)行轉(zhuǎn)發(fā)則毫不知情,在整個Openflow虛擬網(wǎng)絡(luò)中,該組件只是一個執(zhí)行者.其只需要根據(jù)控制模塊已經(jīng)規(guī)劃好并且下發(fā)流表的邏輯進(jìn)行機(jī)械的操作便可.也正是由于這種特點,使得虛擬交換機(jī)模塊具有了很好的擴(kuò)展性,如果需要更新或則改變擴(kuò)展功能時,我們只需要去改變控制模塊端的相應(yīng)規(guī)則便可.

圖3 虛擬交換機(jī)模塊工作流程圖

虛擬交換機(jī)模塊根據(jù)控制模塊中的Openflow控制器制定的轉(zhuǎn)發(fā)邏輯完成虛擬機(jī)數(shù)據(jù)流量的轉(zhuǎn)發(fā)和用戶請求的重定向.在整個平臺中,虛擬交換機(jī)模塊基于Openflow協(xié)議和控制模塊交互,虛擬交換機(jī)負(fù)責(zé)的基本流程為:接收來自控制模塊的用戶請求并根據(jù)流表項進(jìn)行虛擬機(jī)服務(wù)器選擇、同時接收來自底層虛擬機(jī)群的數(shù)據(jù)包并且匹配到相應(yīng)流表項、如果沒有匹配到則反饋到控制模塊建立新的流表.虛擬交換機(jī)所維護(hù)的流表大多都是通過這種方式建立的.

2.4 監(jiān)控機(jī)模塊分析

監(jiān)控模塊是整個系統(tǒng)中聯(lián)系底層計算節(jié)點和控制模塊的邏輯中軸,監(jiān)控模塊將密切關(guān)注處于計算節(jié)點上的各虛擬機(jī)的實時狀態(tài)并且及時向控制模塊和用戶管理員反映虛擬機(jī)群的狀態(tài),方便控制模塊能夠獲得及時的數(shù)據(jù)以便在制定流表項的時候使整個系統(tǒng)達(dá)到負(fù)載均衡,也使管理員用戶能夠及時感知整個系統(tǒng)的運(yùn)行狀態(tài).

現(xiàn)今對虛擬機(jī)的監(jiān)控最為常見的方式便是在虛擬機(jī)中部署Agent進(jìn)行虛擬機(jī)狀態(tài)信息的獲取,這種傳統(tǒng)的監(jiān)控方式是從對物理機(jī)的監(jiān)控上移植過來的.這種通過代理獲取服務(wù)器狀態(tài)信息的監(jiān)控方式主要是基于SNMP協(xié)議進(jìn)行實現(xiàn)的,當(dāng)下使用十分廣泛的nagios監(jiān)控系統(tǒng)即是一個基于SNMP協(xié)議的系統(tǒng),nagios[10]作為一款優(yōu)秀的開源電腦系統(tǒng)和網(wǎng)絡(luò)監(jiān)視工具,能夠十分高效的完成對Windows、Linux、Unix等系統(tǒng)的主機(jī)狀態(tài)和交換機(jī)路由器等網(wǎng)絡(luò)配置的監(jiān)控.但是,正如其它基于SNMP協(xié)議的監(jiān)控一樣,負(fù)責(zé)管理的平臺必須要維護(hù)一個服務(wù)器程序nagios-server,同時對于不同的被監(jiān)控系統(tǒng)需要其維護(hù)不同的客戶端程序,如Windows系統(tǒng)下需要安裝nsclient++客戶端程序,而Linux系統(tǒng)則需要安裝nagios的nrpe插件,這無疑將是虛擬服務(wù)器的一項巨大負(fù)擔(dān).

因此,本系統(tǒng)的在對監(jiān)控模塊進(jìn)行設(shè)計時,摒棄了原本在虛擬服務(wù)器上部署Agent的做法,轉(zhuǎn)而將采用在物理宿主機(jī)上直接部署LibvirtAPI的方式來設(shè)計監(jiān)控模塊.系統(tǒng)中,監(jiān)控模塊使用LibvirtAPI和sFlow

協(xié)議去獲取虛擬機(jī)的網(wǎng)絡(luò)流量信息和虛擬機(jī)運(yùn)行的基本信息.不同于基于SNMP協(xié)議的監(jiān)控程序,Libvirt提供了一種虛擬機(jī)監(jiān)控程序察覺不到的API接口,其直接部署在物理機(jī)上,通過virConnect接口與虛擬機(jī)管理器建立連接,安全的運(yùn)行于宿主機(jī)之上對虛擬機(jī)進(jìn)行穩(wěn)定的監(jiān)控.建立連接后可以通過virNetwork接口對虛擬機(jī)網(wǎng)絡(luò)相關(guān)信息進(jìn)行管理、通過virDomain接口可以獲取虛擬機(jī)CPU使用的相關(guān)信息、通過virStorageVol接口對存儲情況進(jìn)行監(jiān)控.同時sFlow協(xié)議在LbvirtAPI的基礎(chǔ)上獲取網(wǎng)絡(luò)相關(guān)信息,其后傳遞信息至管理員和數(shù)據(jù)庫中.LibvirAPI直接連接Hypervisor對虛擬機(jī)相關(guān)信息進(jìn)行獲取,相較于通過分散在各虛擬機(jī)內(nèi)部的代理獲取的方式也將更具高可用性.

圖4是監(jiān)控系統(tǒng)相關(guān)模塊結(jié)構(gòu)圖,從圖中可以看出整個監(jiān)控系統(tǒng)中以監(jiān)控模塊為核心,向下通過LibvirtAPI和sFlow協(xié)議獲取虛擬服務(wù)器的運(yùn)行狀態(tài)和網(wǎng)絡(luò)狀態(tài)信息,向上則可以直接反饋信息給管理員用戶以便其可以內(nèi)視系統(tǒng)的整體狀況.同時,由于監(jiān)控信息的實時性,數(shù)據(jù)不必要進(jìn)行持久化,因此選擇Redis數(shù)據(jù)庫進(jìn)行數(shù)據(jù)存儲.控制模塊通過Redis數(shù)據(jù)庫便可獲取相關(guān)監(jiān)控信息,并利用監(jiān)控實時信息對流表進(jìn)行維護(hù)和制定,最終使系統(tǒng)整體高效運(yùn)行.

圖4 監(jiān)控系統(tǒng)模塊結(jié)構(gòu)圖

3 Openstack虛擬化流量監(jiān)控系統(tǒng)測試

系統(tǒng)設(shè)計是基于搭建的Openstack云計算平臺之上的,整體采用分布式架構(gòu)進(jìn)行部署,在物理結(jié)構(gòu)上云計算平臺由計算節(jié)點、控制節(jié)點、網(wǎng)絡(luò)節(jié)點構(gòu)成.控制節(jié)點是整個系統(tǒng)的核心部分,系統(tǒng)的控制模塊將與網(wǎng)絡(luò)組件Neutron一起布置在控制節(jié)點,其將負(fù)責(zé)聯(lián)系著位于計算節(jié)點的虛擬機(jī)群和提供給用戶的web界面.為了便于搭建實現(xiàn),系統(tǒng)采用Fuel Openstack工具進(jìn)行一鍵式部署,經(jīng)過全局考慮,系統(tǒng)將部署兩個計算節(jié)點和一個控制節(jié)點.前期將準(zhǔn)備的硬件配置有如表1所示.

表1 測試節(jié)點配置情況表

在基礎(chǔ)系統(tǒng)搭建完畢后,系統(tǒng)將分別在兩個計算節(jié)點上各創(chuàng)建了三臺虛擬機(jī)構(gòu)成虛擬機(jī)群以便進(jìn)行實時的監(jiān)控.其后在一段時間內(nèi)對虛擬機(jī)群內(nèi)的六個虛擬機(jī)進(jìn)行網(wǎng)絡(luò)流量的檢測,分別在控制節(jié)點由管理員用戶下發(fā)進(jìn)行游覽網(wǎng)頁、在線播放歌曲等與網(wǎng)絡(luò)活動相關(guān)的任務(wù)指令到控制模塊(這些網(wǎng)絡(luò)任務(wù)便于觀察中斷和延遲),以便通過監(jiān)測的數(shù)據(jù)流量情況判斷整體負(fù)載(當(dāng)然也可以通過CPU等其它指標(biāo)),同時也將記錄服務(wù)期間是否有中斷和服務(wù)延遲.控制模塊根據(jù)監(jiān)控數(shù)據(jù)和相關(guān)負(fù)載均衡算法制定恰當(dāng)?shù)牧鞅?并且使虛擬交換機(jī)根據(jù)流表轉(zhuǎn)發(fā)數(shù)據(jù)流到計算節(jié)點的相應(yīng)虛擬機(jī)服務(wù)器,后者在完成任務(wù)期間將會產(chǎn)生網(wǎng)絡(luò)流量,同時進(jìn)行監(jiān)控數(shù)據(jù)獲取和相關(guān)數(shù)據(jù)的分析.測試時間間隔為一小時,總共進(jìn)行五次測試,測試數(shù)據(jù)為各節(jié)點虛擬機(jī)的網(wǎng)絡(luò)流量,如表2所示.

表2 各節(jié)點網(wǎng)絡(luò)測試數(shù)據(jù)結(jié)果表(M)

系統(tǒng)測試使用從上層客戶應(yīng)用下達(dá)的網(wǎng)絡(luò)命令,該命令以數(shù)據(jù)包的形式交由控制模塊進(jìn)行處理,控制模塊利用負(fù)載均衡算法和從Redis數(shù)據(jù)庫中獲取的實時虛擬服務(wù)器狀態(tài)信息制定適當(dāng)流表,該客戶數(shù)據(jù)包根據(jù)流表的信息進(jìn)行轉(zhuǎn)發(fā),并且最終到達(dá)或則交給指定的最合適的虛擬機(jī)服務(wù)器.

對測試數(shù)據(jù)分析可得出,系統(tǒng)主要實現(xiàn)了以下三個方面的效果.

1)通過系統(tǒng)能夠成功的獲取計算節(jié)點中各虛擬服務(wù)器的階段性時間內(nèi)的數(shù)據(jù)流量信息;

2)系統(tǒng)在進(jìn)行網(wǎng)絡(luò)活動時,未出現(xiàn)網(wǎng)絡(luò)服務(wù)中斷或延遲的情況,且整體運(yùn)行良好;

3)計算節(jié)點中各虛擬服務(wù)器在進(jìn)行網(wǎng)絡(luò)服務(wù)時,未曾出現(xiàn)單機(jī)負(fù)載過大或則單機(jī)閑置的情況,QoS質(zhì)量良好且系統(tǒng)整體達(dá)到負(fù)載均衡.

通過測試結(jié)果可以看出系統(tǒng)能夠有效的獲取階段性的虛擬服務(wù)器流量信息,同時在實現(xiàn)對虛擬服務(wù)器的監(jiān)控基礎(chǔ)上,系統(tǒng)在進(jìn)行網(wǎng)絡(luò)服務(wù)時未出現(xiàn)服務(wù)中斷和時延且各虛擬服務(wù)器在多任務(wù)下發(fā)時負(fù)載情況基本接近,使系統(tǒng)整體趨向負(fù)載均衡,使系統(tǒng)QoS質(zhì)量得到了保證.

4 虛擬流量監(jiān)控系統(tǒng)問題分析

該虛擬流量監(jiān)控系統(tǒng)在一定程度上達(dá)到了虛擬服務(wù)器數(shù)據(jù)流量的監(jiān)管和負(fù)載均衡控制,但是由于仍需要在計算節(jié)點部署相關(guān)數(shù)據(jù)獲取接口,所以仍將消耗一部分計算資源.同時,測試環(huán)境較為簡單,當(dāng)面對企業(yè)級的大型云平臺系統(tǒng)時,為了能夠達(dá)到預(yù)期的效果,其實時性和高效性仍然需要進(jìn)一步的改進(jìn).系統(tǒng)構(gòu)建于Openstack云平臺上,雖然該平臺在業(yè)內(nèi)被普遍使用,但是其它不同平臺亦占有一定份額,是否能夠在其他平臺上得到更加高效的結(jié)果,將需要在移植到其它平臺后做再一步的測試.

1陳康,鄭緯民.云計算:系統(tǒng)實例與研究現(xiàn)狀.軟件學(xué)報,2009,20(5):1337-1348.[doi:10.3724/SP.J.1001.2009.03493]

2李莉,李紀(jì)成,張超然,等.基于OpenStack云平臺Neutron關(guān)鍵技術(shù)研究.長春理工大學(xué)學(xué)報(自然科學(xué)版),2015,38(6):114-117.

3左青云,陳鳴,趙廣松,等.基于OpenFlow的SDN技術(shù)研究.軟件學(xué)報,2013,24(5):1078-1097.

4姚華超,王振宇.基于KVM-QEMU與Libvirt的虛擬化資源池構(gòu)建.計算機(jī)與現(xiàn)代化,2013,(7):26-29,33.

5范亞國.基于sFlow的網(wǎng)絡(luò)鏈路流量采集與分析[碩士學(xué)位論文].武漢:武漢理工大學(xué),2008.

6邱祝文.基于redis的分布式緩存系統(tǒng)架構(gòu)研究.網(wǎng)絡(luò)安全技術(shù)與用,2014,(10):52,54.

7Malik A,Ahmed J,Qadir J,et al.A measurement study of open source SDN layers in openStack under network perturbation.Computer Communications,2017,12:139-149.

8田浪軍,陳衛(wèi)衛(wèi),陳衛(wèi)東,等.云存儲系統(tǒng)中動態(tài)負(fù)載均衡算法研究.計算機(jī)工程,2013,39(10):19-23.[doi:10.3969/j.issn.1000-3428.2013.10.005]

9張若晨.基于OpenvSwitch的代理虛擬交換機(jī)在SDN網(wǎng)絡(luò)中的實現(xiàn)與應(yīng)用[碩士學(xué)位論文].廣州:華南理工大學(xué),2016.

10和榮,肖海力.基于Nagios的監(jiān)控平臺的設(shè)計與實現(xiàn).科研信息化技術(shù)與應(yīng)用,2014,5(5):77-85.[doi:10.11871/j.issn.1674-9480.2014.05.011]