# 8-3 Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center
:::info
Mesos 以細粒度的方式共享資源，使框架能夠通過輪流讀取每台機器上存儲的數據來實現數據的本地性，為了支持現在框架的高級調度程序，Mesos 引入了一種稱為資源提供的**分散式雙層調度機制**，第一層由Mesos決定向每個框架提供多少資源，第二層由框架決定接受哪些資源以及在這些資源上運行哪些計算(也就是框架自己的scheduler將資源分配給自己內部的任務)。
:::

## Introduce
沒有任何框架是適合所有群集的，因此可以在每個cluster運行不同框架，為不同的cluster選擇最適合的框架，在框架之間重複使用cluster可提高利用率，並允許應用程式共享對大型資料集的訪問，這些資料集可能太大而無法跨集群複製。

目前的共享叢集的兩種常見解決方案是靜態分區集群，每個分區運行一個框架，為每個框架分配一組虛擬機器，但都存在「資源利用率低、未實現高效資料共享」的問題，主要是因為分配粒度和與現有框架不匹配。

* Mesos設計目的:
1. 多框架支援
2. 可擴展性
3. 容錯性和高可用性

* 挑戰
1. 複雜性。調度器需要提供一個足夠明確的API來捕捉所有框架的需求，並解決數百萬任務的線上最佳化問題，即使這樣的調度程序是可行的，這種複雜性也會對其可擴展性和彈性產生負面影響。
2. 新框架和新的調度策略會不斷出現，所以不能保證可以滿足所有的框架和調度策略。
3. 許多現有的框架實現了它們自己的複雜調度，將此功能轉移到全局調度程序需要昂貴的重構。

Mesos將調度權轉交給各個框架，Mesos透過一個新的抽象實現，稱為資源供給（resource offer），它封裝了框架可以在叢集節點上分配以運行任務的一組資源，Mesos根據組織策略（例如公平共享策略）決定給每個框架多少資源，而框架則決定接受哪些資源以及在哪些資源上運行任務。

雖然這種分散的調度模型可能無法總是產生全局最優的調度，但在實踐中發現，它的表現非常出色，使得框架能夠幾乎完美地滿足資料本地性（data locality）等目標。此外，resource offer 能夠簡單快速地實現，使Mesos具有高度的可擴展性和應對故障的穩健性。

## Target Environment
這邊拿Facebook的Hadoop data warehouse做舉例，說明它們想要支援的工作負載例子。
Facebook將其Web服務中的日誌載入到一個2000節點的Hadoop叢集中，用於商業智慧、垃圾郵件偵測和廣告優化等應用程式，大多數作業都短（作業運行時間的中間隔為84s），作業由細粒度的map和reduce任務組成（任務運行時間的中間隔為23s)。

為了滿足這些作業對效能的要求，Facebook 使用了 Hadoop 的公平調度程序，調度程序利用工作負載的細粒度特性來分配任務層級的資源並優化資料位置，但這樣的叢集只能執行 Hadoop作業，為了解決這個問題，才設計一個Mesos這樣的叢集資源管理系統。

## Architecture
### Design Philosophy
* 提供一個可彈性擴展的核心，使各種框架能夠有效地共享叢集資源。
* 定義一個最小的接口來實現跨框架的高效資源共享，將任務和執行的控制交給集群框架。

### Overview
Mesos的元件主要包括master process和slave process，master管理所有的slave，master使用resource offers跨框架實現細粒度共享，叢集框架在slave節點上運行任務。

運行在Mexos的叢集框架包含兩部分：
1. 註冊到master process中的**scheduler**，用來提供資源。
2. 運行在slave節點上的**executor**，用於運行叢集框架的任務。

將master確定要為每個框架提供多少資源時，框架的排程器會選擇要使用的資源，當框架接受提供的資源時，會向Mesos傳遞要啟動的任務描述，如Figure3。


>1. slave 1向主進程報告它有4個CPU和4GB的空閒內存，主進程調用分配模塊，該模塊告訴它應該將所有可用資源提供給框架1。
>2. 主進程向框架1發送一個描述這些資源的資源提供。
>3. 框架的scheduler向主進程回覆有關在slave上運行的兩個任務的信息，第一個任務使用2個CPU和1GB RAM，第二個任務使用1個CPU和2GB RAM。
>4. 主進程將任務發送給slave，slave將適當的資源分配給框架的執行進程，然後啟動這兩個任務（以虛線邊框表示）。
>(還有1個CPU和1GB的內存是空閒的，分配模塊現在可能會將它們提供給框架2。)

為了維持Mesos靈活性，**框架可以拒絕使用提供的資源，直到有滿足框架的資源出現**。為了避免框架需要等待很長時間才能收到滿意的資源，會允許框架設立filter，指定框架將始終拒絕某些資源。

