武義涵　黃　罡　張　穎　熊英飛

1(高可信軟件技術(shù)教育部重點(diǎn)實(shí)驗(yàn)室(北京大學(xué))　北京　100871)

2(北京大學(xué)信息科學(xué)技術(shù)學(xué)院　北京　100871)

3　　　(國家計(jì)算機(jī)網(wǎng)絡(luò)應(yīng)急技術(shù)處理協(xié)調(diào)中心　北京　100029)

(wuyihan@pku.edu.cn)

?

一種基于模型的云計(jì)算容錯機(jī)制開發(fā)方法

武義涵1,2,3黃罡1,2張穎1,2熊英飛1,2

1(高可信軟件技術(shù)教育部重點(diǎn)實(shí)驗(yàn)室(北京大學(xué))北京100871)

2(北京大學(xué)信息科學(xué)技術(shù)學(xué)院北京100871)

3(國家計(jì)算機(jī)網(wǎng)絡(luò)應(yīng)急技術(shù)處理協(xié)調(diào)中心北京100029)

(wuyihan@pku.edu.cn)

A Model-Based Fault Tolerance Mechanism Development Approach for Cloud Computing

Wu Yihan1,2,3, Huang Gang1,2, Zhang Ying1,2, and Xiong Yingfei1,2

1(KeyLaboratoryofHighConfidenceSoftwareTechnologies(PekingUniversity),MinistryofEducation,Beijing100871)2(SchoolofElectronicsEngineering&ComputerScience,PekingUniversity,Beijing100871)3(NationalComputerNetworkEmergencyResponseTechnicalTeamCoordinationCenterofChina,Beijing100029)

AbstractThere are many different kinds of cloud computing platforms, such as CloudStack, OpenStack, Eucalyptus, and so on, which differentiate from each other in management abilities and management styles. Even in a particular cloud platform, there are also different kinds of virtualization technologies, such as Xen, KVM, VMware, etc. Recent years, with the rapid development of private cloud and hybrid cloud, the heterogeneity degree of infrastructure is aggravated. Fault tolerance (FT) mechanisms are usually supported by the management ability and management style of the infrastructure. As a result, a fault-tolerant mechanism needs to be repeatedly implemented on different platforms. Meanwhile, this directly causes the obvious growing difficulty and increasing amount of time consumption in FT mechanism. In order to reach the goal of achieving FT mechanism among different platforms, we propose a model-based, cross-platform FT mechanism development approach in this paper. To validate the effectiveness and practicability of model-based development approach, we implemente seven fault tolerance mechanisms in CloudStack and OpenStack. A series of experiments show that failover is implemented effectively by these FT mechanisms, and the reliability and availability of the FT target are improved. With high reusability (over 90%) of the code, the FT mechanisms in this thesis can function cross different platforms. Analysis of the questionnaire survey conducted among developers show that our approach can improve the development experience and development efficiency.

Key wordscloud computing; fault tolerance(FT) mechanism; runtime model; self-adaptive; dependability

摘要目前商業(yè)云平臺和開源云平臺種類繁多，如CloudStack,OpenStack,Eucalyptus等，這些云平臺提供的管理能力和管理方式存在較大差異，即使在同一個云平臺中也存在多種虛擬化方式，如Xen,KVM,VMware等.近年來，隨著私有云和混合云的迅速發(fā)展，基礎(chǔ)設(shè)施的異構(gòu)程度加劇.由于容錯機(jī)制往往依賴于基礎(chǔ)設(shè)施的管理能力和管理方式，因此容錯機(jī)制實(shí)例在不同的目標(biāo)平臺上需要分別實(shí)現(xiàn)，導(dǎo)致容錯機(jī)制的開發(fā)難度和開發(fā)時間顯著增加.針對這一問題，提出了一種基于模型的容錯機(jī)制開發(fā)方法，實(shí)現(xiàn)容錯機(jī)制的跨平臺性.為了驗(yàn)證容錯機(jī)制開發(fā)方法的有效性和實(shí)用性，實(shí)現(xiàn)了7種常見的容錯機(jī)制實(shí)例，并在CloudStack和OpenStack開源云平臺上進(jìn)行驗(yàn)證.實(shí)驗(yàn)表明，這些容錯機(jī)制能夠有效地實(shí)現(xiàn)故障轉(zhuǎn)移，提升容錯對象可靠性、可用性等指標(biāo)；提出的容錯機(jī)制開發(fā)方法能夠?qū)崿F(xiàn)跨平臺，并達(dá)到90%以上的代碼復(fù)用率；對云平臺管理員以及容錯機(jī)制開發(fā)者的問卷調(diào)查結(jié)果表明，該方法能夠較好地提升容錯機(jī)制的開發(fā)體驗(yàn)和開發(fā)效率.

關(guān)鍵詞云計(jì)算；容錯機(jī)制；運(yùn)行時模型；自適應(yīng)；可信性

在云平臺中，用戶可以便捷地從資源池中申請和釋放計(jì)算、存儲、網(wǎng)絡(luò)等形式的資源，這使資源管理和使用成本大大降低.隨著云平臺的普及和其規(guī)模的擴(kuò)大，其可靠性所面臨的挑戰(zhàn)也越來越嚴(yán)峻.一方面，云平臺中故障頻繁發(fā)生.亞馬遜AWS從2006年上線后共發(fā)生過43次故障，僅在2010年就發(fā)生過13次故障.另一方面，云平臺故障的潛在影響巨大.截至2014年底，在亞馬遜AWS上的活躍客戶數(shù)突破百萬，如果云平臺發(fā)生故障，可能會影響到這些服務(wù)的正常運(yùn)行，從而波及各個服務(wù)上成千上萬的用戶.而容錯技術(shù)可保證在云平臺發(fā)生故障時，使系統(tǒng)持續(xù)提供有效服務(wù)，提升系統(tǒng)的可靠性.

研究表明，容錯(fault tolerance, FT)技術(shù)是防止系統(tǒng)失效的有效手段[1]，并已在航空航天、醫(yī)療、銀行等領(lǐng)域的系統(tǒng)實(shí)踐中得到廣泛應(yīng)用.在航空領(lǐng)域，雙引擎是最常用的容錯方法.當(dāng)主引擎發(fā)生故障，可以通過引擎切換達(dá)到恢復(fù)或降額發(fā)動機(jī)所需性能的要求，保證飛行安全.波音777-200是目前全球最大的雙引擎客機(jī)，在1995—2014年的20年里，1 000多架飛機(jī)未發(fā)生過致命事故.在銀行數(shù)據(jù)系統(tǒng)中，為了保證數(shù)據(jù)的可靠性，系統(tǒng)會將主服務(wù)器的數(shù)據(jù)實(shí)時拷貝至備份服務(wù)器，建立主服務(wù)器的副本，一旦主服務(wù)器停機(jī)，備份服務(wù)器可以繼續(xù)主服務(wù)器上的業(yè)務(wù).在這種單機(jī)或局域網(wǎng)環(huán)境下，上層軟件獨(dú)占底層基礎(chǔ)設(shè)施，系統(tǒng)環(huán)境確定.因此，只需針對明確且基本不變的容錯需求實(shí)現(xiàn)該運(yùn)行環(huán)境特定的若干容錯機(jī)制實(shí)例.

云環(huán)境與單機(jī)(或局域網(wǎng))環(huán)境的最大區(qū)別在于云平臺基礎(chǔ)設(shè)施共享而單機(jī)環(huán)境基礎(chǔ)設(shè)施獨(dú)占.圖1描述了云平臺的應(yīng)用層和系統(tǒng)層各自的特點(diǎn).應(yīng)用層部署的應(yīng)用種類多、數(shù)量大且容錯需求各異；系統(tǒng)層具有異構(gòu)的云平臺管理能力及虛擬化管理方式.

Fig. 1　Application layer and system layer in cloud platform.圖1　云平臺應(yīng)用層與系統(tǒng)層

基于應(yīng)用層與系統(tǒng)層的特點(diǎn)，云計(jì)算容錯機(jī)制(FT mechanism)面臨2方面的挑戰(zhàn):

1) 容錯機(jī)制的容錯邏輯實(shí)現(xiàn)難度和工作量大，而云環(huán)境下容錯機(jī)制實(shí)例的大規(guī)模性加劇了容錯機(jī)制開發(fā)的工作量.容錯的最終目標(biāo)是保證服務(wù)的可用性，所以需要結(jié)合具體的應(yīng)用實(shí)現(xiàn)具有針對性的容錯機(jī)制.而云平臺中應(yīng)用數(shù)量巨大，因此云容錯機(jī)制實(shí)例具有大規(guī)模性.容錯機(jī)制的開發(fā)往往依賴于開發(fā)者經(jīng)驗(yàn)，開發(fā)難度高且工作量大，因此亟需一種高效的容錯機(jī)制開發(fā)方法.

Fig. 2　Cloud platform participators.圖2　云平臺參與者

