正如單機(jī)操作系統(tǒng)的內(nèi)核，在阿里云OS中，飛天大規(guī)模分布式計(jì)算平臺起到了承上啟下的關(guān)鍵作用。飛天運(yùn)行在通過網(wǎng)絡(luò)互聯(lián)的通用服務(wù)器集群上，隱藏了海量硬件所帶來的復(fù)雜度和不可靠，向云OS的其他組件提供可信賴的的計(jì)算能力和存儲(chǔ)能力。

　　具體來講，飛天本身是一個(gè)由多個(gè)組件所構(gòu)成的復(fù)雜的分布式系統(tǒng)，其中的核心組件是以下兩個(gè)子系統(tǒng)。

　　·計(jì)算資源調(diào)度系統(tǒng)(又稱伏羲)：管理和調(diào)度集群計(jì)算資源;在多個(gè)云服務(wù)間動(dòng)態(tài)分配計(jì)算資源，以滿足用戶的計(jì)算需求;自動(dòng)檢測服務(wù)器故障并遷移故障服務(wù)器上的服務(wù)。

　　·分布式文件系統(tǒng)(又稱盤古)：管理集群的所有硬盤;合理地安排數(shù)據(jù)存放位置以兼顧性能和數(shù)據(jù)安全性;自動(dòng)檢測磁盤故障并復(fù)制數(shù)據(jù)以保證安全。

　　在實(shí)現(xiàn)飛天云計(jì)算平臺的過程中，工程師們面臨了許多技術(shù)挑戰(zhàn)，包括：

　　·在不可靠硬件基礎(chǔ)上提供高可靠的計(jì)算能力和存儲(chǔ)能力;

　　·提供高可用服務(wù);

　　·低成本運(yùn)維海量硬件;

　　·在線應(yīng)用與離線應(yīng)用并存;

　　·克服節(jié)點(diǎn)間帶寬的限制;

　　·***化利用計(jì)算資源，等等。

　　其中，不可靠的硬件是最基本的挑戰(zhàn)。集群規(guī)模達(dá)到上千臺后，單機(jī)上的小概率事件變成了必然的、頻繁發(fā)生的事件。硬盤、硬盤控制器、CPU、內(nèi)存、主板、電源等故障造成的宕機(jī)每天都會(huì)發(fā)生。這類硬件失效故障，我們稱之為“硬”故障(fail-stop故障)。此外，還有一類故障現(xiàn)象不那么明顯，稱之為“軟”故障，例如，磁盤可訪問但速度只有正常的1/10、服務(wù)器沒有宕機(jī)但程序運(yùn)行緩慢、網(wǎng)絡(luò)時(shí)好時(shí)壞等。這類“軟”故障同樣會(huì)影響服務(wù)質(zhì)量，因?yàn)樵诰€服務(wù)如果執(zhí)行緩慢會(huì)造成客戶端超時(shí)，而對離線作業(yè)而言，哪怕只有1%的數(shù)據(jù)處理任務(wù)緩慢，也會(huì)拖延整個(gè)數(shù)據(jù)分析作業(yè)的完成時(shí)間。

　　硬、軟故障發(fā)生都會(huì)對系統(tǒng)的可靠性甚至可用性造成不良影響，因此如何及時(shí)有效地進(jìn)行故障檢測和恢復(fù)就變得比較關(guān)鍵。對于硬故障的檢測業(yè)界已有成熟的方案，本文***部分只重點(diǎn)討論軟故障的檢測;本文的第二部分將集中探討故障恢復(fù)策略相關(guān)的問題;***，我們將介紹如何在保證數(shù)據(jù)可靠的同時(shí)滿足在線應(yīng)用的低延時(shí)需求。

　　云環(huán)境中的軟故障檢測

　　檢測“軟”故障有兩種思路。

　　·一種思路是針對每種具體故障設(shè)計(jì)檢測方法。但“軟”故障產(chǎn)生的原因可能很多，例如執(zhí)行緩慢可能是服務(wù)器硬件故障、網(wǎng)絡(luò)故障、磁盤故障、操作系統(tǒng)軟件故障等，逐一檢測會(huì)使系統(tǒng)過于復(fù)雜。

　　·另一種思路是從宏觀現(xiàn)象來檢測，下面看兩個(gè)例子。

　　例子一：檢測作業(yè)在某臺服務(wù)器上執(zhí)行特別緩慢的情況。