### Resource Allocation
目前實現兩個分配模組:
1. 基於多資源**最大-最小公平性**的共享分配模組。
2. 實現嚴格**優先級分配**的模組，Hadoop和Dryad都使用了類似的策略。

因為叢集的資源可能會被長任務佔據滿，所以分配模組有終止任何一個任務的權限，包含兩個機制:
1. **允許框架保存一定的資源量，避免任務遺失**，一個框架獲取的資源低於其「被保證的分配」，則不應終止它的任何任務，如果是，則可能終止它的任何任務。
>被保證的分配指的是一定的數量資源，當集群框架持有的資源是這個數量時，叢集框架不會失去任務，這個數量由分配模組暴露給每個集群框架，來允許框架阻止自己被終止。
2. Mesos需要知道哪些框架會獲得更多的資源，從而確定何時觸發「取消任務」。

### Isolation
Mesos利用現有的網路隔離，為運行在同個slave節點上各個框架的executor之間提供了效能的隔離，由於這些隔離機制對平台具有依賴，Mesos透過可插拔的「隔離模組」支援多種隔離機制。

### Making Resource Offers Scalable and Robust
任務調度在Mesos中是一個循環的過程，所以需要它在解決故障問題上具有高效性和穩健性，所以Mesos提供三種機制來實現:
1. filter: 於指定框架是否會拒絕一個節點上的一束資源，因此可以在主節點上快速計算這些資源。
2. 將提供給框架的資源計入叢集的分配中
3. 如果一個框架在相當長的時間內沒有回應提供，Mesos會撤回該提供並將資源重新提供給其他框架。

### Fault Tolerance
所有框架都依賴Mesos的master，因此master的容錯非常重要。
* 將主進程設計為軟狀態，這樣一個新的主進程可以完全從 slave 和框架調度器持有的信息中重建其內部狀態。
>**什麼是soft state？**
>介於stateless和stateful之間。 master 會以slave 的名義維護狀態，但僅僅維持一段時間，過了這段時間，master 就會將這些狀態資訊丟掉。
* 使用 ZooKeeper 來進行領導者選舉，運行多個主進程以實現熱備份配置，當活動的主進程失敗時，slave 和調度器會連接到下一個當選的主進程並重新填充其狀態。
* Mesos向框架的調度器報告**節點故障和執行器崩潰**，框架可以使用其選擇的策略對這些故障做出反應。
* Mesos允許框架註冊多個調度器，當一個**調度器發生故障**時，另一個調度器會被Mesos的master接管。

## Mesos Behavior
這邊研究Mesos在不同工作負載下的行為，目標不是建立系統的精確模型，而是提供對其行為的粗略理解，以便描述Mesos的分佈式調度模型在何種環境中運行良好。
### Definitions, Metrics and Assumptions
* 考慮三個標準:
1. Framework ramp-up time(一個新框架完成資源分配的時間)
2. Job completion time
3. System utilization

* 從兩個維度描述工作附載
1. 彈性/剛性
* 彈性框架: 例如Hadoop和Dryad，可以向上或向下擴展其資源，也就是說，它可以在獲取節點後立即開始使用它們，並在任務完成後立即釋放它們。
* 剛性框架: 如MPI，只能在獲得固定數量的資源後才能開始運行其作業，並且不能動態地向上擴展以利用新資源或向下擴展，而不會對性能產生很大影響
2. 任務持續時間分佈: 考慮均勻和異構分佈

* 區分兩種類型資源
1. 必需資源: 框架必須獲得某一資源才能運行。
2. 優先資源: 框架在使用某一資源時性能更好，但也可以使用其他等效資源運行。

* 定義兩個假設:
1. 假設一個框架所要求的「強制性資源」的數量永遠不會超過其保證份額，確保框架在等待「強制性資源」釋放之前不會發生死鎖。
2. 假設所有任務都具有相同的資源需求，並在名為slot的機器片上運行，並且每個框架運行一個job。

### Homogeneous Tasks(同質任務)
考慮兩種任務執行時間分布:
* 常數: 所有任務的（時間）長度一樣
* 指數: 任務的（時間）呈指數增長

Table 2總結了對於兩種類型的系統框架(彈性/剛性)的啟動時間、作業完成時間和系統使用率。
>「T」表示平均執行時間。框架從沒有插槽開始，「k」是框架在調度策略下有權獲得的槽數，「βt」表示在框架一次獲得所有k個槽時，一個作業完成所需的時間。

### Heterogeneous Tasks(異質任務)
包含長任務和短任務，長期任務的平均持續時間明顯長於短期任務的平均持續時間，最壞的情況下，所有節點都被長任務佔據，短任務需要等待很長時間才能執行，但當框架能夠使用的slot越多，最壞情況發生的機率就會大大降低。