此外，云平臺難以感知或預(yù)測上層部署的服務(wù)或應(yīng)用，如圖2所示，在云平臺3種角色中，云平臺提供者僅能管理物理機(jī)以及虛擬機(jī)所在的系統(tǒng)層.所以，目前的云平臺更多是從資源和環(huán)境等系統(tǒng)層面提供少量通用的容錯機(jī)制.例如，VMware提供的VMware-HA和VMware-FT兩個機(jī)制僅針對物理機(jī)故障進(jìn)行容錯，以保證虛擬機(jī)的持續(xù)可用，缺少應(yīng)用層容錯支持.2) 云平臺基礎(chǔ)設(shè)施的異構(gòu)性導(dǎo)致一個容錯機(jī)制實(shí)例需要多次開發(fā).目前云平臺種類繁多，例如OpenStack[2],CloudStack[3],Eucalyptus[4]等，提供的管理能力和管理方式各異.即使在同一個云平臺中也存在多種虛擬化技術(shù)，例如Xen,KVM,VMware等.容錯機(jī)制的實(shí)現(xiàn)往往依賴于系統(tǒng)層提供的管理能力和管理方式，所以同一個容錯機(jī)制實(shí)例需要開發(fā)不同的版本適應(yīng)異構(gòu)的云平臺及虛擬化技術(shù).例如虛擬機(jī)優(yōu)先遷移機(jī)制，在CloudStack和OpenStack中需要調(diào)用不同的管理接口實(shí)現(xiàn)虛擬機(jī)遷移；而Eucalyptus未提供虛擬機(jī)遷移接口，需要分別調(diào)用虛擬化管理程序Xen和KVM提供的管理接口實(shí)現(xiàn)該容錯機(jī)制.近年來，隨著私有云及混合云的迅速發(fā)展，基礎(chǔ)設(shè)施的異構(gòu)化程度加劇，導(dǎo)致容錯機(jī)制面臨的異構(gòu)性挑戰(zhàn)更嚴(yán)峻.出于安全考慮，企業(yè)更愿意將數(shù)據(jù)存放在私有云中，但是同時又希望可以獲得公有云的計(jì)算資源，在這種情況下混合云被越來越多地采用，它將公有云和私有云進(jìn)行混合和匹配，以獲得最佳的效果.由于容錯機(jī)制往往依賴于基礎(chǔ)設(shè)施的管理能力和管理方式，因此容錯機(jī)制實(shí)例在不同的目標(biāo)平臺上需要分別實(shí)現(xiàn)，導(dǎo)致容錯機(jī)制的開發(fā)難度、開發(fā)時間等成本顯著增加.

在傳統(tǒng)的自修復(fù)或容錯系統(tǒng)中，容錯機(jī)制被實(shí)現(xiàn)為該系統(tǒng)專用的容錯庫，系統(tǒng)被描述為一個自適應(yīng)回路，容錯機(jī)制在該回路中被調(diào)用.其中，容錯機(jī)制的開發(fā)依賴于容錯機(jī)制開發(fā)者的經(jīng)驗(yàn)，開發(fā)成本高，且這種方式實(shí)現(xiàn)的容錯機(jī)制難以實(shí)現(xiàn)跨平臺性.針對云計(jì)算中容錯機(jī)制面臨的2方面挑戰(zhàn)，本文提出了一種基于模型的容錯機(jī)制開發(fā)方法，提升開發(fā)效率及開發(fā)體驗(yàn)，實(shí)現(xiàn)容錯機(jī)制的異構(gòu)基礎(chǔ)設(shè)施適配能力.

為提升容錯機(jī)制的開發(fā)效率及開發(fā)體驗(yàn)，本文提出了一種基于模型處理語言(QVT)的容錯邏輯實(shí)現(xiàn)方式.容錯機(jī)制開發(fā)的主要工作量在于如何獲取被容錯對象的運(yùn)行時信息以及如何實(shí)現(xiàn)容錯邏輯.本文分別通過以下方式減少這2部分的工作量及開發(fā)難度：1)本文將眾多容錯機(jī)制所需的運(yùn)行時信息提取為一個集合，將其描述為一個運(yùn)行時模型，減少實(shí)現(xiàn)容錯機(jī)制運(yùn)行時信息獲取的工作量.運(yùn)行時模型與運(yùn)行時系統(tǒng)具有同步關(guān)系，能夠及時獲取系統(tǒng)運(yùn)行時信息，詳見1.2節(jié).2)容錯邏輯描述了對容錯對象的錯誤檢測邏輯、錯誤處理邏輯和故障處理邏輯，是容錯機(jī)制的主要業(yè)務(wù)邏輯.本文使用QVT(QueryViewTransformation)語言實(shí)現(xiàn)容錯邏輯.QVT是對象管理組織提出的一種標(biāo)準(zhǔn)模型處理語言，相比于Java等通用語言能夠更加有效和便捷地實(shí)現(xiàn)對模型的分析和操作.本文將運(yùn)行時模型作為容錯邏輯的輸入，利用QVT對模型處理的高效性，大幅度減少容錯機(jī)制開發(fā)工作量.

為實(shí)現(xiàn)容錯機(jī)制的異構(gòu)基礎(chǔ)設(shè)施適配能力，本文通過對容錯機(jī)制處理邏輯的歸納總結(jié)，首次提出將容錯機(jī)制描述為一個自適應(yīng)回路[5]，包括監(jiān)測(monitor)、分析(analyze)、規(guī)劃(plan)、執(zhí)行(execute)四個階段.監(jiān)測階段收集目標(biāo)平臺及應(yīng)用的運(yùn)行時信息；分析階段通過對運(yùn)行時信息的檢查判斷系統(tǒng)是否存在錯誤，如果存在錯誤則進(jìn)一步分析故障源并進(jìn)入規(guī)劃階段，否則返回監(jiān)測階段；規(guī)劃階段根據(jù)出現(xiàn)錯誤的類型以及故障原因制定恢復(fù)操作序列；執(zhí)行階段通過執(zhí)行恢復(fù)操作序列來調(diào)整系統(tǒng)狀態(tài)，實(shí)現(xiàn)容錯.在上述4個階段中，監(jiān)測和執(zhí)行是平臺相關(guān)的，需要調(diào)用目標(biāo)平臺管理接口；分析和規(guī)劃是平臺無關(guān)的，主要實(shí)現(xiàn)機(jī)制自身的容錯邏輯.將平臺相關(guān)的監(jiān)測和執(zhí)行與平臺無關(guān)的分析和規(guī)劃分離開來以最大程度地實(shí)現(xiàn)容錯機(jī)制跨平臺性是一種自然的選擇.基于模型的開發(fā)方式是實(shí)現(xiàn)平臺相關(guān)部分和平臺無關(guān)部分分離的有效手段，既能夠通過隔離關(guān)注充分實(shí)現(xiàn)平臺無關(guān)的容錯邏輯，又能夠通過代碼生成減少容錯機(jī)制開發(fā)的工作量.為了幫助開發(fā)者對容錯機(jī)制進(jìn)行建模，本文定義了容錯機(jī)制的結(jié)構(gòu)元模型，開發(fā)者通過實(shí)例化該結(jié)構(gòu)元模型來實(shí)現(xiàn)特定容錯機(jī)制的結(jié)構(gòu)模型.結(jié)構(gòu)模型定義了容錯機(jī)制的接口、類及關(guān)聯(lián).在結(jié)構(gòu)模型的指導(dǎo)下，通過QVT語言實(shí)現(xiàn)容錯機(jī)制的平臺無關(guān)部分，即容錯分析和規(guī)劃；通過Java代碼調(diào)用平臺管理API實(shí)現(xiàn)容錯機(jī)制平臺相關(guān)部分，即容錯監(jiān)測和執(zhí)行.

1相關(guān)工作

1.1容錯技術(shù)與容錯機(jī)制

容錯是指系統(tǒng)在出現(xiàn)錯誤的情況下繼續(xù)對外提供服務(wù)的能力.錯誤意味著系統(tǒng)至少存在一個不正確的內(nèi)部狀態(tài)，該狀態(tài)產(chǎn)生的原因是系統(tǒng)內(nèi)部故障，即故障被激活時形成錯誤，而當(dāng)錯誤傳播至構(gòu)件或系統(tǒng)邊界時形成失效.容錯就是在系統(tǒng)故障被激活形成錯誤時，使用某種策略防止錯誤進(jìn)一步傳播和失效的發(fā)生.容錯包括2個步驟：錯誤檢測和恢復(fù)[1].錯誤檢測的目的是及時發(fā)現(xiàn)系統(tǒng)內(nèi)出現(xiàn)的錯誤；恢復(fù)的目的是將系統(tǒng)恢復(fù)到正確狀態(tài)并防止錯誤再次發(fā)生，包括錯誤恢復(fù)和故障恢復(fù)2個階段.錯誤恢復(fù)是將系統(tǒng)中的異常狀態(tài)恢復(fù)正常；故障恢復(fù)是將導(dǎo)致系統(tǒng)發(fā)生錯誤的根源從系統(tǒng)中徹底清除掉，防止故障再次被激活.

根據(jù)被激活的時機(jī)，云容錯機(jī)制可分為反應(yīng)式和前攝式2種類型[6-7].

1) 反應(yīng)式容錯機(jī)制.該機(jī)制是指當(dāng)系統(tǒng)故障被激活形成錯誤時，采用某種策略防止系統(tǒng)失效的發(fā)生.在云平臺中常用的反應(yīng)式容錯機(jī)制包括檢查點(diǎn)重啟(check-pointreboot)[8-9]、備份(spare)[10]、雙工(duplex)[10]以及重試(retry)[11].VirtCFT[9]是一個針對虛擬化集群基于檢查點(diǎn)重啟的容錯系統(tǒng).該系統(tǒng)定期保存整個集群的狀態(tài)，包括所有虛擬機(jī)的CPU、內(nèi)存、硬盤以及網(wǎng)絡(luò)交互，當(dāng)故障發(fā)生后將最近的檢查點(diǎn)恢復(fù)到整個集群中實(shí)現(xiàn)容錯.備份和雙工的區(qū)別在于前者同一時刻僅有一個實(shí)例提供服務(wù)，后者則有多個實(shí)例提供服務(wù).根據(jù)主實(shí)例與從實(shí)例的狀態(tài)一致程度，備份機(jī)制又可分為熱備、溫備、冷備3種.Remus[12]在Xen虛擬化技術(shù)的基礎(chǔ)上實(shí)現(xiàn)了一種基于虛擬機(jī)熱備的容錯機(jī)制.通過增量式內(nèi)存拷貝，將主虛擬機(jī)內(nèi)存狀態(tài)同步至從虛擬機(jī).與Remus類似，Kemari[13]通過內(nèi)存拷貝實(shí)現(xiàn)主從虛擬機(jī)的同步，區(qū)別在于前者通過一個固定的頻率同步虛擬機(jī)，而后者僅在由外部事件(例如硬盤讀寫、網(wǎng)絡(luò)發(fā)送事件等)發(fā)生時進(jìn)行同步.Das在其博士論文[4]中提出一種基于雙工機(jī)制的容錯框架.請求轉(zhuǎn)發(fā)器將請求分發(fā)給各個虛擬機(jī)，投票器從各虛擬機(jī)的反饋中選擇正確的結(jié)果返回給用戶，如果有虛擬機(jī)出現(xiàn)故障，則報(bào)告給故障處理器進(jìn)行修復(fù).對于瞬時性故障，重試機(jī)制是一種簡單高效的容錯策略.當(dāng)返回結(jié)果超時或不正確時，該機(jī)制重新發(fā)送請求給同一個目標(biāo)或其他目標(biāo).例如Apache實(shí)現(xiàn)了針對http請求的重試機(jī)制，以幫助開發(fā)者在對基于http請求的網(wǎng)絡(luò)訪問代碼中實(shí)現(xiàn)容錯.

