Mesos優缺點有哪些？

01-08

加州大學伯克利分校提出的mesos有哪些優缺點？

［持續更新］

==================再再更=======================

最近我們在 Mesos 之上開源了一個 golang 的調度器 swan Dataman-Cloud/swan 。該調度器的初衷是因為 Marathon 在一些場景下已經無法滿足用戶需求，譬如灰度發布，更靈活的服務發現機制等，鑒於以上我們決定做一個golang版本的mesos調度器。

==================再更=======================

docker 1.12 將 SwarmKit 內置其中了。基於這個寫了篇技術文章

比拼Mesos/Marathon？基於Docker 1.12 Swarm集群管理深度實踐

同時我們基於 docker 1.12 開源了一個集群管理工具 #golang# #AngularJS#

GitHub - Dataman-Cloud/crane: Control plane based on docker built-in swarm

Feature List:

Swarm features: Portal every feature of swarm almost. Crane has highlighted the common swarm functions and improved the user experiences through the friendly frontend.
Stack templates management: User can save a running stack as a template, by which others can deploy repeatly.
Image management: The private image owned by user can be publiced to others.
Fuzzy search: A in-memory index maintained by the backend serves the function.
Node operation: Crane details about a node such as kernel version, docker info, docker images and also containers running on the node.
Network Management: The overlay network CRUD.
Registries Authentation Managment: You can save your private registry username/password pair to Crane, with which a to-be-deployed stack with restricted image access can attach.
Webssh: Command "docker exec" is the magic behind it.

==================最近又對比了下mesos 與 swarm ================

Docker Swarm與Apache Mesos的區別

summary:

Docker Swarm 是目前 Docker 社區原生支持的集群工具，它通過擴展 Docker API 力圖讓用戶像使用單機 Docker API 一樣來驅動整個集群；而 Mesos 是 Apache 基金會下的集群資源管理工具，它通過抽象主機的 CPU、內存、存儲等計算資源來搭建一套高效、容錯、彈性的分散式系統。

顯然，這兩者功能上有交集，網路上也有很多關於 Docker Swarm, Mesos 和 Kubernetes 之間區別的討論，作為一個 Mesos 重度用戶，最近也抽時間把玩了下 Docker Swarm。一路下來，Docker Swarm 給我的感覺首先是它特別簡單、靈活，相較於 Mesos 而言， Docker Swarm 對集群的侵入性更小，從而資源損耗也更低；其次，我特別想強調的是目前看來，雖然它與 Mesos 之間功能有重疊，但是兩者關注在不同的東西上了，所以拿這兩者作比較沒有多大意義。當然，未來這種情況可能會發生變化，這取決於社區的 roadmap 。下面我會從多個角度把 Docker Swarm 和 Mesos 進行比較。

============================我是分割線======================

Docker大火，我們公司也在使用Docker+Mesos，給出些自己的看法。

歷史

先八卦一下Mesos的歷史，其實Mesos並不是為Docker而生的，它產生的初衷是為spark做集群管理。而且，Mesos有自己的容器隔離，後來，隨著Docker的崛起，Mesos就開始支持Docker容器了。再後來，google一哥們兒發了篇paper，對比google內部的borg(Omega?)，Mesos和Yarn（是不是Yarn）三個集群管理工具的性能，大致結論就是Mesos跟google內部的集群管理工具有異曲同工之妙。有了Docker助力，再加上google的paper，大家就開始去嘗試Mesos了。據我在網上搜羅的消息，國外的twitter，apple（用Mesos管理siri的集群），uber（uber的開發在Mesos的mail-list說他們已經使用Mesos有一段時間了，同時準備把更多的東西遷到Mesos集群上），國內的愛奇藝（視頻轉碼），數人科技（敝公司）都已經或正在使用Mesos集群。

優點

