基于檢驗(yàn)點(diǎn)技術(shù)的云服務(wù)可靠性度量模型

何 利，趙志元

(重慶郵電大學(xué)計(jì)算機(jī)學(xué)院，重慶 400065)

0 引言

近年來，計(jì)算系統(tǒng)的應(yīng)用速度已經(jīng)快速發(fā)展并呈爆發(fā)趨勢。計(jì)算系統(tǒng)應(yīng)用提供商為了向用戶提供一個安全穩(wěn)定的使用環(huán)境，必須確保計(jì)算系統(tǒng)在任何時間都保持高的服務(wù)質(zhì)量(quality of service，QoS)以滿足客戶的需求。當(dāng)前計(jì)算系統(tǒng)的主要模式是云計(jì)算［1］，云計(jì)算本質(zhì)上就是基于行業(yè)領(lǐng)先技術(shù)搭建的，集硬件、軟件、網(wǎng)絡(luò)基礎(chǔ)設(shè)施、數(shù)據(jù)中心為一體的應(yīng)用導(dǎo)向性的服務(wù)平臺，它將企業(yè)的各類信息化需求按功能拆分成不同的模塊，以標(biāo)準(zhǔn)化組件的形式集成在這一平臺之上。云計(jì)算所提供的應(yīng)用服務(wù)均通過互聯(lián)網(wǎng)提供給使用者，“云”中的資源對使用者來說可以隨時獲取、按需使用、隨時擴(kuò)展、按使用付費(fèi)。服務(wù)可靠性是云服務(wù)的關(guān)鍵點(diǎn)，但是很多云服務(wù)事故說明云計(jì)算提供的服務(wù)并不都是絕對安全可靠的:如亞馬遜云計(jì)算數(shù)據(jù)中心故障和香港昂平360纜車故障。同時云用戶并不是都對同一個服務(wù)可靠性級別表示滿意，根據(jù)統(tǒng)計(jì)［2］，45%的云用戶對99.9%的云服務(wù)可靠性滿意，即每個月云平臺可能會發(fā)生45 min的非計(jì)劃性當(dāng)機(jī);14%的云用戶愿意為99.99%(即每個月只發(fā)生大約4 min的非計(jì)劃性當(dāng)機(jī))的服務(wù)可靠性多支付至少25%的費(fèi)用;6%的云用戶則愿意為99.999%及其以上的云服務(wù)可靠性多支付至少50%的費(fèi)用。因此，云平臺的服務(wù)可靠性應(yīng)該作為一種彈性服務(wù)向顧客提供，給予用戶更多的付費(fèi)選擇，那么建立云服務(wù)可靠性的量化模型就是當(dāng)前云計(jì)算進(jìn)一步市場化的必要研究內(nèi)容。

云平臺中，計(jì)算資源(如計(jì)算節(jié)點(diǎn)、通信鏈路、軟件系統(tǒng)等)出現(xiàn)故障失效是客觀存在的，檢驗(yàn)點(diǎn)技術(shù)是當(dāng)前云計(jì)算平臺中為了有效提高服務(wù)可靠性的典型技術(shù)，其中，檢驗(yàn)點(diǎn)的設(shè)置頻率成為影響云服務(wù)可靠性的重要因素。本文利用效用優(yōu)化的檢驗(yàn)點(diǎn)設(shè)置頻率模型，建立了有限云計(jì)算資源下的云服務(wù)可靠性量化模型，然后，對模型進(jìn)行了正確性推導(dǎo)和性能分析，發(fā)現(xiàn)當(dāng)檢驗(yàn)點(diǎn)設(shè)置頻率呈指數(shù)增長時，其可靠性將更好。最后，對全文工作進(jìn)行了總結(jié)。

1 云服務(wù)和檢驗(yàn)點(diǎn)技術(shù)