為了進一步減輕長期任務的影響，可以擴展 Mesos以允許分配策略在每個節點上為短期任務保留一些資源，也就是如果有任務的運行時間超過該設置，這個任務將被終止這，些時間限制可以在資源提供中向框架暴露，允許它們選擇是否使用這些資源。
>類似於 HPC 叢集中為短期作業設立單獨隊列的策略

### Placement Preferences
假設叢集框架對不同slot有偏好，考慮兩種情況:
1. 存在一種集群設置，在這個設置中，每個集群框架都能得到他的偏好槽，並且得到她全部的份額。
2. 沒有這樣的設置(某些框架對首選槽的需求超過了可分配的)，也就是一些偏好的slot不能被提供。需要用到公平調用原則。
>但Mesos的挑戰調度器不知道每種叢集框架的偏好，所以這邊使用**簡易執行彩票調度**，給每個集群架構提供給他們想要的分配成正比的槽。

>**甚麼是彩票調度?**
>基本概念是向進程提供各種系統資源（如CPU時間）的彩票，一旦需要做出調度決策時，就隨機抽出一張彩票，擁有該彩票的進程來獲得該資源。

### Framework Incentives
這邊討論群集框架的建議措施，從而改善他們的作業回應時間。
* 短期任務
* 集群框架能分配任何短期槽中保留的資源。
* 能在叢集框架遺失任務後，最小化減少不必要的工作。
* 彈性的擴展
* 框架一旦獲得資源，就可以開始工作，而不需要等到獲取了所有的資源才開始，使得框架能夠更早開始（和完成）其工作。
* 伸縮能力能夠允許叢集架構隨機抓取未使用的資源，因為它可以稍後釋放這些資源，而不會產生任何負面影響。
* 不接受未知資源

### Limitations of Distributed Scheduling
* Fragmentation
* 當任務有異質需求時，
* 當資源被短任務佔滿後，長任務可能會長時間處於飢餓狀態，因為一個短任務完成後，釋放的資源不符合長任務的需求，很快又會被其他短任務佔用。
* 相互依賴的叢集框架限制
* 叢集複雜性: 使用resource offer可能使叢集調度更複雜，但作者認為在這邊不需要擔心，原因如下:
* 無論是使用Mesos或中心調度器，框架都需要知道它們（對資源）的「偏好」，在中心調度器中，框架需要告訴調度器它們對資源的偏好，而在Mesos中，框架必須使用這些偏好來決定接受哪一個資源。
* 許多現有框架的調度策略都是線上演算法，因為框架無法預測任務運行時間，所以必須能夠處理故障和stragglers，這些策略很容易透過resource offer來實現。

## Implementation
### Hadoop Port
將Hadoop移植到Mesos只需進行相對少的修改，因為Hadoop的細粒度map和reduce任務可以乾淨地映射到Mesos任務，Hadoop 的主節點（JobTracker）和 Hadoop的從節點（TaskTrackers）自然地適應 Mesos模型，作為框架調度器和執行器
* 寫了一個 Hadoop 調度器，它連接到 Mesos，啟動 TaskTrackers 作為其執行器，並將每個 Hadoop 任務映射到一個 Mesos 任務。
* 使用延遲調度通過等待包含任務輸入數據的節點上的插槽來實現數據本地性。
* 更改 map 輸出數據的服務方式，以便減少任務的減少。
### Torque and MPI Ports
* 註冊到 Mesos 主進程後，框架調度器配置並啟動 Torque 服務器，然後定期監控服務器的作業隊列，當隊列為空時，調度器釋放所有任務（可選最小值設為 0）並拒絕所有來自 Mesos 的資源提供。
* 避免接受超出保證分配的資源，以防止作業被撤銷。
* 創建了一個Mesos MPI “包裝”框架，用於直接在 Mesos 上運行 MPI 作業。
### Spark Framework
* Spark 利用 Mesos 執行器的長期運行特性，在每個執行器中將數據集的一部分緩存在內存中，然後在這些緩存的數據上運行多次迭代，實現容錯。
* Spark 的實現規模小，但在迭代作業上性能比 Hadoop 高 10 倍。
* 使用 Mesos 的 API 節省了編寫主守護進程、從守護進程及其通信協議的時間。

<!-- ## Evaluation
在AWS EC2上用macrobenchmark來評測Mesos在下列4個工作負載中如何共享資源。
1. -->

## Conclusion and Future Work
Mesos是一個允許多樣化叢集計算框架高效共享資源的輕薄管理層，圍繞以下兩個設計元素構建，使得Mesos能獲得高使用率。
1. 在任務級別的細粒度共享模型
2. 被稱為resource offer的分佈式調度機制

## Reference
[譯文] https://blog.csdn.net/u011364612/article/details/53613511
[筆記] https://blog.csdn.net/MyNuTh/article/details/95488944
[筆記] https://arthemis911222.github.io/2019/09/04/p4/