如何進行Mesos的實現分析

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

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

1 集群元數據管理

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

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

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

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

1.1 Master的元數據管理

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

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

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

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

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

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

1.2 Slave上的元數據管理

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

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

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

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

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

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

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

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

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

hashset<UUID> received;

hashset<UUID> acknowledged;

std::queue<StatusUpdate> pending;

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

下圖是這三個類的類圖：

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下發(fā)任務，SchedulerDriver會調用SchedulerProcess的launchTasks接口，把任務組裝在LaunchTasksMessage中，進行發(fā)送。SchedulerProcess負責接收和發(fā)送與master的信令交互。Scheduler是實現具體具體框架的業(yè)務邏輯，SchedulerDriver是對SchedulerProcess和Scheduler進行解耦。Framework相關的類圖如下所示：

3、master在收到LaunchTasksMessage，會在內存中創(chuàng)建維護執(zhí)行器和任務的信息，然后向slave下發(fā)任務，下發(fā)任務的信令為RunTaskMessage。

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

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

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

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

8、執(zhí)行器進程在執(zhí)行任務過程中任務出錯，或者任務結束都需要更新任務狀態(tài)，發(fā)送StatusUpdateMessage信令給slave。

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

10、執(zhí)行器進程收到任務狀態(tài)更新的應答。

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

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

刪除任務的流程圖如下：

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

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