張偉華

云平臺安全監(jiān)控數(shù)據(jù)采集關鍵技術研究

張偉華

（華為西安研究所 陜西 710068）

Openstack技術中項目之間的通信使用RESTful API進行通信，項目內(nèi)部不同的組件之間的通信使用消息總線；Ceilometer為Openstack項目提供信息收集功能；Esper是事件流處理和事件關聯(lián)引擎，主要面對的是實時事件驅(qū)動架構（Event Driven Architecture），構成云平臺監(jiān)控數(shù)據(jù)采集和分析處理的關鍵技術，本文介紹了云平臺安全監(jiān)控數(shù)據(jù)采集關鍵技術，供相關讀者參考。

云平臺；監(jiān)控；數(shù)據(jù)采集

1 云平臺監(jiān)控數(shù)據(jù)采集技術

Openstack是IaaS層軟件，允許用戶自行建立和提供云端的運算服務[1-2]。此外，openstack也用作建立防火墻內(nèi)的私有云，提供機構或企業(yè)內(nèi)部各個部門共享資源。它是以python編程語言編寫，遵循Open Virtualization Format、AMQP、SQLAlchemy等標準，所支持的虛擬化軟件包括KVM、Xen、VirtualBox、VMware、Hyper-V等。

Openstack項目中包含了眾多的子項目：Nova、Swift、Glance、Horizon、Cinder、Keystone、Neutron、Heat、Ceilometer、Trove、Saharad等。這些細化的子項目分別負責相應的功能，以保證云平臺的正常運行。由于項目眾多且篇幅有限，本文中只對云平臺監(jiān)控相關的通用技術以及云平臺監(jiān)控項目Ceiloemeter進行詳細的說明。

2 Openstack通用技術

Openstack的設計原則是：項目之間的通信使用RESTful API進行通信，項目內(nèi)部不同的組件之間的通信使用消息總線[3]。

Ceilometer使用公用的Python庫Stevedore將監(jiān)控不同類型部件的監(jiān)控插件在運行時動態(tài)加載到進程中。

（1）RPC（Remote Procedure Call，遠程過程調(diào)用）：通過RPC遠程調(diào)用，一個服務進程可以調(diào)用其他遠程服務進程的方法。

在Openstack項目中，屬于相同子項目的不同服務進程之間使用RPC進行相互調(diào)用。例如，Nova組件主要負責的是虛擬機的創(chuàng)建，刪除，掛起等的操作，Nova又由nova-api、nova-conductor、nova-scheduler，nova-compute組成。在用戶發(fā)出創(chuàng)建虛擬機的指令后，nova-api接受請求，完成權限校驗和參數(shù)校驗之后將請求傳遞給nova-conductor，nova-conductor調(diào)用nova-scheduler完成虛擬機創(chuàng)建位置的選取，然后再調(diào)用nova-compute的方法調(diào)用下層驅(qū)動完成虛擬機的創(chuàng)建。在這個過程中，Nova組件內(nèi)部的通信就是通過RPC消息總線完成的。

消息總線有兩種調(diào)用方式：call和cast。RPC.call遠程調(diào)用的方法會被同步執(zhí)行，調(diào)用者會被阻塞直到返回結果；RPC.cast遠程調(diào)用的方法會被異步執(zhí)行，調(diào)用者在完成調(diào)用后會繼續(xù)往下執(zhí)行，并不會等待遠程方法返回結果[4]。

RPC消息總線是一種概念，Openstack的消息總線支持AMQP（Advanced Message Queuing Protocol）[5]。默認的具體實現(xiàn)為RabbitMQ。

RabbitMQ實現(xiàn)了AMQP，它的工作流程如圖1所示。

RabbitMQ為消息傳遞的中間件，它會實現(xiàn)消息交換（Exchange）模塊和消息隊列（Queue）模塊。部件內(nèi)部通訊時，消息產(chǎn)生的一方稱為生產(chǎn)者（即消息的發(fā)送方），接收消息的一方稱為消費者（即消息的接收方）。RabbitMQ作為中間件，在接收到從生產(chǎn)者發(fā)送來的消息的時候，會根據(jù)消息的屬性以及消息頭部信息將消息與相應的隊列進行綁定（Binding），這個動作是由Exchange模塊實現(xiàn)的。然后消費者會從它所監(jiān)聽的消息隊列中讀出相應的消息，完成遠程方法的調(diào)用。如果使用的是RPC.call的方式進行遠程調(diào)用，那么在遠程函數(shù)執(zhí)行完畢后，將執(zhí)行結果以消息的形式發(fā)送給RabbitMQ，然后由Exchange發(fā)送給相應的消息隊列，原先的生產(chǎn)者現(xiàn)在變成了執(zhí)行結果消息的消費者，從消息隊列中讀取所需消息，然后繼續(xù)向下執(zhí)行。

