作者 韓陸 > 【編者按】Mesos是Apache下的開源分布式資源管理框架，它被稱為是分布式系統的內核。Mesos最初是由加州大學伯克利分校的AMPLab開發的，后在Twitter得到廣泛使用。InfoQ接下來將會策劃系列文章來為讀者剖析Mesos。本文是整個系列的第一篇，簡單介紹了Mesos的背景、歷史以及架構。 注：本文翻譯自[Cloud Architect Musings](http://cloudarchitectmusings.com/2015/03/23/apache-mesos-the-true-os-for-the-software-defined-data-center/)，InfoQ中文站在獲得作者授權的基礎上對文章進行了翻譯。 * * * 在深入淺出Mesos系列的[第一篇文章](http://www.infoq.com/cn/articles/analyse-mesos-part-01)中，我對相關的技術做了簡要概述，在[第二篇](http://www.infoq.com/cn/articles/analyse-mesos-part-02)文章中，我深入介紹了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配置，訪問永久化數據存儲。關于這個建議的功能的更多信息可以從[此處](https://issues.apache.org/jira/browse/MESOS-2018)獲得。 * **持久化卷**。該功能可以創建一個卷，作為Slave節點上任務的一部分被啟動，即使在任務完成后其持久化依然存在。Mesos為需要訪問相同的數據后續任務，提供在可以訪問該持久化卷的節點集合上相同的Framework來初始化。關于這個建議的功能的更多信息可以從[此處](https://issues.apache.org/jira/browse/MESOS-1554)獲得。 ## 容錯 接下來，我們來談談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](https://twitter.com/hui_kenneth)響應你的反饋，請關注 @hui_kenneth。