Mesos 和YARN：兩個集群的故事

這是一個關于兩個孤立集群的故事。第一個是Apache Hadoop集群，它的資源與Hadoop進程完全隔離。另一個集群指代所有的資源，這些資源并不是Hadoop集群的一部分。通過這種方式來區分兩個集群是因為Hadoop通過Apache YARN（Yet Another Resource Negotiator）來管理自己的資源。對于Hadoop來說，在沒有大量數據任務在隊列中時，這些資源常常是未被充分使用的。當一個大數據任務運行時，這些資源迅速被用到極限，并且在請求更多資源。這對于第一種集群而言相當困難。

盡管Hadoop有意打算消除數據壁壘，但是在拆去一些壁壘的同時，其他類型的壁壘又在同樣的地方產生。

作為另一種技術方案，Apache Mesos也有意消除這些壁壘。但Mesos常被用來管理第二種集群，這些集群包括除去Hadoop任務之外的所有資源。

Mesos和YARN的不同，是故事的開端。正如它們并不兼容，經常互相競爭。而我的故事，講的卻是它們協同工作。

Mesos和YARN的簡介

Mesos和YARN之間的主要區別圍繞著優先級的設計以及調度任務的方式。Mesos于2007年誕生于UC Berkeley并在推ter和Airbnb等公司的商用下不斷被鞏固，它的設計初衷是作為整個數據中心的一個可拓展的全局資源管理器。YARN出于管理Hadoop規模的需求。在YARN出現之前，資源管理（功能）集成在Hadoop MapReduce V1架構中，為了有助于MapReduce的擴展而將其移除（轉移到YARN中實現）。MapReduce的Job Tracker并不能在超過上千臺的機器中有效調度MapReduce任務。YARN在下一代Hadoop生命周期中被創造，主要圍繞著資源拓展。

Mesos的調度

Meso決定了那些資源可用，它把分配請求返回給一個應用調度器（應用調度器和執行器被稱作“框架”）。這些分配請求被框架接受或者拒絕。這個模型被認為是非單體模型，因為它是一個“兩級”調度器，調度算法是可拔插的。Mesos允許任何實現任何調度算法，每個算法都能根據自己的策略進行接收或是拒絕分配請求，并且可以容納成千上萬種調度程序以多租戶的方式運行在同一個集群。

Mesos的兩級調度模型允許每個框架（自己）決定使用哪種算法來調度運行的工作。Mesos扮演仲裁者，在多個調度器上來調度資源，解決沖突，并且確保資源基于業務策略被公平地分發。分配請求到來時，框架會執行任務來消費那些提供的資源。或者框架可以選擇拒絕請求并且等待下一個分配請求。這種模型與在一臺筆記本電腦或智能手機上如何同時運行多個app十分類似，當需要更多內存時會創建新的線程或請求，操作系統來仲裁管理所有的請求。多年的操作系統和分布式系統的實踐發展證明，這種模型的好處在于它具有良好的擴展性。它已被Google和推ter證明。

YARN的調度

現在，我們再看一下YARN這邊發生了什么。當job請求到達YARN資源管理器，YARN評估所有可用的資源然后調度job。YARN以一種整體的方式，直接決定job運行的位置。在MapReduce架構演變的過程中，重申強調YARN的出現十分重要。在Hadoop任務的資源規模伸縮需求的驅動下，YARN把資源管理的模型從MR的Job Tracker中獨立出來，在Resources Manager組件中實現。

為了調度Hadoop任務，YARN進行了優化（過去一貫的Hadoop任務是持續一段時間的批處理任務）。這意味著YRAN既不是為長時間運行的服務而設計，也不是為滿足短期交互/快速響應式請求（像簡短而快速的Spark任務），盡管它可能調度其他種類的工作任務，但這并不是一個理想的模型。MapReduce的資源需求、執行模型和架構需求不同于長時間運行的服務，如Web服務器、SOA應用程序或是像Spark和Storm那樣的實時任務。同時，YARN為了易于無狀態的腳本任務重啟而設計。它并不能處理像分布式文件系統或數據庫那樣的有狀態的服務。然而YARN的整體的調度器理論上可以處理不同類型的工作負載（通過把新的算法合并到調度代碼），對于支持日益復雜的調度算法，這并不是一個輕量級的模型。

YARN vs Mesos？

