在10月22日(上周一),Amazon云服務AWS東部地區又出宕機問題,對Reddit, Airbnb, Flipboard, GetGlue, Coursera等多家知名網站造成了影響,不過在受到影響區域以外的EC2和EBS都顯示正常,客戶還可以進行遷移。此次事件的陰霾還未散盡,在10月26日(上周五),Google App Engine宕機,10月30日,蘋果iCloud也出現了一點點小麻煩。作為云計算行業的領軍人物,三巨頭最近的日子都不是太順。不過這也側面反映了云計算對我們生活、工作的影響力越來越大。
亞馬遜宕機事件
盡管2011年亞馬遜AWS也出現了一些問題,但遠遠沒有2012年這么頻繁。從之前6月份由于電力系統的故障,進而影響了AWS的客戶之后,在7月份因為雷擊再次造成數據中心宕機,又影響了一批客戶的正常使用,此次事件發生之后,AWS官方網站對本次宕機事件做出了解釋,而且告訴用戶AWS正在做的工作,以防止未來再次發生類似的問題。
周一 10:00 AM PDT:美國東部地區的亞馬遜彈性塊存儲(EBS)的性能發生下降,在某些情況下,無法進一步處理I / O請求。問題的根源是運行在EBS存儲服務器上的數據收集代理有一個潛在的Bug。每一個EBS存儲服務器的代理都關聯著一組數據收集服務器和用來維護的報告信息。該數據收集系統的數據是非常重要的,但是對時間卻不敏感,因為該系統的設計僅僅容忍延遲或者丟失的數據。
上周,該地區的一個數據收集服務器因為硬件故障被換下。不過替換該服務器部分的一個DNS記錄已更新,刪除了故障服務器并且添加來了替換服務器。不過在那個時候沒有注意到,DNS更新沒有成功地傳播到所有的內部DNS服務器之上,結果,存儲服務器的一小部分并得到沒有更新的服務器地址,而且繼續嘗試聯系原來的數據收集服務器。但是由于設計的數據收集服務容忍丟失數據,顯然這并不會造成任何直接的問題而且沒有發出何報警。然而,因為無法聯系到的數據收集服務器,存儲服務器上的報告代理引發了潛在的內存泄漏錯誤:報告代理并沒有處理連接失敗的問題,而是繼續以嘗試聯系數據收集服務器的方式,慢慢地消耗系統內存。
盡管AWS監控著每個EBS服務器的總內存消耗,但是監控系統沒有對此內存的泄漏進行報警。而且EBS服務器動態地使用所有的可用內存用于管理客戶數據,因此很難對內存的使用和釋放內存進行準確的警報設置。星期一早上,內存消耗的速度已經非常高了,直接影響到存儲服務器,它們無法跟上正常的請求處理。
到目前為止,亞馬遜已經部署了監測預警系統,對內存泄漏問題進行重點關注。與此同時,也修正了EBS存儲服務器上的系統內存監控,從而保證對每個進程的內存消耗進行監控和預警,AWS還將部署資源限制,以防止低優先級的進程消耗過多的主機資源。很關鍵的部分,AWS更新了內部的DNS配置,以進一步確保DNS的信息更改被可靠的傳播,最重要的是,確保AWS的監管的完善性,這些行動完全解決了引發這次事件的問題。此外,AWS正在評估在事件的迅速惡化之前,如何更改EBS故障轉移邏輯。亞馬遜相信,他們有能力作出調整,從而減少任何類似的相關EBS服務器故障或退化的影響。
亞馬遜在最后表達了深深的歉意:“給您帶來不便以及造成的影響,我們深表歉意。我們知道AWS服務對客戶業務來說是多么的重要,我們將會更加努力的工作,從本次事件中認真吸取教訓,我們看到先前的改變也減輕了本次事件一些影響,而且我們也了解了新的故障模式,在未來的日子里,我們會花很多時間改善我們的服務。”
在亞馬遜宕機事件發生后,一位國外網友打趣說:亞馬遜又宕機了呀,為什么亞馬遜不把Amazon.com放在自己的云服務器上呢?另一位專業網友則在網上留言指責亞馬遜無法提供風險預警服務,導致大量網站屢次在毫無征兆的情況下經歷長時間的宕機,給網站造成重大損失。
為什么亞馬遜頻頻出現這么多問題,我們依然還會選擇它?因為我們知道,AWS目前是最好的云服務,對于大多數用戶來說,無論他們遭受到了多么嚴重的影響,他們還是會選擇亞馬遜,因為亞馬遜幫助他們用較少的成本和精力運營著一個強大的基礎架構。許多人在批評亞馬遜之前都會首先感謝亞馬遜幫助他們做到的事情。因為到目前為止,還沒有一家公司能夠取代亞馬遜!我們也很欣喜地看到OpenStack的蓬勃發展,但是在商用平臺始終還是一大軟肋,目前絕對不是亞馬遜的對手。 上一頁1 23 下一頁
推薦閱讀
光棍節促銷期間,天貓商城以當日銷售132億元的成績(未包括淘寶數據),位居各類電商企業首位。 11月12日,天貓商城、蘇寧易購、國美網上商城等電商企業公布光棍節促銷數據。這組堪稱亮麗的數據顯示,光棍節促銷期間>>>詳細閱讀
本文標題:盤點亞馬遜、谷歌、蘋果云端宕機背后故事
地址:http://www.xglongwei.com/a/guandian/yejie/20121229/110681.html