2) 前攝式容錯機(jī)制.該機(jī)制是指根據(jù)系統(tǒng)目前的狀態(tài)，判斷可能會發(fā)生的錯誤，從而采取某種容錯機(jī)制優(yōu)先預(yù)防失效.云平臺中常用的前攝式容錯機(jī)制[11]包括優(yōu)先遷移和軟件恢復(fù).由于云平臺中虛擬機(jī)具有熱遷移能力[15-18]，因此在預(yù)判物理機(jī)可能會發(fā)生錯誤時(例如根據(jù)物理機(jī)CPU溫度、風(fēng)扇轉(zhuǎn)速判斷該物理機(jī)可能會由于溫度過高導(dǎo)致停機(jī)[19])，將虛擬機(jī)優(yōu)先遷移到其他物理機(jī)上，以維持虛擬機(jī)的正確運(yùn)行.遷移機(jī)制不僅限于虛擬機(jī)粒度，對計(jì)算任務(wù)亦可進(jìn)行遷移[20-22].針對軟件老化引起的故障，可以采用軟件恢復(fù)機(jī)制[23]定期重啟軟件，使系統(tǒng)處于干凈的狀態(tài)從而避免錯誤.在云平臺中重啟單位一般是應(yīng)用、虛擬機(jī)或物理機(jī).Sousa等人提出在拜占庭容錯服務(wù)器中設(shè)置定時器[24]，對服務(wù)器進(jìn)行重啟.為了避免所有服務(wù)器同時重啟而影響對外提供服務(wù)，文中設(shè)計(jì)了同步機(jī)制，由系統(tǒng)統(tǒng)一安排重啟.

產(chǎn)業(yè)界云平臺提供的容錯機(jī)制主要是基于重啟和冗余實(shí)現(xiàn)的.重啟是一種簡單高效的容錯機(jī)制，而冗余能夠?qū)ΤＲ姷膄ail-stop進(jìn)行故障轉(zhuǎn)移.基于雙工的容錯機(jī)制能夠處理拜占庭故障，但由于其消耗過多的軟硬件資源，所以更多在關(guān)鍵系統(tǒng)中使用[25].表1對VMware,XenServer,CloudStack以及Windows ServerhyperV四種云平臺中的容錯機(jī)制使用情況進(jìn)行總結(jié).

Table 1　Usage of FT Mechanisms in Industry Cloud Platform

1) VMware-HA.VMware-HA是基于集群實(shí)現(xiàn)的，讓集群內(nèi)的物理機(jī)之間可以彼此互相支持，一旦有物理機(jī)發(fā)生故障，其上運(yùn)行的虛擬機(jī)就會在其他物理機(jī)上重新啟動,VMware-HA會有短暫的停機(jī)時間.對于可靠性要求較高的虛擬機(jī)，可以使用基于熱備機(jī)制的VMware-FT來完成零停機(jī)、沒有數(shù)據(jù)遺失的任務(wù).

2) XenServer HA.XenServer HA持續(xù)監(jiān)視資源池中主機(jī)的運(yùn)行狀態(tài).如果物理機(jī)發(fā)生故障，XenServer HA會自動將受保護(hù)的虛擬機(jī)重啟至一臺運(yùn)行狀況良好的物理機(jī)上.與VMware-HA不同的是，XenServer HA容錯過程由資源池中的主服務(wù)器實(shí)現(xiàn).如果主服務(wù)器發(fā)生故障，將投票產(chǎn)生新的主服務(wù)器，以便能夠繼續(xù)管理XenServer資源池.

3) CloudStack.在CloudStack中，當(dāng)虛擬機(jī)所在的物理機(jī)出現(xiàn)故障時，HA服務(wù)能夠監(jiān)測該事件并且自動在同一個集群中重新啟動該虛擬機(jī).此外，CloudStack還提供了以下容錯方案：

① 基于狀態(tài)監(jiān)測的虛擬機(jī)重啟.周期性地檢查虛擬機(jī)狀態(tài)是否與數(shù)據(jù)庫VM表中status字段所存儲的內(nèi)容一致，若不一致則認(rèn)為虛擬機(jī)狀態(tài)錯誤，并重啟該虛擬機(jī).

② 虛擬機(jī)優(yōu)先遷移.當(dāng)某臺物理機(jī)負(fù)載超過閾值后(該閾值管理員可設(shè)定)，虛擬機(jī)會被遷移至其他負(fù)載較低的物理機(jī).

③ 多管理節(jié)點(diǎn).CloudStack管理節(jié)點(diǎn)是無狀態(tài)的Web應(yīng)用，可將管理節(jié)點(diǎn)部署在多臺物理機(jī)上，避免單點(diǎn)故障.

④ 數(shù)據(jù)庫備份.CloudStack使用MySQL數(shù)據(jù)庫，可以利用數(shù)據(jù)庫的備份機(jī)制提供數(shù)據(jù)容錯.

4) Windows Server 2008.提供了2種容錯技術(shù)：故障轉(zhuǎn)移集群和網(wǎng)絡(luò)負(fù)載均衡.故障轉(zhuǎn)移集群是一個提供后端應(yīng)用程序故障轉(zhuǎn)移的服務(wù)，用于提升應(yīng)用的可用性，如SQL Server和Exchange Server.集群由一臺主服務(wù)器和多個備用服務(wù)器構(gòu)成，所有的服務(wù)器共享一個存儲系統(tǒng).若主服務(wù)器出現(xiàn)故障，則自動由備用服務(wù)器接管應(yīng)用，實(shí)現(xiàn)容錯.備用服務(wù)器從共享存儲里面讀取Session狀態(tài)，繼續(xù)提供服務(wù).網(wǎng)絡(luò)負(fù)載均衡是一個實(shí)現(xiàn)前端Web應(yīng)用故障轉(zhuǎn)移的服務(wù)，其原理與故障轉(zhuǎn)移集群類似.此外，Windows Server 2012還提供了4個容錯方案：

① 無共享實(shí)時遷移.在傳統(tǒng)的熱遷移技術(shù)中，需要在共享存儲的條件下進(jìn)行.但在Windows Server 2012中，管理員可以在無共享環(huán)境下實(shí)現(xiàn)虛擬機(jī)熱遷移.

② 虛擬機(jī)復(fù)制.虛擬機(jī)復(fù)制是熱備份容錯機(jī)制的一個實(shí)例，通過立即復(fù)制或者復(fù)制計(jì)劃(5 min復(fù)制一次)完成虛擬機(jī)初始復(fù)制.當(dāng)主虛擬機(jī)停機(jī)后，管理員通過hyperV管理器啟用計(jì)劃內(nèi)的故障轉(zhuǎn)移，將上次復(fù)制同步后虛擬機(jī)尚未遷移的數(shù)據(jù)遷移到副本服務(wù)器中，并自動啟用從虛擬機(jī).

③ 網(wǎng)卡組合.網(wǎng)卡組合是指將2個或者多個網(wǎng)卡綁定，但對上層軟件透明.提供故障保護(hù)、帶寬聚合以及負(fù)載均衡.

④ 服務(wù)器消息塊(SMB)無縫故障轉(zhuǎn)移.管理員在對文件服務(wù)器集群中的節(jié)點(diǎn)執(zhí)行硬件或軟件維護(hù)任務(wù)時，不會中斷在文件共享中存儲數(shù)據(jù)的服務(wù)器應(yīng)用程序的正常運(yùn)行.如果集群內(nèi)節(jié)點(diǎn)遇到軟硬件故障，SMB 客戶端可重新連接到其他群集節(jié)點(diǎn)，且不會造成服務(wù)中斷.

故障是引起錯誤和失效的源頭，要進(jìn)行容錯首先要確定故障的類型，再采用相應(yīng)的策略和配置方式進(jìn)行容錯.故障類型是對故障源中可能出現(xiàn)的故障類型的一種假設(shè)，云平臺中常見故障類型包含：瞬時性故障、fail-stop故障、拜占庭故障.瞬時性故障是一種具有不確定性的隨機(jī)發(fā)生的故障，具有難以重現(xiàn)的特點(diǎn)，一般可采取重啟等方式實(shí)現(xiàn)容錯;fail-stop故障是云平臺中常出現(xiàn)的故障之一，例如由于軟硬件錯誤導(dǎo)致虛擬機(jī)或物理機(jī)停止運(yùn)行，或由于硬件老化等因素導(dǎo)致磁盤壞道都屬于這類故障；拜占庭故障是指在運(yùn)行階段發(fā)生的任意類型的故障，尤其是指由于受到攻擊產(chǎn)生的故障[25].在容錯過程中，容錯機(jī)制的選擇往往依賴于故障類型以及其他約束，如資源約束、響應(yīng)時間等，可將其描述為一個約束求解問題[26].

本文使用基于模型的容錯機(jī)制開發(fā)方法實(shí)現(xiàn)了云平臺中7種容錯機(jī)制的實(shí)例，它們針對的故障類型以及適用的故障源如表2所示:

Table 2The Fault Type and Fault Source of Each FT Mechanism

FS:Fail-Stop; TF:Transient Fault; BT:Byzantine Fault;

App:Application; VM:Virtual Machine; PM:Physical Machine.

