趙淦森,王維棟,孫 偉,季統(tǒng)凱

（1.華南師范大學計算機學院 廣州510631；2.中山大學軟件學院 廣州510275；3.廣東電子工業(yè)研究院 東莞 523808）

1 引言

云計算（cloud computing）是一種計算模式，它實現(xiàn)了對共享可配置計算資源（網絡、服務器、存儲、應用和服務等）方便、按需的訪問；這些資源可以通過較小的管理代價或服務提供者的交互被快速地準備和釋放。云計算具有以下基本特性：按需索取、廣泛的網絡訪問、資源池化管理和供應、快速彈性伸縮和服務度量[1]。

依據(jù)部署模型分類，云計算可以分為私有云、社區(qū)云、公共云和混合云。依據(jù)服務模式分類，云計算可以分為軟件即服務 （software as a service,SaaS）、平臺即服務（platform as a service,PaaS)和基礎設施即服務（infrastructure as a service,IaaS)。SaaS通過瀏覽器把程序傳給成千上萬的用戶。對用戶來說，這個模式會省去在網絡/系統(tǒng)軟件授權和應用軟件開發(fā)上的開支；從供應商角度來看，同一系統(tǒng)可供多次使用并多次收取使用費以實現(xiàn)效益最大化。Salesforce[2]即是典型的SaaS應用。PaaS可以認為是SaaS的延伸。這種形式的云計算把開發(fā)、部署環(huán)境作為服務來提供，可創(chuàng)建自己的應用軟件并部署在供應商的基礎架構上運行，然后通過網絡從供應商的服務器傳遞給用戶，例如Google App Engine[3]。IaaS提供給消費者的服務是對所有設施的利用，包括處理、存儲、網絡和其他基本的計算資源，用戶能夠部署和運行任意軟件，包括操作系統(tǒng)和應用程序。消費者不管理或控制任何云計算基礎設施，但能控制操作系統(tǒng)的選擇、儲存空間以及應用的部署，也有可能獲得有限制的網絡組件 （如防火墻、負載均衡器等）的控制。典型的例子有EC2[4]、vSphere[5]等。本文的研究主要面向IaaS云。

自從Barnes等人于1993年首次提出信息系統(tǒng)的生存性概念開始，對于生存性的研究就開始逐漸引起人們的關注。生存性是指系統(tǒng)能夠在遭受攻擊、出現(xiàn)故障或意外事故后仍然能夠及時完成其任務的能力[6,7]。這種能力意味著系統(tǒng)可以遭受入侵、部分受損，但能夠保證所執(zhí)行的關鍵任務按時完成。在這種情況下，雖然系統(tǒng)的安全策略失敗了，但是其生存策略卻是成功的。生存性是一個非常重要的系統(tǒng)性能參數(shù)，可以作為系統(tǒng)在遭受攻擊、軟硬件故障等意外事故后對其運行性能優(yōu)劣進行評價和判定的指標。

目前國內外已有不少有關生存性的研究成果。例如Irving Vitra Paputungan等人進行的生存能力相關的恢復過程建模[8]、Andrew P.Moore等人進行的信息安全與生存性的攻擊建模[9]、陳左寧進行的大規(guī)模計算機系統(tǒng)的可信性技術研究[10]等。云計算作為一種新興并迅速發(fā)展的計算模式，在其先進、靈活、高效的服務理念備受贊譽的同時，云計算平臺的穩(wěn)定性和生存性也受到了廣泛的關注。

2 生存性分析方法

目前已經存在許多進行生存性分析的方法，其中最為權威、應用最廣泛的是CMU/SEI提出的SNA（survivable network analysis）[11]方法。SNA方法分為4個步驟，如圖 1所示。

其中3R分析[12]是SNA方法最重要的部分。3R包括以下3種能力。

（1）攻擊識別能力（recognition）

指系統(tǒng)識別攻擊或者攻擊掃描的能力。這種面臨入侵的反應和適應的能力是系統(tǒng)應對攻擊的核心能力。

（2）攻擊抵抗能力（resistance）

