Mesos和YARN的區別以及它們如何協同工作

| 2016-01-04 | 0 Comments


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有意打算消除數據壁壘,但是在拆去一些壁壘的同時,其他類型的壁壘又在同樣的地方產生。作為另一種技術方案,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任務是持續一段時間的批處理任務)。這意味著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上並提供下載。這裡提供文檔更詳細地描述瞭它是如何運作的。

@Container容器技術大會正在火熱報名中,知名公司的Docker、Kubernetes、Mesos應用案例,.下圖可查看大會具體內容。



.左下角閱讀原文鏈接可進入大會官網。

分享這篇文章
Filed in: 最新
×