AWS宕機11個小時,都是光纖被挖斷惹的禍?
原創(chuàng)【51CTO.com原創(chuàng)稿件】2019年6月2日凌晨兩點開始,AWS北京區(qū)域出現大面積癱瘓,據稱是因為CN-NORTH-1地區(qū)有多處光纜在夜晚道路施工中被切斷,導致該區(qū)域的***個可用區(qū)中EC2實例不能訪問,同時不能在整個CN-NORTH-1區(qū)域中新建EC2實例。
Amazon Elastic Compute Cloud(Beijing)的處理進展如下:
02:38,我們正在調查CN-NORTH-1的網絡連接問題。
04:17,我們正在調查CN-NORTH-1的所有可用區(qū)的EC2 API錯誤率上升的問題以及啟動新的EC2實例失敗的問題。我們也在調查CN-NORTH-1區(qū)域EBS API的錯誤率上升和延遲增大的問題。
06:36,我們已經找到了CN-NORTH-1區(qū)所有可用區(qū)中EC2 API和EBS API錯誤率上升的問題,以及新的EC2實例啟動失敗的問題的原因,我們正在修復這個問題。
09:27,我們已經確定了CN2-NORTH-1區(qū)域內所有可用區(qū)域內新EC2實例的EC2和EBS API錯誤率增加以及啟動失敗的原因,并正在努力解決問題。因為網絡連接導致無法成功完成Runlnstances API請求,將影響CN-NORTH-1所有區(qū)域。對其中一個可用區(qū)中的現有運行實例沒有任何影響。
14:56,在北京時間,2:00AM到13:48PM之間,在CN-NORTH-1區(qū)域,客戶遇到在所有區(qū)域中EC2 API調用失敗率增高以及無法新建實例的故障,目前故障已經解決,服務恢復正常。
回顧去年的AWS故障事件:3月,亞馬遜AWS網絡服務出現問題,故障時間不詳。5月,北弗吉尼亞地區(qū)的數據中心出現硬件故障,AWS再次出現連接問題,持續(xù)時間30分鐘。7月,AWS管理控制臺故障,故障持續(xù)近6小時。11月,AWS韓國服務器中斷,故障時間持續(xù)一個多小時。相比之下,此次的從2點到14點,11個多小時的故障不得不稱為最近AWS宕機事件中的大事。
AWS此次的恢復時間為什么長達11個多小時?這不得不讓人聯(lián)想到AWS沒有做好網絡冗余設計。網絡冗余設計主要通過重復設置網絡鏈路和網絡設備冗余措施,并制定網絡重要系統(tǒng)和數據備份策略等。網絡鏈路冗余指為了確保業(yè)務正常運轉,除配置主線路外,同時做好第二種、第三種線路的部署。
據悉,AWS北京區(qū)域使用的是光環(huán)新網的數據中心,該公司在北京擁有酒仙橋、太和橋、光環(huán)新谷、東直門、房山和亦莊6個數據中心,每個都擁有高達100G的BGP總出口帶寬,多運營商通信鏈路。光環(huán)新網并未對此事作出回應。
正值6.18中國電商大促階段,不僅亞馬遜中國官網(www.amazon.cn)的頁面一度崩潰,VIPKID、流利說、三星應用商店等用戶均受到不同程度的影響。筆者也是VIPKID的用戶,所幸當天并未約課,只是無法完成課后作業(yè)及預習課程。而約了課的家長就比較抓狂,取消已約課程,重新約課…
雖然云服務不可能保證100%不出現問題,但是扎扎實實做好災備,把宕機帶來的影響降到***是云廠商的重要職責。
對于用戶來說,除了選擇更安全的云服務外,使用多家云服務,實施多云戰(zhàn)略也是未來的重要方向。
首先,優(yōu)化了業(yè)務負載。由于根據企業(yè)負載的不同,為之匹配不同廠商間最適合的云技術,可以明顯提高企業(yè)業(yè)務運轉效率。
第二,確保服務的可靠性。再可靠的云服務也不能保證100%的安全,即使云計算提供商在多個區(qū)域提供數據中心服務,并可以確保安全的冗余級別,但仍然會存在各種突出事件,影響云服務的可靠性。而通過實施在多個云平臺之間故障轉移,無論發(fā)生什么類型的中斷,都可以盡快完成災備,保持應用程序的運行。
國際數據公司 IDC 的一項預測表明:“截止到2020年,90%以上的企業(yè)將使用多個云服務和平臺”。著名研究機構 451 Research 公司的調查也顯示:“IT 的未來是多云和混合云,69%的受訪企業(yè)表示,計劃到2019年采用各種類型的多云環(huán)境。”
***筆者還想說,光纜、管道等基礎設施的保護也應受到重視,輕而易舉的被破壞,在當今的云時代,付出的代價太大了!
【51CTO原創(chuàng)稿件,合作站點轉載請注明原文作者和出處為51CTO.com】