段文雪 胡 銘 周 瓊 吳庭明 周俊龍 劉 曉 魏同權 陳銘松

1(華東師范大學上海市高可信計算重點實驗室 上海 200062)2(上海外國語大學國際金融貿(mào)易學院 上海 200083)3(南京理工大學計算機科學與技術學院 南京 210094)4(迪肯大學信息技術學院 澳大利亞墨爾本 VIC 3125)

云計算(cloud computing)是基于分布式計算(distributed computing)、網(wǎng)格計算(grid computing)、并行計算(parallel computing)等技術發(fā)展而來的一種新型計算模式[1].它利用虛擬化技術，將各種硬件資源(如計算資源、存儲資源和網(wǎng)絡資源)虛擬化，以按需使用、按使用量付費的方式向用戶提供高度可擴展的彈性計算服務.由于無需自己為了購買IT基礎設施、搭建私有計算平臺以及管理升級軟硬件資源而投入高昂的費用和人力成本，越來越多的企業(yè)選擇將他們的計算需求外包給云計算服務提供商.因此，云計算已經(jīng)引起了學術界和工業(yè)界的高度重視，例如，國外的Amazon，Google，國內(nèi)的阿里、百度、騰訊等企業(yè)競相發(fā)布各種云計算平臺為用戶提供服務.云計算作為一種正在發(fā)展中的信息技術，已經(jīng)被視為信息產(chǎn)業(yè)的一次重大革命.Gartner發(fā)布的研究報告稱，全世界公有云服務的市場收益在2016年為2 196億美元，到2017年已經(jīng)增加到了2 602億美元，增長率大約為18.5%[2].與此同時，各種形式的軟硬件資源仍然在不斷地被加入到云計算系統(tǒng)中，數(shù)據(jù)中心的規(guī)模和復雜度也在動態(tài)增長，這也進一步促進了云計算技術的飛速發(fā)展.

盡管不斷發(fā)展的云計算技術使得數(shù)據(jù)中心能夠提供動態(tài)的、易使用的計算資源，但是由于其具備資源虛擬化、多租戶、規(guī)模巨大和體系結(jié)構復雜等特性，云計算仍然面臨著諸多挑戰(zhàn).隨著云計算系統(tǒng)中硬件資源的不斷增加、規(guī)模不斷擴大，各種資源的不確定性也在迅速增長，導致系統(tǒng)在運行時頻繁發(fā)生各種故障[3].2017年8月30日，受系統(tǒng)更新程序故障的影響，Google云的負載均衡系統(tǒng)癱瘓18 h，導致美國、歐洲和亞洲等地區(qū)的虛擬機都無法連接到Google云后端.云計算系統(tǒng)中頻繁發(fā)生的故障，無論對用戶還是對服務提供商都會帶來巨大的損失.根據(jù)Google發(fā)布的報告稱[4]，每次修復故障需要的開銷包括100美元的技術人員費用和10%的服務器價格(大約為200美元)，即單次故障維修大約需要300美元.因此，單臺服務器在經(jīng)歷7次故障后，修復硬件需要的開銷已經(jīng)超過購買1臺全新服務器所需要的價錢.2016年的一份調(diào)查報告顯示[5]，單次數(shù)據(jù)中心宕機造成的平均損失在2010年為505 502美元，在2013年為690 204美元，到2016年已經(jīng)增加到了740 357美元.根據(jù)信息周刊發(fā)布的報告稱[6]，每年IT服務中斷導致的損失已經(jīng)超過265億美元.因此，作為制約云計算技術發(fā)展的重要因素，云計算系統(tǒng)的可靠性已經(jīng)成為亟待研究的問題.

對用戶而言，云計算系統(tǒng)的可靠性反映了系統(tǒng)能夠提供無故障服務的穩(wěn)定程度，而云計算系統(tǒng)中的故障則經(jīng)常體現(xiàn)為某種形式的系統(tǒng)崩潰、服務失效或結(jié)果錯誤.更具體地說，故障是系統(tǒng)不能正常運行的真實原因，而錯誤是系統(tǒng)故障的一種外在體現(xiàn)，即系統(tǒng)中的失效或錯誤本質(zhì)上來源于系統(tǒng)中的某種故障.多個錯誤可能來自于同一個故障，多個故障也有可能導致同一個錯誤[7].在云計算系統(tǒng)中，故障的發(fā)生可能來自于多方面的原因，如硬件故障、軟件故障等.相比于傳統(tǒng)的并行計算環(huán)境，云計算平臺具有高度異構性，計算資源的失效概率相對更高[8].在云系統(tǒng)發(fā)生故障時采取合理的措施處理異常情況對保證系統(tǒng)服務的可靠性至關重要.因此，為了保證云計算系統(tǒng)的正確運行，故障管理已經(jīng)成為云計算系統(tǒng)的重要特性[9].常見的故障管理技術有故障消除(fault removal)、故障預測與避免(fault forecast and avoidance)以及故障容忍(fault tolerance).故障消除是通過傳統(tǒng)的軟件測試與驗證方法移除云計算系統(tǒng)中存在的軟件缺陷來保證服務可靠性的一種方法，這種方法適用于系統(tǒng)發(fā)布的早期.故障預測與避免是在作業(yè)調(diào)度的過程中預測故障的發(fā)生并采取合理的措施預防故障，它要求系統(tǒng)設計人員具備處理各種類型故障的專業(yè)知識[10].故障容忍是系統(tǒng)在發(fā)生故障的情況下依然能夠正確執(zhí)行功能的一種能力.云計算環(huán)境中的故障容忍技術主要分為2類：主動式容錯和被動式容錯[10-13].主動式容錯是在系統(tǒng)發(fā)生故障后采取措施恢復系統(tǒng)的正常功能，常見的主動式容錯技術有檢查點技術、主動復制技術等.被動式容錯是在不改變系統(tǒng)結(jié)構的條件下，從魯棒控制思想出發(fā)設計控制系統(tǒng)，使其對故障不敏感，典型的被動容錯是用多副本表決來避免由故障引起錯誤.

雖然故障管理技術對于提高云計算系統(tǒng)的可靠性、保障服務的性能具有至關重要的作用，但是在系統(tǒng)運行用戶的應用程序時，使用故障管理技術必然會增加數(shù)據(jù)中心消耗的電能，給云計算服務提供商帶來額外的運營成本，降低投資回報率.例如Google數(shù)據(jù)中心1年的耗電量為1.12×109kW·h，隨之而來的是6 700萬美元的電費；微軟數(shù)據(jù)中心每年的耗電量為6×108kW·h，需要支付3 600萬美元的電費[14].按照目前35%的增長率發(fā)展[15]，到2020年美國的數(shù)據(jù)中心消耗的電能將會達到1.4×1011kW·h，屆時美國將可能需要新建17個發(fā)電站才能滿足數(shù)據(jù)中心的電力需求.由此可見，降低數(shù)據(jù)中心能耗已經(jīng)成為云計算服務提供商面臨的另一個挑戰(zhàn).因此，在保證云計算系統(tǒng)可靠性的同時，如何降低數(shù)據(jù)中心的能耗也是在設計故障管理技術時必須要考慮的問題.

1 云計算系統(tǒng)可靠性概述

保障云計算系統(tǒng)的可靠性對于系統(tǒng)向用戶提供可靠的云計算服務具有至關重要的意義.本節(jié)首先給出云計算系統(tǒng)可靠性的定義，然后介紹可靠云計算系統(tǒng)的設計原則，最后詳細描述影響云計算系統(tǒng)可靠性的主要因素.

1.1 云計算系統(tǒng)可靠性定義

云計算系統(tǒng)的可靠性衡量了系統(tǒng)能夠提供不中斷的無故障服務的穩(wěn)定程度.一般來說，可靠性可以定義為：在某種規(guī)定的條件下，系統(tǒng)能夠在約定的時間范圍內(nèi)穩(wěn)定提供無故障服務的能力[16].如圖1所示[17]，云計算是一種面向服務的架構，客戶端可以隨時隨地通過網(wǎng)絡訪問云計算系統(tǒng)提供各種服務，如基礎設施即服務(infrastructure as a service, IaaS)、平臺即服務(platform as a service, PaaS)和軟件即服務(software as a service, SaaS).因此，云計算系統(tǒng)的可靠性與具體的服務模型密切相關.為了使云計算系統(tǒng)提供的服務更加可靠，每種服務模型的服務提供商都有責任保障服務的可靠性，并且各自的責任隨著服務模型的不同而有所差異.例如，基礎設施即服務層的服務提供商應當保證硬件設施一直處于穩(wěn)定運行的狀態(tài)，不會因為硬件故障而影響到運行在基礎設施上的服務質(zhì)量；而軟件即服務層的服務提供商則需要保證軟件系統(tǒng)中不會存在嚴重的軟件缺陷，避免軟件故障影響到用戶的服務體驗.

Fig. 1 Service model of cloud computing system圖1 云計算系統(tǒng)的服務模型[17]

1.2 可靠云計算系統(tǒng)的設計原則

為了避免云計算系統(tǒng)在運行過程中產(chǎn)生故障或者使云計算服務在系統(tǒng)發(fā)生故障時具備可恢復的能力，微軟公司的Adams等人[18]提出了3個設計原則來保障云計算系統(tǒng)的可靠性：

1) 彈性設計原則(design for resilience).在不需要人為干預的條件下，云計算服務必須能夠容忍系統(tǒng)組件的失效，它應當能夠檢測到系統(tǒng)中故障的發(fā)生并在故障發(fā)生時自動采取矯正措施，使用戶不會察覺到服務的中斷.當服務失效時，系統(tǒng)也應當能夠提供部分功能，而不是徹底崩潰.

2) 數(shù)據(jù)完整性設計原則(design for data integrity).在系統(tǒng)發(fā)生故障的情況下，服務必須能夠以和正常操作一致的方式操縱、存儲和丟棄數(shù)據(jù)，保持用戶托管數(shù)據(jù)的完整性.

3) 可恢復設計原則(design for recoverability).系統(tǒng)在發(fā)生異常情況時，應該能夠保證服務可以盡可能快地自動恢復過來；而當服務中斷事件發(fā)生時，系統(tǒng)維護人員應該能夠盡可能快地并且盡可能完整地恢復服務.

