大規模雲計算平臺的技術挑戰

2月20日報導：正如單機作業系統的內核，在阿裡雲OS中，飛天大規模分散式運算平臺起到了承上啟下的關鍵作用。 飛天運行在通過網路互聯的泛型服務器集群上，隱藏了海量硬體所帶來的複雜度和不可靠，向雲OS的其他元件提供可信賴的的計算能力和存儲能力。

具體來講，飛天本身是一個由多個元件所構成的複雜的分散式系統，其中的核心元件是以下兩個子系統。

計算資源調度系統（又稱伏羲）：管理和調度集群計算資源；在多個雲服務間動態分配計算資源，以滿足使用者的計算需求；自動檢測伺服器故障並遷移故障伺服器上的服務。

分散式檔案系統（又稱盤古）：管理集群的所有硬碟；合理地安排資料存放位置以兼顧性能和資料安全性；自動檢測磁片故障並複製資料以保證安全。

在實現飛天雲計算平臺的過程中，工程師們面臨了許多技術挑戰，包括：

在不可靠硬體基礎上提供高可靠的計算能力和存儲能力；

提供高可用服務；

低成本運維海量硬體；

線上應用與離線應用並存；

克服節點間頻寬的限制；

最大化利用計算資源，等等。

其中，不可靠的硬體是最基本的挑戰。 集群規模達到上千台後，單機上的小概率事件變成了必然的、頻繁發生的事件。 硬碟、硬碟控制器、CPU、記憶體、主機板、電源等故障造成的宕機每天都會發生。 這類硬體失效故障，我們稱之為「硬」故障（fail-stop故障）。 此外，還有一類故障現象不那麼明顯，稱之為「軟」故障，例如，磁片可訪問但速度只有正常的1/10、伺服器沒有宕機但程式運行緩慢、網路時好時壞等。 這類「軟」故障同樣會影響服務品質，因為線上服務如果執行緩慢會造成用戶端超時，而對離線作業而言，哪怕只有1%的資料處理任務緩慢，也會拖延整個資料分析作業的完成時間。

硬、軟故障發生都會對系統的可靠性甚至可用性造成不良影響，因此如何及時有效地進行故障檢測和恢復就變得比較關鍵。 對於硬故障的檢測業界已有成熟的方案，本文第一部分只重點討論軟故障的檢測；本文的第二部分將集中探討故障修復原則相關的問題；最後，我們將介紹如何在保證資料可靠的同時滿足線上應用的低延時需求。

雲環境中的軟故障檢測

檢測「軟」故障有兩種思路。

一種思路是針對每種具體故障設計檢測方法。 但「軟」故障產生的原因可能很多，例如執行緩慢可能是伺服器硬體故障、網路故障、磁片故障、作業系統軟體故障等，逐一檢測會使系統過於複雜。

另一種思路是從宏觀現象來檢測，下面看兩個例子。

例子一：檢測作業在某台伺服器上執行特別緩慢的情況。

我們統計每個作業在每台伺服器上的執行時間。 因為輸入資料被均勻地切片，每台伺服器上的執行時間應該大致相同。 如果某台伺服器上執行時間超過了平均時間的三倍，它就被標記為「緩慢」。 如果各種不同作業在某台伺服器上都「緩慢」，那麼我們有充分理由懷疑這台伺服器有問題（但不知道原因）。 調度系統會自動把這台伺服器加入黑名單，不再用它執行作業。 之後再自動或人工檢查這些可疑伺服器的具體故障原因。

例子二：檢測磁片讀寫慢的情況。

我們在分散式檔案系統裡也會統計每次磁片訪問的時間。 如果某塊磁片有大比率的存取時間遠遠超過系統平均值，那麼很有可能是這塊磁片快要發生故障了。 檔案系統此時會做三件事：

停止寫新資料到這塊磁片，防止更多資料處於危險中；

開始為這塊磁片上的資料增加更多副本；

