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

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

1 引言

云計(jì)算（cloud computing）是一種計(jì)算模式，它實(shí)現(xiàn)了對(duì)共享可配置計(jì)算資源（網(wǎng)絡(luò)、服務(wù)器、存儲(chǔ)、應(yīng)用和服務(wù)等）方便、按需的訪(fǎng)問(wèn)；這些資源可以通過(guò)較小的管理代價(jià)或服務(wù)提供者的交互被快速地準(zhǔn)備和釋放。云計(jì)算具有以下基本特性：按需索取、廣泛的網(wǎng)絡(luò)訪(fǎng)問(wèn)、資源池化管理和供應(yīng)、快速?gòu)椥陨炜s和服務(wù)度量[1]。

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

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

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

2 生存性分析方法

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

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

（1）攻擊識(shí)別能力（recognition）

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

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

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

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

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

3 生存性機(jī)制

3.1 基礎(chǔ)模型

云計(jì)算平臺(tái)，尤其是IaaS云平臺(tái)的用戶(hù)所關(guān)心的，是自己所請(qǐng)求的云服務(wù)是否可用以及云平臺(tái)發(fā)生異常后云服務(wù)能否在盡可能短的時(shí)間內(nèi)恢復(fù)。對(duì)于服務(wù)提供商來(lái)說(shuō)，要滿(mǎn)足用戶(hù)的需求，就必須對(duì)云平臺(tái)的基礎(chǔ)設(shè)施進(jìn)行監(jiān)控，避免可能發(fā)生的攻擊或系統(tǒng)異常，并在盡可能短的時(shí)間內(nèi)恢復(fù)已經(jīng)停止的云服務(wù)。

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

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

·通過(guò)對(duì)云平臺(tái)的物理設(shè)備以及必需服務(wù)進(jìn)行監(jiān)控，獲取監(jiān)控?cái)?shù)據(jù)；

·分析監(jiān)控?cái)?shù)據(jù)，提取異常狀況，分析異常狀況原因和定位相關(guān)起因并生成警報(bào)；

·根據(jù)異常應(yīng)對(duì)策略以及分析得到的異常原因，生成故障應(yīng)對(duì)的方法，通知相關(guān)責(zé)任人；

·根據(jù)警報(bào)狀況和處理方法進(jìn)行自動(dòng)或手動(dòng)處理；

·對(duì)處理結(jié)果進(jìn)行反饋，未能成功自動(dòng)處理的警報(bào)將留待相關(guān)責(zé)任人手動(dòng)處理。所有未能成功處理的警報(bào)都將重新提交至處理環(huán)節(jié)。

3.2 生存性機(jī)制

本文提出的生存型機(jī)制基于虛擬機(jī)的在線(xiàn)遷移，而虛擬機(jī)遷移的基礎(chǔ)則是虛擬化技術(shù)。

虛擬化[13]是IaaS云平臺(tái)的基礎(chǔ)，通過(guò)在物理設(shè)備和應(yīng)用服務(wù)之間加入虛擬化層，使得應(yīng)用服務(wù)不再依賴(lài)于固定的物理設(shè)備。應(yīng)用服務(wù)由此可以在不同物理設(shè)備間遷移。大部分IaaS云平臺(tái)提供的計(jì)算資源粒度是虛擬機(jī)。

當(dāng)某臺(tái)物理設(shè)備遭遇外部攻擊、系統(tǒng)異常或硬件異常時(shí)，系統(tǒng)在進(jìn)行異常應(yīng)對(duì)過(guò)程中，需要將運(yùn)行于有風(fēng)險(xiǎn)或異常的物理設(shè)備上的虛擬機(jī)遷移[15]至其他狀態(tài)正常的物理設(shè)備。遷移后的虛擬機(jī)的狀態(tài)與遷移前保持一致，從而保證了云平臺(tái)能夠在不影響服務(wù)可用性的前提下把云服務(wù)從有風(fēng)險(xiǎn)或異常的物理設(shè)備轉(zhuǎn)移到穩(wěn)定的物理設(shè)備之上，避免了云服務(wù)因?yàn)橄到y(tǒng)異常或硬件異常而失效的風(fēng)險(xiǎn)。

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

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