遵循這些設計原則有助于提高云計算系統(tǒng)的可靠性并降低故障帶來的影響.除了這些原則外，如果某個應用服務實例發(fā)生了失效事件，那么未完成的部分服務和被延遲的服務最終也應該能夠按規(guī)定順利完成.一旦系統(tǒng)發(fā)生了故障，服務提供商或用戶都應該采取合適的措施恢復服務，避免因故障導致的服務性能的下降，同時在服務恢復過程中也應盡可能減少人工干預.

1.3 影響云計算系統(tǒng)可靠性的因素

根據(jù)Javadi等人[19]的總結(jié)，系統(tǒng)失效可以定義為系統(tǒng)不能按照約定的方式繼續(xù)正常運行的事件.當系統(tǒng)偏離了正常功能，就可以認為系統(tǒng)發(fā)生了故障.因此，系統(tǒng)中發(fā)生的故障是影響系統(tǒng)可靠性的主要因素.在云計算系統(tǒng)中，系統(tǒng)資源規(guī)模巨大、體系結(jié)構異常復雜、運行的服務數(shù)量眾多，同時由于各層服務模型之間相互依賴，故障的發(fā)生相比于普通系統(tǒng)更加頻繁.因而，故障是影響云計算系統(tǒng)可靠性的主要威脅.

Fig. 2 Common causes of faults in cloud computing system圖2 云計算系統(tǒng)中常見的故障起因

在軟件測試領域，失效是指軟件在運行過程中出現(xiàn)的一種不希望或不可接受的可觀察到的外部行為.故障是指軟件在運行過程中出現(xiàn)的不希望或不可接受的內(nèi)部狀態(tài)，例如軟件在執(zhí)行過程中進入了錯誤的條件分支，軟件便出現(xiàn)了故障[20].如果沒有恰當?shù)拇胧┨幚砉收希藭r軟件將會出現(xiàn)失效.缺陷是指存在于軟件的程序、數(shù)據(jù)或文檔中的不希望或不可接受的差異，如代碼錯誤.當軟件在某個條件下出現(xiàn)軟件故障，便可以認為軟件中存在缺陷.本文引申軟件測試中的故障定義，將使硬件、軟件等組件或系統(tǒng)的行為發(fā)生失效的不正確狀態(tài)稱為故障，例如內(nèi)存因為讀寫老化使計算機系統(tǒng)不能正常工作，此時可以稱系統(tǒng)中發(fā)生了內(nèi)存故障.

對云計算系統(tǒng)中故障的類型和起因進行概括和總結(jié)可以幫助計算機科學家和工程人員設計可擴展的算法、以可容錯的方式部署基礎設施和軟件服務，這也有助于降低故障的修復代價，并使云計算系統(tǒng)提供更加可靠的服務.本節(jié)總結(jié)了云計算系統(tǒng)中的常見故障以及故障發(fā)生的主要原因.

基于故障的特征，云計算系統(tǒng)中的故障主要可以分為3種類型：資源故障、服務故障和其他故障.資源故障是指物理資源進入了不正確狀態(tài)，如硬件故障、軟件錯誤、電源中斷、網(wǎng)絡中斷等.資源故障既可以發(fā)生在客戶端，也可以發(fā)生在服務提供商端.目前大部分容錯工作主要集中在資源故障上[21-24].云計算系統(tǒng)中的服務故障是指服務提供商不能提供、或用戶不能獲取滿足服務等級協(xié)議(service level agreement, SLA)中規(guī)定服務質(zhì)量的服務.在沒有采取容錯措施時，資源故障通常會導致服務故障，但在物理資源正常運行時，服務故障依然可能會發(fā)生.云計算系統(tǒng)中的其他故障一般是指一些無法預測的由自然或人為原因引起的故障，例如高能粒子、網(wǎng)絡攻擊和人員操作失誤等.為了保證云計算服務的可靠性與可用性，理解故障發(fā)生的原因是非常重要的.圖2總結(jié)了云計算系統(tǒng)中常見的故障起因，主要包括資源故障(如硬件故障、軟件故障、電源中斷和網(wǎng)絡故障)、服務故障和其他因素(如軟錯誤、網(wǎng)絡攻擊和人為因素).

1.3.1 硬件故障

硬件故障是指由于硬件設施如硬盤、內(nèi)存等設備不能正常工作導致的系統(tǒng)失效現(xiàn)象.在數(shù)據(jù)中心發(fā)生的所有故障中，大約50%的故障是由硬件引起的[23].隨著數(shù)據(jù)中心的規(guī)模和使用時間在增加，硬盤故障的發(fā)生頻率也在不斷增長.據(jù)Google發(fā)布的報告稱[4]，硬盤驅(qū)動器和內(nèi)存模塊是2007年修復最普遍的2個模塊.Vishwanath等人[24]的研究表明，在硬件故障中，有78%的故障是由磁盤驅(qū)動器產(chǎn)生的，并且隨著使用時間的增加，硬盤驅(qū)動器故障的發(fā)生次數(shù)呈指數(shù)規(guī)律增長.因此，定期更換磁盤或者使用冗余磁盤陣列可以顯著降低磁盤故障的發(fā)生概率，增加系統(tǒng)的可靠性.

1.3.2 軟件故障

隨著云計算系統(tǒng)中的系統(tǒng)和軟件變得日益復雜，軟件故障已經(jīng)成為了系統(tǒng)崩潰的一個重要原因.軟件故障主要來源于軟件的設計錯誤、更新失敗以及系統(tǒng)重啟可能帶來的功能失效等.在云計算系統(tǒng)中，大約存在40%的服務會由于軟件故障而被中斷[25].2013年10月份，交易算法中的一個錯誤導致Knight Captical公司基于云的股票交易軟件停止運行45 min，給公司帶來了4 400萬美元的經(jīng)濟損失[26].有時候，軟件更新升級過程中的一個不可預期的錯誤，也有可能引起整個系統(tǒng)崩潰.2013年，微軟的云服務因此癱瘓16 h，據(jù)說是因為他們在數(shù)據(jù)中心的某個區(qū)域執(zhí)行防火墻的常規(guī)更新時，某個錯誤導致了整個系統(tǒng)的崩潰[27].另一個服務中斷事例發(fā)生在2015年1月份，微軟的搜索引擎Bing在代碼更新過程中宕機20 min[28].發(fā)生故障后，微軟的回滾機制沒有發(fā)生作用，這使得原來在相關聯(lián)的服務器上的其他服務也被迫關閉.根據(jù)Proffitt[29]的調(diào)查稱，大約20%的重啟會由于數(shù)據(jù)不一致產(chǎn)生失敗事件.當然，軟件中存在的內(nèi)存泄漏、不確定的線程、數(shù)據(jù)誤操作、存儲空間碎片化等原因也可能造成其他的一些系統(tǒng)故障或系統(tǒng)性能下降.

1.3.3 電力故障

在云計算數(shù)據(jù)中心中，大約會有33%的服務會由于電力故障而發(fā)生服務被迫中斷的現(xiàn)象，這在自然災害或戰(zhàn)爭時期很容易發(fā)生.2012年，在云計算數(shù)據(jù)中心中發(fā)生的所有27次主要的電源中斷問題中，有6次是由颶風沙暴造成的[30].2011年，大規(guī)模海嘯使得日本整個國家在很長一段時期內(nèi)都處于電力危機中，并且所有客戶服務都被中斷[31].電力故障的另一個主要原因是不間斷電源系統(tǒng)發(fā)生故障，它造成了大約25%的電力中斷，單次故障會造成大約1 000美元的損失[5].

1.3.4 網(wǎng)絡故障

在分布式計算架構中，尤其在云計算系統(tǒng)中，所有的服務都由通信網(wǎng)絡所支撐，服務器之間所有的信息都經(jīng)過網(wǎng)絡進行交換和存儲.底層網(wǎng)絡的中斷也可能導致云計算服務的中斷.對一些基于云的實時應用來說，網(wǎng)絡的性能通常起到了關鍵的作用.一個很小的網(wǎng)絡擁塞可能引起網(wǎng)絡傳輸延遲，使得系統(tǒng)提供的服務違反服務等級協(xié)議(SLA).在所有的服務故障中，一部分故障是由網(wǎng)絡連接中斷引起的，并且網(wǎng)絡服務的中斷有可能是由物理原因造成的，也有可能是邏輯原因造成的，如加密、帶寬等因素.

1.3.5 服務故障

在云計算系統(tǒng)中，無論是否發(fā)生資源故障，服務故障都有可能會發(fā)生.Dai等人[32]的研究表明，服務故障的發(fā)生與提交作業(yè)所處的階段 (如作業(yè)的請求階段和執(zhí)行階段)是密切相關的.一方面，在作業(yè)的請求階段，用戶提交的含有特定服務需求的作業(yè)都被保存在就緒隊列中.在這個階段中，資源過載 (如服務請求的高峰時間)可能導致服務請求超時，此時用戶會訪問不到服務.在這種情況下，雖然系統(tǒng)底層資源運行良好，但是它們不能完全容納全部的請求，從而導致服務故障的發(fā)生.另一方面，在作業(yè)的執(zhí)行階段，作業(yè)會被提交到底層的物理資源上，因而資源中斷也有會導致服務被中斷.

1.3.6 軟錯誤

隨著CMOS技術的持續(xù)發(fā)展和處理器電壓的不斷調(diào)節(jié)，軟錯誤已經(jīng)成為現(xiàn)代計算機系統(tǒng)的一個重要的關注點[33].由于高能粒子、噪聲和硬件老化等原因，硬件電路中可能會發(fā)生瞬時故障和間歇式故障，這些故障會導致軟錯誤的發(fā)生[34].隨著軟錯誤在整個系統(tǒng)中傳播，它們可能表現(xiàn)為不同形式的系統(tǒng)失效現(xiàn)象，如錯誤的輸出或系統(tǒng)崩潰.在云計算系統(tǒng)級別，這個問題會變得更加嚴重[4,22,35-37]，尤其在由普通商業(yè)計算機構成的云計算系統(tǒng)中[38].研究人員已經(jīng)見證了很多在云中或網(wǎng)格系統(tǒng)中運行科學計算任務產(chǎn)生很高故障率的情況[39-40].盡管不能完全避免系統(tǒng)中產(chǎn)生的軟錯誤，但是系統(tǒng)設計人員可以通過故障預測以及容錯措施來消除軟錯誤給服務帶來的影響.