資源管理策略Dominant Resource Fairness(DRF), 這是Mesos的核心，也是我們把Mesos比作分散式系統Kernel的根本原因。通俗講，Mesos能夠保證集群內的所有用戶有平等的機會使用集群內的資源，這裡的資源包括CPU，內存，磁碟等等。很多人拿Mesos跟k8s相比，我對k8s了解不深，但是，我認為這兩者側重點不同不能做比較，k8s只是負責容器編排而不是集群資源管理。不能因為都可以管理docker，我們就把它們混為一談。
輕量級。相對於 Yarn，Mesos 只負責offer資源給framework，不負責調度資源。這樣，理論上，我們可以讓各種東西使用Mesos集群資源，而不像yarn只拘泥於hadoop，我們需要做的是開發調度器（mesos framework）。
提高分散式集群的資源利用率：這是一個 generic 的優點。從某些方面來說，所有的集群管理工具都是為了提高資源利用率。VM的出現，催生了IaaS；容器的出現，催生了k8s, Mesos等等。簡單講，同樣多的資源，我們利用IaaS把它們拆成VM 與利用k8s/Mesos把它們拆成容器，顯然後者的資源利用率更高。(這裡我沒有討論安全的問題，我們假設內部子網環境不需要考慮這個。)

缺點

門檻太高。只部署一套Mesos，你啥都幹不了，為了使用它，你需要不同的mesos framework，像Marathon，chronos，spark等等。或者自己寫framework來調度Mesos給的資源，這讓大家望而卻步。
目前對stateful service的支持不夠。Mesos集群目前無法進行數據持久化。即將發布的0.23版本增加了persistent resource和dynamic reserver，數據持久化問題將得到改善。
臟活累活不會少。Team在使用Mesos前期很樂觀，認為搞定了Mesos，我們的運維同學能輕鬆很多。然而，根本不是那麼回事兒，集群節點的優化，磁碟，網路的設置，等等這些，Mesos是不會幫你乾的。使用初期，運維的工作量不僅沒有減輕，反而更重了。
Mesos項目還在緊鑼密鼓的開發中，很多功能還不完善。譬如，集群資源搶佔還不支持。

針對weitao提到的幾個缺點，Mesos已經到了1.2.0。我像大部分問題都已經解決或者在解決中。

&> 1.門檻太高。只部署一套Mesos，你啥都幹不了，為了使用它，你需要不同的mesos framework，像Marathon，chronos，spark等等。或者自己寫framework來調度Mesos給的資源，這讓大家望而卻步。

Mesos 目標是在於做數據中心操作系統的Kernel，正如Linux Kernel一樣，只做最核心的調度和資源隔離，正如Linux Kernel不會去做Gnome，KDE等等跑在Linux上面的應用程序需要做的事情一樣。因為各個公司和組織的內部系統不一樣，Mesos傾向於提供模塊化插拔介面，便於各種不同類型的第三方集成，包括驗證，log收集等等。

這也是為啥需要Swan, Spark, Marathon等等框架的原因，因為每個使用Mesos的用戶和公司都有不同的場景，這也是為啥apache/mesos 列出的Frameworks涵蓋了從服務到批量任務，從數據存儲到深度學習框架等等的Framework的原因。把更專業的層交給更專業的Swan，Marathon，Spark，Tensorflow去處理，Mesos更專註如何擴展到數十萬機器和更好的資源調度和容器隔離。

&> 2.目前對stateful service的支持不夠。Mesos集群目前無法進行數據持久化。即將發布的0.23版本增加了persistent resource和dynamic reserver，數據持久化問題將得到改善。

0.23後俞捷和其他twitter的童鞋已經加上了Persistent volumes。包括Cassandra，HDFS，ElasticSearch，Kafka，Ceph等對狀態有以來的都可以跑在Mesos上（mesosphere/dcos-commons ）。Uber和Apple已經在生產環境使用了很長時間，其中Uber把Cassandra和MySQL都放到了Mesos上進行調度（How Uber Manages a Million Writes Per Second Using Mesos and Cassandra Across Multiple Datacenters - High Scalability - ）。