當(dāng)沒(méi)有提供處理預(yù)案的異常發(fā)生，或者異常自動(dòng)處理失敗時(shí)，本生存性機(jī)制能夠通過(guò)用戶(hù)界面通知相關(guān)責(zé)任人，也可以調(diào)用第三方監(jiān)控軟件的相關(guān)功能，通過(guò)E-mail、短信等方式通知相關(guān)責(zé)任人手動(dòng)處理異常。

3.3 物理設(shè)備運(yùn)行狀態(tài)建模

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

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

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

表1 節(jié)點(diǎn)主機(jī)運(yùn)行狀態(tài)建模

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

3.4 異常應(yīng)對(duì)

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

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

第一種，應(yīng)對(duì)必要服務(wù)狀態(tài)異常、存儲(chǔ)空間不足等問(wèn)題，本生存性機(jī)制通過(guò)向該物理設(shè)備上的控制器發(fā)送相應(yīng)的處理指令來(lái)解決異常。

第二種，當(dāng)設(shè)備負(fù)荷過(guò)重、資源利用過(guò)高、硬件狀況異常、遭受或可能遭受外部攻擊時(shí)，本生存性機(jī)制將運(yùn)行于該物理設(shè)備上的虛擬機(jī)遷出。對(duì)于設(shè)備負(fù)荷過(guò)重、資源利用過(guò)高、硬件狀況異常等問(wèn)題，將虛擬機(jī)遷出可以有效保證虛擬機(jī)內(nèi)部署的應(yīng)用不會(huì)因?yàn)檫@些問(wèn)題而變得效率低下或中斷。對(duì)于虛擬機(jī)遭受或可能遭受外部攻擊的情況，將該虛擬機(jī)遷出并更新相應(yīng)配置可使外部攻擊失去目標(biāo)，從而防止因?yàn)橥獠抗魧?dǎo)致的虛擬機(jī)內(nèi)的應(yīng)用中斷或數(shù)據(jù)泄漏。

本生存性機(jī)制依據(jù)以下幾個(gè)原則來(lái)進(jìn)行虛擬機(jī)遷移目標(biāo)的決策。

原則一：當(dāng)用戶(hù)無(wú)特殊要求時(shí)，將虛擬機(jī)遷移到哪個(gè)物理設(shè)備由云平臺(tái)當(dāng)前所應(yīng)用的自動(dòng)調(diào)度策略決定。這些自動(dòng)調(diào)度策略可能包括節(jié)能策略、最小需求策略、高性能策略等。

原則二：當(dāng)用戶(hù)有安全性需求，或需要遷出的虛擬機(jī)對(duì)物理設(shè)備的架構(gòu)有所要求時(shí)，本生存性機(jī)制將允許用戶(hù)制定相應(yīng)的遷移規(guī)則（例如某個(gè)部署敏感應(yīng)用的虛擬機(jī)只能被遷移到指定網(wǎng)段的物理設(shè)備等），并在遷移規(guī)則允許范圍內(nèi)應(yīng)用云平臺(tái)現(xiàn)有的自動(dòng)調(diào)度策略決定虛擬機(jī)遷移的目標(biāo)。

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

4 原型架構(gòu)設(shè)計(jì)

4.1 整體架構(gòu)

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

云監(jiān)控模塊與底層監(jiān)控軟件Nagios運(yùn)行于云監(jiān)控主機(jī)上，通過(guò)插件監(jiān)控狀態(tài)讀取插件和配置器控制底層監(jiān)控軟件Nagios。Nagios則通過(guò)調(diào)用運(yùn)行于遠(yuǎn)端受監(jiān)控主機(jī)上的NRPE插件實(shí)現(xiàn)對(duì)遠(yuǎn)端主機(jī)的實(shí)時(shí)監(jiān)控。云監(jiān)控模塊通過(guò)與用戶(hù)界面交互來(lái)提供可定制性，通過(guò)與其他云平臺(tái)控制器交互來(lái)實(shí)現(xiàn)警報(bào)自動(dòng)處理功能。對(duì)該架構(gòu)進(jìn)行詳細(xì)分析如下。

（1）部署情況

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

（2）云監(jiān)控模塊結(jié)構(gòu)

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

（3）通信方式

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

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

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

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

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

4.2 云監(jiān)控模塊架構(gòu)設(shè)計(jì)

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

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

