叢集排程系統的演進

叢集（Cluster）：這個系統管理的 Linux 主機組成一個資源池，用來執行任務，這個資源池就是叢集。

作業（Job）：就是定義叢集如何去執行任務，在例子裡面 Crontab 就是一個簡單的作業，裡面明確的告訴了叢集需要在什麼時間（時間間隔） ，做什麼事情（執行的指令碼）。一些作業的定義會複雜很多，比如還會定義一個作業分幾個任務做完，以及任務之間的依賴關係，還包括每一個任務對資源的需求。

任務（Task）：作業需要被排程成具體的執行任務，如果我們定義了一個作業是每天晚上凌晨 1 點執行一個指令碼，那麼在每天凌晨 1點被執行的這個指令碼行程就是任務。

任務排程。作業提交給叢集排程系統之後，需要對提交的作業拆分成具體的執行任務，並且跟蹤和監控任務的執行結果。在分散式 Cron 的例子中，排程系統需要按照作業的要求定時啟動行程，如果行程執行失敗，需要重試等，一些複雜的場景，比如 Hadoop 的 Map Reduce ，排程系統需要把 Map Reduce 任務拆分成相應的多個 Map 和 Reduce 任務，並且最終拿到任務執行結果的資料。

資源排程：本質上是對任務和資源做匹配，根據叢集中主機的資源使用情況，分配合適的資源來執行任務。和作業系統的行程排程演演算法比較類似，資源排程的主要標的是，在固定的資源供給的情況下，盡可能提高資源使用率，減少任務等待的時間（任務等待資源去執行的時間），減少任務執行的延遲或者響應時間（如果是批次任務的話，就是任務從開始執行到結束的時間，如果線上響應式任務的話，比如 Web 應用，就是每一次響應請求的時間），盡可能公平（資源公平的被分配到所有任務）的同時，還需要考慮任務的優先順序。這些標的裡面有一些是有衝突的，需要平衡，比如資源利用率和響應時間，公平和優先順序。

Job Tracker 是叢集主要的管理元件，同時承擔了資源排程和任務排程的責任。

Task Tracker 執行在叢集的每一臺機器上，負責在主機上執行具體的任務，並且彙報狀態。

Resource Manager：承擔資源排程的職責，管理所有資源，將資源分配給不同型別的任務，並且透過“可插拔”的架構來很容易的擴充套件資源排程演演算法。

Application Master：承擔任務排程的職責，每一個作業（在 YARN 裡面叫做 Application）都會啟動一個對應的 Application Master，它來負責把作業拆分成具體的任務、向 Resource Manager 申請資源、啟動任務、跟蹤任務的狀態並且彙報結果。

將原來的 Job Tracker 的任務排程職責拆分出來，大幅度提高了效能。原來的 Job Tracker 的任務排程的職責拆分出來由 Application Master 承擔，並且 Application Master 是分散式的，每一個實體只處理一個作業的請求，將原來能夠支撐的叢集節點最大數量，從原來的5千節點提升到1萬節點。

任務排程的元件，Application Master，和資源排程解耦，而且是根據作業的請求而動態建立的，一個 Application Master 實體只負責一個作業的排程，也就更加容易支援不同型別的作業。

引入了容器隔離技術，每一個任務都是在一個隔離的容器裡面執行，根據任務對資源的需求來動態分配資源，大幅提高了資源利用率。不過有一個缺點是，YARN 的資源管理和分配，只有記憶體一個維度。

Mesos Master ，單純是承擔資源分配和管理的元件，的對應到 YARN 裡面就是那個 Resource Manager，不過工作方式會稍微有些不太一樣，後面會講到。

Framework，承擔作業排程，不同的作業型別都會有一個對應的 Framework，比如負責 Spark 作業的 Spark Framework。

YARN 中 Resource Manager 提供資源的方式是被動的，當資源的消費者（Application Master) 需要資源的時候，會呼叫 Resource Manager 的介面來獲取到資源，Resource Manager 只是被動的響應 Application Master 的需求。

Mesos 的 Master 提供資源的方式是主動的。Mesos 中的 Master 會定期的主動推送當前的所有可用的資源（就是所謂的 Resource Offer，後面統一都叫 Offer）給 Framework，Framework 如果有任務需要被執行，不能主動申請資源，只有當接收到 Offer 的時候，從 Offer 裡面挑選滿足要求的資源來接受（在 Mesos 裡面這個動作叫做 Accept），剩餘的 Offer 就都拒絕掉（這個動作叫做 Reject），如果這一輪 Offer 裡面沒有足夠能夠滿足要求的資源，只能等待下一輪 Master 提供 Offer。

任何一個 Framework 的決策效率會影響整體的效率。為了一致性，Master 一次只能給一個 Framework 提供 Offer，等待這個 Framework 挑選完 Offer 之後，再把剩餘的提供給下一個 Framework，這樣的話，任何一個 Framework 做決策的效率就會影響整體的效率；

“浪費”很多時間在不需要資源的 Framework 上。Mesos 並不知道哪個 Framework 需要資源，所以會出現有資源需求的 Framework 在排隊等待 Offer，但是沒有資源需求的 Framework 卻頻繁收到 Offer 的情況。

效能明顯提高。根據模擬測試一個叢集最大可以支撐 10 萬個節點，Twitter 的生產環境最大叢集支撐 8 萬個節點，主要原因是 Mesos Master主動 Offer 的機制，進一步簡化了 Mesos Master 的工作職責，Mesos 中將資源排程的過程（資源 —> 任務的匹配）分成了 2 個階段：資源 —> Offer —> 任務 。Mesos Master 只負責完成第一個階段，第二個階段的匹配交給 Framework 來完成。

更加靈活，能夠滿足更加負責的任務排程的策略。舉個例子，All Or Nothings 的資源使用策略。