云服務(wù)是一種特殊的服務(wù)模式，區(qū)別于其他的分布式計(jì)算服務(wù)系統(tǒng)。本文首先研究了云服務(wù)的特點(diǎn)和檢驗(yàn)點(diǎn)技術(shù)。

1.1 云服務(wù)是一種彈性服務(wù)

2006年，亞馬遜公司最早提出了彈性云［3］的概念:認(rèn)為用戶可以根據(jù)需要購買云計(jì)算的服務(wù)，尤其是服務(wù)可靠性。云計(jì)算時代，云服務(wù)的可靠性全部依賴于云。云計(jì)算通過計(jì)算資源池化，使得計(jì)算資源并不依賴于單一系統(tǒng)的高可靠性，通過集群技術(shù)，保證系統(tǒng)整體服務(wù)的高可靠性。根據(jù)數(shù)據(jù)統(tǒng)計(jì)［4］，國內(nèi)采用容錯技術(shù)的云系統(tǒng)服務(wù)提供商尚沒有國外的1/3。云服務(wù)的可靠性一直作為一個固定參數(shù)向用戶提供并不能使所有用戶滿意，對于云服務(wù)提供者來講，數(shù)據(jù)中心的資源也沒有得到最大化利用。對于用戶來講，當(dāng)前云服務(wù)的可靠性要么太高，要么太弱(比如銀行等需要實(shí)時準(zhǔn)確的云服務(wù))。用戶的云服務(wù)需求才是云服務(wù)市場得以發(fā)展的基礎(chǔ)，因此，滿足用戶的個性化需求應(yīng)該是云服務(wù)的基本目標(biāo)，根據(jù)用戶的需求提供相應(yīng)級別的服務(wù)可靠性則是云服務(wù)市場繼續(xù)擴(kuò)大化的必然發(fā)展方向。所以，云服務(wù)的可靠性必須作為一種彈性服務(wù)向用戶提供。在上述分析的基礎(chǔ)上，可以得到的結(jié)論是對云服務(wù)可靠性進(jìn)行建模度量，找出影響云服務(wù)可靠性的關(guān)鍵因素是非常有必要的。

1.2 檢驗(yàn)點(diǎn)技術(shù)

系統(tǒng)的可靠性主要依賴于容錯技術(shù)的應(yīng)用。檢驗(yàn)點(diǎn)技術(shù)［5］是一種利用檢驗(yàn)點(diǎn)回卷恢復(fù)機(jī)制來減少計(jì)算故障損失的典型技術(shù)。應(yīng)用程序周期性的設(shè)置檢驗(yàn)點(diǎn)，當(dāng)因故障原因發(fā)生計(jì)算節(jié)點(diǎn)故障失效時，可以從最近的正確檢驗(yàn)點(diǎn)通過回卷方式從失效點(diǎn)恢復(fù)。因此，檢驗(yàn)點(diǎn)技術(shù)經(jīng)常運(yùn)用到分布式系統(tǒng)和高性能計(jì)算中作為系統(tǒng)計(jì)算失效的容錯技術(shù)，以此來提高系統(tǒng)服務(wù)的可靠性。當(dāng)前許多采用檢驗(yàn)點(diǎn)的容錯方法都來源于 Chandy和 Lamport開創(chuàng)性的工作［6-7］，常用的檢驗(yàn)點(diǎn)技術(shù)有順序檢驗(yàn)點(diǎn)技術(shù)和分叉檢驗(yàn)點(diǎn)技術(shù)2種。順序檢驗(yàn)點(diǎn)中設(shè)置檢驗(yàn)點(diǎn)的時間開銷和檢驗(yàn)點(diǎn)延遲是一致的，當(dāng)應(yīng)用程序想要設(shè)置一個檢驗(yàn)點(diǎn)時，它會暫停程序的執(zhí)行并把其當(dāng)前計(jì)算狀態(tài)保存在安全的存儲空間中，當(dāng)狀態(tài)保存完后進(jìn)程會繼續(xù)執(zhí)行。因此，保存檢驗(yàn)點(diǎn)需要的時間實(shí)際上和執(zhí)行程序增加的時間開銷相同，即保存檢驗(yàn)點(diǎn)的延遲時間等于程序增加檢驗(yàn)點(diǎn)后的時間開銷。這種機(jī)制獲得了最小的檢驗(yàn)點(diǎn)延遲開銷，然而，在帶寬有限的情況下，保存檢驗(yàn)點(diǎn)的延遲時間相對就變大了。在本文中，我們選擇了順序檢驗(yàn)點(diǎn)技術(shù)，因?yàn)樵诋?dāng)前的云計(jì)算平臺中，任務(wù)計(jì)算資源節(jié)點(diǎn)間的通信鏈路帶寬是完全可以得到保證的，所以，順序檢驗(yàn)點(diǎn)的延遲開銷因?yàn)閹挼南拗贫龃蟮膯栴}就不存在了。