當這塊磁片上的所有資料都有額外的副本，就可以將它下線，待運維處理。

故障自動復原的策略

在檢測到故障後，需要有自動及時的故障恢復機制。 然而，故障自動復原機制一旦沒有考慮周全就會成為一把雙刃劍。 讓我們從Amazon雲服務那次嚴重的事故說起。

Amazon EC2大規模停機事件

2011年4月21日，Amazon的虛擬主機服務EC2發生大規模停機，時間超過兩天，影響波及Reddit、Foursquare、Quora等眾多網站。 事後Amazon對此次事故作了詳細分析。 事故起因是Amazon對集群網路作日常維護升級時操作錯誤，網路流量被全部切換到備用網路，導致備用網路超載。 自動故障恢復機制檢測到網路不通，認為伺服器大量宕機，馬上開始資料複製以替換「宕機」的伺服器上的資料副本，引發了「鏡像風暴」（大量伺服器同時嘗試創建資料鏡像）。 而由此增加的資料流量更加劇了網路超載，從而使故障在集群中蔓延，進入惡性循環。 最終採取了包括暫時關閉自動故障恢復系統和增加硬體在內的多種措施，服務于故障發生兩天半以後恢復。

在此案例中，故障自動檢測和恢復的策略是「在資料副本所在伺服器失去聯繫時，複製資料」。 這一策略對「一台伺服器故障」這種小範圍的常見問題很有效，然而在大範圍故障如「網路超載」的場景下，可能會起反作用。 在這個案例中，如果根本沒有故障自動復原機制，故障影響範圍反而不會有那麼大。

實際上，這一模式在過去的大規模分散式系統故障中反復出現：發生了未曾預料到的、中小範圍的故障

→故障自動復原機制採取了錯誤的手段

→故障惡化，進入惡性循環

Amazon S3存儲服務2008年的故障就僅僅是由於故障自動檢測機制的自身狀態中一個bit出錯，然而故障同樣迅速蔓延到整個系統，導致服務在沒有發生硬體故障的情況下不可用。

對此，我們的策略是限制故障自動復原機制的作用範圍：

正常情況下，任何時候集群中都有且僅有很小比例的伺服器發生故障，此時自動復原有效，即使無效也不會造成災難；

如果發生（罕見的）大範圍故障，明智的策略是儘量降低系統負載，因為此時實際上已不可能靠故障自動復原來保持服務品質。 萬一此時故障自動復原機制試圖進行大量操作，並超出預設的限制，即暫時禁止掉這部分邏輯。

以前面提到的硬碟訪問變慢為例：考慮到硬碟平均日故障率小於千分之一，我們給前述的疑似問題硬碟自動下線機制設置上限，例如，任何時候只能通過此機制下線總數1%的硬碟。 此限制可以防止極端情況下，如大量硬碟出現問題，或者自動下線機制本身故障時，故障恢復機制本身不會引發災難。

資料可靠性和即時性能優化

雲環境中，由於分散式系統有硬體故障多發的特點，保證資料可靠性成為檔案系統的一個挑戰。

在飛天雲計算平臺的實際運營中發生故障最多的硬體是硬碟。 硬碟故障占阿裡雲資料中心故障總數的80%.原因之一是硬碟是數量最多的部件，例如一個3000節點的集群就有30000多塊硬碟，即使硬碟本身的平均無故障工作時間（MTBF）達到1，000，000小時， 30000塊硬碟也意味著平均每33小時就有一次硬碟故障發生。 實際運營資料顯示硬碟廠家標稱的MTBF值並不可靠，生產環境的硬碟故障率可以幾倍到幾十倍于標稱值。

硬碟故障最直接影響的就是盤古分散式檔案系統。 為了保證資料安全性，盤古檔案系統對所有的資料均採用了多份拷貝。 在創建檔時，使用者可以指定檔資料的拷貝數目，檔案系統會保證資料分佈在不同的節點和不同的機架上，使得單個硬體故障不會造成資料無法訪問。

