談談Apache Mesos和Mesosphere DCOS：歷史、架構、發展和應用

Mesos 是一個很年輕的開源項目，它的理念是怎樣的? 它的整體架構以及服務對象又是什么? 基于此的 Mesosphere DCOS 又是如何定位的? 本文作者就這些話題展開了探討。

Mesos 發展史

Mesos 是一個早在2009年由 Benjamin Hindman、Andy Konwinski、Matei Zaharia、Ali Ghodsi、Anthony D. Joseph、Randy Katz、Scott Shenker和Ion Stoica幾人聯合發起的伯克利大學研究項目。Benjamin 隨后將其引入 推ter，而如今它已經完美的運行在他們的數據中心上， Benjamin 本人也在不久之后成為了 Mesosphere 的首席架構師，正是它構建了 Mesosphere 數據中心操作系統（DCOS）。

Mesos 的設計宗旨在于嘗試和提高集群的利用效率和性能，他們認為對于數據中心資源的單純靜態劃分和使用的這樣一個方式是值得重新考量的，舉個例子來說：

我們假設你的數據中心里擁有9個主機：

如果把它靜態的劃分開來，并且指定每三個主機承載一個應用，這樣一來總共是3個應用（這里是Hadoop、Spark 和 Ruby on Rails）。

顯而易見的一個問題是這些主機的資源利用率并不會很高；

因此如果你想使用全部的資源，即這里例子中的全部9臺主機，那么就需要將其抽象成一個共享資源池，而你可以按需計劃配置，這樣的話，利用率自然可以得到相應的提升；

Mesos團隊的第二個觀點在于他們覺得需要為分布式系統量身定制一套新的系統，換句話說，他們覺得MapReduce并不是適用于所有的場景 （這也導致了Spark的誕生，而它又是另外一個故事了），而我們需要一個新的更簡單和更具有通用性的專為分布式系統提供服務的這樣一個框架。

Mesos 框架（分布式系統）到底是什么?

一般來說，一個分布式系統你需要有一個Coordinator（調度器）和 多個Worker（執行任務）。調度器以同步（分布式）的方式運行進程/任務，處理程序錯誤（容錯），并且負責優化性能（即彈性伸縮）。換句話說，它負責 協調在數據中心去實際執行你想要運行的代碼（不需要是一個完整的程序，它也可以是某些種類的運算）。正如之前所提到的那樣，Mesos將其稱之為聯合調 度。

或者也可以這么說，Mesos是一個帶有調度器的分布式系統。

那么Mesos的真正定位是什么呢? 當你嘗試去執行它的任務時你可以理解為它實際上就是機器和調度器之間的一層抽象。

因此在Mesos里，調度器是和Mesos層（通過API等）通信，而不是直接跟物理機器打交道。Mesos這里通過這樣的方式嘗試解決的即是資 源的靜態劃分問題，這意味著你不再需要針對每個特定的運行時分配一個對應的調度器去決定實際去執行它的workers，而取而代之的是，你有一個調度器去 和Mesos通信，而它會反過來依據整個資源池的剩余資源做調度。

這樣做帶來的最顯而易見的好處就是你可以在一批機器上運行多個不同的分布式系統并且更有效的（不再是靜態劃分）動態劃分和共享這些資源。

其次，之所以這樣抽象設計的另外一個重要原因在于它能夠提供一個通用功能集（故障檢測、分布式任務、任務啟動、任務監控、結束任務、清理任務等），這樣一來就無需每個分布式系統都各自重復的去實現這樣一套邏輯。

Mesos 適合作為數據中心的哪一層的抽象?

Mesos 這一層抽象實現的目的即是想要嘗試通過使用并更好的調度資源使得運行在其之上的這些框架變得更加易于構建和運行。

IaaS的抽象的是機器，例如你給它指定一個數字，它便會生成一堆的機器而這也可以看作是Mesos概念模型更底層化的一個抽象。PaaS則考慮的更多是 部署和管理應用/服務，它并不關心底層的那些基礎架構，而你可以把它看作是Mesos概念模型的一個更高層面的抽象。在交互方面，PaaS可能是和開發者 直接交互，而Mesos則是以API的形式和軟件程序交互。

換句話說，你可以基于Mesos之上構建一個Paas系統（例如像Marathon - 它好像任何地方都比一個真正的Paas系統更像PaaS），同時你可以在一個IaaS上運行Mesos（例如OpenStack）。