指系統(tǒng)遭受攻擊時的抵抗能力。抵抗在滲透和探測階段比破壞發(fā)生的時候更重要?，F(xiàn)在的抵抗策略包括防火墻、認證、加密等。

（3）系統(tǒng)恢復能力（recovery）

指系統(tǒng)在遭受攻擊后恢復服務以及抵抗和識別未來潛在攻擊的能力。

3 生存性機制

3.1 基礎模型

云計算平臺，尤其是IaaS云平臺的用戶所關心的，是自己所請求的云服務是否可用以及云平臺發(fā)生異常后云服務能否在盡可能短的時間內恢復。對于服務提供商來說，要滿足用戶的需求，就必須對云平臺的基礎設施進行監(jiān)控，避免可能發(fā)生的攻擊或系統(tǒng)異常，并在盡可能短的時間內恢復已經停止的云服務。

依據(jù)以上分析，結合SNA方法，提出“監(jiān)控—分析—決策—處理—反饋”模型，如圖2所示。

監(jiān)控—分析—處理—反饋模型的基本思路是：

·通過對云平臺的物理設備以及必需服務進行監(jiān)控，獲取監(jiān)控數(shù)據(jù)；

·分析監(jiān)控數(shù)據(jù)，提取異常狀況，分析異常狀況原因和定位相關起因并生成警報；

·根據(jù)異常應對策略以及分析得到的異常原因，生成故障應對的方法，通知相關責任人；

·根據(jù)警報狀況和處理方法進行自動或手動處理；

·對處理結果進行反饋，未能成功自動處理的警報將留待相關責任人手動處理。所有未能成功處理的警報都將重新提交至處理環(huán)節(jié)。

3.2 生存性機制

本文提出的生存型機制基于虛擬機的在線遷移，而虛擬機遷移的基礎則是虛擬化技術。

虛擬化[13]是IaaS云平臺的基礎，通過在物理設備和應用服務之間加入虛擬化層，使得應用服務不再依賴于固定的物理設備。應用服務由此可以在不同物理設備間遷移。大部分IaaS云平臺提供的計算資源粒度是虛擬機。

當某臺物理設備遭遇外部攻擊、系統(tǒng)異?；蛴布惓r，系統(tǒng)在進行異常應對過程中，需要將運行于有風險或異常的物理設備上的虛擬機遷移[15]至其他狀態(tài)正常的物理設備。遷移后的虛擬機的狀態(tài)與遷移前保持一致，從而保證了云平臺能夠在不影響服務可用性的前提下把云服務從有風險或異常的物理設備轉移到穩(wěn)定的物理設備之上，避免了云服務因為系統(tǒng)異常或硬件異常而失效的風險。

虛擬機的遷移有離線遷移和在線遷移兩種。離線遷移過程需要把虛擬機暫停，從而虛擬機承載的服務也將停止。系統(tǒng)通過把暫停后的虛擬機的狀態(tài)和數(shù)據(jù)同步到目標的機器后，再把虛擬機重新運行。在線遷移在不需要暫停虛擬機的前提下，把在運行狀態(tài)的虛擬機的狀態(tài)和數(shù)據(jù)同步到目標機器，然后在關閉原來的虛擬機的同時啟動目標機器上的虛擬機。

當某臺物理設備因為系統(tǒng)異常而不可用，則它的物理資源對于云平臺來說是失效的。本生存性機制通過向運行于該物理設備上的控制器發(fā)送命令，恢復該物理設備上異常的系統(tǒng)服務或重啟設備，使物理設備恢復為可用狀態(tài)，從而實現(xiàn)云平臺自動恢復失效物理資源的能力。

當沒有提供處理預案的異常發(fā)生，或者異常自動處理失敗時，本生存性機制能夠通過用戶界面通知相關責任人，也可以調用第三方監(jiān)控軟件的相關功能，通過E-mail、短信等方式通知相關責任人手動處理異常。

3.3 物理設備運行狀態(tài)建模

