云平臺安全監控數據采集關鍵技術研究

張偉華

云平臺安全監控數據采集關鍵技術研究

張偉華

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

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

云平臺；監控；數據采集

1 云平臺監控數據采集技術

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

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

2 Openstack通用技術

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

Ceilometer使用公用的Python庫Stevedore將監控不同類型部件的監控插件在運行時動態加載到進程中。

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

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

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

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

RabbitMQ實現了AMQP，它的工作流程如圖1所示。

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

圖1 RPC工作流程

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

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

用戶與網站服務器的交互，實質上就是用戶通過瀏覽器發送請求，對網絡服務器上的資源的狀態進行改變的過程。互聯網通信協議HTTP協議是無狀態的，因此資源狀態都保存在服務器上面。用戶需要使用HTTP協議的4個基本操作：GET、POST、PUT、DELETE使服務器上的資源發生狀態轉化，這就是RESTful API架構的核心原則。

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

WSGI（Web Server Gateway Interface）是一種接口，定義了Python程序與Web服務器之間的通信規范。Python庫Paste中的Deploy組件可以發現和配置WSGI Appliaction和Server。在Openstack的設計中，用戶發送RESTful API請求到云平臺，用以操作云服務提供商提供的計算資源，而整個云計算平臺的所有組件都以應用的形式部署在服務器端，以供用戶和平臺內部調用。Paste.Deploy組件在Openstack項目中的功能就是讓服務器識別各個組件，使服務器在接受到來自用戶和平臺內部其他組件的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配置文件中提取的參數鍵、值都以字符串的形式傳入底層實現。以Nova組件的Paste.ini文件中的部分進行說明：

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

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

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

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

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

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

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

namespace=

插件名=相關函數實現位置：函數名

...

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

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

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

[2]梁宇，楊海波，李鴻彬，等.基于OpenStack資源監控系統[J].計算機系統應用，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]王姜，余萍，曹春，等.開放網絡環境下的程序設計：從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.