1.2基于運(yùn)行時模型的自適應(yīng)回路

自修復(fù)是IBM在2001年提出的自治計(jì)算[27]中一個重要組成部分(其他3個部分是自配置、自修復(fù)、自保護(hù))，其目的是實(shí)現(xiàn)系統(tǒng)容錯.此后，在學(xué)術(shù)界從自修復(fù)的角度實(shí)現(xiàn)容錯已達(dá)成共識.自治系統(tǒng)通過MAPEK(monitor-analysis-plan-executorknowledge)控制回路實(shí)現(xiàn)自適應(yīng).在上述自適應(yīng)回路中，知識處于核心地位.如何獲取與管理目標(biāo)相符的知識成為自治計(jì)算研究的熱點(diǎn)之一.北京大學(xué)開發(fā)的運(yùn)行時模型支撐工具SM@RT(supporting model at runtime)實(shí)現(xiàn)了一種通用的運(yùn)行時模型構(gòu)造方法[28]，利用目標(biāo)平臺的管理能力實(shí)現(xiàn)模型與系統(tǒng)的因果關(guān)聯(lián)，即系統(tǒng)的狀態(tài)變化同步至模型，反之模型的變化也會同步至系統(tǒng).圖3展示了SM@RT工具的輸入輸出以及元模型和訪問模型的概念.元模型描述了被管理的元素及元素間的組織結(jié)構(gòu),訪問模型描述了獲取這些元素運(yùn)行時信息的方法.

Fig. 3　Input and output of SM@RT.圖3　SM@RT工具輸入輸出

借助運(yùn)行時模型的同步能力，可以構(gòu)造基于運(yùn)行時模型的自適應(yīng)回路，如圖4所示.宋暉等人[28]對Android,Eclipse以及物聯(lián)網(wǎng)等系統(tǒng)或應(yīng)用構(gòu)造了運(yùn)行時模型，并利用運(yùn)行時模型與系統(tǒng)具有的同步關(guān)聯(lián)這一特點(diǎn)，使用基于模型的語言或管理工具對運(yùn)行時系統(tǒng)在模型層面進(jìn)行管理，以避免對系統(tǒng)進(jìn)行直接管理的復(fù)雜性.

Fig. 4　Runtime model-based self-adaptive loop.圖4　基于運(yùn)行時模型的自適應(yīng)回路

本文在自適應(yīng)回路和SM@RT的基礎(chǔ)上提出了一種基于模型的容錯機(jī)制開發(fā)方法.在容錯機(jī)制開發(fā)階段，將容錯機(jī)制開發(fā)過程描述為自適應(yīng)回路，通過容錯機(jī)制平臺相關(guān)部分和平臺無關(guān)部分的分離，實(shí)現(xiàn)容錯機(jī)制的跨平臺性.在容錯機(jī)制執(zhí)行階段:①使用SM@RT將系統(tǒng)信息抽象為運(yùn)行時模型，并實(shí)現(xiàn)運(yùn)行時系統(tǒng)與運(yùn)行時模型的同步;②通過容錯機(jī)制對運(yùn)行時模型的監(jiān)測和調(diào)整，實(shí)現(xiàn)對目標(biāo)系統(tǒng)的容錯.

2基于模型的容錯機(jī)制開發(fā)方法

本文提出將容錯機(jī)制描述為一個自適應(yīng)回路.一個自適應(yīng)回路包含4個步驟[5]：監(jiān)測、分析、規(guī)劃、執(zhí)行.在監(jiān)測階段，收集被管理系統(tǒng)的運(yùn)行時信息，一般通過調(diào)用目標(biāo)系統(tǒng)管理API或查看日志等方式收集，例如Aparna根據(jù)CloudStack架構(gòu)提出了被監(jiān)測對象的相關(guān)屬性[29].本文假設(shè)容錯機(jī)制的監(jiān)測能力一定程度上依賴于目標(biāo)系統(tǒng)提供的管理接口且該管理接口持續(xù)可用，若目標(biāo)系統(tǒng)不具備該管理功能，需要容錯機(jī)制開發(fā)者實(shí)現(xiàn)該信息的獲取能力.在分析階段，通過預(yù)先定義的方式處理監(jiān)測信息，得出系統(tǒng)運(yùn)行狀態(tài)的相關(guān)結(jié)論.在規(guī)劃階段，按照分析階段得出的結(jié)論制定相應(yīng)的策略，以便將系統(tǒng)調(diào)整到一個更加合適的目標(biāo)狀態(tài).在執(zhí)行階段，按照規(guī)劃結(jié)果對系統(tǒng)進(jìn)行調(diào)整.由此可以看出，在一個自適應(yīng)過程中只有監(jiān)測和執(zhí)行階段需要與目標(biāo)系統(tǒng)交互，是平臺相關(guān)的，而分析和規(guī)劃階段僅包含該自適應(yīng)過程自身的業(yè)務(wù)邏輯，是平臺無關(guān)的;與此相對應(yīng)，在一個容錯機(jī)制中，監(jiān)測和執(zhí)行階段是平臺相關(guān)的，分析和規(guī)劃階段是平臺無關(guān)的.因此，本文通過將平臺相關(guān)部分(監(jiān)測、執(zhí)行)和平臺無關(guān)部分(分析、規(guī)劃)進(jìn)行分離，最大程度地實(shí)現(xiàn)容錯機(jī)制的跨平臺性.如圖5所示，在容錯機(jī)制實(shí)例的跨平臺實(shí)現(xiàn)過程中，分析模塊和規(guī)劃模塊可實(shí)現(xiàn)一次性開發(fā)，為適應(yīng)異構(gòu)的基礎(chǔ)設(shè)施，開發(fā)者只需開發(fā)其相應(yīng)的監(jiān)測模塊和執(zhí)行模塊即可.

Fig. 5　A fault tolerance mechanism enables cross-platform.圖5　一個容錯機(jī)制的跨平臺實(shí)現(xiàn)

2.1容錯機(jī)制實(shí)例研究

Fig. 6　Deployment of hot spare mechanism.圖6　熱備容錯機(jī)制的部署

本節(jié)以熱備容錯機(jī)制為例，展示容錯機(jī)制描述為自適應(yīng)回路的過程.熱備是一種基于資源冗余的容錯機(jī)制.主節(jié)點(diǎn)和備用節(jié)點(diǎn)中部署著相同的服務(wù)，其中主節(jié)點(diǎn)處于活動狀態(tài)，備用節(jié)點(diǎn)處于待命狀態(tài).當(dāng)主節(jié)點(diǎn)出現(xiàn)故障時，備用節(jié)點(diǎn)將被激活至活動狀態(tài).熱備機(jī)制的部署方式如圖6所示.主節(jié)點(diǎn)的外部IP地址為192.168.1.50(IP1)，備用節(jié)點(diǎn)的外部IP地址為192.168.1.51(IP2).當(dāng)主節(jié)點(diǎn)失效，IP1不可訪問時，用戶可通過訪問IP2繼續(xù)獲得服務(wù)，但會影響用戶體驗(yàn).為使容錯過程對用戶透明，通常采用虛擬IP(VIP)技術(shù)實(shí)現(xiàn)故障轉(zhuǎn)移.當(dāng)主節(jié)點(diǎn)有效時，VIP綁定于主節(jié)點(diǎn).當(dāng)主節(jié)點(diǎn)失效且備用節(jié)點(diǎn)被激活時，VIP漂移到備用節(jié)點(diǎn)，此時客戶端通過訪問VIP依然可以獲取正確的服務(wù).這一過程中，為使備用節(jié)點(diǎn)感知主節(jié)點(diǎn)的失效，熱備機(jī)制使用心跳(heartbeat[30])的方式進(jìn)行監(jiān)測.容錯機(jī)制配置過程中需要為2個節(jié)點(diǎn)配置內(nèi)部IP以便于傳輸和監(jiān)測心跳.

熱備機(jī)制容錯邏輯對應(yīng)的自適應(yīng)環(huán)路過程如圖7所示.首先，在監(jiān)測階段獲取主節(jié)點(diǎn)的運(yùn)行時信息，包括該節(jié)點(diǎn)的運(yùn)行狀態(tài)、被監(jiān)測服務(wù)的運(yùn)行狀態(tài)等;其次，在分析階段判斷目標(biāo)服務(wù)是否正常運(yùn)行，如果任務(wù)非正常則進(jìn)入規(guī)劃階段;再次，在規(guī)劃階段制定相應(yīng)的故障轉(zhuǎn)移實(shí)施步驟;最后，在執(zhí)行階段按照規(guī)劃方案對系統(tǒng)進(jìn)行調(diào)整.

Fig. 7　Relationship between hot spare and adaptive loop.圖7　熱備機(jī)制與自適應(yīng)回路對應(yīng)關(guān)系

檢查點(diǎn)重啟機(jī)制容錯邏輯對應(yīng)自適應(yīng)環(huán)路的過程如圖8所示.1)在監(jiān)測階段獲取容錯對象的運(yùn)行時信息;2)在分析階段判斷容錯對象是否正常運(yùn)行，若非正常則進(jìn)入規(guī)劃階段;3)在規(guī)劃階段制定相應(yīng)的故障轉(zhuǎn)移實(shí)施步驟，例如選擇最近可用的檢查點(diǎn);4)在執(zhí)行階段將容錯對象進(jìn)行重啟并恢復(fù)至檢查點(diǎn).

Fig. 8　Relationship between check-point restart and adaptive loop.圖8　檢查點(diǎn)重啟機(jī)制與自適應(yīng)回路對應(yīng)關(guān)系

在傳統(tǒng)的自修復(fù)系統(tǒng)中，開發(fā)者通常將目標(biāo)系統(tǒng)描述為一個自適應(yīng)環(huán)路，容錯機(jī)制作為規(guī)劃階段的一部分實(shí)現(xiàn)于該系統(tǒng)特定的容錯庫中[31-33].這種方式并未考慮容錯機(jī)制的跨平臺性，導(dǎo)致其難以復(fù)用；此外，傳統(tǒng)的容錯機(jī)制開發(fā)方法要求開發(fā)者對目標(biāo)系統(tǒng)管理能力和管理方式具有比較深入的了解，且實(shí)現(xiàn)難度大.