1.3.7 網(wǎng)絡攻擊

近年來，網(wǎng)絡攻擊成為數(shù)據(jù)中心故障發(fā)生概率迅速增長的主要原因之一.根據(jù)Ponemon研究中心發(fā)布的報告稱，2010年數(shù)據(jù)中心大約有2%的故障是由網(wǎng)絡攻擊造成的，這個比例在2013年增加到18%，2016年的最新數(shù)據(jù)比例為22%[5].由網(wǎng)絡攻擊造成的宕機平均損失為822 000美元[41].IBM針對網(wǎng)絡安全智能的報告稱，55%的網(wǎng)絡威脅都來自于可以訪問系統(tǒng)的人，如企業(yè)的內(nèi)部員工[42].

1.3.8 人為因素

和網(wǎng)絡攻擊一樣，人為因素在云計算系統(tǒng)的故障起因中也占據(jù)了非常大的比重 (22%)，由人為因素引起的故障需要的平均代價為489美元[5].例如，2015年5月由于員工錯誤刪除了生產(chǎn)服務器上的執(zhí)行代碼，攜程旅行網(wǎng)的官網(wǎng)和客戶端應用同時崩潰數(shù)小時.Schroeder和Gibson[43]的研究表明，缺乏經(jīng)驗和操作失誤是人為錯誤發(fā)生的主要原因，并且在云計算基礎設施部署的早期，人為錯誤所占的比重非常大.因此，云計算系統(tǒng)的管理人員獲取更多經(jīng)驗可以有助于降低人為錯誤發(fā)生的概率.

2 云計算系統(tǒng)的可靠性評估

為了保障云計算系統(tǒng)的可靠性，研究人員需要設計適當?shù)姆椒ê筒呗詠硐收蠈ο到y(tǒng)行為的影響.但是在設計具體的方法之前，研究人員首先需要根據(jù)實際需求確定系統(tǒng)可靠性的評估標準.因此，很多學者提出了不同的指標與建模方法來評估云計算系統(tǒng)的可靠性.本節(jié)將從衡量系統(tǒng)可靠性的時間指標、云資源系統(tǒng)的可靠性以及云服務系統(tǒng)的可靠性3個方面來介紹與可靠性評估相關的工作.

2.1 衡量系統(tǒng)可靠性的時間指標

通常情況下，對提供云計算服務的服務提供商而言，可靠性高的云計算系統(tǒng)一般都具有的特點有：故障的發(fā)生次數(shù)少、正常工作時間長、在故障發(fā)生后需要的修復時間短.在長期的工程實踐中，工程人員總結(jié)了3個時間指標來衡量云計算系統(tǒng)可靠性：平均無故障時間、平均故障修復時間和平均故障間隔時間[44]，這些指標體現(xiàn)了系統(tǒng)在規(guī)定時間內(nèi)保持正常運行狀態(tài)的能力.

1) 平均無故障時間

平均無故障時間(mean time to failure, MTTF)是指系統(tǒng)從開始正常工作到故障發(fā)生時所經(jīng)歷的時間間隔的平均值，即系統(tǒng)無故障運行的平均時間.系統(tǒng)的平均無故障時間越長，說明系統(tǒng)的可靠性越高.

2) 平均故障修復時間

平均故障修復時間(mean time to repair, MTTR)是指從系統(tǒng)發(fā)生故障到故障維修結(jié)束并且可以重新正常工作所經(jīng)歷的時間間隔的平均值.系統(tǒng)的平均無故障時間越長，意味著系統(tǒng)的恢復性能越好.

3) 平均故障間隔時間

平均故障間隔時間(mean time between failure, MTBF)是指系統(tǒng)發(fā)生相鄰2次故障所經(jīng)歷的時間間隔的平均值.系統(tǒng)的平均故障間隔時間越長表示系統(tǒng)具有較高的可靠性并且具有較強的正確工作性能.

2.2 云資源系統(tǒng)的可靠性

在云計算環(huán)境中，服務提供商需要管理各式各樣的資源組件，如處理器、內(nèi)存模塊、存儲單元、網(wǎng)絡交換機等.組件越多，云計算系統(tǒng)失效的可能性越大.如果服務提供商了解各種資源組件的失效特征，那么這將可以幫助他們更好地管理計算資源來使系統(tǒng)具備容錯機制并提供高性能服務.文獻[45]分別從軟件組件(包括進程、虛擬機和管理程序)失效和硬件組件(即服務器節(jié)點)失效以及組件失效之間的關聯(lián)關系研究了云計算系統(tǒng)的可靠性.

Fig. 3 Architecture of cloud resource system圖3 云資源系統(tǒng)的架構

文獻[45]中將節(jié)點從第j個節(jié)點被替換或某個虛擬機由于失效而被重啟后到節(jié)點首次發(fā)生故障所經(jīng)歷的時間稱為節(jié)點的無故障時間(time to failure, TTF).文獻[45]中對系統(tǒng)中每個節(jié)點的失效特征的假設為：1)每個節(jié)點的TTF遵循韋伯分布；2)運行在某個虛擬機上進程的TTF遵循指數(shù)分布；3)節(jié)點首次失效會中斷整個應用程序；4)節(jié)點失效后，失效節(jié)點將被新節(jié)點替換，然后系統(tǒng)會被重啟運行.

對于含有n(n=+s+k)個軟件組件(進程、虛擬機和管理程序)的k節(jié)點系統(tǒng)，文獻[45]將系統(tǒng)的可靠性定義為系統(tǒng)在第j次重啟后存活到時刻x的概率并將其表示為Rj(x).Rj(x)的值越大，系統(tǒng)的可靠性越高.由于系統(tǒng)中可能存在多種組件之間的失效組合，文獻[45]首先假設硬件組件失效和軟件組件失效之間相互獨立，然后實際考慮了4種主要情況：

1) 如果軟件組件失效相互獨立，硬件失效也相互獨立，那么云系統(tǒng)的可靠性可以表示為

2) 如果軟件失效不相互獨立，而硬件失效相互獨立，那么云系統(tǒng)的可靠性可以計算為

其中λi,j,…是組件i,j,…的聯(lián)合失效率；γi,j,…是與組件i,j,…相關的聯(lián)合參數(shù).需要注意的是，由于硬件失效獨立性的存在，λi不為0.

3) 如果軟件失效相互獨立，而硬件失效不相互獨立，那么云系統(tǒng)的可靠性可以計算為

4) 如果軟件失效和硬件失效都不相互獨立，那么云系統(tǒng)的可靠性為

由于文獻[45]中的工作假設運行在k個物理服務器上的所有n個軟件組件的失效模式都遵循相同的概率分布，但是這在現(xiàn)實應用場景中是不實際的.云計算系統(tǒng)中存在著新的軟件組件和重用的軟件組件，并且不同的軟件組件是在不同的環(huán)境中被開發(fā)出來的，因此所有n個軟件組件并不會遵循相同的概率分布.因此，文獻[46]在文獻[45]工作的基礎之上對其進行拓展.文獻[46]中假設云計算環(huán)境中的新組件會遵循指數(shù)分布，這些新組件會由于更容易產(chǎn)生bug而更容易失效；而重用的或舊的軟件組件依據(jù)它們的到達時間遵循延遲的指數(shù)分布.

2.3 云服務系統(tǒng)的可靠性

文獻[32]開發(fā)了一個云服務系統(tǒng)，其中包含一個云管理系統(tǒng)(cloud management system, CMS).云管理系統(tǒng)能夠?qū)崿F(xiàn)4種不同的功能：1)管理由來自不同用戶的作業(yè)請求組成的請求隊列；2)管理互聯(lián)網(wǎng)上的計算資源(如個人計算機、集群、超級計算機等)；3)管理網(wǎng)絡上的數(shù)據(jù)資源(如數(shù)據(jù)庫、網(wǎng)頁等)；4)劃分請求為子任務，并將子任務分配到多個可以訪問數(shù)據(jù)資源的不同計算資源上.當某個用戶請求云服務時，CMS系統(tǒng)首先使用工作流來描述云服務包含的子任務、子任務需要的數(shù)據(jù)資源以及資源之間的依賴關系，然后將各個子任務分布到各個可以訪問數(shù)據(jù)資源的計算資源節(jié)點上.

在云服務運行的過程中，存在各種各樣因素會影響云服務的可靠性，具體包括：請求隊列溢出、請求超時、數(shù)據(jù)資源缺失、計算資源缺失、軟件失效、數(shù)據(jù)庫失效、硬件失效和網(wǎng)絡失效.在文獻[32]中，云服務的可靠性被定義為:在特定條件下云服務在用戶指定的時間范圍內(nèi)順利完成的概率.因此，云服務能夠順利完成執(zhí)行的條件為：用戶的作業(yè)請求能及時被調(diào)度器處理、云服務的子任務能順利完成、子任務請求的計算數(shù)據(jù)資源可用、服務運行期間網(wǎng)絡是通暢的.文獻[32]中將服務的失效過程分為：請求階段失效和執(zhí)行階段失效.由于第1種失效發(fā)生在作業(yè)請求被成功分配到計算數(shù)據(jù)資源之前，而第2種失效發(fā)生在作業(yè)請求被成功分配之后、子任務執(zhí)行過程中，所以這2個階段的失效可以是相互獨立的.然而，每個階段中的不同失效是相互關聯(lián)的.因此，云服務可靠性建?？梢员环譃檎埱箅A段可靠性建模與執(zhí)行階段可靠性建模.

假設CMS系統(tǒng)中有S個同構服務器服務用戶的請求，每個服務器處理單個請求的服務時間滿足參數(shù)為μr的指數(shù)分布.在請求階段，用戶會為請求的服務設置一個約束時間，即從提交作業(yè)請求到作業(yè)完成時允許花在該服務上的時間.如果一個作業(yè)請求在約束時間之前沒有被調(diào)度器服務，那么該請求將被丟棄，丟棄率表示為μd；假設請求隊列的容量為N，作業(yè)請求的到達行為遵循到達率為λa的泊松分布.因此，請求隊列可以使用如圖4所示的Markov過程建模，其中狀態(tài)n(n=0,1,…,N)表示請求隊列中請求的數(shù)量.在圖4中，從狀態(tài)n到狀態(tài)n+1的轉(zhuǎn)移概率為λa.當隊列處于狀態(tài)N時，新到達的請求會使請求隊列溢出，因此該請求將被丟棄并且隊列依然處于狀態(tài)N.