如果你將你的Mesos運行在一個組合系統（例如就像Openstack + 物理硬件 + 虛擬機）之上，那么你可以很直觀的再次體會到動態劃分資源的好處，那便是你能夠跨越這些底層組件而直接的去管理和計劃你的工作負載，某種意義上來說，你可 以認為Mesos類似于是一個數據中心的內核，即它負責將物理機器抽象成資源，從而使得你能夠忽略底層組件的存在，通過消費Mesos的抽象資源來構建分 布式系統。

因此我們可以說，Apache Mesos是為構建和運行其它分布式系統（例如像Spark）提供服務的分布式系統。

Mesos架構內幕

在 Mesos 里，一個框架程序（或者說分布式系統）發起的一次請求會在被接收到的那個時刻由調度器承接和分配。這跟傳統分布式系統一般人為發起請求的方式不太一樣（再 強調一下，Mesos將會讓框架程序發起請求，而不是人工操作），傳統的方式即需要在人為發起請求時設定好需要分配的特定資源，然后再去真正請求和獲取這 些資源，這類情況中最典型的莫過于需求場景的變換（設想在Map/Reduce的場景下，比如在Map和Reduce階段切換之際產生的一個需求資源的變 化）

與傳統分布式系統不一樣的是，Mesos 將會立馬為其分配所能分配的最大資源，而不是傻傻的在那等到滿足該請求的資源完成/完全到位（在這里它想要實現的便是在絕大多數情況下十分奏效的無阻塞式資源分配策略，即你無須立馬消費預期請求的全量資源的這樣的情景）。

當然，現在框架類應用（分布式系統）也可以使用Mesos提供的資源完成他們自己的調度，這便是所謂的 “二次資源調度”。

最終達到的效果即是你下發的一個任務可以在整個數據中心的任意一個地方提交并且運行。

構建這樣的“二次資源調度”系統的原因在于它可以在同一時間內支持多個分布式系統。同樣以上面的例子來解釋，Mesos為Spark提供和分配所 需的資源。而這里，Spark則負責決策和分配這些可用資源去運行實際任務（即因為可用的資源得以滿足需求，所以我才能夠實際去運行這些map任務）。

所以一旦一個任務被框架應用提交到Mesos，那么這些任務就必須被實際執行。Mesos master 負責指派任務給每個slave，而每個slave通過上面跑著的agent來管理和運行這些任務。（這即是說如果這個任務是對應的一個命令，那么它會去執 行它，如果它需要一些特定的資源來完成這個任務，比如像jar包，那么它會先獲取所需的資源，然后在一個沙盒里執行它，最后才發起這個任務）

或者說你也可以這樣，框架應用可以通過一個執行器（框架應用需要一個中間層，這個中間層可以用來多線程執行任務）來靈活的決定它想要執行的任務。

為了保證資源的相對隔離性，Mesos 對 Kernel的cgroups和namespaces 提供了內置的原生支持，當然你也可以將一個Docker容器當做一個任務去運行。這樣一來，它便給你提供了一個多租戶的（框架）資源池的訪問機制（跨主機 和主機內部的進程間通信）。

你可以預請求你所需的資源，當然這樣你也就回到了資源固定劃分的時代。如果你有一些有狀態的應用，那么你需要預定一些資源（這類任務通常需要在同一臺主機上運行）并且需要一些持久化的存儲卷（數據需要能夠支持故障遷移和恢復），而這類需求Mesos同樣能夠支持。

Mesosphere DCOS

DCOS（數據中心操作系統）即是Mesos的“核心”與其周邊的服務及功能組件所組成的一個生態系 統。例如像mesos-dns這樣的插件模塊，類似一個CLI，一個GUI又或者是提供你想運行的所有的包的倉庫等工具，以及像Marathon（又名分 布式的init）、Chronos（又名分布式的cron）這樣的框架等等。

顧名思義，它即是意味著一個跨越在數據中心或者云環境所有主機之上的操作系統。DCOS 可以運行在任意的現代Linux環境，公有或私有云，虛擬機甚至是裸機環境。（當前所支持的平臺有：亞馬遜AWS、谷歌GCE、微軟Azure、 OpenStack、Vmware、RedHat、CentOS、CoreOS以及Ubuntu）。迄今為止，DCOS 在其 公有倉庫上已經提供了多達40余種服務組件（Hadoop、Spark、Cassandra、Jenkins、Kafka、MemSQL等等）。

另附 Mesosphere 集群操作系統（DCOS）入門視頻。

原文鏈接：Introduction to Apache Mesos and Mesosphere DCOS （翻譯：吳佳興）

來自：http://dockone.io/article/686