正如單機操作系統的內核，在阿里云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內核，各種豐富的云計算服務及應用便有了生存、長大的肥沃土壤。我們隨后將會介紹的各種云服務，正是運行建立在阿里云自行研發的飛天云計算平臺上。