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

徐 毅,曾文兵

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

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

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

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

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

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

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

1.1 Neutron[2]模塊概述

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

Neutron中的各個(gè)組件在實(shí)際部署中通常根據(jù)各自的功能實(shí)現(xiàn)的不同,分別布置在Openstack框架中的三個(gè)節(jié)點(diǎn)中,分別是用于部署Neutron Server的控制節(jié)點(diǎn)、部署負(fù)責(zé)轉(zhuǎn)發(fā)服務(wù)的L3-agent和提供DHCP服務(wù)的DHCP-agent等插件的網(wǎng)絡(luò)節(jié)點(diǎn)、部署負(fù)責(zé)具體實(shí)現(xiàn)的 Plugin-agent(插件代理)的計(jì)算節(jié)點(diǎn).在Neutron部署的網(wǎng)絡(luò)拓?fù)鋱D中還有三個(gè)關(guān)鍵的網(wǎng)絡(luò)需要我們認(rèn)識(shí),分別是負(fù)責(zé)Openstack中各個(gè)模塊之間交互和連接數(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ù)采用控制邏輯和實(shí)際工作硬件組相互分開的形式.作為一種新型的網(wǎng)絡(luò)創(chuàng)新架構(gòu),是對(duì)傳統(tǒng)分布式網(wǎng)絡(luò)架構(gòu)的一種應(yīng)時(shí)更進(jìn).由于現(xiàn)今網(wǎng)絡(luò)更新和創(chuàng)建的速度已經(jīng)達(dá)到了新量級(jí),快速的網(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è)備中剝離出來,將其集中化,再形成新的集中控制平臺(tái),使設(shè)備只需要負(fù)責(zé)單純的數(shù)據(jù)處理.同時(shí)SDN將向上提供開放的API接口給用戶,既北向接口.向下開發(fā)出接口連接普通網(wǎng)絡(luò)設(shè)備層,既南向接口.同時(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的差異實(shí)現(xiàn)高效的虛擬機(jī)管理.LibvirtAPI所有API均采用C語言進(jìn)行開發(fā),可以有效地切合Linux系統(tǒng).LibvirtAPI可以根據(jù)其功能分為五個(gè)API部分:虛擬機(jī)監(jiān)管程序連接API、域API、網(wǎng)絡(luò)API、存儲(chǔ)卷API和存儲(chǔ)池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)上,同時(shí),對(duì)于物理機(jī)上不同的虛擬機(jī),LibvirtAPI為用戶屏蔽了底層Hypervisor的差異,通過對(duì)其提供統(tǒng)一的virConnect接口,建立起與虛擬機(jī)群之間的連接.其中,Hypervisor負(fù)責(zé)統(tǒng)計(jì)和管理對(duì)應(yīng)虛擬機(jī)群和其占有的所有資源.與其建立連接后,通過調(diào)用LibvirtAPI相應(yīng)API接口便可以獲取來自Hypervisor對(duì)虛擬機(jī)群所有有價(jià)值的資源統(tǒng)計(jì)信息.利用LibvirtAPI技術(shù)不僅解除了傳統(tǒng)方法中將虛擬機(jī)當(dāng)作物理機(jī),在每個(gè)被監(jiān)控虛擬服務(wù)節(jié)點(diǎn)部署監(jiān)控代理時(shí)虛擬機(jī)承受的額外壓力.同時(shí),也使得用戶和運(yùn)維人員可以在單一物理機(jī)上實(shí)現(xiàn)對(duì)其上多臺(tái)和多樣的虛擬服務(wù)器的監(jiān)控管理,有效地提高了相應(yīng)的工作效率.

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

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

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

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

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

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

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

2.2 控制模塊分析

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

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

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

