如何進行Mesos的實現分析

本篇文章給大家分享的是有關如何進行Mesos的實現分析，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

在這里詳細地介紹一下除了mesos資源分配器之外的元數據組織和加載、刪除任務的流程。

1 集群元數據管理

Mesos的架構如上圖所示，mesos包括兩個重要組成部分，首先是一個master進程，它管理運行在各個集群節點上的slave后臺進程，而slave進程則負責運行計算框架的計算任務，向master匯報集群節點的資源和計算框架的任務運行狀態。

Master的集群元數據管理主要是維護應用程序框架、slave、執行器，計算任務和resource offer之間的對應關系。Slave 則需要維護在slave上運行的所用應用程序框架執行器、任務及其狀態。

在mesos的設計中，master是一個非常輕量級地實現，不需要對集群的元數據進行持久化，應用程序框架和slave會向master注冊，上報其自身地狀態，那么master就可以快速失敗和重啟。而slave則需要持久化所有的框架信息、執行器信息和任務的狀態變化，slave持久化的目的是在slave進程掛掉時候，執行器和任務可以繼續運行，以及允許一個重新啟動的slave和正在運行的執行器和任務重新連接。

在mesos的master中，Resource offer是多個slave節點上的一組空閑資源。個人理解resource offer其實是代表slave上處于一種中間狀態的資源。表示資源分配器選取了這部分資源，并將其發送給應用程序框架，供應用程序框架進行選擇，但master還沒有收到resource offer的回復（這里回復是指framework選擇具體的offer然后下發任務給master）。一旦master收到任務后就會刪除resource offer，并更新slave的資源使用狀況。

1.1 Master的元數據管理

在master中，需要維護以下一些信息：

1、發送給框架但還沒有收到確認的的resource offer，需要在master的內存中進行記錄保存。Key為OfferId,value為Offer PB對象的指針。resource offer會在master收到framework下發的任務時，刪除對應的offer，更新slave上的資源（這里對framework有個要求，master在resource offer發送了n個offer,那么framework必須回復n個，否則會造成master的資源泄露）。

2、Master需要在內存中維護正在運行的應用程序框架。在應用程序框架中需要記錄所有此框架正在運行的任務、已經完成的任務，發送給應用程序框架但還沒有收到回復的resource offer、框架的已分配資源、在slave上運行的執行器信息。

3、Master需要在內存中維護所有保活的slave。在slave中需要記錄在slave上運行的應用程序框架的執行器、在slave上運行的所有任務，屬于slave上的已經發送給應用程序框架但沒有收到回應的offer，slave上所有offer占用的資源，已被任務和執行器使用的資源，負責slave心跳保活的process。

4、Master需要在內存中維護framework群組的信息。包括群組的role，屬于這個群組的應用程序框架。

以上這些元數據，都不需要進行持久化，在master失敗重啟后，各個slave和framework重新向master注冊后會重新上報和恢復。另外為什么像task和offer會在slave和framework中重復地存儲，因為slave和framework都有可能異常，那么需要master在slave或framework異常后處理task和offer的刪除和狀態更新，比如在framework異常時需要刪除所有屬于framework的任務和offer。

1.2 Slave上的元數據管理

在Slave上，將應用程序框架和框架的執行器進行抽象，分別用類Framework和Executor來表示，在Framework中維護此應用程序框架在這個slave上運行的執行器，而執行器則維護著所有在此執行器上運行的任務信息，并持久每一個任務的狀態變化。如下圖所示：

Framework的執行器維護著所有在執行器中運行的處于各種狀態的任務，執行器有四個隊列，分別對應四種不同狀態的任務，這四個隊列如下：

LinkedHashMap<TaskID, TaskInfo> queuedTasks;  //任務已經下發，但執行器還沒啟動，所以任務暫時放在這個隊列中。
LinkedHashMap<TaskID, Task*> launchedTasks;    // 已經在執行器中運行的任務
LinkedHashMap<TaskID, Task*> terminatedTasks; //已經結束（master向slave下發刪除任務的命令）但沒有釋放的任務
boost::circular_buffer<Task> completedTasks;     //已經完成的任務，放在circular_buffer中延遲釋放

在framework中還維護著應用程序框架所有已經下發到slave上但處于啟動狀態的執行器和任務的映射。為什么要維護這么個映射呢，因為mesos采用了libprocess作為并發框架，啟動執行器運行任務是異步執行，在這個過程中如果框架和執行器被刪除，那么需要保證框架和執行器的持久化目錄不被刪除，所以維護這個映射來做一些異常處理，通過延后垃圾回收的方式回收這些已經被刪除的框架和執行器的目錄文件。

Slave持久化的數據分成五個部分，分別是slave的信息、framework的信息、executor的信息、任務的信息，和任務的狀態變化。

1、 slave信息的持久化：在slave成功向master注冊后，收到SlaveRegisteredMessage信息后的處理函數registered會對slave的信息進行持久化。

2、 framework和executor信息的持久化：framework和執行器的持久化都在其構造函數里完成。在加載新任務(runTask)時，會創建新的framework和executor。