圖1 RPC工作流程

（2）RESTful API（Representational State Transfer）是由HTTP協(xié)議（1.0版和1.1版）的主要設計者、Apache服務器軟件的作者之一、Apache基金會的第一任主席Roy Thomas Fielding博士2000年在他的論文中提出的[6]，目的是為了想在符合架構原理的前提下，理解和評估以網(wǎng)絡為基礎的應用軟件的架構設計，得到一個功能強、性能好、適宜通信的架構。

REST（Representational State Transfer，表現(xiàn)層狀態(tài)轉(zhuǎn)化），也可以理解為資源狀態(tài)轉(zhuǎn)化（Resource State Transfer）。RESTful API將網(wǎng)絡上的所有內(nèi)容都看作是一種資源，可以是一張圖片，一段音頻視頻，也可以是一種服務。使用一個特定的URL（統(tǒng)一資源定位符）指向這個資源，一個特定的URL指向獨一無二的資源，如果需要對這個資源進行操作，那么就需要通過與之綁定的URL對其進行訪問，這個URL就成了這個資源的識別符[7]。

用戶與網(wǎng)站服務器的交互，實質(zhì)上就是用戶通過瀏覽器發(fā)送請求，對網(wǎng)絡服務器上的資源的狀態(tài)進行改變的過程?；ヂ?lián)網(wǎng)通信協(xié)議HTTP協(xié)議是無狀態(tài)的，因此資源狀態(tài)都保存在服務器上面。用戶需要使用HTTP協(xié)議的4個基本操作：GET、POST、PUT、DELETE使服務器上的資源發(fā)生狀態(tài)轉(zhuǎn)化，這就是RESTful API架構的核心原則。

Openstack各個部件都提供了RESTful架構的API作為對外接口，以方便部件之間內(nèi)部的相互調(diào)用以及用戶通過瀏覽器對各個部件的訪問[8]。依舊以創(chuàng)建虛擬機的過程為例子：用戶通過Horizon或者命令行調(diào)用Nova-API向Openstack發(fā)送創(chuàng)建虛擬機的請求，從而改變后端計算、存儲、網(wǎng)絡資源的狀態(tài)。而在創(chuàng)建虛擬機的過程中，Nova部件不僅要選取合適的位置創(chuàng)建服務器，還需要向Cinder以及Neutron組件發(fā)送請求，調(diào)用相應API完成卷的創(chuàng)建和網(wǎng)絡資源的準備，只有在計算、存儲、網(wǎng)絡資源都被正確選取之后，才能真正開始創(chuàng)建虛擬機，供用戶使用。

WSGI（Web Server Gateway Interface）是一種接口，定義了Python程序與Web服務器之間的通信規(guī)范。Python庫Paste中的Deploy組件可以發(fā)現(xiàn)和配置WSGI Appliaction和Server。在Openstack的設計中，用戶發(fā)送RESTful API請求到云平臺，用以操作云服務提供商提供的計算資源，而整個云計算平臺的所有組件都以應用的形式部署在服務器端，以供用戶和平臺內(nèi)部調(diào)用。Paste.Deploy組件在Openstack項目中的功能就是讓服務器識別各個組件，使服務器在接受到來自用戶和平臺內(nèi)部其他組件的RESTful請求的時候，可以找到相應的組件應用。因此，Openstack項目中例如Nova、Cinder、Neutron、Swift等主要子部件中，都包含了自己的Paste.Deploy的配置文件Paste.ini，以完成功能在服務端的注冊。Paste.Deploy配置文件的格式如下：

[type：name]

其中，方括號括起的Section聲明一個新Section的開始，Section的聲明由兩部分組成，Section的類型（Type）和Section的名稱（Name），如：[app：main]等。Section的Type可以有：app、composite、filter、pipeline、filter-app等。每個Section中具體配置項的格式就是基本的ini格式： key = value ，所有從PasteDeploy配置文件中提取的參數(shù)鍵、值都以字符串的形式傳入底層實現(xiàn)。以Nova組件的Paste.ini文件中的部分進行說明：