在當(dāng)前典型的云計(jì)算平臺中，一個專門的虛擬機(jī)管理系統(tǒng)對其管轄的所有的虛擬機(jī)狀態(tài)進(jìn)行檢查，并負(fù)責(zé)把任務(wù)分配到計(jì)算資源池的相應(yīng)計(jì)算資源節(jié)點(diǎn)中，當(dāng)一個任務(wù)的所有計(jì)算節(jié)點(diǎn)完成計(jì)算后，由該管理系統(tǒng)對計(jì)算結(jié)果進(jìn)行合并并反饋給用戶。當(dāng)某個任務(wù)在執(zhí)行過程中發(fā)生了計(jì)算節(jié)點(diǎn)資源故障失效后，該任務(wù)的正確計(jì)算可以從檢驗(yàn)點(diǎn)回卷后恢復(fù)。

2 云服務(wù)可靠性度量模型

云計(jì)算平臺中，系統(tǒng)分配給任意任務(wù)i的計(jì)算資源存在故障的可能性是客觀存在的。因此，為了客觀的描述在故障客觀存在的情況下云服務(wù)的可靠性度量模型，本文對基于檢驗(yàn)點(diǎn)技術(shù)的云服務(wù)可靠性模型進(jìn)行了研究，并考慮了各種可能的故障情況。

2.1 模型假設(shè)

在云服務(wù)系統(tǒng)中，計(jì)算資源因?yàn)楦鞣N原因引起的故障都會影響分配任務(wù)的計(jì)算可靠性。在任務(wù)執(zhí)行的過程中，一旦計(jì)算資源(計(jì)算節(jié)點(diǎn)、通信鏈路、軟件等)發(fā)生故障，任務(wù)i的服務(wù)可靠性可能會受到影響。檢驗(yàn)點(diǎn)回卷技術(shù)可以采用一定的時間開銷使得云服務(wù)的可靠性得到提高。在當(dāng)前的云計(jì)算平臺中，任務(wù)的計(jì)算節(jié)點(diǎn)都是用計(jì)算虛擬機(jī)實(shí)現(xiàn)的?；谏鲜銮疤?，作出如下假設(shè)和定義:

①在云服務(wù)系統(tǒng)中，負(fù)責(zé)任務(wù)分配的虛擬機(jī)管理者是可靠的;

②由虛擬機(jī)管理者分配的任務(wù)計(jì)算資源節(jié)點(diǎn)之間是相互獨(dú)立的;

③在任務(wù)i計(jì)算的過程中，各種類型的計(jì)算資源故障之間是相互獨(dú)立的;

④計(jì)算資源故障都是可以通過檢驗(yàn)點(diǎn)回卷技術(shù)進(jìn)行修復(fù)的。

定義1 可靠性。計(jì)算資源在一定時間一定條件下完成特定任務(wù)的概率。(參考了ISO8402和英國標(biāo)準(zhǔn)BS4778)，用可靠性R(t)來表示。其他變量定義如表1所示。