控制模塊在南向與虛擬交換機(jī)模塊相聯(lián)系,虛擬交換機(jī)模塊直接與計(jì)算組件Nova構(gòu)建的計(jì)算節(jié)點(diǎn)群相橋接.Nova創(chuàng)建的虛擬機(jī)分布于各個(gè)計(jì)算節(jié)點(diǎn)上,虛擬機(jī)相互之間產(chǎn)生的數(shù)據(jù)流量包和與外界交互的數(shù)據(jù)流量包都直接通過虛擬交換機(jī)模塊進(jìn)行轉(zhuǎn)發(fā),而不用再去創(chuàng)立單一的網(wǎng)絡(luò)節(jié)點(diǎn).每當(dāng)虛擬交換機(jī)模塊接收到來自底層虛擬機(jī)群的數(shù)據(jù)包的時(shí)候,首先會(huì)提取數(shù)據(jù)包,并且嘗試匹配到相應(yīng)的流表項(xiàng),如果匹配到相應(yīng)的流表項(xiàng),則根據(jù)流表項(xiàng)中的目的地址進(jìn)行下一步的數(shù)據(jù)轉(zhuǎn)發(fā).如果沒有能匹配到相應(yīng)的流表項(xià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)完全實(shí)現(xiàn)了傳統(tǒng)物理交換機(jī)的功能,并且Openswitch已經(jīng)提供了對(duì)sFlow和Openflow協(xié)議的支持.這些特性使得該虛擬交換機(jī)能夠在Openflow的支持下作為Openflow交換機(jī)進(jìn)行基于流表轉(zhuǎn)發(fā)數(shù)據(jù),且與控制邏輯層解耦的新一代交換機(jī),相對(duì)于此,將轉(zhuǎn)發(fā)邏輯融合在內(nèi)的傳統(tǒng)物理交換機(jī)就顯得沉重緩慢.同時(shí),Openswitch主要是通過C語言實(shí)現(xiàn),因此對(duì)于在大多數(shù)平臺(tái)上進(jìn)行部署都會(huì)較好移植.

基于Openflow和Openswitch實(shí)現(xiàn)的虛擬交換機(jī)模塊兼具著良好的控制性和擴(kuò)展性,具體的數(shù)據(jù)轉(zhuǎn)發(fā)控制策略都是由控制模塊進(jìn)行制定,因此也就實(shí)現(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é)實(shí)現(xiàn)普通虛擬交換機(jī)的數(shù)據(jù)轉(zhuǎn)發(fā)功能,對(duì)于數(shù)據(jù)包如何進(jìn)行轉(zhuǎn)發(fā)則毫不知情,在整個(gè)Openflow虛擬網(wǎng)絡(luò)中,該組件只是一個(gè)執(zhí)行者.其只需要根據(jù)控制模塊已經(jīng)規(guī)劃好并且下發(fā)流表的邏輯進(jìn)行機(jī)械的操作便可.也正是由于這種特點(diǎn),使得虛擬交換機(jī)模塊具有了很好的擴(kuò)展性,如果需要更新或則改變擴(kuò)展功能時(shí),我們只需要去改變控制模塊端的相應(yīng)規(guī)則便可.

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

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

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

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

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

因此,本系統(tǒng)的在對(duì)監(jiān)控模塊進(jìn)行設(shè)計(jì)時(shí),摒棄了原本在虛擬服務(wù)器上部署Agent的做法,轉(zhuǎn)而將采用在物理宿主機(jī)上直接部署LibvirtAPI的方式來設(shè)計(jì)監(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ī)之上對(duì)虛擬機(jī)進(jìn)行穩(wěn)定的監(jiān)控.建立連接后可以通過virNetwork接口對(duì)虛擬機(jī)網(wǎng)絡(luò)相關(guān)信息進(jìn)行管理、通過virDomain接口可以獲取虛擬機(jī)CPU使用的相關(guān)信息、通過virStorageVol接口對(duì)存儲(chǔ)情況進(jìn)行監(jiān)控.同時(shí)sFlow協(xié)議在LbvirtAPI的基礎(chǔ)上獲取網(wǎng)絡(luò)相關(guān)信息,其后傳遞信息至管理員和數(shù)據(jù)庫中.LibvirAPI直接連接Hypervisor對(duì)虛擬機(jī)相關(guān)信息進(jìn)行獲取,相較于通過分散在各虛擬機(jī)內(nèi)部的代理獲取的方式也將更具高可用性.

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

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

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

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

表1 測(cè)試節(jié)點(diǎn)配置情況表

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5范亞國(guó).基于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)東,等.云存儲(chǔ)系統(tǒng)中動(dòng)態(tài)負(fù)載均衡算法研究.計(jì)算機(jī)工程,2013,39(10):19-23.[doi:10.3969/j.issn.1000-3428.2013.10.005]

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

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