此外，PasteDeploy的配置文件中使用“#”標注注釋。

（3）動態(tài)加載是指程序在開始運行的時候再將所需要的庫文件以及代碼加載到內(nèi)存中，而不是在運行開始之前就將所有的代碼加載到內(nèi)存里。這樣做的目的是為了減輕內(nèi)存壓力，使程序運行速度加快。動態(tài)加載技術在云計算中的應用十分重要：云計算平臺結構復雜，代碼量在千萬行以上，雖然Openstack項目以分布式的方式部署在各個節(jié)點，但使用動態(tài)加載技術仍然十分有意義。

對于Openstack各個項目組件來說，調(diào)用公用的函數(shù)庫，例如訪問數(shù)據(jù)庫操作，鑒權操作以及相互之間調(diào)用各項服務的API的時候，都需要先將對應的函數(shù)庫加載到自己的代碼中，然后才能使用這些函數(shù)完成相應的操作。

對于Openstack的監(jiān)控組件Ceilometer來說，動態(tài)加載還有更重要的意義：Ceilometer分布式的部署在Openstack集群的不同節(jié)點，Ceilometer的不同插件監(jiān)控的部件也不相同，如果所有節(jié)點上都全量加載Ceilometer的所有組件的話就會造成性能下降和資源不必要的浪費，另外，部署在不同節(jié)點上的相同組件，因為物理環(huán)境不同需要加載的插件也不相同。因此，Ceilometer監(jiān)控組件使用動態(tài)加載的方式，可以在不同的節(jié)點上按照需求，加載不同的監(jiān)控插件。

Openstack項目就采用了Stevedore庫來實現(xiàn)動態(tài)加載以及創(chuàng)建發(fā)布Python包。它對Setuptools庫有依賴關系。Python Enterprise Application Kit（PEAK）項目中的子項目Setuptools是對Python 標準庫中的Distutils模塊的增強，而Stevedore是對Setuptools的簡化，更加方便了創(chuàng)建和發(fā)布Python包。

Stevtedore實現(xiàn)程序動態(tài)載入插件的過程主要分為三個部分：插件函數(shù)功能的實現(xiàn)，插件注冊，以及插件的動態(tài)載入。插件的實現(xiàn)和正常的函數(shù)功能的編寫沒有什么區(qū)別，繼承公共接口后，在指定的函數(shù)名下完成對相應特性的實現(xiàn)。

插件注冊的過程是在Setuptools的相關文件中注冊，注冊的格式為：

namespace=

插件名=相關函數(shù)實現(xiàn)位置：函數(shù)名

...

在Openstack項目的實例中，只有在setup.cfg中完成了相應插件的注冊，才能被Stevedore庫所識別。因此，每個組件對外所提供的接口在組件的相應的setup.cfg中都明確地給出，setup.cfg文件也就成為快速熟悉組件的“項目地圖”。

在代碼中將steverdore庫引入后，使用stevedore.driver.插件函數(shù)名即可完成插件的載入。

[1]李阿妮，張曉，趙曉南，等.面向IaaS的云計算系統(tǒng)可用性評估[J].計算機科學，2016，43（10）：33-39.

[2]梁宇，楊海波，李鴻彬，等.基于OpenStack資源監(jiān)控系統(tǒng)[J].計算機系統(tǒng)應用，2014，23（4）：44-47.

[3]Wang Y，Li X. Achieve high availability about point-single failures in OpenStack[C]// International Conference on Computer Science and Network Technology. IEEE，2015.

[4]王姜，余萍，曹春，等.開放網(wǎng)絡環(huán)境下的程序設計：從RPC到REST[J].計算機工程與應用，2013，49（17）：30-37.

[5]Ismail M A，Ismail M F，Ahmed H. Openstack cloud performance optimization using linux services[C]//Cloud Computing （ICCC）， 2015 International Conference on. IEEE，2015：1-4.

[6]Fielding R T. Architectural styles and the design of network-based software architectures[D]. University of California，Irvine，2000.

[7]Salvadori I，Siqueira F. A Maturity Model for Semantic RESTful Web APIs[C]//Web Services （ICWS），2015 IEEE International Conference on. IEEE，2015：703-710.