為實(shí)現(xiàn)容錯機(jī)制中平臺相關(guān)部分和平臺無關(guān)部分的分離，需要對容錯機(jī)制過程進(jìn)行抽象，并定義這2部分之間的接口.由于模型具有良好的抽象能力，模型驅(qū)動軟件開發(fā)能夠有效地控制開發(fā)成本、提升開發(fā)效率，因此，使用基于模型的方法開發(fā)容錯機(jī)制，通過隔離關(guān)注，不僅可以有效地實(shí)現(xiàn)平臺無關(guān)部分的容錯邏輯，還可以提升平臺相關(guān)部分的開發(fā)效率，降低容錯機(jī)制跨平臺所需的工作量.

2.2容錯機(jī)制開發(fā)

Fig. 9　Development procedure of a FT mechanism.圖9　容錯機(jī)制開發(fā)過程

基于模型的容錯機(jī)制開發(fā)過程包括3個階段：定義結(jié)構(gòu)模型、構(gòu)造行為模型、實(shí)現(xiàn)適配代碼.其中結(jié)構(gòu)模型通過UML類圖描述容錯機(jī)制的靜態(tài)特征；行為模型通過QVT語言描述容錯機(jī)制的動態(tài)行為，實(shí)現(xiàn)容錯機(jī)制的平臺無關(guān)部分；適配代碼通過Java,C等程序語言調(diào)用目標(biāo)云平臺的管理API，實(shí)現(xiàn)容錯機(jī)制的平臺相關(guān)部分.基于模型的容錯機(jī)制開發(fā)過程如圖9所示，首先將結(jié)構(gòu)元模型實(shí)例化為結(jié)構(gòu)模型，然后在結(jié)構(gòu)模型的指導(dǎo)下分別實(shí)現(xiàn)行為模型和適配代碼.

2.2.1結(jié)構(gòu)模型

Fig. 11　Structure model of hot spare.圖11　熱備機(jī)制結(jié)構(gòu)模型

在基于模型的容錯機(jī)制開發(fā)過程中，結(jié)構(gòu)模型描述了容錯機(jī)制的靜態(tài)特征.為了便于開發(fā)者定義結(jié)構(gòu)模型，本文根據(jù)容錯機(jī)制自適應(yīng)環(huán)路的4個階段定義了結(jié)構(gòu)模型的元模型.當(dāng)開發(fā)者實(shí)現(xiàn)特定的容錯機(jī)制時，只需按照該元模型的約束定義結(jié)構(gòu)模型即可，元模型如圖10所示.Manager類定義了容錯機(jī)制的主邏輯，包括對監(jiān)測、分析、規(guī)劃、執(zhí)行4個階段的調(diào)用，并定義了該容錯機(jī)制的非功能屬性，例如該容錯機(jī)制對容錯對象提供的可用性、故障轉(zhuǎn)移時間、資源消耗等.其中，可用性屬性描述了使用該容錯機(jī)制后容錯對象可用性的提升程度.如雙機(jī)熱備可將故障時間減少一倍，從而提升可用性的百分比.ManagedObject類描述了云平臺中被監(jiān)測和調(diào)整的對象，其用于描述物理機(jī)、虛擬機(jī)、應(yīng)用、網(wǎng)絡(luò)、存儲等軟硬件設(shè)備.Monitor類描述了容錯機(jī)制中監(jiān)測模塊，其中，platform屬性描述被監(jiān)測的平臺，getObject方法獲取到被監(jiān)測的對象，例如虛擬機(jī)對象；Analyzer類描述了運(yùn)行時信息分析過程，并最終判定被監(jiān)測的對象是否出現(xiàn)狀態(tài)錯誤，根據(jù)其分析結(jié)果來判定Planner類是否被調(diào)用；Planner類描述了針對該錯誤狀態(tài)構(gòu)造的恢復(fù)邏輯，例如將出現(xiàn)錯誤的虛擬機(jī)關(guān)閉、啟動備份虛擬機(jī)等；Executor類描述了通過對目標(biāo)云平臺管理API的調(diào)用，執(zhí)行規(guī)劃模塊制定的恢復(fù)邏輯.

Fig. 10　The meta-model of structure model.圖10　結(jié)構(gòu)模型的元模型

本文對上述元模型進(jìn)行實(shí)例化，定義出熱備機(jī)制的結(jié)構(gòu)模型，如圖11所示.該結(jié)構(gòu)模型定義了在3種云平臺中熱備機(jī)制的實(shí)現(xiàn)方式，由于分析、規(guī)劃模塊是可復(fù)用的平臺無關(guān)部分，因此在結(jié)構(gòu)模型中只需出現(xiàn)一次；而監(jiān)測、執(zhí)行模塊是平臺相關(guān)部分，因此需要針對3種云平臺分別定義.圖11中僅展示了CloudStack被管理元素的部分細(xì)節(jié).其中被監(jiān)測的元素分別是haproxy應(yīng)用(name屬性值為haproxy，type屬性值為application)和ubuntuVM虛擬機(jī)(name屬性值為ubuntuVM，type屬性值為VM)，并且該應(yīng)用運(yùn)行于該虛擬機(jī)之上.Monitor類通過監(jiān)測被管理元素的運(yùn)行時信息，將其反饋給Analyzer類，當(dāng)Analyzer類分析結(jié)果表明被監(jiān)測對象出現(xiàn)錯誤時，Manager主函數(shù)則調(diào)用Planner類制定恢復(fù)計(jì)劃，并最終通過Executor類實(shí)施該計(jì)劃.被實(shí)施操作的對象是2臺名為ubuntuVM和ubuntuVM_backup的虛擬機(jī).操作過程則是將虛擬IP從主虛擬機(jī)遷移到備份虛擬機(jī)，實(shí)現(xiàn)故障轉(zhuǎn)移.該熱備機(jī)制在Eucalyptus和OpenStack中的處理邏輯與CloudStack中的處理邏輯類似，此處不再贅述.

2.2.2行為模型

行為模型負(fù)責(zé)實(shí)現(xiàn)結(jié)構(gòu)模型中定義的Analyzer類和Planner類，其功能是分析系統(tǒng)運(yùn)行狀態(tài)、檢測系統(tǒng)中發(fā)生的錯誤、查找故障源并制定恢復(fù)計(jì)劃.本文通過運(yùn)行時模型獲取系統(tǒng)狀態(tài)，并將其作為行為模型的輸入.為了便于實(shí)現(xiàn)對運(yùn)行時模型的分析和操作，本文采用QVT[34]語言實(shí)現(xiàn)行為模型.圖12描述了行為模型對系統(tǒng)調(diào)整的條件和過程.當(dāng)在虛擬機(jī)v1上運(yùn)行的應(yīng)用hp1出現(xiàn)故障且虛擬機(jī)v2上運(yùn)行的應(yīng)用hp2狀態(tài)正常時，則將虛擬機(jī)v1上的VIP遷移至虛擬機(jī)v2.我們采用XML格式描述分析和規(guī)劃的結(jié)果，并在代碼中使用QVT的log()函數(shù)將結(jié)果保存至中間數(shù)據(jù).

Fig. 12　Behavior model of hot spare mechanism.圖12　熱備機(jī)制行為模型.

上述行為模型的執(zhí)行結(jié)果如圖13所示，其含義是將VIP從webloadbalancer3虛擬機(jī)刪除，并且綁定至webloadbalancer3Backup虛擬機(jī).

Fig. 13　Output of behavior model.圖13　行為模型執(zhí)行結(jié)果

2.2.3適配代碼

適配代碼實(shí)現(xiàn)結(jié)構(gòu)模型中Executor類，即按照分析規(guī)劃的結(jié)果調(diào)用目標(biāo)平臺的管理能力，對云平臺實(shí)現(xiàn)狀態(tài)調(diào)整.由于在熱備機(jī)制的結(jié)構(gòu)模型中定義了3個異構(gòu)的云平臺:CloudStack，OpenStack，Eucalyptus，因此適配代碼需要分別加以實(shí)現(xiàn).如圖14所示，熱備機(jī)制通過調(diào)用CloudStack提供的RESTFUL API、OpenStack提供的CLI以及Eucalyptus提供的RESTFUL API實(shí)現(xiàn)對VIP的綁定.對VIP的刪除操作與之類似，此處不贅述.

Fig. 14　Adapter code of hot spare in three cloud platforms.圖14　熱備機(jī)制在3種云平臺的部分適配代碼實(shí)現(xiàn)

3基于運(yùn)行時模型的容錯執(zhí)行框架

為支持容錯機(jī)制的運(yùn)行，本文實(shí)現(xiàn)了一個基于運(yùn)行時模型的容錯機(jī)制執(zhí)行框架.如圖15所示，包括云容錯運(yùn)行時模型的構(gòu)造以及容錯測試.

運(yùn)行時模型的構(gòu)造分為2個步驟：構(gòu)造元模型以及構(gòu)造訪問模型.1)構(gòu)造面向容錯的云平臺元模型.該元模型包括2個方面的屬性，即云平臺屬性以及容錯機(jī)制相關(guān)屬性，本文對CloudStack,OpenStack以及Eucalyptus三大開源云平臺的管理能力進(jìn)行統(tǒng)計(jì)，取其并集構(gòu)造出通用云平臺管理模型，此外將容錯機(jī)制相關(guān)屬性進(jìn)行整合，得到面向容錯的云平臺容錯元模型.2)構(gòu)造平臺相關(guān)的訪問模型，實(shí)現(xiàn)對元模型的實(shí)例化.元模型是平臺無關(guān)模型，定義了云平臺管理能力以及運(yùn)行時信息的結(jié)構(gòu)，而運(yùn)行時模型是平臺相關(guān)模型，通過對各個平臺管理能力的綁定實(shí)現(xiàn)對元模型的實(shí)例化.SM@RT將元模型和訪問模型作為輸入，通過代碼生成工具構(gòu)造維護(hù)運(yùn)行時模型的引擎.