（1）監(jiān)控

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

（2）分析

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

（3）處理

嘗試依據(jù)警報(bào)自動(dòng)處理預(yù)案處理警報(bào)。

（4）反饋

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

警報(bào)處理預(yù)案一般分為以下幾個(gè)類(lèi)型。

·向發(fā)生警報(bào)的主機(jī)發(fā)送對(duì)應(yīng)指令，解決系統(tǒng)相關(guān)服務(wù)異常等問(wèn)題。

·應(yīng)用自動(dòng)遷移策略，將運(yùn)行于異常節(jié)點(diǎn)主機(jī)的虛擬機(jī)動(dòng)態(tài)遷移[15]到正常運(yùn)行的節(jié)點(diǎn)主機(jī)上。

·延遲處理警報(bào)，留待維護(hù)人員手動(dòng)處理。

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

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

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

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

（2）警報(bào)隊(duì)列

存儲(chǔ)現(xiàn)存的所有未處理警報(bào)，隊(duì)內(nèi)警報(bào)按優(yōu)先級(jí)降序排列，需手動(dòng)處理的警報(bào)將被視為最低優(yōu)先級(jí)警報(bào)并置于隊(duì)尾。

（3）用戶(hù)界面控制器

管理與用戶(hù)界面的交互，包括監(jiān)控策略管理、警報(bào)管理和監(jiān)控服務(wù)的啟動(dòng)與停止。

（4）策略控制器

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

（5）警報(bào)處理器

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

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

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

（7）日志接口

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

5 生存性機(jī)制原型的應(yīng)用

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

Vebula私有云基礎(chǔ)設(shè)施平臺(tái)的核心架構(gòu)主要分為以下幾個(gè)模塊。

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

通過(guò)與Vebula Web進(jìn)行交互，來(lái)接受和反饋用戶(hù)請(qǐng)求。負(fù)責(zé)云平臺(tái)的最高層統(tǒng)一調(diào)度。

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

轉(zhuǎn)發(fā)CLC的事件請(qǐng)求，收集并上報(bào)集群信息，管理屬于本集群的節(jié)點(diǎn)控制器。

表2 可用性機(jī)制原型應(yīng)用前后對(duì)比

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

相應(yīng)上層發(fā)出的事件請(qǐng)求，管理節(jié)點(diǎn)主機(jī)上運(yùn)行的虛擬機(jī)（VM）和其他虛擬化資源，收集并上報(bào)節(jié)點(diǎn)主機(jī)及節(jié)點(diǎn)主機(jī)上運(yùn)行的虛擬機(jī)信息。

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

提供DHCP服務(wù)，管理云平臺(tái)的IP資源。

（5）存儲(chǔ)設(shè)備（storage）

存儲(chǔ)云平臺(tái)的內(nèi)部數(shù)據(jù)，包括數(shù)據(jù)庫(kù)、虛擬機(jī)鏡像、用戶(hù)虛擬磁盤(pán)等。

下面，通過(guò)舉例若干個(gè)Vebula私有云基礎(chǔ)設(shè)施平臺(tái)可能發(fā)生的異常來(lái)對(duì)比說(shuō)明應(yīng)用本文提出的可用性機(jī)制原型前后，云平臺(tái)應(yīng)對(duì)異常的情況。具體舉例見(jiàn)表2。

6 結(jié)束語(yǔ)

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

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

在目前工作的基礎(chǔ)上，本文提出的生存性機(jī)制可以在攻擊檢測(cè)和攻擊避免方面進(jìn)行擴(kuò)展，通過(guò)整合IDS等第三方入侵檢測(cè)軟件并在生存性機(jī)制中加入應(yīng)對(duì)外部攻擊的遷移策略，可以提升云計(jì)算平臺(tái)抵御外部攻擊的能力，進(jìn)一步提升云計(jì)算平臺(tái)的生存性。

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ī)模計(jì)算機(jī)系統(tǒng)可信性技術(shù)的研究.高性能計(jì)算技術(shù),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開(kāi)源軟件技術(shù)中心，復(fù)旦大學(xué)并行處理研究所.系統(tǒng)虛擬化—原理與實(shí)現(xiàn).北京：清華大學(xué)出版社，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