Fig. 4 Markov model for the request queue圖4 請求隊列的Markov模型

執(zhí)行階段失效包括數(shù)據(jù)資源缺失、計算資源缺失、軟件失效、數(shù)據(jù)庫失效、硬件失效和網(wǎng)絡失效.由于服務執(zhí)行階段涉及到3種類型的節(jié)點：硬件節(jié)點、軟件節(jié)點和網(wǎng)絡連接節(jié)點.由于與某個子任務相關聯(lián)的所有元素(節(jié)點和鏈路)可以構成一個子任務生成樹(subtask spanning tree, SST)，并且一個SST可以被視為由多個子任務最小生成樹(minimal subtask spanning tree, MSST)組合而成，其中每個MSST表示順利完成這個子任務的最小元素集合(任何一個元素失敗都可能導致子任務失敗).假設第i個元素的失效率為λ(elementi),那么其可靠性為

R(elementi)=exp(-λ(elementi)×Tw(elementi)),

其中,符號Tw(elementi)表示云服務中第i個元素的工作時間.軟件節(jié)點的工作時間為軟件程序在某臺機器上的運行時間，其與軟件程序的工作量和處理器的處理能力相關；網(wǎng)絡連接節(jié)點的工作時間為在某個網(wǎng)絡連接上傳輸數(shù)據(jù)需要的時間，其與傳輸?shù)臄?shù)據(jù)量和網(wǎng)絡帶寬相關；硬件節(jié)點的工作時間為運行在某臺機器上所有軟件程序的工作時間與連接該機器的所有網(wǎng)絡傳輸時間之和.類似于MSST，成功完成某個服務需要的所有元素集合可以表示為最小執(zhí)行生成樹(minimal execution spanning tree,MEST).如果MEST中所有元素都執(zhí)行成功，那么MEST便可以被視為可靠的.MEST可靠性為

Tw(elementi)).

如果某個云服務有N個MEST，那么任意一個MEST的成功執(zhí)行便意味著該云服務在執(zhí)行階段順利完成.因此，執(zhí)行階段的可靠性為

最終，如果云服務的請求階段和執(zhí)行階段都是可靠的，那么該云服務便可以被認為成功執(zhí)行結(jié)束.因此，云服務的可靠性Rservice可以被計算為請求階段和執(zhí)行階段可靠性的乘積：

Rservice=Rrequest×Rexecute.

類似于文獻[32]中的工作，文獻[47]在研究云計算服務系統(tǒng)運行過程的基礎上，將云計算服務系統(tǒng)可靠性定義為云計算系統(tǒng)在給定的條件和規(guī)定時間內(nèi)完成用戶請求的能力.文獻[47]中首先對云計算服務系統(tǒng)分階段建模，包括用戶服務請求達到CMS系統(tǒng)的任務請求階段、調(diào)度系統(tǒng)對服務請求的子任務進行調(diào)度的調(diào)度階段、子任務開始被執(zhí)行到全部完成的執(zhí)行階段，然后建立了云計算服務系統(tǒng)的可靠性模型.

3 云計算系統(tǒng)故障管理技術研究

為了使云計算系統(tǒng)能夠提供可靠的服務，研究人員在設計云計算系統(tǒng)的架構時應該考慮到故障的管理，所有針對運行良好的云計算環(huán)境設計的架構和技術都應當能夠適用于容易發(fā)生故障的云環(huán)境.為了管理云環(huán)境中容易發(fā)生的資源故障以及保證服務的可用性，研究人員已經(jīng)設計了各種技術與方法，使云計算系統(tǒng)在容易發(fā)生故障的環(huán)境中能夠提供可靠的服務.由于云計算使用了面向服務的架構，所有的技術與方法都應該從服務可靠性的角度開始著手設計.如圖5所示，云計算系統(tǒng)中主要的故障管理技術分為3類：故障消除、故障容忍、故障預測與避免.

Fig. 5 Main fault management techniques in cloud computing圖5 云計算中主要的故障管理技術

3.1 故障消除

故障消除技術是運用傳統(tǒng)的軟件測試與驗證方法發(fā)現(xiàn)并移除云計算系統(tǒng)中潛在的故障以提高系統(tǒng)服務可靠性的一種方法，主要針對于云計算中的軟件故障.軟件測試對于移除軟件中的故障、提高系統(tǒng)的容錯能力具有至關重要的作用，通過測試的系統(tǒng)組件通?？梢员徽J為已經(jīng)具備了較高程度的可靠性.文獻[48-49]表明，在分布式環(huán)境中部署軟件之前，如果軟件沒有經(jīng)過充分的測試，也有可能會產(chǎn)生故障，帶來巨大的經(jīng)濟損失.

為了保證軟件系統(tǒng)的可靠性，研究人員已經(jīng)設計了各種各樣的方法和工具來檢測云計算系統(tǒng)中潛在的故障，其中比較典型的一種方法是故障注入.它是一種通過向代碼中引入故障來提高軟件系統(tǒng)測試覆蓋率的軟件測試技術，經(jīng)常和壓力測試一起被用來測試軟件系統(tǒng)的魯棒性.故障注入常被應用在分布式系統(tǒng)部署的早期[50-52]，也可以被用于普通的軟件系統(tǒng)[53].Hoara等人[54]提出了故障注入語言FAIL及其集群版本的故障注入工具FCI，可以用來在分布式應用中進行故障注入.FAIL語言不僅可以讓用戶不再編寫低級代碼，以簡單的方式設計復雜的故障場景；它還可以被用于構造一些概率性場景、確定性場景和可再生場景，讓用戶能夠研究系統(tǒng)在某些特定情景下的行為模式.他們的故障注入工具FCI包含一個編譯器、運行時庫和在分布式應用中進行故障注入的中間件平臺，支持與其他編程語言直接交互，不需要用戶修改應用軟件的源代碼，對應用運行時間的影響特別小.Monnet等人[55]開發(fā)了一個故障注入工具，該工具可以讓開發(fā)者在不改變應用程序代碼的條件下向應用中注入故障.實驗結(jié)果表明，他們的工具能夠以可再生的方式提供精確的控制粒度，發(fā)現(xiàn)大規(guī)模網(wǎng)格環(huán)境中的獨立故障和有依賴關系的故障.

除了故障注入外，研究人員還設計了一些其他的測試技術.Song等人[56-57]利用大量的系統(tǒng)消息流創(chuàng)建系統(tǒng)組件依賴圖，通過分析網(wǎng)格系統(tǒng)來發(fā)現(xiàn)關鍵的hub組件.由于包含故障的hub組件容易影響到整個系統(tǒng)的操作，因而它們具備較高的測試優(yōu)先級，對hub組件進行檢測有助于更快地發(fā)現(xiàn)系統(tǒng)中存在故障的區(qū)域.文獻[58]中利用認證編譯器產(chǎn)生能夠在網(wǎng)格資源中執(zhí)行的機器碼，生成的機器碼中包含了可驗證的子句，它可以在軟件系統(tǒng)的運行過程中自動驗證代碼屬性.該方法不僅能驗證代碼的安全性，也可以檢測系統(tǒng)中的故障和可疑代碼.

文獻[48-58]所述的方法都是利用測試技術對系統(tǒng)進行故障檢測的，它們可以被用于確定哪些系統(tǒng)組件應該被優(yōu)先測試與驗證，以及哪些測試(如組件測試、集成測試、交互測試等)具備更低的測試開銷.因此，以前適用于軟件組件的故障預測研究也可以為識別大規(guī)模云計算系統(tǒng)中的故障可能區(qū)域提供很好的基礎.然而，由于在特別復雜的云計算系統(tǒng)中很難有效地實施故障消除技術，并且虛擬機的失效現(xiàn)象是不可避免的[59]，所以故障消除技術通常也很難完全發(fā)現(xiàn)系統(tǒng)中潛在的故障.因此，和后文中將要提到的故障容忍方法相比，軟件測試與驗證在故障管理中獲得的關注度并不是特別高.

3.2 故障容忍

對云計算系統(tǒng)而言，容錯已經(jīng)成為了數(shù)據(jù)存儲、傳輸和計算必不可少的需求之一.提供數(shù)據(jù)存儲級的容錯相對直接[60]，RAID[61]和Amazon的EBS(elastic block storage)[62]都通過局部冗余存儲來提高磁盤故障的容忍程度.目前復制和檢查點是2種廣泛使用的故障容忍機制[63].糾刪碼[64]作為存儲系統(tǒng)容錯的主要方法受到了越來越多的重視.在數(shù)據(jù)傳輸方面，目前很多知名的網(wǎng)絡協(xié)議都可以通過被重新設計來恢復云計算中的數(shù)據(jù)傳輸錯誤，例如，微軟的云計算服務平臺Azure就使用了基于隊列的消息檢索重傳機制來保證數(shù)據(jù)的傳輸可靠性[65].在云計算系統(tǒng)中，處理計算過程中發(fā)生的錯誤與資源故障和服務故障都有關系.

盡管用戶可以繼續(xù)使用傳統(tǒng)的算法級別容錯方法來處理錯誤[66]，但由于公有云對用戶呈現(xiàn)出不透明性[67]，由云計算服務提供商來提供容錯機制則更加有效.在故障發(fā)生時，云計算系統(tǒng)應當能采取合理的措施讓服務從故障中恢復.目前比較流行的高級容錯措施包括空間冗余和時間冗余.空間冗余的概念可以追溯到3模塊冗余系統(tǒng)(triple modular redundancy, TMR)[68].當空間冗余概念首次出現(xiàn)在云計算環(huán)境中時，模塊便被替換成了虛擬機副本或處于鎖步狀態(tài)的任務副本[69-70].目前，這種實現(xiàn)已經(jīng)被具有高可用性的云計算解決方案所采用，如VMware[71]和VGrADS[72].時間冗余通常會引起任務的重新執(zhí)行.任務在發(fā)生錯誤時可以被重新提交[39,73]，或者回滾到之前的一個正確狀態(tài)并重新執(zhí)行[74].類似地，檢查點方法周期性地將主虛擬機的狀態(tài)保存為1個檢查點，并存儲在另一個虛擬機上，例如，Remus[75]中的虛擬機對就是以leader-follower的方式執(zhí)行的.Kemari[76]和HydraVM[77]是使用虛擬機檢查點的另一個例子.通過故障容忍技術，可以有效地降低硬件故障、網(wǎng)絡故障以及軟錯誤等故障所帶來的影響.表1展示了本節(jié)將要描述的4種容錯技術.