表1 可靠性度量模型定義Tab.1 MAIN NOTATION

假設(shè)云計(jì)算環(huán)境中任意節(jié)點(diǎn)的故障率為λ，因此，一個虛擬機(jī)節(jié)點(diǎn)的平均故障時間是1/λ。虛擬機(jī)管理系統(tǒng)任意任務(wù)i分配給k個虛擬機(jī)節(jié)點(diǎn)，任務(wù)k的平均故障時間為1/kλ。當(dāng)虛擬機(jī)管理系統(tǒng)收到了任務(wù)i的計(jì)算資源請求后，對任務(wù)i的請求立即進(jìn)行資源分配k個虛擬機(jī)計(jì)算節(jié)點(diǎn)，并在執(zhí)行任務(wù)i時在相應(yīng)的時間間隙設(shè)置檢驗(yàn)點(diǎn)。當(dāng)虛擬機(jī)管理系統(tǒng)通過虛擬鏡像比對發(fā)現(xiàn)分配給任務(wù)i的某個計(jì)算資源發(fā)生故障導(dǎo)致計(jì)算失效后，用了Tr的時間開銷對任務(wù)i進(jìn)行回卷恢復(fù)到最近一次正確的檢驗(yàn)點(diǎn)位置。檢驗(yàn)點(diǎn)設(shè)置和回卷過程如圖1所示。

圖1 任務(wù)i檢測點(diǎn)和恢復(fù)模型Fig.1 Task i checkpoint and recovery model

2.2 可靠性度量模型

在本文中我們假設(shè)Tr是一個時間常數(shù)，根據(jù)假設(shè)，分配到k個計(jì)算節(jié)點(diǎn)的任務(wù)i在經(jīng)歷了h－1個檢驗(yàn)點(diǎn)設(shè)置后發(fā)生了計(jì)算資源故障，因此，我們可以得到任務(wù)i在計(jì)算過程中云平臺提供的服務(wù)故障概率密度函數(shù)即Weibull分布，其中，α=1。

在此基礎(chǔ)上我們可以計(jì)算出當(dāng)經(jīng)歷個h－1個檢驗(yàn)點(diǎn)設(shè)置后，任務(wù)i的計(jì)算資源節(jié)點(diǎn)可能會在2個時間點(diǎn)發(fā)生故障:①在第h個(0，Tc，i)時間期間發(fā)生故障;②在第 h 個(Tc，i，Tm，i)時間點(diǎn)內(nèi)發(fā)生故障。因此，我們可以計(jì)算子任務(wù)i在虛擬機(jī)節(jié)點(diǎn)k上執(zhí)行的總時間TA。

在第1種情況下:

(2)—(3)式中:TA，h－1表示故障發(fā)生前任務(wù) i的執(zhí)行時間;T1A，h，T2A，h分別表示在第 1，第 2 種情況下故障發(fā)生前任務(wù)i已經(jīng)執(zhí)行的時間。

基于以上分析，在云用戶提出了具體的云服務(wù)請求并且成功得到了所需計(jì)算資源后，在檢驗(yàn)點(diǎn)技術(shù)下的任務(wù)i在k個虛擬機(jī)計(jì)算節(jié)點(diǎn)上產(chǎn)生故障的時間分布函數(shù)(連續(xù)變量)為

根據(jù)(5)式和(6)式，我們可以得到關(guān)于任務(wù)i的可靠度度量函數(shù)R(t)。

3 度量模型分析

3.1 度量模型正確性分析

3.2 度量模型性能分析

