Mesos和YARN是怎么協同工作的

這篇文章主要講解了“Mesos和YARN是怎么協同工作的”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Mesos和YARN是怎么協同工作的”吧！

Hadoop 2.0之后把對集群資源的管理從MapReduce v1的JobTracker中提取出來，在YARN中進行了實現。雖然YARN支持了多種不同的計算框架，但依舊沒有很好的解決集群資源的彈性伸縮問題。本文介紹了一個新的項目- Myriad，它把YARN和Mesos兩者的優勢結合起來，不僅使YARN的運行使用更加靈活，而且讓整個數據中心的擴容變得更簡單。

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

圖1- 獨立集群- 來源：Mesosphere and MapR,侵刪.

盡管Hadoop有意打算消除數據壁壘，但是在拆去一些壁壘的同時，其他類型的壁壘又在相同的地方產生。作為新的技術方案，Apache Mesos也有意消除這些壁壘。但Mesos常被用來管理“第二種集群”，這些集群包括除去Hadoop任務之外的所有資源。

前面介紹的關于Mesos和YARN的不同點，這只是開始。正如它們并不兼容，經常互相競爭。而我的故事，講的卻是它們協同工作。

Mesos和YARN的簡介

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

Mesos的調度

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

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

YARN的調度

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

過去一貫的Hadoop任務是持續一段時間的批處理任務，YARN為了調度新的Hadoop任務進行了優化。這意味著YARN既不是為長時間運行的服務而設計，也不是為滿足短期交互/快速響應式請求（像簡短而快速的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中資源）之間架起了一座無縫連接的橋梁。

圖2- myriad如何工作？ 來源：Mesosphere and MapR,侵刪.

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

圖3- 資源共享 來源：Mesosphere and MapR,侵刪.

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

感謝各位的閱讀，以上就是“Mesos和YARN是怎么協同工作的”的內容了，經過本文的學習后，相信大家對Mesos和YARN是怎么協同工作的這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！