　　我們統(tǒng)計(jì)每個(gè)作業(yè)在每臺服務(wù)器上的執(zhí)行時(shí)間。因?yàn)檩斎霐?shù)據(jù)被均勻地切片，每臺服務(wù)器上的執(zhí)行時(shí)間應(yīng)該大致相同。如果某臺服務(wù)器上執(zhí)行時(shí)間超過了平均時(shí)間的三倍，它就被標(biāo)記為“緩慢”。如果各種不同作業(yè)在某臺服務(wù)器上都“緩慢”，那么我們有充分理由懷疑這臺服務(wù)器有問題(但不知道原因)。調(diào)度系統(tǒng)會(huì)自動(dòng)把這臺服務(wù)器加入黑名單，不再用它執(zhí)行作業(yè)。之后再自動(dòng)或人工檢查這些可疑服務(wù)器的具體故障原因。

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

　　我們在分布式文件系統(tǒng)里也會(huì)統(tǒng)計(jì)每次磁盤訪問的時(shí)間。如果某塊磁盤有大比率的訪問時(shí)間遠(yuǎn)遠(yuǎn)超過系統(tǒng)平均值，那么很有可能是這塊磁盤快要發(fā)生故障了。文件系統(tǒng)此時(shí)會(huì)做三件事：

　　·停止寫新數(shù)據(jù)到這塊磁盤，防止更多數(shù)據(jù)處于危險(xiǎn)中;

　　·開始為這塊磁盤上的數(shù)據(jù)增加更多副本;

　　·當(dāng)這塊磁盤上的所有數(shù)據(jù)都有額外的副本，就可以將它下線，待運(yùn)維處理。

　　故障自動(dòng)恢復(fù)的策略

　　在檢測到故障后，需要有自動(dòng)及時(shí)的故障恢復(fù)機(jī)制。然而，故障自動(dòng)恢復(fù)機(jī)制一旦沒有考慮周全就會(huì)成為一把雙刃劍。讓我們從Amazon云服務(wù)那次嚴(yán)重的事故說起。

　　Amazon EC2大規(guī)模停機(jī)事件

　　2011年4月21日，Amazon的虛擬主機(jī)服務(wù)EC2發(fā)生大規(guī)模停機(jī)，時(shí)間超過兩天，影響波及Reddit、Foursquare、Quora等眾多網(wǎng)站。事后Amazon對此次事故作了詳細(xì)分析。事故起因是Amazon對集群網(wǎng)絡(luò)作日常維護(hù)升級時(shí)操作錯(cuò)誤，網(wǎng)絡(luò)流量被全部切換到備用網(wǎng)絡(luò)，導(dǎo)致備用網(wǎng)絡(luò)過載。自動(dòng)故障恢復(fù)機(jī)制檢測到網(wǎng)絡(luò)不通，認(rèn)為服務(wù)器大量宕機(jī)，馬上開始數(shù)據(jù)復(fù)制以替換“宕機(jī)”的服務(wù)器上的數(shù)據(jù)副本，引發(fā)了“鏡像風(fēng)暴”(大量服務(wù)器同時(shí)嘗試創(chuàng)建數(shù)據(jù)鏡像)。而由此增加的數(shù)據(jù)流量更加劇了網(wǎng)絡(luò)過載，從而使故障在集群中蔓延，進(jìn)入惡性循環(huán)。最終采取了包括暫時(shí)關(guān)閉自動(dòng)故障恢復(fù)系統(tǒng)和增加硬件在內(nèi)的多種措施，服務(wù)于故障發(fā)生兩天半以后恢復(fù)。

　　在此案例中，故障自動(dòng)檢測和恢復(fù)的策略是“在數(shù)據(jù)副本所在服務(wù)器失去聯(lián)系時(shí)，復(fù)制數(shù)據(jù)”。這一策略對“一臺服務(wù)器故障”這種小范圍的常見問題很有效，然而在大范圍故障如“網(wǎng)絡(luò)過載”的場景下，可能會(huì)起反作用。在這個(gè)案例中，如果根本沒有故障自動(dòng)恢復(fù)機(jī)制，故障影響范圍反而不會(huì)有那么大。

　　實(shí)際上，這一模式在過去的大規(guī)模分布式系統(tǒng)故障中反復(fù)出現(xiàn)：發(fā)生了未曾預(yù)料到的、中小范圍的故障

　　→故障自動(dòng)恢復(fù)機(jī)制采取了錯(cuò)誤的手段

　　→故障惡化，進(jìn)入惡性循環(huán)

　　Amazon S3存儲(chǔ)服務(wù)2008年的故障就僅僅是由于故障自動(dòng)檢測機(jī)制的自身狀態(tài)中一個(gè)bit出錯(cuò)，然而故障同樣迅速蔓延到整個(gè)系統(tǒng)，導(dǎo)致服務(wù)在沒有發(fā)生硬件故障的情況下不可用。