Fig. 15　Runtime model-based FT framework.圖15　基于運(yùn)行時模型的容錯框架

Fig. 16　FT testing.圖16　容錯測試

為驗(yàn)證容錯機(jī)制和容錯配置效果，本文提出一種基于運(yùn)行時模型的容錯測試方法.在運(yùn)行階段對云平臺中的故障源進(jìn)行故障注入，并對運(yùn)行時模型以及容錯機(jī)制的運(yùn)行狀態(tài)進(jìn)行分析，計(jì)算可靠性指標(biāo).如圖16所示，本文通過QVT腳本對運(yùn)行時模型進(jìn)行故障注入，模擬系統(tǒng)故障.例如，通過QVT對運(yùn)行時模型進(jìn)行操作，將指定的應(yīng)用狀態(tài)從running設(shè)置為error，此時容錯機(jī)制的監(jiān)測模塊觀察到該錯誤，并由執(zhí)行模塊實(shí)現(xiàn)故障轉(zhuǎn)移.在狀態(tài)調(diào)整后，利用QVT實(shí)現(xiàn)SBRA(scenario-based reliability analysis approach)[35]等可靠性分析算法在模型層面對系統(tǒng)進(jìn)行可靠性評估.

4實(shí)驗(yàn)與分析

在本文的實(shí)驗(yàn)中采用基于模型的容錯機(jī)制開發(fā)方法，實(shí)現(xiàn)了7個容錯機(jī)制實(shí)例:重試、重啟、熱備、冷備、雙工、優(yōu)先遷移、軟件恢復(fù)，并將這些容錯機(jī)制分別在CloudStack和OpenStack環(huán)境下進(jìn)行測試.1)分析容錯效果，驗(yàn)證容錯機(jī)制跨平臺能力，統(tǒng)計(jì)代碼復(fù)用率及開發(fā)成本;2)分析對云平臺管理員以及容錯機(jī)制開發(fā)者的問卷調(diào)查結(jié)果，驗(yàn)證基于模型的容錯機(jī)制開發(fā)方法能夠提升開發(fā)體驗(yàn)和開發(fā)效率.

為了對實(shí)現(xiàn)的容錯機(jī)制進(jìn)行效果評估，本文在CloudStack和OpenStack中進(jìn)行了一系列實(shí)驗(yàn)，驗(yàn)證容錯機(jī)制的有效性、跨平臺性以及基于模型開發(fā)方法對容錯機(jī)制開發(fā)效率的提升.本文將相同的JOnAS應(yīng)用服務(wù)器部署于多個虛擬機(jī)中，并部署基準(zhǔn)測試程序PetStore，使用LoadRunner作為測試工具.

實(shí)驗(yàn)配置如下：應(yīng)用：PetStore 1.3.1_02及JOnAS_4_9_2;虛擬機(jī)：操作系統(tǒng)Centos6.4，VCPU 2×2 GHz，內(nèi)存1 GB;云平臺：CloudStack4.2.1，OpenStack Essex;測試工具：HP LoadRunner 11.00.

4.1容錯機(jī)制有效性及跨平臺性

原生CloudStack系統(tǒng)中有3個容錯機(jī)制實(shí)例，分別是虛擬機(jī)重啟、虛擬機(jī)遷移以及應(yīng)用雙工.基于容錯機(jī)制開發(fā)方法，本文實(shí)現(xiàn)了其他4種容錯機(jī)制相應(yīng)的實(shí)例，即熱備、冷備、重啟、恢復(fù).OpenStack中僅提供了針對基礎(chǔ)設(shè)施的容錯機(jī)制實(shí)例，而不對客戶虛擬機(jī)提供容錯支持，因此本文在OpenStack中為客戶虛擬機(jī)或應(yīng)用實(shí)現(xiàn)了7種容錯機(jī)制相應(yīng)的實(shí)例.

Fig. 17　Success rate of transactions.圖17　事務(wù)成功率曲線

在容錯對象運(yùn)行過程中，通過預(yù)先定義的腳本隨機(jī)觸發(fā)一類故障，并選取故障前后20 min內(nèi)的數(shù)據(jù)進(jìn)行分析.實(shí)驗(yàn)中測量的是故障注入前后的一段時間內(nèi)事務(wù)成功率，監(jiān)測無故障運(yùn)行的時間過長并無太大意義.此外，針對JOnAS服務(wù)器以及實(shí)驗(yàn)環(huán)境中虛擬機(jī)的資源配置，100個用戶的使用量能夠較好地將服務(wù)質(zhì)量維持在較為穩(wěn)定的水平，排除由于用戶量過大導(dǎo)致的JOnAS請求丟失.在表2描述的3類故障中，fail-stop故障是云平臺中常出現(xiàn)的故障之一[36].例如由于軟硬件錯誤導(dǎo)致虛擬機(jī)或物理機(jī)停止運(yùn)行，或由于硬件老化等因素導(dǎo)致磁盤壞道都屬于這類故障，對該故障的模擬能夠覆蓋最多的故障數(shù)量，因此本文實(shí)驗(yàn)中選擇注入fail-stop類型故障.在JOnAS服務(wù)器運(yùn)行過程中，故障注入腳本在某時刻被激活，導(dǎo)致JOnAS強(qiáng)行關(guān)閉(模擬fail-stop故障)，并分別驗(yàn)證7個容錯機(jī)制實(shí)例的容錯效果.本文對容錯機(jī)制的評價指標(biāo)主要體現(xiàn)在可靠性和可用性2個方面，其中可靠性描述事務(wù)的成功率，可用性描述系統(tǒng)的可用時間占總時間的比例，性能方面的評價暫未考慮在容錯機(jī)制的評價范圍內(nèi).圖17展示了7種容錯機(jī)制的容錯效果.縱坐標(biāo)表示每秒事務(wù)成功數(shù)量，橫坐標(biāo)表示訪問時間.其中，雙工機(jī)制能夠提供最優(yōu)的容錯效果，較快實(shí)現(xiàn)故障轉(zhuǎn)移，而由于重試機(jī)制僅能支持瞬時性故障，因此在第10分鐘之后無法針對fail-stop錯誤提供有效的容錯支持. 圖18展示了7種容錯機(jī)制分別部署在CloudStack和OpenStack中的可靠性.可靠性是指在規(guī)定的條件下和規(guī)定的時間內(nèi)軟件不引起系統(tǒng)失效的概率.據(jù)此概念，本文通過對事務(wù)成功率進(jìn)行計(jì)算描述在各種容錯機(jī)制保障下的軟件可靠性，即，可靠性=成功事務(wù)數(shù)總事務(wù)數(shù).其中，雙工機(jī)制均能提供100%的可靠性，這是因?yàn)殡p工機(jī)制無故障轉(zhuǎn)移時間，能夠最有效地防止單點(diǎn)故障引起的系統(tǒng)失效；重試機(jī)制無法針對fail-stop錯誤提供有效的容錯支持，因此其理論可靠性為50%(20 min內(nèi)僅有前10 min工作，且用戶以相同的頻率訪問).實(shí)驗(yàn)測試可靠性(分別是49.9%和49.7%)與理論值較接近，說明本實(shí)驗(yàn)將誤差控制在較小范圍內(nèi).其他各種容錯機(jī)制在2種云平臺中的可靠性有較小區(qū)別，是由于在容錯機(jī)制中調(diào)用云平臺管理API實(shí)現(xiàn)效率的差別，導(dǎo)致錯誤恢復(fù)和故障轉(zhuǎn)移時間不同.

Fig. 18　Reliability of FT mechanisms.圖18　容錯機(jī)制可靠性

本文分別統(tǒng)計(jì)了7個容錯機(jī)制實(shí)例的故障轉(zhuǎn)移時間，具體如圖19所示：

Fig. 19　Failover time of FT mechanisms.圖19　容錯機(jī)制故障轉(zhuǎn)移時間

為更進(jìn)一步描述容錯機(jī)制在可信性方面的支持能力，本文從可用性(Availability)角度進(jìn)行分析.Availability=MTTF(MTTF+MTTR).其中,MTTF為評價無故障運(yùn)行時間;MTTR為平均故障修復(fù)時間，即本文中的故障轉(zhuǎn)移時間.可用性直接從故障轉(zhuǎn)移時間的角度評估系統(tǒng)可信性，因此7種容錯機(jī)制的實(shí)例對可用性的提升能力不同于可靠性.圖20展示了各種容錯機(jī)制的可用性.

Fig. 20　Availability of FT mechanisms.圖20　容錯機(jī)制可用性

此外，基于模型的容錯機(jī)制具有較小的性能損失.相關(guān)文獻(xiàn)[19]展示了基于虛擬機(jī)遷移的容錯方法會帶來1%～4%的性能損耗，而本文實(shí)現(xiàn)的虛擬機(jī)熱遷移容錯機(jī)制產(chǎn)生3.4%的性能損失(本文部署的CloudStack環(huán)境中虛擬機(jī)遷移基準(zhǔn)時間為14.7 s，基于優(yōu)先遷移的容錯機(jī)制時間為15.2 s)，處在性能損失范圍內(nèi)，因此基于模型的容錯機(jī)制帶來的性能損失是可接受的.

4.2容錯機(jī)制資源消耗

容錯機(jī)制會產(chǎn)生額外的資源消耗，包括計(jì)算資源、存儲資源以及網(wǎng)絡(luò)資源.表3展示了各種容錯機(jī)制消耗的資源在EC2(類型為t2.small)和EBS(存儲介質(zhì)為磁盤類型)中的成本.其中，相對于不使用容錯機(jī)制時應(yīng)用本身所消耗的資源，雙工機(jī)制使用了2倍的計(jì)算資源、1倍的存儲資源以及2倍的網(wǎng)絡(luò)資源.重啟、重試以及優(yōu)先遷移不消耗計(jì)算資源和存儲資源，這是由于這3種機(jī)制是基于時間冗余的容錯機(jī)制.