通過對物理設備運行狀態(tài)進行建模，可以明確物理設備運行狀態(tài)正常與否的標準，并為各種可以預期的外部攻擊、系統(tǒng)異常或硬件異常提供有針對性的處理預案。當部分物理設備遭受攻擊、發(fā)生或可能發(fā)生異常時，云平臺可依據(jù)處理預案做出響應，并執(zhí)行對應的指令，從而在無需人工干預的情況下，處理大部分可預期的攻擊和系統(tǒng)異常，保證云服務的正常運行。

對物理設備運行狀態(tài)進行建模，首先需要依據(jù)該物理設備的功能來制定監(jiān)控計劃，界定需要監(jiān)控的硬件狀況、必要服務和資源使用情況，生成監(jiān)控項；然后對每個監(jiān)控項制定判定異常發(fā)生的標準以及異常的級別；最后針對各個監(jiān)控項的異常狀態(tài)提出對應的處理預案。下面是一個簡單的例子。

節(jié)點主機指運行節(jié)點控制器（node controller,NC）的物理主機，提供云平臺實際物理資源并管理運行于其上的虛擬機。針對該類物理機進行運行狀態(tài)建模見表1。

表1 節(jié)點主機運行狀態(tài)建模

與上例類似，也可以用同樣的方法對云平臺內的其他物理設備進行運行狀態(tài)建模。完成對所有類型的物理設備的運行狀態(tài)建模工作并將這些模型整合后，就得到了云平臺的運行狀態(tài)模型。云平臺內的任何一個物理設備都可以映射到云平臺運行狀態(tài)模型中對應的物理設備運行狀態(tài)模型。所以，對云平臺內物理設備的監(jiān)控數(shù)據(jù)的分析就轉化為對該物理設備的實時運行狀態(tài)模型和正常運行狀態(tài)模型的匹配，對云平臺的監(jiān)控數(shù)據(jù)的分析也就轉化為對云平臺實時運行狀態(tài)模型和云平臺正常運行狀態(tài)模型的匹配。

3.4 異常應對

當云平臺中某臺物理設備的實時運行狀態(tài)模型和云平臺正常運行狀態(tài)模型的匹配失敗時，該物理設備將被判定為有風險的物理設備。本生存性機制將通過匹配過程得到匹配失敗的具體監(jiān)控項，并根據(jù)該監(jiān)控項的實時監(jiān)控數(shù)據(jù)得到發(fā)生的風險或異常的嚴重程度，嚴重程度較高的風險或異常將被優(yōu)先處理。

在處理風險或異常時，本生存性機制從該物理設備的運行狀態(tài)模型中獲取與當前異常對應的處理預案。依據(jù)處理預案，本生存性機制對異常處理方法進行決策，具體可以分為以下兩種情況。

第一種，應對必要服務狀態(tài)異常、存儲空間不足等問題，本生存性機制通過向該物理設備上的控制器發(fā)送相應的處理指令來解決異常。

第二種，當設備負荷過重、資源利用過高、硬件狀況異常、遭受或可能遭受外部攻擊時，本生存性機制將運行于該物理設備上的虛擬機遷出。對于設備負荷過重、資源利用過高、硬件狀況異常等問題，將虛擬機遷出可以有效保證虛擬機內部署的應用不會因為這些問題而變得效率低下或中斷。對于虛擬機遭受或可能遭受外部攻擊的情況，將該虛擬機遷出并更新相應配置可使外部攻擊失去目標，從而防止因為外部攻擊導致的虛擬機內的應用中斷或數(shù)據(jù)泄漏。

本生存性機制依據(jù)以下幾個原則來進行虛擬機遷移目標的決策。

原則一：當用戶無特殊要求時，將虛擬機遷移到哪個物理設備由云平臺當前所應用的自動調度策略決定。這些自動調度策略可能包括節(jié)能策略、最小需求策略、高性能策略等。

原則二：當用戶有安全性需求，或需要遷出的虛擬機對物理設備的架構有所要求時，本生存性機制將允許用戶制定相應的遷移規(guī)則（例如某個部署敏感應用的虛擬機只能被遷移到指定網段的物理設備等），并在遷移規(guī)則允許范圍內應用云平臺現(xiàn)有的自動調度策略決定虛擬機遷移的目標。