　　對此，我們的策略是限制故障自動(dòng)恢復(fù)機(jī)制的作用范圍：

　　·正常情況下，任何時(shí)候集群中都有且僅有很小比例的服務(wù)器發(fā)生故障，此時(shí)自動(dòng)恢復(fù)有效，即使無效也不會(huì)造成災(zāi)難;

　　·如果發(fā)生(罕見的)大范圍故障，明智的策略是盡量降低系統(tǒng)負(fù)載，因?yàn)榇藭r(shí)實(shí)際上已不可能靠故障自動(dòng)恢復(fù)來保持服務(wù)質(zhì)量。萬一此時(shí)故障自動(dòng)恢復(fù)機(jī)制試圖進(jìn)行大量操作，并超出預(yù)設(shè)的限制，即暫時(shí)禁止掉這部分邏輯。

　　以前面提到的硬盤訪問變慢為例：考慮到硬盤平均日故障率小于千分之一，我們給前述的疑似問題硬盤自動(dòng)下線機(jī)制設(shè)置上限，例如，任何時(shí)候只能通過此機(jī)制下線總數(shù)1%的硬盤。此限制可以防止極端情況下，如大量硬盤出現(xiàn)問題，或者自動(dòng)下線機(jī)制本身故障時(shí)，故障恢復(fù)機(jī)制本身不會(huì)引發(fā)災(zāi)難。

　　數(shù)據(jù)可靠性和實(shí)時(shí)性能優(yōu)化

　　云環(huán)境中，由于分布式系統(tǒng)有硬件故障多發(fā)的特點(diǎn)，保證數(shù)據(jù)可靠性成為文件系統(tǒng)的一個(gè)挑戰(zhàn)。

　　在飛天云計(jì)算平臺的實(shí)際運(yùn)營中發(fā)生故障最多的硬件是硬盤。硬盤故障占阿里云數(shù)據(jù)中心故障總數(shù)的80%。原因之一是硬盤是數(shù)量最多的部件，例如一個(gè)3000節(jié)點(diǎn)的集群就有30000多塊硬盤，即使硬盤本身的平均無故障工作時(shí)間(MTBF)達(dá)到1,000,000小時(shí)，30000塊硬盤也意味著平均每33小時(shí)就有一次硬盤故障發(fā)生。實(shí)際運(yùn)營數(shù)據(jù)顯示硬盤廠家標(biāo)稱的MTBF值并不可靠，生產(chǎn)環(huán)境的硬盤故障率可以幾倍到幾十倍于標(biāo)稱值。

　　硬盤故障最直接影響的就是盤古分布式文件系統(tǒng)。為了保證數(shù)據(jù)安全性，盤古文件系統(tǒng)對所有的數(shù)據(jù)均采用了多份拷貝。在創(chuàng)建文件時(shí)，用戶可以指定文件數(shù)據(jù)的拷貝數(shù)目，文件系統(tǒng)會(huì)保證數(shù)據(jù)分布在不同的節(jié)點(diǎn)和不同的機(jī)架上，使得單個(gè)硬件故障不會(huì)造成數(shù)據(jù)無法訪問。

　　多副本技術(shù)是業(yè)內(nèi)廣泛認(rèn)可的有效防止數(shù)據(jù)丟失的技術(shù)，通常采用流水線方式傳遞寫需求以減輕單個(gè)節(jié)點(diǎn)的負(fù)載。但這會(huì)導(dǎo)致數(shù)據(jù)寫入的延遲增大，因?yàn)橹挥挟?dāng)所有副本都寫成功后才能結(jié)束一個(gè)寫操作。

　　由于磁盤讀寫特性，上述多副本寫入磁盤的延遲通常在幾十毫秒量級，有時(shí)可達(dá)100毫秒以上。云環(huán)境中的線上應(yīng)用，有時(shí)會(huì)有更高的實(shí)時(shí)性要求。盤古通過內(nèi)存日志文件(in-memory redo log)來解決此問題。

　　內(nèi)存日志文件的基本思想基于以下事實(shí)：雖然服務(wù)器因?yàn)榈綦娀蛘咤礄C(jī)丟失內(nèi)存數(shù)據(jù)的概率高于硬盤損壞的概率(所以在單機(jī)系統(tǒng)中我們會(huì)把日志文件寫入磁盤以避免內(nèi)存數(shù)據(jù)丟失)，但多臺服務(wù)器同時(shí)故障的概率卻可以低到能夠滿足數(shù)據(jù)可靠性的要求。對于實(shí)時(shí)性要求高的應(yīng)用，盤古提供接口，使得數(shù)據(jù)文件進(jìn)入指定數(shù)量服務(wù)器的內(nèi)存即可認(rèn)為是寫成功;盤古的后臺線程隨后會(huì)把內(nèi)存中的數(shù)據(jù)批量寫入磁盤。