Table 3　FT Costs

4.3容錯機(jī)制開發(fā)工作量及代碼復(fù)用率

基于模型的容錯機(jī)制開發(fā)方法能夠在較大程度上降低容錯機(jī)制的開發(fā)量.本文統(tǒng)計(jì)了7種容錯機(jī)制實(shí)例開發(fā)過程中的工作量,如表4所示.在結(jié)構(gòu)模型中，本文統(tǒng)計(jì)了所有模型元素的總數(shù)，包括類、屬性、方法和關(guān)聯(lián);在行為模型中，本文統(tǒng)計(jì)了QVT代碼行數(shù)(line of code, LOC).在適配代碼中，分別統(tǒng)計(jì)了在CloudStack和OpenStack中的Java代碼行數(shù).

Table 4　Development Efforts of FT Mechanisms

行為模型是容錯機(jī)制開發(fā)過程中的平臺無關(guān)部分，適配代碼是平臺相關(guān)部分.根據(jù)各自實(shí)現(xiàn)的代碼行數(shù)，本文計(jì)算出7個容錯機(jī)制實(shí)例的代碼復(fù)用率.參照實(shí)驗(yàn)及相關(guān)論文[28]中的統(tǒng)計(jì)數(shù)據(jù)，實(shí)現(xiàn)相同功能所需的QVT代碼與Java代碼的行數(shù)比為1∶40.按照該比例將行為模型的QVT代碼轉(zhuǎn)化為Java代碼，容錯機(jī)制的代碼復(fù)用率在90%以上，如表4所示.因此，本文提出的基于模型的容錯機(jī)制開發(fā)方法能夠較好地解決平臺異構(gòu)性問題.

與相關(guān)工作相比，本文提出的容錯機(jī)制開發(fā)方法有效地減少了容錯機(jī)制開發(fā)過程中的工作量.原生CloudStack實(shí)現(xiàn)了一個基于虛擬機(jī)重啟的容錯機(jī)制.被標(biāo)記為HA-Enable的虛擬機(jī)將會被High-AvailabilityManager監(jiān)控，如果該虛擬機(jī)的狀態(tài)與數(shù)據(jù)庫中保存的狀態(tài)不一致或其所在的物理機(jī)失效，則對該虛擬機(jī)在集群內(nèi)其他物理機(jī)上進(jìn)行重啟.該容錯機(jī)制實(shí)現(xiàn)需1 597行Java代碼，而在本文的開發(fā)方法中僅使用了49行QVT以及71行Java代碼.

4.4容錯機(jī)制開發(fā)效率及開發(fā)體驗(yàn)

基于模型的容錯機(jī)制開發(fā)方法將平臺無關(guān)模塊與平臺相關(guān)模塊分離，由容錯機(jī)制開發(fā)者和云管理員2類開發(fā)者共同參與.其中，容錯機(jī)制開發(fā)者擅長容錯邏輯，實(shí)現(xiàn)平臺無關(guān)部分(即容錯機(jī)制的分析和規(guī)劃邏輯)；云管理員擅長云平臺管理能力的使用，實(shí)現(xiàn)平臺相關(guān)部分(即容錯機(jī)制的執(zhí)行邏輯).2類開發(fā)者只需預(yù)先定義之間的接口即可.

本文通過對容錯機(jī)制開發(fā)者和云管理員的問卷調(diào)查，分析虛擬機(jī)重啟、應(yīng)用熱備和優(yōu)先遷移3種機(jī)制分別在平臺相關(guān)部分和無關(guān)部分的開發(fā)難度，探索基于模型的容錯機(jī)制開發(fā)方法是否能夠在整體上降低開發(fā)難度、提升開發(fā)效率.

本研究邀請7名云管理員對容錯機(jī)制開發(fā)過程進(jìn)行評估，評估內(nèi)容包括在容錯機(jī)制開發(fā)過程中的平臺相關(guān)和無關(guān)部分的開發(fā)難度、開發(fā)時間、代碼行數(shù)，評估結(jié)果統(tǒng)計(jì)如表5所示.本文的調(diào)查對象均來自北京大學(xué)軟件所的碩士研究生和博士研究生，分別開發(fā)和維護(hù)不同的云平臺Openstack 和CloudStack.其中，部分調(diào)查對象的OpenStack開發(fā)和管理經(jīng)驗(yàn)達(dá)1年，CloudStack的開發(fā)和管理經(jīng)驗(yàn)達(dá)2年，且曾基于OpenStack和CloudStack參與開發(fā)青云[37]和燕云[38]2個云平臺系統(tǒng).目前燕云已經(jīng)部署于北京大學(xué)軟件所供上百名師生使用，且該云平臺的日常維護(hù)和管理均由他們完成.因此，調(diào)查對象對云平臺具有豐富的管理經(jīng)驗(yàn)，能夠代表一般的云管理員.在問卷中首先描述了基于模型容錯機(jī)制的原理及開發(fā)過程，然后由云調(diào)查對象對平臺無關(guān)部分和相關(guān)部分的實(shí)現(xiàn)難度(1～10)進(jìn)行評估，并預(yù)測平臺相關(guān)部分的代碼行數(shù)以及開發(fā)時間.其中，開發(fā)時間包括對云平臺API的學(xué)習(xí)時間.調(diào)查結(jié)果表明，平臺無關(guān)部分的開發(fā)難度相對較大.例如，調(diào)查對象在實(shí)現(xiàn)虛擬機(jī)優(yōu)先遷移平臺無關(guān)部分的反饋中提到“難以找出物理機(jī)故障的判定條件，諸如資源實(shí)時利用率過高、最近出現(xiàn)過故障、距上一次出現(xiàn)故障時間、磁盤壽命等.如果只是簡單地考慮幾個屬性會比較容易，但要作出正確率較高的決策比較困難”.這反映了容錯機(jī)制開發(fā)過程中的一般問題，即難以準(zhǔn)確判斷錯誤的出現(xiàn)以及故障源，而這一過程對于容錯機(jī)制開發(fā)者相對簡單.

Table 5　Development Efforts on Cloud Administrators of FT Mechanisms

The following numbers stand for difficulty. 1: Very Easy; 3: Easy; 5: Hard; 7: Very Hard; 10: Impossible.

此外，本文對4名具有容錯經(jīng)驗(yàn)的開發(fā)者進(jìn)行問卷調(diào)查，結(jié)果如表6所示.這4名開發(fā)者均為對QVT語言具有一年以上編程經(jīng)驗(yàn)的研究生.為了模擬容錯機(jī)制開發(fā)者，我們在問卷中預(yù)先描述了每個容錯機(jī)制實(shí)例的分析、規(guī)劃邏輯.在該問卷中，首先，描述了基于模型容錯機(jī)制的原理及開發(fā)過程；然后，描述這3種容錯機(jī)制的分析、規(guī)劃邏輯，例如如何判斷物理機(jī)故障、如何實(shí)現(xiàn)故障轉(zhuǎn)移(模擬容錯機(jī)制開發(fā)者)；最后，由開發(fā)者評估平臺無關(guān)部分和相關(guān)部分的實(shí)現(xiàn)難度(1～10分)，并預(yù)測平臺無關(guān)部分的代碼行數(shù)以及開發(fā)時間.調(diào)查表明對容錯機(jī)制開發(fā)者而言，平臺相關(guān)的容錯邏輯的實(shí)現(xiàn)難度更低.

Table 6　Development Efforts on FT Experts

綜上所示，平臺相關(guān)部分的開發(fā)對于管理員難度較低，而平臺無關(guān)部分的開發(fā)對于容錯機(jī)制開發(fā)者難度較低.因此，通過容錯機(jī)制平臺相關(guān)部分與平臺無關(guān)部分的分離，由云管理員實(shí)現(xiàn)平臺相關(guān)部分、容錯機(jī)制開發(fā)者實(shí)現(xiàn)平臺無關(guān)部分，能夠有效地降低容錯機(jī)制開發(fā)難度、提升開發(fā)效率及開發(fā)體驗(yàn).

5結(jié)束語

在傳統(tǒng)的自修復(fù)或容錯系統(tǒng)中，容錯機(jī)制被實(shí)現(xiàn)在該系統(tǒng)專用的容錯庫中，系統(tǒng)被描述為一個自適應(yīng)回路，容錯機(jī)制在該回路中被調(diào)用.這種方式實(shí)現(xiàn)的容錯機(jī)制難以實(shí)現(xiàn)跨平臺性和復(fù)用性.不同于傳統(tǒng)方法，本文首次提出將容錯機(jī)制描述為一個自適應(yīng)回路(監(jiān)測-分析-規(guī)劃-執(zhí)行)，并采用基于模型的開發(fā)方式實(shí)現(xiàn)容錯機(jī)制的跨平臺性，同時降低開發(fā)成本、提升開發(fā)體驗(yàn).通過本文方法實(shí)現(xiàn)的容錯機(jī)制可形成一個跨平臺的容錯機(jī)制庫，供異構(gòu)云平臺調(diào)用.為了幫助容錯機(jī)制開發(fā)者實(shí)現(xiàn)容錯機(jī)制，本文提出一個容錯機(jī)制開發(fā)方法，包括3個步驟：定義機(jī)構(gòu)模型、定義行為模型、實(shí)現(xiàn)適配代碼.1)本文定義了容錯機(jī)制結(jié)構(gòu)模型的元模型，該元模型的實(shí)例化開發(fā)者可以構(gòu)造出特定容錯機(jī)制的結(jié)構(gòu)模型，以進(jìn)一步指導(dǎo)該容錯機(jī)制的實(shí)現(xiàn)；2)本文提出通過模型描述語言QVT實(shí)現(xiàn)平臺無關(guān)的行為模型，實(shí)現(xiàn)容錯分析和規(guī)劃；3)適配代碼可由目標(biāo)系統(tǒng)提供管理接口的語言類型實(shí)現(xiàn)(例如Java，C++等通用語言)，即開發(fā)容錯機(jī)制平臺相關(guān)部分，將行為模型的分析和規(guī)劃結(jié)果通過平臺管理API實(shí)現(xiàn)到系統(tǒng)中.