多副本技術是業內廣泛認可的有效防止資料丟失的技術，通常採用流水線方式傳遞寫需求以減輕單個節點的負載。 但這會導致資料寫入的延遲增大，因為只有當所有副本都寫成功後才能結束一個寫操作。

由於磁片讀寫特性，上述多副本寫入磁片的延遲通常在幾十毫秒量級，有時可達100毫秒以上。 雲環境中的線上應用，有時會有更高的即時性要求。 盤古通過記憶體日誌檔（in-memory redo log）來解決此問題。

記憶體日誌檔的基本思想基於以下事實：雖然伺服器因為掉電或者宕機丟失記憶體資料的概率高於硬碟損壞的概率（所以在單機系統中我們會把日誌檔寫入磁片以避免記憶體資料丟失）， 但多台伺服器同時故障的概率卻可以低到能夠滿足資料可靠性的要求。 對於即時性要求高的應用，盤古提供介面，使得資料檔案進入指定數量伺服器的記憶體即可認為是寫成功；盤古的後臺執行緒隨後會把記憶體中的資料批量寫入磁片。

盤古在保證記憶體日誌的可靠性和低延時上做了如下考慮。

保證redo log是多份拷貝的，避免單機故障造成資料損壞或丟失。

為降低寫入延遲，確保redo log寫入多個資料伺服器記憶體buffer後即返回成功，由後臺工作執行緒保證記憶體資料在很短時間內持久化到磁片。

嚴格檢測redo log資料的健康狀態，並及時採取補救策略確保資料的可靠性。

分散式系統的一個優勢是對單點故障的遮罩：資料的可靠性通過多台伺服器間的複本備份得到極大的增強。 對於單機，記憶體資料是易丟失的；但在多機環境下，如果能保證伺服器不是同一時間宕機，並輔以嚴格的策略保證，記憶體資料在不降低可靠性的情況下，可以極大地提高性能。 阿裡雲的資料中心保證了很好的硬體隔離和冗余，並備有UPS等應急措施，為我們提供了使用記憶體緩衝的良好硬體環境。

下面主要介紹我們在記憶體檔資料可靠性上的一些考慮。

寫入記憶體階段

確保多個資料伺服器成功接收資料並放到記憶體buffer中（這點是redo log的設計基礎）。

選擇資料伺服器充分考慮硬體的隔離性，避免故障的關聯。

在接受資料時資料伺服器判斷自身的健康狀態：

所寫的磁片狀態是正常的，並且剩餘空間足夠；

當前的workload狀況良好，比如記憶體和I/O佇列沒有超負荷。

記憶體到磁片持久化階段

限制從記憶體buffer到磁片I/O的最長時間（30秒內）。

發現寫入超時後（比如磁片異常慢或I/O請求超載），立刻通知master伺服器進行複本備份。

當發現寫入異常（磁片壞或者滿等）後，立刻報警，通知master複製。

檢測與複製階段

監測磁片異常和後臺檢查資料完整性，發現異常後立刻通知master複製。

可以看出，寫入記憶體階段的策略是預防措施；記憶體到磁片持久化階段最危險，我們確保這個階段盡可能短（保證預期性能的情況下給出最長寫入時間），並在確認出錯後及時採取措施；檢測與複製階段是典型的磁片壞掉但保證資料不丟的策略。

小結

在設計和實現飛天雲計算平臺過程中，工程師們花費了大量努力來應對海量硬體所帶來的可靠性的挑戰。 本文敘述了部分設計思路但遠遠不是全部。 錘煉一個健壯的大規模分散式系統一定需要良好的設計、精緻的實現以及嚴格的測試。 有了飛天這個穩定可靠的雲OS內核，各種豐富的雲計算服務及應用便有了生存、長大的肥沃土壤。 我們隨後將會介紹的各種雲服務，正是運行建立在阿裡雲自行研發的飛天雲計算平臺上。

(責任編輯：呂光)