3、 任務的持久化：在執行器已經在運行的情況下，會在加載任務時進行持久化；或者執行器正在注冊，則在任務進行排隊時會進程持久化。

4、 任務的狀態變化持久化：任務的狀態變化的持久化稍微復雜一點。slave用三個類實現了對所有運行在slave上的task的狀態管理，分別是StatusUpdateManager、StatusUpdateManagerProcess、StatusUpdateStream這三個類；StatusUpdateManager僅僅是一個wrapper，StatusUpdateManagerProcess管理所有在slave上運行的框架的task狀態更新，在收到狀態更新后先進行持久化，然后向master發送狀態更新，接收scheduler的狀態更新確認，再對確認進行持久化。StatusUpdateStream完成task的狀態更新和確認的持久化工作。Task的狀態更新有兩種，一種是update，是由執行器向slave發送的狀態更新；另一種是scheduler向slave發送的task狀態確認。這兩種都需要進行持久化。在StatusUpdateStream維持著三個數據結構用于維護這些狀態：

hashset<UUID> received;

hashset<UUID> acknowledged;

std::queue<StatusUpdate> pending;

用于記錄task的狀態更新的執行狀態，received中保存的是slave接收到執行器發送的task狀態更新。Acknowleged是scheduler向slave發送確認的task狀態更新。Pending中是已經接收到但沒有進行確認的task狀態更新。

下圖是這三個類的類圖：

2 加載task和刪除task的流程圖

加載Task的流程圖如下：

1、master進行resource offer：master在初始化、framework注冊、slave注冊時都會進行resource offer，而且除了以上事件之外，master會定期地進行resource offer。Master資源調度算法見我的另外一篇博客。

2、framework在接收到ResourceOffersMessage信令后，會調用scheduler的resourceOffers接口，scheduler要選擇自己需要的資源，然后調用SchedulerDriver的launchTasks接口，向master下發任務，SchedulerDriver會調用SchedulerProcess的launchTasks接口，把任務組裝在LaunchTasksMessage中，進行發送。SchedulerProcess負責接收和發送與master的信令交互。Scheduler是實現具體具體框架的業務邏輯，SchedulerDriver是對SchedulerProcess和Scheduler進行解耦。Framework相關的類圖如下所示：

3、master在收到LaunchTasksMessage，會在內存中創建維護執行器和任務的信息，然后向slave下發任務，下發任務的信令為RunTaskMessage。

4、slave在加載任務時，需要做的工作比較多；如果task對應的框架或執行器沒有被創建，那么需要創建一個新的框架并持久化框架的ID和信息，或者讓isolator分配資源并啟動一個執行器進程，執行器進程啟動后會向slave進行注冊。加載任務時會先對task信息進行持久化，然后向執行器的數據結構中添加task信息。如果此時執行器進程正在向slave注冊（slave中的執行器狀態為REGISTERING），那么會將先task進行放在隊列中緩存。否則會向執行器進程發送RunTaskMessage信令，讓執行器運行task。

5、如果執行器剛啟動，則啟動之后根據傳入的slave的IP和端口，連接slave；然后發送RegisterExecutorMessage信令，向slave進行注冊。

6、slave在收到RegisterExecutorMessage，更新執行器的狀態，如果支持持久化，那么將執行器的pid進行持久化；如果緩存隊列中有等待處理的task，則執行器添加這些task，使用isolator來分配執行器的資源。回復ExecutorRegisteredMessage給執行器進程，然后將所有緩存隊列中等待處理的task打包在RunTaskMessage信令中，發送給執行器進程來執行這些task。清空執行器的緩存隊列。

7、執行器進程在接收到RunTaskMessage信令，會調用執行器的抽象接口launchTask，來加載任務。

8、執行器進程在執行任務過程中任務出錯，或者任務結束都需要更新任務狀態，發送StatusUpdateMessage信令給slave。

9、slave在收到StatusUpdateMessage信令后，會更新任務信息，并將任務狀態更新進行持久化（由StatusUpdateManager這個類完成），然后向master轉發StatusUpdateMessage信令，傳遞任務的狀態更新。如果task的狀態為failed、killed或者finished，則執行器會重新調整使用的資源，由isolator為執行器重新分配資源。

10、執行器進程收到任務狀態更新的應答。

11、master收到StatusUpdateMessage后，會更新任務狀態信息，并向framework轉發任務狀態更新。如果task已經結束（為failed、killed以及finished），則從master的內存中清除這些被刪除的任務，

12、framework收到task狀態更新后，會調用scheduler的statusUpdate接口。如果task已經結束，則需要框架進行一些清理工作。

刪除任務的流程圖如下：

刪除任務則較為簡單，刪除任務是由framework發起的，killTaskMessage沿著framework、master、slave、執行器這一條鏈路上進行傳遞，但在處理killTaskMessage信令時，正常情況下都不會直接刪除task，而是在后續處理StatusUpdateMessage時，檢測到task狀態為failed、killed和finished才會真正刪除task。

以上就是如何進行Mesos的實現分析，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。