深刻淺出Mesos（三）：持久化存儲和容錯

【編者按】Mesos是Apache下的開源分佈式資源管理框架，它被稱爲是分佈式系統的內核。Mesos最初是由加州大學伯克利分校的AMPLab開發的，後在Twitter獲得普遍使用。InfoQ接下來將會策劃系列文章來爲讀者剖析Mesos。本文是整個系列的第一篇，簡單介紹了Mesos的背景、歷史以及架構。

注：本文翻譯自Cloud Architect Musings，InfoQ中文站在得到做者受權的基礎上對文章進行了翻譯。

---

在深刻淺出Mesos系列的第一篇文章中，我對相關的技術作了簡要概述，在第二篇文章中，我深刻介紹了Mesos的架構。完成第二篇文章以後，我本想開始着手寫一篇Mesos如何處理資源分配的文章。不過，我收到一些讀者的反饋，因而決定在談資源分配以前，先完成這篇關於Mesos持久化存儲和容錯的文章。

持久化存儲的問題

正如我在前文中討論過的，使用Mesos的主要好處是能夠在同一組計算節點集合上運行多種類型的應用程序（調度以及經過Framework初始化任務）。這些任務使用隔離模塊（目前是某些類型的容器技術）從實際節點中抽象出來，以便它們能夠根據須要在不一樣的節點上移動和從新啓動。

由此咱們會思考一個問題，Mesos是如何處理持久化存儲的呢？若是我在運行一個數據庫做業，Mesos如何確保當任務被調度時，分配的節點能夠訪問其所需的數據？如圖所示，在Hindman的示例中，使用Hadoop文件系統（HDFS）做爲Mesos的持久層，這是HDFS常見的使用方式，也是Mesos的執行器傳遞分配指定任務的配置數據給Slave常用的方式。實際上，Mesos的持久化存儲可使用多種類型的文件系統，HDFS只是其中之一，但也是Mesos最常用的，它使得Mesos具有了與高性能計算的親緣關係。其實Mesos能夠有多種選擇來處理持久化存儲的問題：

• 分佈式文件系統。如上所述，Mesos可使用DFS（好比HDFS或者Lustre）來保證數據能夠被Mesos集羣中的每一個節點訪問。這種方式的缺點是會有網絡延遲，對於某些應用程序來講，這樣的網絡文件系統或許並不適合。

• 使用數據存儲複製的本地文件系統。另外一種方法是利用應用程序級別的複製來確保數據可被多個節點訪問。提供數據存儲複製的應用程序能夠是NoSQL數據庫，好比Cassandra和MongoDB。這種方式的優勢是再也不須要考慮網絡延遲問題。缺點是必須配置Mesos，使特定的任務只運行在持有複製數據的節點上，由於你不會但願數據中心的全部節點都複製相同的數據。爲此，可使用一個Framework，靜態地爲其預留特定的節點做爲複製數據的存儲。

• 不使用複製的本地文件系統。也能夠將持久化數據存儲在指定節點的文件系統上，而且將該節點預留給指定的應用程序。和前面的選擇同樣，能夠靜態地爲指定應用程序預留節點，但此時只能預留給單個節點而不是節點集合。後面兩種顯然不是理想的選擇，由於實質上都須要建立靜態分區。然而，在不容許延時或者應用程序不能複製它的數據存儲等特殊狀況下，咱們須要這樣的選擇。

Mesos項目還在發展中，它會按期增長新功能。如今我已經發現了兩個能夠幫助解決持久化存儲問題的新特性：

• 動態預留。Framework可使用這個功能框架保留指定的資源，好比持久化存儲，以便在須要啓動另外一個任務時，資源邀約只會發送給那個Framework。這能夠在單節點和節點集合中結合使用Framework配置，訪問永久化數據存儲。關於這個建議的功能的更多信息能夠從此處得到。

• 持久化卷。該功能能夠建立一個卷，做爲Slave節點上任務的一部分被啓動，即便在任務完成後其持久化依然存在。Mesos爲須要訪問相同的數據後續任務，提供在能夠訪問該持久化卷的節點集合上相同的Framework來初始化。關於這個建議的功能的更多信息能夠從此處得到。

容錯

接下來，咱們來談談Mesos在其協議棧上是如何提供容錯能力的。恕我直言，Mesos的優點之一即是將容錯設計到架構之中，並以可擴展的分佈式系統的方式來實現。

• Master。故障處理機制和特定的架構設計實現了Master的容錯。

  首先，Mesos決定使用熱備份（hot-standby）設計來實現Master節點集合。正如Tomas Barton對上圖的說明，一個Master節點與多個備用（standby）節點運行在同一集羣中，並由開源軟件Zookeeper來監控。Zookeeper會監控Master集羣中全部的節點，並在Master節點發生故障時管理新Master的選舉。建議的節點總數是5個，實際上，生產環境至少須要3個Master節點。 Mesos決定將Master設計爲持有軟件狀態，這意味着當Master節點發生故障時，其狀態能夠很快地在新選舉的Master節點上重建。 Mesos的狀態信息實際上駐留在Framework調度器和Slave節點集合之中。當一個新的Master當選後，Zookeeper會通知Framework和選舉後的Slave節點集合，以便使其在新的Master上註冊。彼時，新的 Master能夠根據Framework和Slave節點集合發送過來的信息，重建內部狀態。

• Framework調度器。Framework調度器的容錯是經過Framework將調度器註冊2份或者更多份到Master來實現。當一個調度器發生故障時，Master會通知另外一個調度來接管。須要注意的是Framework自身負責實現調度器之間共享狀態的機制。

• Slave。Mesos實現了Slave的恢復功能，當Slave節點上的進程失敗時，可讓執行器/任務繼續運行，併爲那個Slave進程從新鏈接那臺Slave節點上運行的執行器/任務。當任務執行時，Slave會將任務的監測點元數據存入本地磁盤。若是Slave進程失敗，任務會繼續運行，當Master從新啓動Slave進程後，由於此時沒有能夠響應的消息，因此從新啓動的Slave進程會使用檢查點數據來恢復狀態，並從新與執行器/任務鏈接。

以下狀況則大相徑庭，計算節點上Slave正常運行而任務執行失敗。在此，Master負責監控全部Slave節點的狀態。

當計算節點/Slave節點沒法響應多個連續的消息後，Master會從可用資源的列表中刪除該節點，並會嘗試關閉該節點。

而後，Master會向分配任務的Framework調度器彙報執行器/任務失敗，並容許調度器根據其配置策略作任務失敗處理。一般狀況下，Framework會從新啓動任務到新的Slave節點，假設它接收並接受來自Master的相應的資源邀約。

• 執行器/任務。與計算節點/Slave節點故障相似，Master會向分配任務的Framework調度器彙報執行器/任務失敗，並容許調度器根據其配置策略在任務失敗時作出相應的處理。一般狀況下，Framework在接收並接受來自Master的相應的資源邀約後，會在新的Slave節點上從新啓動任務。

結論

在接下來的文章中，我將更深刻到資源分配模塊。同時，我很是期待讀者的反饋，特別是關於若是我打標的地方，若是你發現哪裏不對，請反饋給我。我非全知，虛心求教，因此期待讀者的校訂和啓示。我也會在twitter響應你的反饋，請關注 @hui_kenneth。