在對比YARN和Mesos時，明白整體的調度能力和為什么需要兩者選一十分重要。雖然有些人可能認為YARN和Mesos大同小異，但并非如此。區別在于用戶一開始使用時需求模型的不同。每種模型沒有明確地錯誤，但每種方法會產出不同的長期結果。我認為這就是選擇如何使用它們的關鍵。Ben Hindman和Berkeley AMP實驗室在設計Mesos時，與Google設計Omega的團隊同期進行，Mesos系統得益于Google的Omega系統設計的經驗，構建了一個更好的非單體（兩階段）的調度器。

當你把如何管理數據中心作為整體來評估時，一方面使用Mesos來管理數據中心的所有資源，另一方面使用YARN來安全的管理Hadoop任務，但它并不具有管理整個數據中心的能力。數據中心運營商傾向于把集群劃分為的不同區域（Hadoop集群和非Hadoop集群）來應對這兩個場景。

在同一個數據中心使用Mesos和YARN，為了受益于資源管理器，目前需要創建兩個靜態分區。此時意味著當指定資源被Hadoop的YARN管理時，Mesos就無法起作用。這也許過于簡化了，盡管這么做確實有效。但本質上，我們是想避免這種情況。

項目Myriad介紹

這不禁讓我們發問：可不可以讓YARN和Mesos一起工作呢？能否讓企業和數據中心受益于它們的協調工作？答案是肯定的。一些著名的公司——eBay,MapR和Mesosphere共同合作了一個項目叫做 Myriad .

這個開源軟件項目既是一個Mesos框架，又是一個YARN調度器，這就使得Mesos能夠管理YARN的資源請求。當一個任務到達YARN時，它會通過Myriad調度器調度它，使請求與Mesos提供的資源匹配。相應的，Mesos也會將它傳遞給Mesos工作節點。之后，這個Mesos節點會把這個請求與一個正在執行YARN節點的管理器的Myriad執行器關聯。Myriad在Mesos資源啟動YARN節點管理器，啟動之后，Mesos資源會告訴YARN資源管理器哪些資源可用。這時候YARN就可以隨意地使用這些資源。Myriad為Mesos的可用資源池和YARN的任務（需要用到Mesos中資源）之間架起了一座無縫連接的橋梁。

這種做法的優點是，它不僅讓你在共享的集群中彈性的使用YARN，使得YARN比最初設計時更具活力和彈性。而且，它使得數據中心的運維團隊在給YARN資源擴容時無需重新配置YARN集群。整個數據中心的擴容變得十分容易。該模型提供了一種簡單的方式運行和管理多個YARN的實現，甚至在同一個集群上運行多個不同版本的YARN。

Myriad把YARN和Mesos兩者的優勢結合起來。通過使用Myriad項目，讓Mesos和YARN可以協作，你可以完成一個實時業務。數據分析可以在和運行生產服務的相同硬件上執行。你不再需要面臨由靜態分區引起的資源限制（和低利用率）。資源可以根據業務的需求彈性的伸縮。

最后的思考

為了確保人們理解這個項目的來源，我認為Mesos和YARN擅長在自己特定的場景下工作，并且都有提升的空間。兩者的資源管理器在安全領域都能有所提升；而安全的支持對企業采納與否至關重要。

Mesos需要一個端到端的安全架構，我個人對使用Kerberos來提供安全支持不會拒絕，但以我個人經驗這樣做并不會簡單。對Mesos其他方面的提升同樣十分復雜，主要歸納為資源的搶占和撤銷。假設一個業務的所有資源已經分配，當業務依賴運行的一個最重要的資源項需要擴容時，甚至這個擴容工作僅需要數十分鐘來完成，你仍然會因為缺少資源而無法完成。資源的搶占和撤銷就可以解決這個問題。目前，Mesos圍繞著這個問題有多種解決方案，但我十分期待Mesos委員會使用 Dynamic Reservations 和 Optimistic (Revocable) Resources Offers 來解決這個問題。

Myriad作為一種新的技術，讓我們把數據中心或云端的所有資源當作一個簡單的資源池來使用。正如Hadoop消除數據孤島之間的壁壘一樣，Myriad消除了孤立的集群之間的壁壘。通過Myriad，開發者可以專注于業務依賴的數據和應用程序，而運維團隊可以更敏捷地管理他們的計算資源。這為我們專注數據而不被基礎設施持續困擾打開了另一扇窗。有了Myriad，在實現完整的靈活性、敏捷和伸縮方面，存儲網絡的限制和計算與存儲之間的協調就成為我們“最后一英里的擔憂”。

Myriad項目 托管在GitHub上并提供下載。這里提供文檔更詳細地描述了它是如何運作的。

原文鏈接： A tale of two clusters: Mesos and YARN （翻譯：張怡）