最近梳理調度系統相關的一些設計，找到一篇5年前翻譯的文章，挺有意思的。可惜Myraid項目看起來發展不盡如人意。 http://dockone.io/article/927
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需要一個端到端的安全架構，我個人覺得可以使用Kerberos來提供安全支持，但根據個人經驗，這樣做應該不會簡單。對Mesos其他方面的提升同樣十分複雜，主要歸納爲資源的搶佔和撤銷。假設一個業務的所有資源已經分配，當業務依賴運行的一個最重要的資源項需要擴容時，甚至這個擴容工作僅需要數十分鐘來完成，你仍然會因爲缺少資源而無法完成。資源的搶佔和撤銷就可以解決這個問題。目前，Mesos圍繞着這個問題有多種解決方案，但我十分期待Mesos委員會使用Dynamic Reservations和Optimistic (Revocable) Resources Offers來解決這個問題。
Myriad作爲一種新的技術，讓我們把數據中心或雲端的所有資源當作一個簡單的資源池來使用。正如Hadoop消除數據孤島之間的壁壘一樣，Myriad消除了孤立的集羣之間的壁壘。通過Myriad，開發者可以專注於業務依賴的數據和應用程序，而運維團隊可以更敏捷地管理他們的計算資源。這爲我們專注數據而不被基礎設施持續困擾打開了另一扇窗。有了Myriad，存儲網絡的限制和計算與存儲之間的協調就成爲我們在實現完整的靈活性、敏捷和伸縮上的最後一個需要攻克的難題。
Myriad項目託管在GitHub上並提供下載。這裏提供文檔更詳細地描述了它是如何運作的。