&>3.臟活累活不會少。Team在使用Mesos前期很樂觀，認為搞定了Mesos，我們的運維同學能輕鬆很多。然而，根本不是那麼回事兒，集群節點的優化，磁碟，網路的設置，等等這些，Mesos是不會幫你乾的。使用初期，運維的工作量不僅沒有減輕，反而更重了。

長期來看，Mesos是可以減輕總體的運維工作量的，但是中間Mesos和已有的公司內部系統有個磨合的過程，在磨合期結束後，運維可以把精力更專註在其他方面上。以目前Twitter 3萬台的Mesos集群為例，只有一位與Mesos相關的運維童鞋。

而社區也一直在儘力讓Mesos更易用，包括1.2.0後更易用的命令行工具以便用戶直接遠程連接到容器中執行命令或者調試，就像舊有直接ssh到伺服器上一樣等等。需要有更多童鞋參與進來review patch讓更多功能能合併到Mesos的代碼庫中。

&> Mesos項目還在緊鑼密鼓的開發中，很多功能還不完善。譬如，集群資源搶佔還不支持。

Mesos 0.23 後增加了Oversubscription，允許低優先順序的任務（動畫渲染，數據分析）的資源被更高優先順序的任務（在線服務）搶佔。還有更多功能，歡迎使用。

我們已經使用了兩年了。現在主要面臨的問題是資源的碎片化，造成資源的利用率不夠高。 resource offer 這種機制似乎不可避免有這樣的問題。

優點:輕量級，目前已經有一些大廠在用，包括twitter

缺點:社區相對不夠活躍，

以一個團隊如何管理升級為例。無狀態應用程序可以從「藍/綠」部署方法中獲益;當舊的應用程序還在使用的時候，另一個完整版本的應用程序已經spun up，當舊的應用程序被銷毀時，流量切換到新的應用程序。但是，升級像HDFS或Cassandra這樣的數據工作負載需要一次離線，維護本地數據量以避免數據丟失，執行特定序列的升級，並在升級之前和之後對每個節點類型執行特殊檢查和命令。這些步驟中的所有環節針對特定的應用程序或服務，甚至是特定版本進行的。這使得用常規容器編排調度器管理數據服務變得非常困難。

作為一個集群管理器，Mesos的架構是為了解決一組非常不同的挑戰:

將數據中心資源整合成一個單一的池，以簡化資源配置，同時在私有或公共雲之間提供一致的應用程序和操作體驗;
在相同的基礎設施上使用不同的工作負載，比如分析、無狀態微服務、分散式數據服務和傳統應用程序，以提高利用率，降低成本和空間;
特定應用程序的任務(如部署、自修復、擴展和升級)設置為自動化day-two 操作;提供高可用的容錯基礎設施;
在不修改集群管理器或現有應用程序的情況下，提供常綠的可擴展性來運行新的應用程序和技術;
將應用程序和底層基礎設施彈性擴展到數萬個節點。

Mesos的獨特之處還在於，可以單獨管理各種不同的工作負載——包括傳統的應用程序，如Java、無狀態Docker微服務、批處理作業、實時分析和有狀態的分散式數據服務。Mesos廣泛的工作負載覆蓋來自於它的兩級架構，它支持「應用感知」的調度。應用感知調度是通過將應用程序特定操作邏輯封裝到「Mesos框架」(類似於運行中的runbook)來完成的。

Mesos Master資源管理器，提供這些底層基礎設施的框架部分，同時保持隔離。這種方法允許每個工作負載有自己專用的應用程序調度器，它了解其對部署、縮放和升級的具體操作需求。應用程序調度程序也獨立地被開發、管理和更新，這讓Mesos保持高度可擴展性，支持新的工作負載，或者隨著時間的推移增加更多的操作能力。

Mesos具備按需管理每個工作負載的能力，使得許多公司將Mesos作為一個統一的平台，並通過其將微服務和數據服務結合運行。運行數據密集型應用程序的一個通用參考架構是「SMACK堆棧」。

吾優測試 | 傳播軟體測試

雖然有大廠在用，但是是不是能夠很快的推廣，還得觀望，比較新的技術，還是需要一些公司，一些人出來牽頭的。