原則三：用戶手動指定遷移目標。完成對異常處理方法的決策后，本生存性機制原型向異常發(fā)生的物理設備上的控制器發(fā)送對應指令，并獲取指令執(zhí)行結果。參考§3.1中提出的“監(jiān)控—分析—決策—處理—反饋”模型，當異常處理失敗時，其警報將被重新提交到處理環(huán)節(jié)，留待用戶手動處理。

4 原型架構設計

4.1 整體架構

依據(jù)上文提出的生存性機制，進行原型的整體架構設計。為了實現(xiàn)預想功能，整體架構設計需要包括監(jiān)控、分析、處理、反饋4個方面，此外，監(jiān)控項目和處理方法應該具有可定制性，以期適應不同的監(jiān)控需求。本原型將分析、處理、反饋以及可定制性進行整合，得到云監(jiān)控（cloud monitor）模塊。監(jiān)控功能通過使用第三方開源監(jiān)控軟件Nagios[14]實現(xiàn)，實現(xiàn)可定制性需要與用戶界面交互，實現(xiàn)自動處理功能需要與其他云平臺的其他控制器（controller）交互。綜合考慮以上各個方面，得出生存性方案的整體架構如圖3所示。

云監(jiān)控模塊與底層監(jiān)控軟件Nagios運行于云監(jiān)控主機上，通過插件監(jiān)控狀態(tài)讀取插件和配置器控制底層監(jiān)控軟件Nagios。Nagios則通過調用運行于遠端受監(jiān)控主機上的NRPE插件實現(xiàn)對遠端主機的實時監(jiān)控。云監(jiān)控模塊通過與用戶界面交互來提供可定制性，通過與其他云平臺控制器交互來實現(xiàn)警報自動處理功能。對該架構進行詳細分析如下。

（1）部署情況

云監(jiān)控模塊和底層監(jiān)控軟件Nagios均部署在云監(jiān)控主機上，Nagios的遠程監(jiān)控插件NRPE則部署在所有被監(jiān)控主機上。

（2）云監(jiān)控模塊結構

為保證能夠獨立穩(wěn)定地運行，且盡量少地受到操作系統(tǒng)的影響，云監(jiān)控模塊被設計成Daemon進程（即守護進程，是一種后臺服務進程，通常生存期較長并獨立于控制終端。常用于周期性地執(zhí)行某項任務，等待處理某些可能發(fā)生的事件），在云監(jiān)控主機啟動時加載并開始監(jiān)控服務。

（3）通信方式

云監(jiān)控模塊通過基類已實現(xiàn)的套接字（socket）接口與用戶界面和云平臺其他控制器進行通信。Nagios與其插件NRPE之間的通信則依靠SSL（secure sockets layer，安全套接字，是Netscape為保證網絡通信安全及數(shù)據(jù)完整性提出的一種安全網絡通信協(xié)議，SSL在傳輸層對網絡連接進行加密以實現(xiàn)通信安全）協(xié)議實現(xiàn)。

（4）云監(jiān)控模塊與底層監(jiān)控軟件的關系

出于可擴展性考慮，云監(jiān)控模塊與底層監(jiān)控軟件沒有包含或直接調用關系。二者的交互通過插件完成。如果需要用其他監(jiān)控軟件代替現(xiàn)有的Nagios，云監(jiān)控模塊將無需修改，僅針對新的監(jiān)控軟件開發(fā)相關插件即可實現(xiàn)兼容。

（5）云監(jiān)控模塊插件

云監(jiān)控模塊通過相關插件與底層監(jiān)控軟件交互。插件包括監(jiān)控狀態(tài)讀取插件和配置器。監(jiān)控狀態(tài)讀取插件用于讀取并規(guī)格化底層監(jiān)控軟件監(jiān)控數(shù)據(jù)。配置則用于配置底層監(jiān)控軟件參數(shù)并重啟監(jiān)控服務以應用改變。

