Amazon云服務故障分析

上周四即6月14日，Amazon位于美國東部的數據中心出現故障，并影響了AWS多項云服務以及基于之上的Heroku、Quora等知名網站。16日，Amaozn公布了事故分析。事故是由公共電網故障引起，并引發了一系列連鎖故障。：

事情的起因是電纜故障影響了高壓配電系統。

6月14日20：44左右，一電纜發生故障，進而影響了高壓配電系統。2個為可用區域提供電力的公用變電站出現故障，進而使得整個供應區供電不足。但這個情況是可以處理的，亞馬遜啟動了備用發電機，保證了所有的EC2實例和EBS存儲成功轉移。

然而，20：53，1個備用發電機因其風扇過熱造成了超負荷運轉而斷電。所以采用備用發電機（由一個完全獨立的配電電路完成額外發電能力）的方案也宣告失敗。更不幸的是，在這套特定的后備電源分配電路中，一個斷路器被錯誤配置為在低功率閾值時打開，這樣，當負載轉移到該電路時，錯誤發生了，該斷路器斷路了。

20：57，當該電路斷路器斷開時，實例和存儲失去了主要備份電力或二次后備電源。受此影響客戶的實例和卷是運行在多個可用區域的，只能在此環境中等到電力恢復才能正常運行。

15日10：19，發電機風扇被替換并安裝好，發電機開始提供動力。電力逐步恢復后，受影響的實例和存儲也開始恢復。

10：50，絕大多數實例已經恢復正常。但對于EBS存儲（含啟動塊）而言，電力不足之時寫入會有數據損失，也就是這些存儲可能存在不一致的狀況。這并非是潛在的不一致，因為即使是存儲上I/O停頓，EBS也會在線直接反饋出受損狀態。用戶只能通過驗證存儲上的一致性來恢復它。

最后，16日1：05，超過99%受影響的存儲才得以解決。

總的來看，EBS-related EC2 API的損失集中在20：57-22：40.具體來看，這段時間內，可變系統調用（如創建，刪除）失敗，進而直接影響到客戶發布新的EBS-backed EC2實例。EC2和EBS APIs實施在多個可用復制數據存儲區。EBS數據存儲被用來存儲元數據等資源的卷快照。一個主要的EBS數據存儲因為這個時間失去了動力，使得系統無法將數據存儲的副本放到另外一個可用區。一般來看，為了保護數據存儲，系統會自動翻轉為只讀模式，直到電力恢復可以啟動可用區，進而盡快恢復到一致狀態，并返回到數據存儲讀寫模式，使得啟用可變EBS調用成功。但這個事件中，這一保護方案沒有起到作用。

未來，為了保證數據存儲實現快速切換，亞馬遜將實施變革。高壓配電系統以及所有運行實例和存儲將采用全冗余電源。此外，亞馬遜還完成了對所有備用配電的審計。在審計中，亞馬遜還發現了另一個設置有問題的斷路器。至此，亞馬遜表示，已經確定所有斷路器都是正確的配置了，并會進行定期的測試和審計。

最后，亞馬遜對在這次事件中受到損失的企業表示了歉意。

CSDN觀點：從亞馬遜的解釋來看，頗有“屋漏偏逢連夜雨”之慨，但也從另一層面看出對于數據中心的任何一次事故而言，所需要提供的應對方案應是復雜的，連續的，方案之外，定期測試也是必須的。在該事件之后，有很多有價值的分析與評論，特選擇一些和大家共享。

ericabiz：（自2001-2007年一直經營一個專用服務器托管公司）

在托管實施設計中，電池要有足夠的力量來支持發電機。但這也會帶來一個巨大單點故障的可能性。一個更好的設計是通過飛輪產生足夠的電力。不過，對于一般數據中心而言，一年左右的時間內總會遇到這些發電機故障。

亞馬遜有著好的設置，但是沒有進行有效的測試。

順便說一下，這也是問你的數據中心供應商的一個好問題：是否擁有兩個完全冗余電源并包含PDU和發電機器的系統？多長時間進行一次測試？如果一個電路單元/發電機失敗，我如何設置服務器來保證應用不失去動力？

有一個正確的方法：多電源保證每一個服務器連接到2PDUs或連接到2個不同的發電機——但這是昂貴的，許多最低端的托管服務提供商是無法接受這個成本的。

rdl：

大型余熱發電設備（比如利用蒸汽、建筑、供熱設備產生的廢熱等）往往采用grid-backup模式。舉個例子，麻省理工學院的熱電廠（幾大天然氣渦輪機），也有很多大學利用蒸汽加熱，很多工業遺址也證明了這些。它歸結為成本和分區允許。顯然比起運行一個24*7的發電機，其更容易獲得許可證。而從實際價格上看，利用余熱更能體現循環價值。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]