在前面的可靠性模型中，我們把檢驗(yàn)點(diǎn)之間的時間間隔考慮為一個常數(shù)，但是在實(shí)際系統(tǒng)中，通過對故障數(shù)據(jù)進(jìn)行分布擬合和擬合優(yōu)度發(fā)現(xiàn)檢驗(yàn)點(diǎn)之間的時間間隔設(shè)置不可能是常數(shù)。因此，為了更加真實(shí)的刻畫實(shí)際系統(tǒng)的檢驗(yàn)點(diǎn)機(jī)制。我們對任務(wù)i的檢驗(yàn)點(diǎn)設(shè)置頻率進(jìn)行了更加細(xì)致的研究。在每一個恢復(fù)重啟的過程中，可以用Wj，i表示任務(wù)i在第j次失敗故障之間的時間間隔。

(7)式中:N(t)= ∫ton(t)dt為檢驗(yàn)點(diǎn)設(shè)置頻率函數(shù)。根據(jù)參考文獻(xiàn)［8］中回卷恢復(fù)過程理論，任務(wù)i由故障失效導(dǎo)致的時間開銷應(yīng)該為E(Wj，i)的最小值，由此可以得到一個基于恒定Tc，i的周期指數(shù)增長函數(shù)，當(dāng)檢驗(yàn)點(diǎn)間隔頻率按指數(shù)分布時R(t)可以達(dá)到最優(yōu)。

4 結(jié)論

云計(jì)算服務(wù)可靠性是其典型特性之一，本文在基于檢驗(yàn)點(diǎn)回卷策略分析的基礎(chǔ)上，建立了適用于云服務(wù)系統(tǒng)特點(diǎn)的云服務(wù)可靠性度量模型，并對該模型的正確性進(jìn)行了推導(dǎo)證明。在此模型的基礎(chǔ)上，進(jìn)一步研究了影響實(shí)際系統(tǒng)可靠性的檢驗(yàn)點(diǎn)設(shè)置頻率問題，理論證明了科學(xué)的檢驗(yàn)點(diǎn)設(shè)置頻率，對提高云服務(wù)的可靠性有著積極的意義，對云服務(wù)系統(tǒng)的設(shè)計(jì)推廣有著一定的實(shí)用性。

［1］HOFER C N，KARAGIANNIS G.Cloud computing services:taxonomy and comparison［J］.Journal of Internet Services and Applications，2011，2(6):81-94.

［2］MISHRA A K，HELLERSTEIN J L，CIRNE W，et al.Towards Characterizing Cloud Backend Workloads:Insights from Google Compute Clusters［J］.SIGMETRICS Perform Eval Rev，2010，(3)37:34-41.

［3］Amazon.We Promise Our EC2 Cloud Will Only Crash Once A Week［EB/OL］.(2008-08-23)［2012-11-01］.http://articles.businessinsider.com/2008-10-23/tech/30005168_1_amazon-s-ec2-erp-system-uptime.

［4］VMware.Protecting Mission-Critical Workloads with Vmware Fault Tolerance［EB/OL］.(2009-02-24)［2012-11-01］.http://www.vmware.com.

［5］CHANDY K M，BROWNE J C，DISSLY C W，et al.Analytic Models for Rollback and Recovery Strategies in Data Base Systems［J］.IEEE Trans Software Eng，1975，(1)1:100-110.

［6］PLANK J S，BECK M，KINGSLEY G，et al.Libckpt:Transparent Checkpointing under Unix［C］//Proc.Usenix Winter 1995 Technical Conf，New Orleans:［s.n.］，1995，1:213-223.

［7］BADRINATH R，KRISHNAKUMAR R，RAJAN R.Virtualization aware job schedulers for checkpoint-restart［C］//Proceedings of 13th International Conference on Parallel and Distributed Systems(ICPADS07).［s.l.］:conference publication，2007(2):1-7.

［8］ROSS S M.Stochastic Processes［M］.American:Wiley，2004.

［9］LIN J F.Performance analysis and discussion on a heuristic approach for scheduling multiprocessor tasks in a grid computing environment［J］.International Journal of Innovative Computing，Information and Control，2010，16(12):5451-5462.