4.2 云監(jiān)控模塊架構設計

根據(jù)本文提出的生存性機制和§4.1中的分析設計，設計云監(jiān)控模塊的基本運行流程，如圖4所示。

云監(jiān)控運行流程分為以下幾個步驟。

（1）監(jiān)控

通過控制第三方監(jiān)控軟件遠程監(jiān)控各個服務器，并生成狀態(tài)記錄。云監(jiān)控模塊讀取監(jiān)控狀態(tài)記錄。

（2）分析

分析監(jiān)控數(shù)據(jù)，建模并匹配，對異常狀態(tài)生成警報，并通知維護人員。

（3）處理

嘗試依據(jù)警報自動處理預案處理警報。

（4）反饋

獲取自動處理結果，處理失敗的警報留待維護人員手動處理。維護人員手動處理后通過用戶界面通知云監(jiān)控模塊。

警報處理預案一般分為以下幾個類型。

·向發(fā)生警報的主機發(fā)送對應指令，解決系統(tǒng)相關服務異常等問題。

·應用自動遷移策略，將運行于異常節(jié)點主機的虛擬機動態(tài)遷移[15]到正常運行的節(jié)點主機上。

·延遲處理警報，留待維護人員手動處理。

依據(jù)以上分析，設計云監(jiān)控模塊架構如圖5所示。

對云監(jiān)控模塊的各個子模塊功能分析如下。

（1）狀態(tài)分析器

監(jiān)控循環(huán)中，從監(jiān)控狀態(tài)文件讀取已規(guī)格化的監(jiān)控數(shù)據(jù)，依據(jù)物理機類型生成運行狀態(tài)模型，與對應的正常狀態(tài)模型進行匹配，對匹配失敗的監(jiān)控項生成警報，依據(jù)警報優(yōu)先級將警報插入警報隊列。

（2）警報隊列

存儲現(xiàn)存的所有未處理警報，隊內警報按優(yōu)先級降序排列，需手動處理的警報將被視為最低優(yōu)先級警報并置于隊尾。

（3）用戶界面控制器

管理與用戶界面的交互，包括監(jiān)控策略管理、警報管理和監(jiān)控服務的啟動與停止。

（4）策略控制器

云監(jiān)控模塊啟動時，調用數(shù)據(jù)庫接口讀取監(jiān)控策略，并對云平臺不同類型的物理機分別建立正常狀態(tài)模型，監(jiān)控策略變更時，更新數(shù)據(jù)庫和正常狀態(tài)模型，調用配置器配置并重啟底層監(jiān)控軟件。

（5）警報處理器

從警報隊列依次取出警報，依據(jù)預置自動處理預案向其他云平臺控制器發(fā)送命令并獲取返回結果。分析返回結果，處理成功則從警報隊列刪除警報，處理失敗則更改警報類型和優(yōu)先級，然后再次插入警報隊列，完成后調用數(shù)據(jù)庫接口更新數(shù)據(jù)庫。

（6）數(shù)據(jù)庫接口

管理數(shù)據(jù)庫操作。

（7）日志接口

對云監(jiān)控模塊的所有關鍵操作進行日志記錄。

5 生存性機制原型的應用

本文提出的生存性機制的原型的具體應用和測試平臺為Vebula私有云基礎設施平臺。Vebula云計算基礎設施平臺是一個提供系統(tǒng)虛擬化、資源整合、按需提供虛擬化資源、安全驗證等服務的云計算解決方案。其核心架構如圖6所示。

Vebula私有云基礎設施平臺的核心架構主要分為以下幾個模塊。

（1）云控制器（cloud controller，CLC）

通過與Vebula Web進行交互，來接受和反饋用戶請求。負責云平臺的最高層統(tǒng)一調度。

（2）集群控制器（cluster controller,CC）

轉發(fā)CLC的事件請求，收集并上報集群信息，管理屬于本集群的節(jié)點控制器。

表2 可用性機制原型應用前后對比

（3）節(jié)點控制器（node controller，NC）