　　盤古在保證內(nèi)存日志的可靠性和低延時(shí)上做了如下考慮。

　　·保證redo log是多份拷貝的，避免單機(jī)故障造成數(shù)據(jù)損壞或丟失。

　　·為降低寫入延遲，確保redo log寫入多個(gè)數(shù)據(jù)服務(wù)器內(nèi)存buffer后即返回成功，由后臺工作線程保證內(nèi)存數(shù)據(jù)在很短時(shí)間內(nèi)持久化到磁盤。

　　·嚴(yán)格檢測redo log數(shù)據(jù)的健康狀態(tài)，并及時(shí)采取補(bǔ)救策略確保數(shù)據(jù)的可靠性。

　　分布式系統(tǒng)的一個(gè)優(yōu)勢是對單點(diǎn)故障的屏蔽：數(shù)據(jù)的可靠性通過多臺服務(wù)器間的復(fù)制備份得到極大的增強(qiáng)。對于單機(jī)，內(nèi)存數(shù)據(jù)是易丟失的;但在多機(jī)環(huán)境下，如果能保證服務(wù)器不是同一時(shí)間宕機(jī)，并輔以嚴(yán)格的策略保證，內(nèi)存數(shù)據(jù)在不降低可靠性的情況下，可以極大地提高性能。阿里云的數(shù)據(jù)中心保證了很好的硬件隔離和冗余，并備有UPS等應(yīng)急措施，為我們提供了使用內(nèi)存緩沖的良好硬件環(huán)境。

　　下面主要介紹我們在內(nèi)存文件數(shù)據(jù)可靠性上的一些考慮。

　　寫入內(nèi)存階段

　　·確保多個(gè)數(shù)據(jù)服務(wù)器成功接收數(shù)據(jù)并放到內(nèi)存buffer中(這點(diǎn)是redo log的設(shè)計(jì)基礎(chǔ))。

　　·選擇數(shù)據(jù)服務(wù)器充分考慮硬件的隔離性，避免故障的關(guān)聯(lián)。

　　·在接受數(shù)據(jù)時(shí)數(shù)據(jù)服務(wù)器判斷自身的健康狀態(tài)：

　　·所寫的磁盤狀態(tài)是正常的，并且剩余空間足夠;

　　·當(dāng)前的workload狀況良好，比如內(nèi)存和I/O隊(duì)列沒有超負(fù)荷。

　　內(nèi)存到磁盤持久化階段

　　·限制從內(nèi)存buffer到磁盤I/O的最長時(shí)間(30秒內(nèi))。

　　·發(fā)現(xiàn)寫入超時(shí)后(比如磁盤異常慢或I/O請求超載)，立刻通知master服務(wù)器進(jìn)行復(fù)制備份。

　　·當(dāng)發(fā)現(xiàn)寫入異常(磁盤壞或者滿等)后，立刻報(bào)警，通知master復(fù)制。

　　檢測與復(fù)制階段

　　·監(jiān)測磁盤異常和后臺檢查數(shù)據(jù)完整性，發(fā)現(xiàn)異常后立刻通知master復(fù)制。

　　可以看出，寫入內(nèi)存階段的策略是預(yù)防措施;內(nèi)存到磁盤持久化階段最危險(xiǎn)，我們確保這個(gè)階段盡可能短(保證預(yù)期性能的情況下給出最長寫入時(shí)間)，并在確認(rèn)出錯(cuò)后及時(shí)采取措施;檢測與復(fù)制階段是典型的磁盤壞掉但保證數(shù)據(jù)不丟的策略。

　　小結(jié)

　　在設(shè)計(jì)和實(shí)現(xiàn)飛天云計(jì)算平臺過程中，工程師們花費(fèi)了大量努力來應(yīng)對海量硬件所帶來的可靠性的挑戰(zhàn)。本文敘述了部分設(shè)計(jì)思路但遠(yuǎn)遠(yuǎn)不是全部。錘煉一個(gè)健壯的大規(guī)模分布式系統(tǒng)一定需要良好的設(shè)計(jì)、精致的實(shí)現(xiàn)以及嚴(yán)格的測試。有了飛天這個(gè)穩(wěn)定可靠的云OS內(nèi)核，各種豐富的云計(jì)算服務(wù)及應(yīng)用便有了生存、長大的肥沃土壤。我們隨后將會(huì)介紹的各種云服務(wù)，正是運(yùn)行建立在阿里云自行研發(fā)的飛天云計(jì)算平臺上。