Table 1 Comparison of Four Fault Tolerance Technologies表1 4種容錯技術的對比

3.2.1 糾刪碼

糾刪碼[78]的設計思想是將數(shù)據(jù)對象劃分成若干個數(shù)據(jù)塊，然后在每個數(shù)據(jù)塊中添加額外的信息并對數(shù)據(jù)塊進行編碼.當存儲數(shù)據(jù)塊的某個節(jié)點失效時，利用編碼后的數(shù)據(jù)塊的一個子集便可以恢復出完整的原始數(shù)據(jù)集.通常情況下，糾刪碼可以被描述為三元組(n,k,r)，其中k為編碼前數(shù)據(jù)對象被劃分的塊數(shù),n為編碼后數(shù)據(jù)塊的個數(shù),r為1個不小于k的整數(shù).糾刪碼將k個原始數(shù)據(jù)塊編碼生成n個數(shù)據(jù)塊，其中包含n-k個冗余數(shù)據(jù)塊.因此，編碼后的數(shù)據(jù)具有n-k個數(shù)據(jù)塊的容錯能力，當發(fā)生不多于n-k個數(shù)據(jù)塊損壞或丟失時，我們便可以使用存活的r(r≥k)個數(shù)據(jù)塊修復數(shù)據(jù).下面介紹基于糾刪碼的備份與恢復方案[79].

假設需要存儲的數(shù)據(jù)對象F=(F0,F1,…,Fk-1)可以被劃分成長度固定的k個數(shù)據(jù)塊Fi(0≤i≤k-1)，糾刪碼(n,k,r)將k個原始數(shù)據(jù)塊編碼成n(n>k)個數(shù)據(jù)塊.如果編碼時選擇n個長度為k的向量gi=(gi0,gi1,…,gi(k-1))(0≤i≤n-1)，并且其中任意k個向量都線性無關，那么編碼后的數(shù)據(jù)塊Di(0≤i≤n-1)為

Di=gi·F=gi0·F0+

gi1·F1+…+gi(k-1)·Fk-1.

并且這n個編碼后的數(shù)據(jù)塊中的任意k個都可以被用來重構原始數(shù)據(jù).如果:

G=(gij)(0≤i≤n-1,0≤j≤k-1)，

那么可以得到：

所以1個糾刪碼(n,k,r)可以被表示為D=G·F.其中F=(F0,F1,…,Fk-1)是原始數(shù)據(jù)對象；D=(D0,D1,…,Dn-1)是編碼后的數(shù)據(jù)；G是n×k的矩陣，稱為糾刪碼(n,k,r)的生成矩陣.

需要注意的是：k與n的比值kn稱為該糾刪碼的編碼率；(n-k)k稱為該編碼的冗余度.

糾刪碼冗余機制要求G的任意k行組成的子矩陣G′均可逆，所以使用任意k個數(shù)據(jù)塊都可以重構出原始的k個數(shù)據(jù)塊.除此之外，系統(tǒng)碼的使用使得任何生成矩陣可以通過運算轉(zhuǎn)化為

其中,Ik為k×k的單位矩陣，P為(n-k)×k矩陣.

在所得的編碼數(shù)據(jù)中，其前k位由單位矩陣Ik決定，因而和原始數(shù)據(jù)F中的各位數(shù)據(jù)相同，而其余的n-k位被稱為校驗數(shù)據(jù)，是k個原始數(shù)據(jù)塊的線性組合.

采用這種系統(tǒng)碼編碼數(shù)據(jù)塊時，會生成較多的分塊，這些分塊中不僅包含了數(shù)據(jù)分塊還包含了冗余分塊，這樣數(shù)據(jù)分塊和冗余分塊的數(shù)量便大于原始的數(shù)據(jù)分塊.此時，系統(tǒng)便可以將數(shù)據(jù)分塊和冗余分塊發(fā)送給存儲節(jié)點進行存儲.當用戶讀取數(shù)據(jù)時，只要獲取其中一定數(shù)量的分塊，無論這些分塊是數(shù)據(jù)分塊還是冗余分塊，都可以通過這些分塊重構出原始數(shù)據(jù)對象.由于該算法在生成冗余分塊時引入了糾錯思想，因而其可以極大地避免了恢復數(shù)據(jù)與原始數(shù)據(jù)存在差異或無法重構的現(xiàn)象.

當需要恢復數(shù)據(jù)時，在所有的r(r≥k)個存活數(shù)據(jù)塊中選擇任意k個數(shù)據(jù)塊便可以重構原始數(shù)據(jù).由于生成矩陣中每個行向量都與1個數(shù)據(jù)塊一一對應，當從r個數(shù)據(jù)塊中選取k個數(shù)據(jù)塊進行解碼運算時，這k個數(shù)據(jù)塊對應的行向量可以組成k階方陣Q.如果將這k個數(shù)據(jù)塊記作(R0,R1,…,Rk-1)，Q記作(q0,q1,…,qk-1)，那么Q與原始k個數(shù)據(jù)塊相乘便可以得到這些存活下來的k個數(shù)據(jù)塊，即：

由于生成矩陣中任意k個向量線性無關，即Q可逆，因而使用Q的逆矩陣Q-1便可以計算出原始數(shù)據(jù)F，其計算過程為

在實際應用中，節(jié)點的失效可能引起原始數(shù)據(jù)塊的損壞，也可能引起冗余數(shù)據(jù)塊的損壞.因此，數(shù)據(jù)塊的恢復過程分為2個部分.

1) 原始數(shù)據(jù)塊.在恢復原始數(shù)據(jù)時，使用Q-1中的第i行與R進行數(shù)量積運算，所得的積再做異或運算，即可得到損壞的原始數(shù)據(jù)塊Di(0≤i≤k)：

2) 冗余數(shù)據(jù)塊.恢復由編碼過程生成的冗余數(shù)據(jù)Dk,Dk+1,…,Dn-1時，將編碼矩陣P中對應行Pi與k個數(shù)據(jù)塊進行數(shù)量積運算，所得積再做異或運算，便得到損壞的冗余數(shù)據(jù)塊Di(0≤i≤n-k-1)：

Dk+i=Pi·R=Pi,0·R0⊕Pi,1·R1⊕…⊕Pi,k-1·Rk-1.

使用糾刪碼能夠提供優(yōu)化的數(shù)據(jù)冗余度，防止數(shù)據(jù)丟失，恰當?shù)厥褂眉m刪碼可以提高空間的利用效率并獲得較好的數(shù)據(jù)保護效果.目前該方法在通訊方面已經(jīng)得到了廣泛應用.此外，將糾刪碼引入云存儲系統(tǒng)中代替副本備份策略，可以有效提高云存儲系統(tǒng)的可靠性.但是由于糾刪碼需要存儲額外的冗余數(shù)據(jù)，因而該方法存在一定的存儲空間開銷.

3.2.2 檢查點

檢查點技術(checkpointing)是目前被廣泛使用的一種故障容忍技術.檢查點技術是將正在運行的進程的當前狀態(tài)周期性地保存在某個穩(wěn)定存儲資源上，每次保存的狀態(tài)則稱之為一個“檢查點”.當檢測到任務發(fā)生失效事件時，進程的狀態(tài)會被回滾到最近保存的檢查點狀態(tài)并從該狀態(tài)開始重新執(zhí)行.如圖6所示，在任務的執(zhí)行過程中，每隔一段時間系統(tǒng)會將任務的狀態(tài)保存為一個檢查點，在相鄰檢查點之間的時間間隔叫做檢查點區(qū)間(checkpoint interval).當一個檢查點區(qū)間結(jié)束時，系統(tǒng)會使用某種錯誤檢測技術檢查任務的執(zhí)行是否正確.當檢測到任務的狀態(tài)發(fā)生錯誤時，任務會被回滾到臨近的一個檢查點狀態(tài)并重新執(zhí)行從該檢查點開始的檢查點區(qū)間內(nèi)的工作.由于檢查點技術能夠?qū)⑷蝿諒腻e誤狀態(tài)中恢復過來，目前已經(jīng)有很多云計算管理套件整合了檢查點機制來提供不中斷的云計算服務，如Oracle的UniCloud，Intel的數(shù)據(jù)中心管理器(data center manager, DCM)等.基于檢查點的工作原理，檢查點技術可以被分為3種類型：非一致性檢查點、一致性檢查點和通信引導的檢查點[80].

Fig. 6 Fault management using checkpoints圖6 使用檢查點進行故障管理

非一致性檢查點允許屬于同一應用程序的每個進程自主決定何時執(zhí)行檢查點操作.由于每個進程可以相互獨立地在不同時刻執(zhí)行檢查點操作，因而這種方式的優(yōu)點是進程執(zhí)行檢查點操作具有較大的自由度，不需要受到其他進程狀態(tài)的限制.但是這種方式也存在諸多缺點，其中最大的一個缺點便是多米諾效應.當一個進程執(zhí)行回滾操作時，之前接受過這個進程發(fā)送消息的進程也需要回滾.如果這些被迫回滾的進程之前也發(fā)送過消息，那么它們的回滾必然又會引起其他進程進行回滾.此時，系統(tǒng)就發(fā)生了多米諾效應，使得很多進程都做了無用功，甚至可能回歸到計算的起點.此外，由于非一致性檢查點迫使每個進程維護多個檢查點，因而這種方式需要進程周期性地進行垃圾收集回收無用的檢查點.

