譯 | 像使用一臺主機一樣管理叢集

作者：michaelmalak

【編者的話】不論是 YARN、Mesos 還是 Omega，都是某種意義上為叢集設計的作業系統，讓使用者像使用一臺單機一樣來使用整個叢集。向下集中管理所有物理資源，向上承載各種叢集化的應用; 同時， docker 的出現也為雲作業系統提供了更有力的支撐。

1984年，SUN 的 John Gage 說出了那句家喻戶曉的名言 “網路就是計算機”

三十年後，Gage 的夢想“幾乎”成為的現實。特別是隨著 web 2.0 和雲端計算時代的到來，人們可以使用任何裝置從任何地方通過網際網路訪問任何雲端的資源。

不過即使在“雲端”，實際上還是一堆物理伺服器。每一臺伺服器的 CPU 和記憶體資源都是有限的，但是組合成叢集就像雲一樣無窮無盡。套用 Gage 的名言，可以說“叢集就是計算機”。

當單機的 CPU 效能和硬碟容量逐漸碰到了天花板，通過 Hadoop 這樣的叢集化技術來突破單機效能瓶頸就越來越流行。當然在 Hadoop 出現之前，叢集方案早就應用於高效能的生產系統，例如 Weblogic 或者叢集化的 WEB 伺服器（複雜均衡按照 round-robin 演算法將流量傳送到叢集中的 Web 伺服器上）。這些叢集方案都針對特定場景設計，無法像通用的計算機一樣用來執行各種不同的軟體。

Hadoop 是第一個具有通用的叢集化計算平臺特徵的技術，而且目前已經發展地相當成熟。隨著新的叢集化計算技術層出不窮，例如 Spark、Storm 和 Cassandra，運維人員希望能夠隔離它們以便更好的管理，同時，從節約成本的角度講， 大家又希望公司內部各個團隊能夠共用這些昂貴的計算資源。

目前解決這個問題的兩大法寶是 Hadoop YARN 和 Apache Mesos。Mesos 的設計受到了 Google 的 Omega 平臺啟發，而後者則來自 Google 內部久經考驗的Borg任務管理平臺。同樣的事情當初也發聲在 Hadoop 之上，它就是受到了 Google 的 GFS 和 Big-Table 啟發。不論是 YARN、Mesos 還是 Omega，都是某種意義上為叢集設計的作業系統，讓使用者像使用一臺單機一樣來使用整個叢集。向下集中管理所有物理資源，向上承載各種叢集化的應用。

因為 YARN 本身與 Hadoop/Map Reduce v2 繫結，對於使用早期 Hadoop 版本的開發者，升級到 YARN 也許是一個比較容易的決定。理論上可以將 YARN 跑在 Mesos 上，不過有些人擔心隨之而來的兩層資源分配問題。

Mesos 可以支援大量的框架（外掛），逐步在構建一個快速增長的生態環境。例如 Twitter的 Aurora 就是用來在 Mesos 管理的叢集上進行任務排程，已經成為了 Apache 的孵化器專案。此外 Ringmaster 則用來在 Mesos 上快速執行 Cassandra 和 Spark。

Chronos 相當於 Mesos 之上的 crontable，Marathon 則相當於 init.d，讓大家用熟悉的方式來排程任務。

最激動人心的還是 Docker 與 mesos 的整合，幾乎讓 Mesos 可以執行任何語言編寫的軟體。

Docker 的崛起本身和叢集技術倒沒有直接關係，它首先被用來代替傳統的 VM（虛擬機器）。容器分享了底層作業系統，遠比傳統 VM 更加輕量。類似技術在2000年就出現了，那就是“jail”命令。Wiki 有關詞條描述了 35 年來 chroot 如何發展到 jails，最後的 Docker 和容器成為了集大成者。

Docker 化的應用像一個 tar 壓縮包，在一臺普通的物理機上，你可以輕鬆地執行數十個獨立的 Docker。對於一個由 Mesos 管理的叢集，而且恰好你的應用某種程度上使用了分散式的架構，那麼瞬間你的叢集變成了一臺強大的大型機。其實 tar 本身意思是 “tape archive”，就是過去大型機磁帶系統的檔案格式。

使用 Docker 容器來完全取代傳統的 jar 或者 ear 檔案，一夜間用 Mesos 來完全取代 weblogic，還是有點操之過急——目前傳統軟體的架構依然是 web、計算邏輯和儲存分開部署。不過對於網際網路公司的後臺，用 Mesos 來承載 web 伺服器叢集應付高併發業務，完全不是什麼新鮮事兒了。

點選檢視英文原文