在未來工作中，可進(jìn)一步提高容錯機(jī)制開發(fā)過程的自動化程度.在基于模型的容錯機(jī)制開發(fā)方法中，行為模型描述了容錯邏輯是通過QVT語言實(shí)現(xiàn)的，該過程需要手動實(shí)現(xiàn).雖然工作量已大幅度減少，但考慮到該語言的專業(yè)性，會增加學(xué)習(xí)成本.針對這一問題，可以采用領(lǐng)域建模語言半自動代碼生成的方式幫助管理員生成容錯邏輯代碼.

參考文獻(xiàn)

[1]Avizienis A, Laprie J C, Randell B, et al. Basic concepts and taxonomy of dependable and secure computing[J]. IEEE Trans Dependable and Secure Computing, 2004, 1(1): 11-33

[2]OpenStack Foundation. OpenStack API complete reference[ROL]. 2015 [2015-06-15]. http:www.openstack.org

[3]Apache CloudStack. Apache CloudStack API documentation(V4.5.0)[ROL]. 2015 [2015-06-15]. http:cloudstack.apache.orgapiapidocs-4.5TOC_Root_Admin.html

[4]Hewlett Packard Enterprise Development LP. General purpose reference architecture: Detailed solution example for Eucalyptus private clouds[ROL]. 2015 [2015-06-15]. http:docs.hpcloud.comeucalyptus4.2.0

[5]Kephart J O, Chess D M. The vision of autonomic computing[J]. Computer, 2003, 36(1): 41-50

[6]Mahalkari A, Tondon R. A replica distribution based fault tolerance management for cloud computing[J]. International Journal of Computer Science & Information Technologies, 2014, 5(5): 6880-6887

[7]Ganesh A, Sandhya M, Shankar S. A study on fault tolerance methods in cloud computing[C]Proc of Int Advance Computing Conf (IACC2014). Piscataway, NJ: IEEE, 2014: 844-849

[8]Joshi S C, Sivalingam K M. Fault tolerance mechanisms for virtual data center architectures[J]. Photonic Network Communications, 2014, 28(2): 154-164

[9]Zhang Minjia, Jin Hai, Shi Xuanhua, et al. VirtCFT: A transparent VM-level fault-tolerant system for virtual clusters[C]Proc of the 16th Int Conf on Parallel and Distributed Systems (ICPADS). Piscataway, NJ: IEEE, 2010: 147-154

[10]Haas F. Openstack High Availability Guide[MOL]. 2014 [2015-06-15]. http:docs.openstack.orgha-guide

[11]Ganga K, Karthik S. A fault tolerent approach in scientific workflow systems based on cloud computing[C]Proc of Int Conf on Pattern Recognition, Informatics and Mobile Engineering (PRIME). Piscataway, NJ: IEEE, 2013: 387-390

[12]Cully B, Lefebvre G, Meyer D, et al. Remus: High availability via asynchronous virtual machine replication[C]Proc of the 5th USENIX Symp on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2008: 161-174

[13]Tamura Y, Sato K, Kihara S, et al. Kemari: Virtual machine synchronization for fault tolerance[C]Proc of USENIX Annual Technology Conf. Berkeley, CA: USENIX Association, 2008: 1-3

[14]Das P. Virtualization and fault tolerance in cloud computing[D]. Rourkela, India: National Institute of Technology Rourkela, 2013

[15]Clark C, Fraser K, Hand S, et al. Live migration of virtual machines[C]Proc of the 2nd USENIX Symp on Networked Systems Design & Implementation. Berkeley, CA: USENIX Association, 2005: 273-286

[16]Pradip D, Miren K, Bhavsar M, et al. Live virtual machine migration techniques in cloud computing: A survey[J]. International Journal of Computer Applications, 2014, 86(16): 18-21

[17]Ahmad R W, Gani A, Hamid S H A, et al. A survey on virtual machine migration and server consolidation frameworks for cloud data centers[J]. Journal of Network and Computer Applications, 2015, 52(1): 11-25

[18]Ahmad R W, Gani A, Hamid S H A, et al. Virtual machine migration in cloud data centers: A review, taxonomy, and open research issues[J]. The Journal of Supercomputing, 2015, 71(7): 1-43

[19]Nagarajan A B, Mueller F, Engelmann C, et al. Proactive fault tolerance for HPC with Xen virtualization[C]Proc of the 21st Annual Int Conf on Supercomputing. New York: ACM, 2007: 23-32

[20]Bala A, Chana I. Fault tolerance-challenges, techniques and implementation in cloud computing[J]. International Journal of Computer Science Issues, 2012, 9(1): 37-41

[21]Choudhary S, Vits M. Task migration based fault tolerant scheme for cloud computing[J]. International Journal of Scientific Progress and Research, 2014, 2(1): 55-61

[22]Shyamsunder S, Varkhede K, Bhuruk S, et al. Efficient fault tolerant strategies in cloud computing systems[J]. Resource, 2015, 2(2): 32-34

[23]Sudhakar C, Shah I, Ramesh T. Software rejuvenation in cloud systems using neural networks[C]Proc of Int Conf on Parallel, Distributed and Grid Computing (PDGC2014). Piscataway, NJ: IEEE, 2014: 230-233

[24]Sousa P, Bessani A N, Correia M, et al. Highly available intrusion-tolerant services with proactive-reactive recovery[J]. IEEE Trans on Parallel and Distributed Systems, 2010, 21(4): 452-465

[25]Fan Jie, Yi Letian, Shu Jiwu. Research on the technologies of Byzantine system[J]. Journal of Software, 2013, 24(6): 1346-1360 (in Chinese)(范捷, 易樂天, 舒繼武. 拜占庭系統(tǒng)技術(shù)研究綜述[J]. 軟件學(xué)報(bào), 2013, 24(6): 1346-1360)

[26]Zheng Zibin, Zhou T C, Lyu M R, et al. Component ranking for fault-tolerant cloud applications[J]. IEEE Trans on Services Computing, 2012, 5(4): 540-550

[27]Kephart J O, Chess D M. The vision of autonomic computing[J]. Computer, 2003, 36(1): 41-50

[28]Song Hui, Huang Gang, Wu Yihan, et al. Modeling and maintaining runtime software architectures[J]. Journal of Software, 2013, 24(8): 1731-1745 (in Chinese)(宋暉, 黃罡, 武義涵, 等. 運(yùn)行時軟件體系結(jié)構(gòu)的建模與維護(hù)[J]. 軟件學(xué)報(bào), 2013, 24(8): 1731-1745)

[29]Datt A, Goel A, Gupta S C. Comparing infrastructure monitoring with CloudStack compute services for cloud computing systems[G]Databases in Networked Information Systems. Berlin: Springer, 2015: 195-212

[30]Haas F. The Linux-HA User’s Guide[MOL]. 2010 [2015-06-15]. http:www.linux-ha.orgdocusers-guideusers-guide.html

[31]Garlan D, Schmerl B. Model-based adaptation for self-healing systems[C]Proc of the 1st Workshop on Self-Healing Systems. New York: ACM, 2002: 27-32

[32]Cheng S W, Garlan D, Schmerl B, et al. Using architectural style as a basis for system self-repair[G]Software Architecture. Berlin: Springer, 2002: 45-59

[33]Garlan D, Cheng S W, Huang A C, et al. Rainbow: Architecture-based self-adaptation with reusable infrastructure[J]. Computer, 2004, 37(10): 46-54

[34]Object Management Group, Inc. OMG Formal Version of QVT. Version 1.1: Meta Object Facility (MOF) 2.0 QueryViewTransformation Specification[R]. 2015 [2015-06-15]. http:www.omg.orgspecQVT1.2

[35]Sherif Y, Bojan C, Hany A. A scenario-based reliability analysis approach for component-based software[J]. IEEE Trans on Reliability 2004, 53(4): 465-480

[36]Vishwanath K V, Nagappan N. Characterizing cloud computing hardware reliability[C]Proc of the 1st ACM Symp on Cloud Computing. New York: ACM, 2010: 193-204

[37]Wu Yihan, Huang Gang. Model-based high availability configuration framework for cloud[C]Proc of the Middleware Doctoral Symp. New York: ACM, 2013: 6-11

[38]Wu Yihan. Research on runtime model-based approach to cloud fault tolerance[D]. Beijing: Peking University, 2015 (in Chinese)(武義涵. 基于運(yùn)行時模型的云計(jì)算容錯技術(shù)研究[D]. 北京: 北京大學(xué), 2015)

Wu Yihan, born in 1988. PhD from Peking University. His research interests include software reliability, runtime software architecture, cloud availability and fault tolerance.

Huang Gang, born in 1975. Professor and PhD supervisor. His research interests include middleware, software architecture, and Internetware which is a new paradigm for software of Internet as a computer.

Zhang Ying, born in 1982. Research assistant. His research interests include distributed computing with a focus on middleware, the construction and management of middleware, software engineering with a focus on component based development, and mobile computing.

Xiong Yingfei, born in 1982. Received his BS degree from University of Electronic Science and Technology of China in 2004, and his PhD degree from the Department of Information Engineering of University of Tokyo in 2009. He worked as a post-doctoral in University of Waterloo from 2009 to 2011. Assistant professor (Young Talents Plan) at Peking University. His research interests include consistency management.

中圖法分類號TP311.5

基金項(xiàng)目：國家“八六三”高技術(shù)研究發(fā)展計(jì)劃基金項(xiàng)目(2015AA01A202);國家自然科學(xué)基金項(xiàng)目(61222203，61300002)

收稿日期：2015-06-29；修回日期：2015-11-16

This work was supported by the National High Technology Research and Development Program of China (863 Program) (2015AA01A202), and the National Natural Science Foundation of China (61222203, 61300002).