在一致性檢查點中，同一應用程序的進程之間需要同步檢查點來確保每個進程保存的檢查點相互一致，并且所有的檢查點合并起來也需要形成一致的全局狀態(tài).一致性檢查點的恢復過程相對容易，每個進程總是從最近的檢查點重新執(zhí)行，因此該方法不易受到多米諾效應的影響.此外，一致性檢查點要求每個進程在穩(wěn)定存儲上只需要存儲一個持久檢查點，因而它可以顯著降低存儲開銷，也不需要進行垃圾收集.然而，一致性檢查點的主要缺點是系統(tǒng)提交輸出時會產(chǎn)生很大的延遲.

在通信引導的檢查點中，它不需要同步所有的檢查點，因而可以避免多米諾效應.在這個協(xié)議中，進程會執(zhí)行2種檢查點：局部檢查點和強制檢查點.進程可以獨立地、有選擇地執(zhí)行局部檢查點，但是必須執(zhí)行強制檢查點來保證恢復過程的一致性.

文獻[81]表明，在容易發(fā)生故障的環(huán)境中，不采用檢查點技術時成功完成某個任務所需的時間遠大于采用檢查點技術時完成該任務所需要的時間.雖然檢查點技術能夠保證云計算服務的可靠性，但值得注意的是，由于在穩(wěn)定存儲介質(zhì)上保存檢查點需要一定的時間，因此應用檢查點技術必然會帶來一些時間開銷[82].Fu[22]的實驗表明，在像云計算這樣的大規(guī)模系統(tǒng)中，頻繁地應用檢查點機制會帶來巨大的額外開銷.據(jù)估計，在千萬億次操作的系統(tǒng)中，1個100 h的作業(yè)會花費約150 h的檢查點創(chuàng)建開銷[21]；相反，如果降低使用檢查點技術的頻率，那么在程序發(fā)生故障后重新執(zhí)行又會增加程序的總執(zhí)行時間.因此，如何確定最優(yōu)檢查點區(qū)間并減少檢查點開銷已經(jīng)成為眾多研究人員的研究目標[83-84].例如，為了優(yōu)化云計算環(huán)境中的檢查點重啟機制，Di等人[85]首先設計了一個計算公式為具備不同失效事件分布的云作業(yè)計算最優(yōu)檢查點數(shù)量；然后設計了一個自適應算法優(yōu)化檢查點帶來的各種影響，如檢查點開銷、重啟開銷等；最后他們在Google系統(tǒng)的運行數(shù)據(jù)上評估了他們的方法，實驗結(jié)果表明他們的方法可以降低任務的執(zhí)行時間平均達50～100 s.由于云計算底層計算基礎設施具備動態(tài)性，科學工作流系統(tǒng)中經(jīng)常會發(fā)生任務執(zhí)行延遲的現(xiàn)象，導致大量的時序違反事件發(fā)生.對時序違反事件進行處理會消耗大量的時間，因此必須采取合理的措施，在滿足時序一致性要求的同時，盡可能降低不必要的時序違反事件處理開銷.Liu等人[86]發(fā)現(xiàn)，通常情況下，在某個檢查點處檢測到的時序違反事件帶來的時間赤字是非常小的，而工作流后續(xù)活動的盈余時間(時序約束和執(zhí)行時間之間的時間差)基本可以彌補該時間赤字，他們將這種現(xiàn)象命名為“自動恢復”.例如工作流中的某個任務由于時序違反產(chǎn)生10 s的時間赤字，但是很有可能該任務后面的任務會產(chǎn)生10 min的平均冗余時間，那么這些冗余時間便可以用來彌補該任務的時間赤字.基于這個發(fā)現(xiàn)，他們提出了一個自適應的時序處理點選擇策略，它只選擇關鍵的而非所有的檢查點作為處理點來解決時序違反問題.仿真實驗表明，他們的方法可以在滿足時序一致性和成本高效的條件下，顯著避免不必要的時序違反事件的處理開銷.

3.2.3 復制

復制(replication)是提供系統(tǒng)容錯能力的另一種故障管理技術，這種方法使用多個計算資源同時運行同一任務的多個進程副本并維持相同的狀態(tài).根據(jù)副本的更新方式，復制策略可以分成2種類型：主從復制和主動復制.如圖7(a)所示，在主從復制中，客戶端僅僅將請求發(fā)送給主副本，只有主副本會處理用戶請求.主副本在處理完成用戶的請求后，會將其狀態(tài)轉(zhuǎn)發(fā)給所有從副本并通知它們更新狀態(tài)，在所有從副本完成狀態(tài)更新并向主副本發(fā)送確認消息后，主副本向客戶端發(fā)送反饋.如圖7(b)所示，在主動復制中，客戶端會將請求發(fā)送給所有副本，所有副本在接收到請求后都會執(zhí)行請求.在客戶端接收到所有副本的第1個響應后，可以繼續(xù)處理其他的事務.

Fig. 7 Replication technology圖7 復制技術

目前已經(jīng)有許多云計算服務提供商使用復制機制來提供不同級別的容錯保障.微軟的Azure云計算平臺使用虛擬機副本來提供虛擬機級別的容錯.當虛擬機發(fā)生故障時，Azure總是使用副本虛擬機來接管發(fā)生故障的虛擬機，繼續(xù)執(zhí)行故障虛擬機中正在運行的任務.在基礎設施即服務級別，Open-Stack云計算平臺將文件和對象分布在不同數(shù)據(jù)中心的多個服務器的磁盤上，使用數(shù)據(jù)副本來保證數(shù)據(jù)的可靠性.在Apache Hadoop，Amazon的EBS等DFS系統(tǒng)中也應用了資源復制來保證系統(tǒng)的可靠性.此外，還有很多應用復制機制的其他例子，例如Benoit等人[87]提出了一個容錯調(diào)度算法，該算法基于資源復制策略，致力于在不增加應用延遲時間的條件下，將有依賴關系的多個任務映射到異構系統(tǒng)中，并使其能夠容忍多次處理器失效.為了考慮任務之間的通信競爭并保證具有依賴關系的一組任務的執(zhí)行可靠性，Benoit等人[88]又提出了一個競爭感知的容錯調(diào)度算法，該算法使用了任務復制策略，在不犧牲任務總執(zhí)行時間的情況下能夠容忍多次處理器失效.Wang等人[89]提出了RMSR(replication-based scheduling for maximizing system reliability)算法，它將任務通信整合到系統(tǒng)可靠性中，使用任務復制技術在異構系統(tǒng)中進行可靠性感知的任務調(diào)度.為了最大化通信可靠性，他們提出了一個算法為當前任務搜索具有最優(yōu)可靠性的所有通信路徑，在任務復制階段，由用戶決定任務的可靠性閾值并確定每個任務的動態(tài)副本.實驗結(jié)果表明，他們的方法能夠顯著提高系統(tǒng)的可靠性.

雖然應用復制技術可以保障云計算服務可靠性，但是它對計算資源、存儲資源的需求較高，同時存在存儲效率低下的缺點.目前，應用該技術存在諸多挑戰(zhàn)，其中最大的3個挑戰(zhàn)為：1)設計算法確定副本的最優(yōu)放置策略以達到最佳的容錯效果；2)設計方法同步副本狀態(tài)，保持副本之間的狀態(tài)一致性；3)降低副本數(shù)量，減少維護可靠性需要的成本.這3個問題都是開放性研究問題，很多學者就此提出了各種各樣的解決方案.

1) 副本選擇與放置.在應用復制技術時，由于每個進程或數(shù)據(jù)選擇副本數(shù)量的不同以及每個副本在不同計算資源上的放置方式，對復制技術能夠?qū)崿F(xiàn)的容錯效果和該技術能獲得的存儲空間利用率具有很大的影響.因此，該問題要求設計合適的副本選擇算法與最優(yōu)放置策略以達到最佳的容錯效果、實現(xiàn)最高的資源利用率.文獻[90]嘗試對在動態(tài)分布式系統(tǒng)中進行副本放置的自適應算法的容錯能力及可擴展性等屬性進行評估.Weissman等人[91]設計了一個副本管理系統(tǒng)，它可以基于用戶的需求動態(tài)地分配副本資源.當某個副本失效時，用戶的資源請求可以被系統(tǒng)透明地重新路由，測試實驗驗證了他們方法的有效性.文獻[92]提出了一個SRIRAM研究系統(tǒng)，它可以在網(wǎng)格系統(tǒng)和分布式系統(tǒng)中自動對計算資源進行備份，提高計算資源的可用性和容錯能力.Valcarenghi等人[93]提出了一個服務復制方法，他們首先讓副本之間相互臨近形成網(wǎng)絡中的服務島，然后使用混合整數(shù)規(guī)劃評估不同的復制配置來決定哪種服務島配置具備較高的容錯能力.仿真實驗表明，這種方法能夠發(fā)現(xiàn)長距離的服務間連接，降低了副本的需求量，同時也簡化了副本的管理.文獻[94]提出了一個用于通信公司內(nèi)的計算網(wǎng)格資源分配系統(tǒng)，該系統(tǒng)使用動態(tài)進程復制來提供容錯能力，滿足服務等級協(xié)議.在e -Demand項目中，Townend等人[95]提出了一個基于復制的方法來檢測由多個任務組成的工作流中的錯誤計算，一個工作流會在多個服務副本上同時執(zhí)行，同時，該方法還使用一個投票過程來選擇哪個副本集合應該將結(jié)果返回給用戶.實驗表明，該方法可以顯著提供工作流的容錯能力.Genaud等人[96]為基于MPI的網(wǎng)格環(huán)境設計了一個容錯機制，它使用資源復制來提高并行環(huán)境的容錯能力，實驗表明這種方法具備非常好的可擴展性.