相應上層發(fā)出的事件請求，管理節(jié)點主機上運行的虛擬機（VM）和其他虛擬化資源，收集并上報節(jié)點主機及節(jié)點主機上運行的虛擬機信息。

（4）DHCP 控制器（DHCP controller，DC）

提供DHCP服務，管理云平臺的IP資源。

（5）存儲設備（storage）

存儲云平臺的內部數(shù)據(jù)，包括數(shù)據(jù)庫、虛擬機鏡像、用戶虛擬磁盤等。

下面，通過舉例若干個Vebula私有云基礎設施平臺可能發(fā)生的異常來對比說明應用本文提出的可用性機制原型前后，云平臺應對異常的情況。具體舉例見表2。

6 結束語

本文通過分析IaaS云計算平臺的生存性問題，確立了IaaS云計算平臺的生存性需求，并提出了基于虛擬資源遷移的生存性機制。在設計并實現(xiàn)了該生存性機制的原型后，將其整合進已有的Vebula私有云基礎設施平臺并進行了測試。

測試證明，該生存性機制原型能較好地應對系統(tǒng)異常和硬件異常。在出現(xiàn)發(fā)生部分可預期的異常的趨勢時，該原型能夠將虛擬機由可能發(fā)生異常的物理設備遷移到正常運行的物理設備。當異常已經發(fā)生時，該原型能夠在很短時間內監(jiān)測到異常，并通過遷移、重啟系統(tǒng)服務等方式自動解決異常。當出現(xiàn)無法自動解決的異常時，該原型也能夠及時通過用戶界面以及第三方監(jiān)控軟件提供的E-mail、短信等方式通知相關責任人手動解決異常，從而較好地保證了云服務的可用性，大大提升了云計算平臺的生存性。

在目前工作的基礎上，本文提出的生存性機制可以在攻擊檢測和攻擊避免方面進行擴展，通過整合IDS等第三方入侵檢測軟件并在生存性機制中加入應對外部攻擊的遷移策略，可以提升云計算平臺抵御外部攻擊的能力，進一步提升云計算平臺的生存性。

1 Peter Mell,Tim Grance,The NIST definition ofcloud computing,national institute of standards and technology,http://csrc.nist.gov/groups/SNS/cloud-computing/,2010

2 Salesforce,http://www.salesforce.com/,2011

3 Google App Engine,http://en.wikipedia.org/wiki/Google_App_Engine,2011

4 EC2,http://aws.amazon.com/ec2/,2011

5 Vsphere,http://communities.vmware.com/community/vmtn/vsphere,2011

6 Hollway B A,Neumman P G.Survivable computer-communication systems:the problem and working group recommendations,Washington:US Army Research Laboratory,1993

7 Ellison R J,Fisher D A,Linger R C,et al.Survivable network system:an emerging discipline,Tech ReportCMU/SEI-97-TR-013,Pittsburgh,Software Eng Inst,Carnegie Mellon Univ,1997

8 Irving Vitra Paputungan, Azween Abdullah. Survivability assessment:modeling a recovery process,seminarnasional aplikasi teknologi informasi,2007

9 Moore A P,Ellison R J,Linger R C.Attack modeling for information security and survivability,technicalnote CMU/SEI-2001-TN-001,2001

10 陳左寧.大規(guī)模計算機系統(tǒng)可信性技術的研究.高性能計算技術,2004(6)

11 Mead N R,Ellison R J,Linger R C,et al.Survivable network analysis method.Carnegie Mellon University,2000

12 Lin Xuegang,Xu Rongsheng,Zhu Miaoliang.Survivability computation of networked information systems.Computer Science,2005(3802):407～414

13 Intel開源軟件技術中心，復旦大學并行處理研究所.系統(tǒng)虛擬化—原理與實現(xiàn).北京：清華大學出版社，2008

14 Nagios.http://www.nagios.org/,2011

15 Liu Pengcheng,Yang Ziye,Song Xiang,et al.Heterogeneous live migration ofvirtualmachines,internationalsymposium on computer architecture,2008