【中雲網獨家】 作者:陳懷臨 中雲網首席顧問
摘要:
雲計算在被越來越多的個人和企業所採用, 但人們對於雲計算服務在安全性, 可靠性和服務回應確定性方面的擔憂也與日俱增. 雖然雲服務提供者(Clouds Service Provider) 通常都會承諾SLA(Service Level Agreement)的可用性(Availability)範圍等, 但許多雲租戶不理解可用性的內在複雜性, 因此在選擇雲平臺時缺乏對風險進行評估的能力. 本文首次系統的定義和分析了雲計算可用性的演算法模型, 特別是對雲計算的IaaS, PaaS和SaaS各個層次可用性的內在關係展開定性討論. 文章的最後, 針對2008年到2012年以來AWS被外界所報導過的服務事故做了相應的統計調查和一些定量分析.
1. 雲計算的挑戰:
雲服務在被越來越多的企業所採用. 據Gartner預測, 2013年公有雲的市場份額將會以8%的增長率從2012年的1110億美金增長至1310億美金, 如圖1所示.
圖1 公有雲服務市場和年增長率
在IaaS(Infrastructure as a Service)方面, 增長速度為47.3%, 市場份額為90億美金. 2012年, IaaS增長了42.4%. 2016年, 公有雲的市場大小會達到2100億美金, 增長率為17.7%, 而在IaaS方面會保持41.3%的增長率[1].
然而, 隨著大量中小型企業的CIO在考慮把公司的資料和應用遷移到雲計算平臺上, 伴隨而來的是對雲計算的服務品質(Quality of Service)的擔憂.
UCBerkeley電腦系RAD實驗室的Michael Armbrust等在2009年2月發表了關於對雲計算服務的論文--「Above the Clouds:A Berkeley View of Cloud Computing」. 文中Berkeley提出了其理解的雲計算概念模型, 並提出了雲服務必須克服的10大障礙[2], 如圖2所示.
圖2 Berkeley的雲計算模型
在這10大障礙中, 1(Availability of Service), 2(Data Confidentiality and Auditability), 5(Performance Unpredictability), 6( Scalable Storage), 7(Bugs in Large-Scale Distributed Systems), 8(Scaling Quickly) 都與雲計算品質緊密相關. Berkeley在對可用性(Availability)的解釋中, 還特別提到了DDoS攻擊對雲計算帶來的危害和需要防範的措施.
另外, 據來自Newvem的調查資料包告, 有35%的亞馬遜的AWS使用者對宕機基本上沒有防範措施; 40%的AWS使用者沒有定期做資料的備份. TeamQuest最近對許多企業的CIO做了一次調查, 接受調查的的CIO有40%的表示他們在使用雲計算的時候發生了機群宕機現象[3].
2012年, 許多著名的公有雲計算資料中心都發生了重大的安全事故.下面是一些典型的案例[4][5]:
*2012年2月29日和7月26日, 微軟的Azure發生事故, 時間分別為長達9個小時和2.5個小時, 許多北美和歐洲的使用者無法正常管理和使用其公司正常業務, 有的徹底丟失了他們最新的資料.
* 2012年6月14日, 6月29日, 10月22日和耶誕節期間的12月24日, 亞馬遜AWS發生了嚴重雲服務緩慢和崩潰無法訪問的問題, 影響的租戶包括許多重要的互聯網公司, 例如Netflix, pInterest, twitter , Instagram等等[4]. 每次事故導致使用者無法正常使用服務的時間長達9個小時和更多.
* 2012年7月10日, 著名的SaaS(Service as a Service)公司Salesforce的服務出現重大停頓. 其原因是提供Salesforce公司IaaS服務的公司(Equinix)的資料中心電源失效. Equinix據說在1分鐘內就恢復了電源. 但Salesforce花費了接近9個小時來完整的恢復其相關業務.
* 2012年9月10日, 著名的DNS服務提供者GoDaddy的資料中心服務暫停. GoDaddy管理著接近5千萬個功能變數名稱和5百萬個WEB網站. 這次服務無法正常使用長達7個小時. 其原因被解釋為路由器的資料被破壞. 也有媒體報導是GoDaddy遭遇到了強大的DDoS攻擊. 但這一聲稱被GoDaddy否認.
* 2012年10月26日, 谷歌的App Engine雲服務出現暫停, 時間長達4個小時. 事後谷歌沒有發表具體原因解釋.
* 2012年10月26日, 著名的雲存儲供應商Dropbox的服務出現暫停, 時間長達10個小時. 其具體原因不詳.
由上可見, 伴隨著雲計算本身具備的無可爭議的巨大價值, 雲計算帶來的諸多服務品質問題也正變得越來越明顯.
因此對雲計算的可用性的定性和定量分析逐漸變為一個兼有研究和工程價值的問題. 有助於説明CIO們評估一個雲計算平臺.
目前學術和工業界對雲計算, 特別是公有雲的可用性方面還沒有引起足夠的重視. 缺乏這方面的定性和定量分析工作.
本文首次系統的定義和分析了雲計算可用性的演算法模型, 特別是對雲計算的IaaS, PaaS和SaaS各個層次可用性的內在關係展開定性討論. 文章的最後, 針對2008年到2012年以來AWS被外界所報導過的服務事故做了相應的統計調查和一些定量分析.
2. 雲計算可用性(Cloud Computing Availability)
雲計算可用性是一個很廣義的概念. 本文定義雲計算可用性如下:
雲計算可用性: 包括IaaS, PaaS和SaaS各個層面服務的連接, 可靠性, 延時, 資料洩露和丟失, 網路攻擊以及其他任何意外而導致租戶的業務不能滿足期望, 或者更嚴重的業務完全暫停. 雲服務商通常是通過SLA(Service Level Agreement) 來量化可用性的承諾, 給出相應的Availability的數值範圍, 例如,99.9%或者99.99等等.
按照雲計算層次的分類[6], 我們認為雲計算的Availability(簡稱AvailabilityCS) 包括IaaS的Availability(AvailabilityIaaS), PaaS的Availability( AvailabilityPaaS)和SaaS的Availability (AvailabilitySaaS).
我們認為, 使用者最終感知的的雲計算的可用性是與雲計算3個層面的可用性緊密相關的.
在下面小節中, 我們首先來形式化定義一個雲計算服務的可用性並做相應的演算法討論. 然後, 對雲計算分層模型中IaaS, PaaS和SaaS在可用性之間的關係做理論探討.
2.1 可用性
假定在一個採樣時間範圍(例如時間 T小時內)服務發生的不可用(Unavailable)次數是N. 每次不可用之前正常運行的時間定義為TBFi(Time Before Failure). 每次用來恢復服務正常運行的時間定義為TTRi(Time To Repair).
圖3 雲計算服務的可用性
由圖3可知, 在採樣時間T範圍內, 服務的可用性為:
因此, 我們推匯出在時間T小時裡, 雲服務的可用性為:
其中:
MTBFT: 在時間T內, 雲服務的Mean Time Before Failure[7].
MTTRT: 在時間T內, 雲服務的Mean Time To Repair[8].
根據公式1, 我們可以定義一個雲服務在基於採樣週期T下, 時間跨度為K下的Mean Time Availability(MTA)為:
假設一個雲服務的SLA取樣時間T是每天, 或者說24個小時. 如果考察7224個小時的MTA, 根據上述公式, 其MTA計算方法為:
(責任編輯:蒙遺善)