2) 副本同步.在大規(guī)模計算環(huán)境中，應用復制技術需要保持不同副本狀態(tài)的一致性.然而，副本同步會產(chǎn)生巨大的額外開銷.因此，研究人員需要設計合適的方法同步副本狀態(tài)，在保持副本之間的狀態(tài)一致性的同時，降低副本同步帶來的開銷.當前有很多研究嘗試解決在云計算中應用復制機制帶來的副本一致性問題[83-84]，其中比較典型的算法有Paxos算法[97]和Raft算法[98].Raft算法比Paxos算法更容易理解和實現(xiàn).這2種算法都可以被用來在分布式環(huán)境中同步副本間的狀態(tài)，它們無論在局部環(huán)境中還是在廣域網(wǎng)環(huán)境中都展示出了較好的性能.Zhang等人[99]基于主從復制方法在多個主機上復制服務，構建可靠的、高可用的網(wǎng)格服務.他們的方法能夠在局部環(huán)境中保證較高的服務可用性，但是為了同步服務副本間的狀態(tài)進行開放網(wǎng)格服務基礎設施(open grid service infrastructure, OGSI)通知所產(chǎn)生的額外開銷也是非常可觀的.Dasgupta等人[100]提出了一個框架將冗余副本資源的預留整合到服務等級協(xié)議中，當主副本失效時允許程序切換到從副本繼續(xù)運行.仿真實驗表明這個方法可以提高系統(tǒng)資源分配的效率.

3) 副本數(shù)量的確定.在云計算系統(tǒng)中，雖然采用復制策略能夠提高云服務的容錯能力，但過多的副本會增加云服務的成本.因此副本數(shù)量與成本之間的折中也是采用復制技術時應該考慮的問題.研究人員需要設計副本管理策略，降低副本數(shù)量，減少維護可靠性需要的成本.為了在減少云存儲消耗的同時滿足數(shù)據(jù)中心數(shù)據(jù)可靠性要求，Li等人[101]提出一個成本高效的數(shù)據(jù)可靠性管理機制PRCR，該方法通過主動檢測副本的狀態(tài)來減少副本的數(shù)量，可以在保證數(shù)據(jù)可靠性的同時，降低存儲成本.Amazon云也提供了低冗余存儲選項[102]，讓客戶以較低的冗余級別來存儲非關鍵性的可再生數(shù)據(jù).

3.2.4 重新調(diào)度

除了應用檢查點和復制策略，一個失敗的任務可以使用不同的資源進行重新調(diào)度.如圖8所示，當檢測到任務產(chǎn)生錯誤時，調(diào)度程序使用額外的計算資源重新提交并執(zhí)行任務，因此重新調(diào)度可以有效地避免檢查點和副本同步帶來的開銷.然而，重新調(diào)度技術也必然會引起調(diào)度結(jié)果的延遲.文獻[103]提出了一個框架，通過資源的有效監(jiān)控和作業(yè)執(zhí)行狀態(tài)的跟蹤，在任務失敗時做出高效的調(diào)度策略，該框架能夠在具備高度動態(tài)性的環(huán)境中以容錯的方式完成任務的執(zhí)行.重新調(diào)度在某些情況下被認為是一種可行的容錯機制，但是，由于重新調(diào)度會產(chǎn)生額外的延遲，它可能會影響工作流中與之并發(fā)執(zhí)行的任務或工作流中依賴于它的其他任務的執(zhí)行過程.或許正是由于這個原因，這個技術一直沒有成為被廣泛研究的焦點.

Fig. 8 Fault management using rescheduling mechanism圖8 使用重新調(diào)度機制進行故障管理

3.3 故障預測與避免

由于故障容忍技術存在巨大的存儲和計算開銷并且實現(xiàn)方式非常復雜，云服務提供商已經(jīng)開始采用故障預測與避免機制來保障云服務的可靠性.故障預測與避免機制會在故障發(fā)生之前采取預防措施避免故障的發(fā)生.

故障預測與避免機制的性能主要依賴于對故障發(fā)生的正確預測[104-105]，基于故障預測的結(jié)果，故障避免機制會采取合理的措施預防故障.例如，系統(tǒng)可以將正在運行的進程從可疑的資源上遷移到正常的資源上以保證服務可以不被中斷地運行.因此，對故障進行精確的預測可以使故障管理更加高效且可靠.遷移是配合故障預測的被廣泛使用的一種容錯方式.隨著高速網(wǎng)絡和分布式架構的發(fā)展，遷移正在運行的任務已經(jīng)變得可行.隨著云計算的出現(xiàn)，遷移主要可以分為進程遷移[106]和虛擬機遷移.考慮到云計算基礎設施的動態(tài)性，在云計算中主要采用虛擬機遷移來保障服務的可靠性.

4 云計算可靠性與能耗的權衡問題

在第3節(jié)中，我們已經(jīng)討論了很多可以用來保證云計算系統(tǒng)可靠性的技術，這些技術已經(jīng)被證明是高度優(yōu)化且非常高效的[82].它們通過使用存儲資源來存儲日志或檢查點，或者使用額外的計算資源重新執(zhí)行任務片段，讓系統(tǒng)在發(fā)生故障或服務被中斷時恢復到最近的正確狀態(tài).因此，這些技術都或多或少地增加了計算資源或存儲資源的冗余程度.通過使用這些技術，云計算服務提供商聲稱他們可以在大于99.99%的時間內(nèi)提供可靠的服務[107]，即每年只允許大約52.6 min的服務中斷時間.然而，增加額外資源必然會增加系統(tǒng)的能耗、降低服務提供商的收益，并會給環(huán)境帶來負面的影響.隨著資源冗余程度的增加，云計算系統(tǒng)的可靠性得到提高，而系統(tǒng)的能效則迅速下降.因此，研究人員在為云計算系統(tǒng)設計可靠性保障措施時也應考慮可靠性與能耗的權衡問題.

當前，云計算數(shù)據(jù)中心的資源利用率僅為6%～12%，較低的資源使用率導致系統(tǒng)消耗了較高的電能[108].然而，在應用或任務被提交之前，精確地預測它們的資源需求是非常困難的，有可能會存在過度供給或過少供給的現(xiàn)象.因此，根據(jù)應用的需求，精確地供給資源可以使云計算服務更加可靠與節(jié)能.由于能耗管理機制能夠通過對系統(tǒng)可靠性和硬件資源的管理來降低系統(tǒng)的能耗，所以很多學者采用能耗管理機制對云計算系統(tǒng)的可靠性與能耗進行折中.

目前被用來降低系統(tǒng)能耗的方法主要有能耗感知的資源調(diào)度或任務調(diào)度、硬件節(jié)能技術等.在資源過度供給的情況下，通過資源調(diào)度或任務調(diào)度可以降低系統(tǒng)能耗和其他操作開銷.

為了在多用戶公有云系統(tǒng)中進行能耗感知的容錯調(diào)度，Gao等人[109]提出了一個統(tǒng)一的資源分配與容錯調(diào)度框架.該框架包含2種調(diào)度：靜態(tài)調(diào)度和動態(tài)調(diào)度.靜態(tài)調(diào)度首先為每個用戶分配足夠的虛擬機資源，保證用戶的任務能夠在規(guī)定的截止時間內(nèi)完成；接著為每個用戶的應用選擇合適的錯誤檢測機制與容錯方法(即確定副本因子)，保證應用具備較高的容錯確信度；最后將用戶的任務副本映射到具體的物理服務器上，獲得一個臨時調(diào)度.為了應對云計算系統(tǒng)的運行時變化，動態(tài)調(diào)度通過任務遷移保證用戶應用能夠在規(guī)定時間內(nèi)完成.他們的框架能夠使云服務提供商在可靠性、性能和能耗3個因素之間進行權衡，在保證所有用戶的應用程序滿足截止時間約束的前提下，最小化系統(tǒng)全局能耗，并獲得較高的故障覆蓋率和容錯確信度.

Faragardi等人[110]從服務的截止時間角度考慮服務質(zhì)量，提出了一個基于整數(shù)線性規(guī)劃的數(shù)學模型來調(diào)整云計算系統(tǒng)的可靠性和能耗.利用這個模型，他們提出了一個基于帝國競爭算法[111]的群體智能資源調(diào)度算法以故障感知和節(jié)能的方式分配資源.和混合遺傳算法相比，他們提出的方法可以降低能耗達17%，提供系統(tǒng)可靠性達9%.

Diouri等人[112]從能耗的角度評估了檢查點協(xié)議和一致性與非一致性容錯協(xié)議.對非一致性協(xié)議而言，日志可以保存在HDD(hard disk drive)中，也可以保存在RAM(random access memory)中.文獻[112]經(jīng)過實驗表明，使用RAM保存日志消耗的能耗要低于使用HDD保存日志消耗的能耗，因而在大規(guī)模分布式系統(tǒng)中使用RAM存儲日志要優(yōu)于基于HDD的消息日志協(xié)議.對于一致性協(xié)議而言，它的能耗模式和非一致性協(xié)議的能耗模式類似，只是一致性協(xié)議的能耗會依賴于進程的協(xié)調(diào)過程.較差的同步過程則意味著更長的協(xié)調(diào)過程以及更多的能耗消耗.因此，減緩最快速進程的執(zhí)行過程可以顯著降低系統(tǒng)的能耗.

虛擬機遷移和任務合并是降低云計算系統(tǒng)能耗的關鍵技術：系統(tǒng)可以將使用率較低的服務器上運行的虛擬機遷移到其他主機上或者通過任務合并來使利用率較低的資源進入休眠模式或關閉狀態(tài).然而，隨著虛擬機合并和任務遷移頻率的增加，雖然系統(tǒng)的能耗會被降低，但是頻繁地進行虛擬機遷移或任務合并也會影響到系統(tǒng)的可靠性.Choi[113]從虛擬機布局的角度提出了一種考慮節(jié)能和服務器可靠性的虛擬機放置算法.該算法在最小化服務器消耗功率的同時避免虛擬機的密集放置而導致的熱島，從而提升服務器可靠性.Zhou等人[114]提出了一種虛擬機放置策略——最優(yōu)冗余虛擬機布局(optimal redundant virtual machine placement, OPVMP).該方法在滿足k-容錯(k-fault-tolerance)約束下，當主虛擬機故障需要遷移至備份虛擬機時，最小化網(wǎng)絡資源的開銷.

