- 相關(guān)推薦
基于通信消息的云計算系統(tǒng)故障傳播效果應(yīng)對
寫畢業(yè)論文主要目的是培養(yǎng)學(xué)生綜合運用所學(xué)知識和技能，理論聯(lián)系實際，獨立分析，解決實際問題的能力，使學(xué)生得到從事本專業(yè)工作和進(jìn)行相關(guān)的基本訓(xùn)練。下面是一篇信息安全論文范文，歡迎閱讀參考!
隨著云計算平臺的不斷發(fā)展，以O(shè)penStack為代表的云平臺管理軟件逐漸受到人們的關(guān)注。這類軟件的交互對象涉及計算機(jī)中多個層次的程序，軟件本身較為復(fù)雜。并且在企業(yè)級的運用過程中通常會具有較大的規(guī)模。因此云計算系統(tǒng)在運行時極其容易發(fā)生硬件和軟件故障。在線故障檢測技術(shù)可以幫助云計算平臺獲得系統(tǒng)級的可靠性保障。為了發(fā)現(xiàn)故障，需要對云平臺進(jìn)行監(jiān)控，收集系統(tǒng)運行期間的各項特征。
系統(tǒng)運行時的特征來源，從已有的工作來看，可以大致分為三類。一是宿主機(jī)狀態(tài)相關(guān)的特征，包括CPU使用情況、IO使用情況等;二是與代碼相關(guān)的特征，包括程序特征、函數(shù)調(diào)用序列等;第三種是與數(shù)據(jù)相關(guān)，包括函數(shù)調(diào)用中的參數(shù)、寄存器與內(nèi)存某位置上的值等[1]。
本文分析了面向消息的中間件中的通信消息與發(fā)出/接收這些通信消息的系統(tǒng)的故障行為之間的關(guān)系。從靜態(tài)的代碼角度，分析了故障的發(fā)生到傳播至通信消息的機(jī)理;對AMQP協(xié)議構(gòu)建的消息建立了模型，提出了一個簡單的故障檢測方式。通過故障注入實驗得出了在OpenStack云計算平臺上，能夠通過通信消息得到反映的故障行為的比例。表明了使用通信消息作為故障檢測的信息來源的可行性與有效性。
1 OpenStack故障傳播分析
云計算管理軟件是典型的分布式軟件。不同的組件之間需要通過網(wǎng)絡(luò)進(jìn)行通信。常見的通信方式基于RPC實現(xiàn)。出于解耦等因素的考慮，RPC的實現(xiàn)又會依賴于中間件。OpenStack主要采用了兩種通信機(jī)制。一種是在組件內(nèi)部使用的AMQP通信協(xié)議。另一種是遵循REST風(fēng)格的通信構(gòu)架，主要用來與用戶通信交互。前者是本文關(guān)注的對象。
OpenStack使用了多種方式嘗試捕捉OpenStack運行時發(fā)生的故障。這些方式包括了檢查函數(shù)調(diào)用的返回值、捕捉Python語言中被拋出的異常、對耗時操作設(shè)置超時時間以及對異步操作進(jìn)行狀態(tài)輪詢等。
返回值被經(jīng)常用來向調(diào)用者表示被調(diào)用者的執(zhí)行情況。通常對封裝良好的功能的返回值進(jìn)行仔細(xì)得檢查，并做出適當(dāng)?shù)奶幚砟軌虮苊夂芏嗲闆r下故障的傳播[2]。
盡管人們早已認(rèn)同對被調(diào)用者返回的返回值進(jìn)行檢查是一種良好的編程習(xí)慣。已有的工作還是發(fā)現(xiàn)，即使在一些組織構(gòu)架的很好的項目中，很多軟件故障的原因與對返回值不恰當(dāng)?shù)奶幚碛嘘P(guān)[3]。這些故障，以及一些其他來源的故障，會或多或少對軟件的內(nèi)部狀態(tài)產(chǎn)生影響，即軟件的內(nèi)部存在差錯。一旦這些差錯被異常處理機(jī)制偵測時，程序控制流會跳轉(zhuǎn)到異�？刂屏髦羞M(jìn)行相關(guān)異常的處理。避免了故障進(jìn)一步不受控制的傳播[4]。
同時在調(diào)用一些外部程序時，容易發(fā)生外部調(diào)用長時間不返回，最終阻塞住了調(diào)用者的情況。在分布式系統(tǒng)中，面對這種類型的故障，使用超時機(jī)制是十分常見，并且有效的。盡管存在難以界定超時時間的問題，超時機(jī)制還是被廣泛的運用在OpenStack之中。
超時機(jī)制能夠較好的解決同步阻塞操作的無限等待問題。但是面對異步調(diào)用，會發(fā)生調(diào)用者始終不進(jìn)入期望的最終狀態(tài)。如在OpenStack創(chuàng)建虛擬機(jī)的操作中，目標(biāo)虛擬機(jī)的狀態(tài)遷移從虛擬機(jī)不存在到BUILD，最終創(chuàng)建成功進(jìn)入ACTIVE狀態(tài)，創(chuàng)建過程中出現(xiàn)錯誤導(dǎo)致創(chuàng)建失敗則進(jìn)入ERROR狀態(tài)。但是存在一定的可能性使得被創(chuàng)建的虛擬機(jī)始終停留在BUILD狀態(tài)。面對這種情況，分布式系統(tǒng)可以采用輪詢策略，并采用一定的超時/重試機(jī)制來發(fā)現(xiàn)此類故障。
OpenStack采用上述幾種機(jī)制來檢測內(nèi)部發(fā)生的故障。通過閱讀源碼，發(fā)現(xiàn)故障被上述機(jī)制檢測出后，存在有兩種策略通知有關(guān)的模塊。一是直接在故障被檢測出的位置中斷正常執(zhí)行流程，并直接通知有關(guān)模塊;另外一種是將相關(guān)的標(biāo)志位設(shè)置為故障狀態(tài)，通常還會中斷當(dāng)前的執(zhí)行流程，最終在一個統(tǒng)一的位置處通知有關(guān)模塊。前者通常出現(xiàn)在通過捕獲異常發(fā)現(xiàn)故障的代碼中;后者在一些調(diào)用較深的位置，并且需要執(zhí)行后續(xù)代碼的情況下被使用。無論是哪一種機(jī)制，都會通過試圖通知有關(guān)的模塊。在OpenStack中最重要的nova模塊中，使用AMQP消息隊列實現(xiàn)。
2 實驗方案介紹
這一章節(jié)將介紹向OpenStack云計算平臺進(jìn)行故障注入，以及獲取RabbitMQ消息的方案。
2.1 OpenStack的故障注入方案
OpenStack云計算平臺使用了Python語言實現(xiàn)。Python語言內(nèi)建了異常機(jī)制。并且OpenStack的實現(xiàn)中廣泛使用了異常機(jī)制來實現(xiàn)內(nèi)部錯誤、故障的捕獲與處理。基于先前的工作，通過一種基于異常控制流的程序錯誤行為分析方法，該文構(gòu)建了一套OpenStack的錯誤行為[5]。并以O(shè)penStack的功能為依據(jù)，對這些錯誤行為進(jìn)行了分類。
基于上述錯誤行為，可以根據(jù)差錯引起的異常所在的位置，以及異常類型進(jìn)行故障注入。通過手工修改OpenStack的代碼，可以強(qiáng)制當(dāng)OpenStack運行至有關(guān)位置的代碼時，拋出特定類型的異常。通過觀察手工插入的日志信息是否被打印來確定這些外部環(huán)境與功能入口是否確實能夠激活特定的錯誤行為。這些信息將作為后續(xù)實驗的負(fù)載。
2.2 影子隊列技術(shù)
根據(jù)AMQP協(xié)議的設(shè)計，消息隊列是消息儲存和分發(fā)的實體。而消息隊列又是接收來自消息交換器根據(jù)綁定關(guān)系分發(fā)而來的消息。“影子隊列”技術(shù)的核心思想就是，為每一條實體消息隊列創(chuàng)建一個對應(yīng)的影子隊列，這條影子隊列使用相同的綁定關(guān)系與有關(guān)的消息交換器進(jìn)行綁定。從而使得影子隊列能夠與其對應(yīng)的實體消息隊列一樣，獲得一份相同的消息。從而實現(xiàn)對通過AMQP進(jìn)行傳輸?shù)南⑦M(jìn)行監(jiān)控。
2.3 實驗流程
由于OpenStack并沒有在Python語言級別特別明確的API。因此通過OpenStack的Horizon組件中的提供的功能，以及Linux下nova工具提供的功能進(jìn)行經(jīng)驗上的總結(jié)。得出了部分常用的且具有較高故障注入價值的功能入口。并通過在代碼中寫入日志的手段，確保待注入故障位置能夠被特定的功能入口的指令覆蓋。
本文在進(jìn)行各個操作前，還收集了在未執(zhí)行任何操作的情況下，OpenStack組件之間的通信消息。該文將這些通信消息稱之為本底消息。收集這些消息的目的是希望盡可能的幫助區(qū)分出于操作相關(guān)的通信消息以及無關(guān)的通信消息。
在進(jìn)行故障注入實驗前，同樣也收集了在未注入故障的情況下，操作正常返回的的前后的所有通信消息。這些通信消息將直接與故障注入實驗時，收集到的通信消息作為對比。觀察兩者的區(qū)別。
2.4 實驗環(huán)境
實驗平臺由3臺64位x86服務(wù)器構(gòu)成。運行在其中的OpenStack版本為Grizzly。其中nova-compute等組件運行于服務(wù)器compute，組件quantum運行于服務(wù)器network，其余必要的組件運行于服務(wù)器manager。RabbitMQ同樣運行于manager節(jié)點。
3 實驗結(jié)果分析
本文針對OpenStack的共進(jìn)行了668次故障注入。按照功能入口對這些故障注入實驗進(jìn)行分類。實現(xiàn)結(jié)果出現(xiàn)了以下三種情況：
1) 注入故障后，相關(guān)功能無法正確完成。收集到的通信消息與正常情況下收集到的通信消息具有顯著的差別。
2) 注入故障后，相關(guān)功能無法正確完成。收集到的通信消息未出現(xiàn)原本應(yīng)當(dāng)出現(xiàn)的RPC調(diào)用相關(guān)的通信消息。
3) 注入故障后，相關(guān)功能無法正確完成。收集到的通信消息與正常情況下收集到的通信消息沒有上述兩種情況中描述的任何區(qū)別。
實驗中還出現(xiàn)了一些少數(shù)情況。在這些情況下，注入故障后，OpenStack相關(guān)的組件無法啟動;或者有關(guān)的功能依然能夠正常完成。前一種情況下，無法收集到有效的通信消息。而后一種情況說明故障注入后，OpenStack能夠容忍注入的故障。這兩種情況不在本文需要的討論的范圍之內(nèi)。
幾種情況下故障注入后，收集到的通信消息情況如下表1所示。
由表1的統(tǒng)計數(shù)據(jù)可見，有相當(dāng)一部分比例的故障可以通過通信消息進(jìn)行區(qū)分�？梢酝ㄟ^較為簡單的建模后，有效的進(jìn)行故障檢測。
4 結(jié)論
通過代碼分析以及實驗可以看出，在云計算平臺中，通過消息隊列中的通信消息能夠有效的檢測出其中的故障。
參考文獻(xiàn)：
[1] Avizienis A，Laprie J C，Randell B，et al.Basic concepts and taxonomy of dependable and secure computing[J]. Dependable and Secure Computing， IEEE Transactions on，2004，1(1)： 11-33.
[2] 單錦輝，徐克俊，王戟.一種軟件故障診斷過程框架[J].計算機(jī)學(xué)報， 2011， 34(2)： 372-373.
[3] Ju X， Soares L， Shin K G， et al. On fault resilience of OpenStack[C]//Proceedings of the 4th annual Symposium on Cloud Computing. ACM， 2013： 2.
[4] Min-na X I A，De-liang G，Juan X.一種面向可靠云計算的自適應(yīng)故障檢測方法[J].計算機(jī)應(yīng)用研究，2014， 31(2).
【基于通信消息的云計算系統(tǒng)故障傳播效果應(yīng)對】相關(guān)文章：
基于云計算的網(wǎng)絡(luò)信息安全服務(wù)論文10-08
基于智能體服務(wù)的云計算架構(gòu)分析論文10-10
基于云計算機(jī)系統(tǒng)的實訓(xùn)平臺研究和實現(xiàn)的論文10-08
淺談基于云計算的數(shù)字化教育資源共享模式與機(jī)制研究09-30
計算機(jī)云計算10-09
基于軟交換技術(shù)的通信網(wǎng)絡(luò)融合10-08
淺談基于云計算機(jī)系統(tǒng)的實訓(xùn)平臺研究和實現(xiàn)的論文10-08
計算機(jī)通信技術(shù)通信論文10-01