此外，動態(tài)電壓和頻率調(diào)節(jié)(dynamic voltage and frequency scaling, DVFS)作為一種非常高效的功耗管理技術，已經(jīng)被廣泛用在數(shù)據(jù)中心中來降低服務器的能耗.然而，使用DVFS降低處理器的執(zhí)行頻率，會不可避免地增加處理器發(fā)生瞬時故障(即軟錯誤)的概率，從而降低服務器系統(tǒng)的可靠性.因此，對大規(guī)模異構計算系統(tǒng)如云計算數(shù)據(jù)中心而言，高可靠性和低能耗是服務提供商應當考慮的2個目標.為了在異構集群中降低有依賴關系的任務集的能耗并最大化其可靠性，Zhang等人[115]提出了3個算法：RHEFT(reliability-aware heterogeneous earliest finish time)，RCPOP(reliability-aware critical-path-on-a-processor)，RMEC(reliability maximization with energy constraint).這3個算法都具有3個階段：確定任務優(yōu)先級、處理器頻率選擇、任務到處理器的映射.在確定任務優(yōu)先級階段，計算有向無環(huán)圖中所有任務的拓撲順序和優(yōu)先級并將任務放入一個優(yōu)先級隊列中.在處理器頻率選擇階段，在考慮任務集可靠性的前提下，為優(yōu)先級隊列中的每個任務確定最優(yōu)的執(zhí)行頻率和電壓.在任務到處理器的映射階段，算法利用基于HEFT算法[116]的改進算法將每個任務分配到不同的處理器上.通過仿真實驗結(jié)果表明，RMEC算法在可靠性和能耗指標上明顯要優(yōu)于其他2種算法.盡管文獻[115]對有向無環(huán)圖的任務集使用DVFS技術時可以保證應用具備較高的可靠性，但是RMEC算法并沒有考慮故障發(fā)生情況下的容錯問題.與之不同，Li等人[117]也使用DVFS技術降低實時應用執(zhí)行的頻率、最小化應用消耗的電能.他們利用檢查點技術在任務之間的松弛時間內(nèi)重新執(zhí)行任務，保證應用的可靠性.他們提出的方法能夠在保證實時應用的可靠性與截止時間要求的情況下，最小化系統(tǒng)的能耗.與Li等人的工作類似，Wu等人[118]通過任務調(diào)度將DVFS技術應用于工作流應用的執(zhí)行過程.當處理器發(fā)生瞬時故障時，他們的方法可以使用檢查點與回滾-恢復技術重新執(zhí)行任務片段.該方法可以在同時滿足截止時間與可靠性約束的條件下，最小化工作流應用消耗的電能.

5 云計算可靠性面臨的挑戰(zhàn)

云計算由于能夠以“按需使用，按使用量付費”的方式向用戶提供動態(tài)可擴展的服務，其已經(jīng)成為了備受關注的一種計算模式.當前，存在著非常多的新應用已經(jīng)基于云計算被開發(fā)和部署，并且有越來越多的應用程序正在被從傳統(tǒng)的計算平臺上遷移到基于云計算的平臺上.未來，隨著科學技術的進一步發(fā)展，云計算技術的應用也必將更加廣泛.然而，由于云計算基于虛擬化技術實現(xiàn)，并且其具有多租戶、規(guī)模巨大和體系結(jié)構復雜等特性，精確地管理云計算系統(tǒng)中的軟硬件資源存在非常大的難度.同時，信息安全、邊緣計算等技術的發(fā)展以及它們與云計算的深度融合，也給云計算的可靠性帶來了諸多挑戰(zhàn).綜合來看，未來云計算可靠性的研究工作可以分別從5個方面繼續(xù)展開：

1) 虛擬化技術在硬件資源失效場景下的服務可靠性問題.虛擬化技術是云計算得以實現(xiàn)的關鍵.通過虛擬化技術，云計算平臺可以向用戶提供隔離的虛擬機，虛擬機之間相互獨立，一個虛擬機的失效并不會影響到其他虛擬機的正常運行.因此，當某個虛擬機失效時，服務提供商可以很容易地使用另一臺虛擬機來替換失效的虛擬機，使失效虛擬機上運行的應用服務可以不被中斷地運行.在硬件資源失效時，為了保持用戶虛擬機的正確運行狀態(tài)，服務提供商也需要將虛擬機從異常主機遷移到正常主機上.然而，虛擬機的替換和遷移過程必將會影響虛擬機中服務的運行可靠性.如何在硬件資源失效時不降低虛擬機中應用服務的可靠性是目前存在的一個挑戰(zhàn).

2) 系統(tǒng)可靠性引發(fā)的信息安全問題.隨著云計算市場的持續(xù)快速增長，用戶對云計算的依賴程度也在逐漸增加，越來越多的用戶將個人數(shù)據(jù)放到云中.但是由于用戶對云計算系統(tǒng)的管控能力較弱，用戶對云中的個人數(shù)據(jù)保護能力不足.同時，云計算系統(tǒng)中存在的漏洞也給系統(tǒng)攻擊者提供了訪問他人隱私數(shù)據(jù)的機會，網(wǎng)絡入侵很可能會導致大范圍的安全問題和服務隱患.因此，如何通過提高云計算系統(tǒng)可靠性來保障用戶的信息安全，已經(jīng)成為云計算服務提供商面臨的一大挑戰(zhàn).在未來的研究工作中，研究人員應該投入更多的精力保證云計算系統(tǒng)的可靠性，避免可靠性問題帶來的信息安全問題.

3) 可靠性導致服務成本增長的問題.為了提高云計算系統(tǒng)提供的服務的可靠性，很多服務提供商采用冗余資源來提高服務對故障的容錯能力.雖然冗余資源的增加可以顯著提高服務的可靠性，但是它也相應地增加了系統(tǒng)提供服務需要付出的成本.這不僅會增加用戶的使用云計算服務需要付出的費用，還可能會降低服務提供商的收益率.因此，在研究如何提高系統(tǒng)可靠性的同時，設計合理的資源分配策略來降低云計算服務的使用成本也是未來研究人員需要考慮的問題.

4) 可靠性導致服務性能下降的問題.為了提高云計算系統(tǒng)對系統(tǒng)中故障的容忍程度，目前幾乎所有的數(shù)據(jù)中心都具備容錯能力.在系統(tǒng)或服務發(fā)生故障時，系統(tǒng)管理程序利用容錯措施將系統(tǒng)或服務從故障中恢復過來.但是，在處理故障保證服務可靠性的過程中，用戶服務的性能必然會受到影響，例如，在虛擬機執(zhí)行用戶任務的過程中使用檢查點機制雖然可以增加任務的容錯能力，但是它也會增加任務的完成時間，影響用戶的滿意程度.因此，如何在保證用戶服務可靠性的同時降低容錯機制對服務性能的影響也是云計算研究面臨的一大挑戰(zhàn).未來，研究人員在設計容錯措施時，應該仔細地考慮到恢復過程對服務性能的影響，在提高服務的可靠性的同時，保障服務的高效性.

Fig. 9 Integration of cloud computing, fog computing and Internet of things圖9 云計算、霧計算和物聯(lián)網(wǎng)深度融合

5) 云計算、霧計算和物聯(lián)網(wǎng)深度融合場景中的可靠性問題.隨著物聯(lián)網(wǎng)的持續(xù)深度發(fā)展，智慧城市、智能家庭等物聯(lián)網(wǎng)應用在可預見的未來將會極大地豐富人們的生活.但是目前市場上的各種智能終端設備的計算資源、存儲資源有限，智能程度普遍不能令用戶滿意.云計算由于具有無限的資源、方便的使用模式，很自然地成為了給物聯(lián)網(wǎng)中大量終端設備提供智能的首要選擇.然而，云計算由于以集中式的方式提供大量資源，具有網(wǎng)絡延遲高、網(wǎng)絡擁塞和可靠性較低等不足，并不適用于對實時性、可靠性要求較高的物聯(lián)網(wǎng)應用場景.為了彌補云的不足、滿足未來應用的需求，人們在這種背景下提出了霧計算[119].如圖9所示，作為云計算的一種延伸，霧計算使用邊緣網(wǎng)絡中數(shù)量龐大的霧節(jié)點(即專門部署的本地服務器或已經(jīng)部署在網(wǎng)絡中的路由器、交換機、網(wǎng)關等)，彌補單一物聯(lián)網(wǎng)設備的不足.然而，霧中設備相對分散、中心控制困難，而且霧節(jié)點的資源相對受限、節(jié)點間協(xié)調(diào)困難，這些限制都會對霧計算提供的服務的性能產(chǎn)生很大影響.如何在云計算、霧計算和物聯(lián)網(wǎng)深度融合的場景中保證應用服務的可靠性是未來的一項重要研究工作.

6 總 結(jié)

云計算作為一種新型計算模式，能夠為用戶提供高度可擴展的計算服務，已經(jīng)吸引了學術界和工業(yè)界的廣泛關注.然而，隨著云計算數(shù)據(jù)中心的規(guī)模、復雜度不斷增加，云計算系統(tǒng)的運行故障也日益頻繁，可靠性問題已經(jīng)成為制約云計算技術發(fā)展的一大挑戰(zhàn).本文以云計算的故障為主線，介紹了云計算中常見的故障，并詳細介紹了云計算中關鍵的提高可靠性的3類故障管理技術：故障消除、故障容忍和故障預測與避免.其中故障消除技術主要采用軟件測試和驗證技術，針對于云計算中的軟件故障；故障容忍技術又包括糾刪碼、檢查點、復制和重新調(diào)度等，通過增加時間或空間的冗余提高系統(tǒng)的容錯能力，可以有效地降低硬件故障、網(wǎng)絡故障和軟錯誤等故障帶來的影響；故障預測與避免機制基于故障預測的結(jié)果，采取合理的措施預防故障.

由于引入故障管理技術，不可避免地提高了云計算系統(tǒng)的能耗，因此云計算系統(tǒng)可靠性和能耗的權衡問題成為當下的研究熱點之一.目前被用來降低系統(tǒng)能耗的方法主要有能耗感知的資源調(diào)度或任務調(diào)度、硬件節(jié)能技術等.

除此之外，如何解決提高系統(tǒng)可靠性帶來的成本增長和服務性能下降問題、如何發(fā)現(xiàn)和預防提高系統(tǒng)可靠性而帶來的潛在的信息安全問題都將會是很大的挑戰(zhàn).同時，如何在硬件資源失效時不降低虛擬機中應用服務的可靠性也是目前存在的一個挑戰(zhàn).在未來，隨著云計算與邊緣計算、物聯(lián)網(wǎng)等新興技術與云計算的深度融合，云計算可靠性將會迎來更多、更大的挑戰(zhàn).