目錄

• Mesos簡介

• Zookeeper簡介

• Marathon簡介

• docker叢集實踐

• Mesos叢集部署

一、Mesos簡介

Mesos是Apache下的開源分散式資源管理框架，它被稱為分散式系統的核心。Mesos最初是由加州大學伯克利分校的AMPLab開發，後在Twitter得到廣泛使用。

• Mesos-Master：主要負責管理各個framework和slave，並將slave上的資源分配給各個framework。

• Mesos-Slave：負責管理本節點上的各個mesos-task，比如：為各個executor分配資源。

• Framework：計算框架，如：Hadoop、Spark、Kafaka、ElasticSerach等，通過MesosSchedulerDiver接入Mesos

• Executor：執行器，就是安裝到每個機器節點的軟體，這裡就是利用docker的容器來擔任執行器的角色。具有啟動銷燬快，隔離性高，環境一致等特點。

Mesos-Master是整個系統的核心，負責管理接入Mesos的各個framework(由frameworks_manager管理)和slave(由slaves_manager管理)，並將slave上的資源按照某種策略分配給framework(由獨立插拔模組Allocator管理)。

Mesos-Slave負責接受並執行來自Mesos-master的命令、管理節點上的mesos-task，併為各個task分配資源。Mesos-slave將自己的資源量傳送給mesos-master，由mesos-master中的Allocator模組決定將資源分配給哪個framework，當前考慮的資源有CPU和記憶體兩種，也就是說，Mesos-slave會將CPU個數的記憶體量傳送給mesos-master，而使用者提交作業時，需要指定每個任務需要的CPU個數和記憶體。這樣當任務執行時，mesos-slave會將任務放導包含固定資源Linux container中執行，以達到資源隔離的效果。很明顯，master存在單點故障問題，為此Mesos採用了Zookeeper解決該問題。

Framework是指外部的計算框架，如果Hadoop、Mesos等，這些計算框架可通過註冊的方式接入Mesos，以便Mesos進行統一管理和資源分配。Mesos要求可接入的框架必須有一個排程模組，該排程器負責框架內部的任務排程。當一個framework想要接入Mesos時，需要修改自己的排程器，以便向Mesos註冊，並獲取Mesos分配給自己的資源，這樣再由自己的排程器將這些資源分配給框架中的任務，也就是說，整個Mesos系統採用了雙層排程框架：第一層，由Mesos將資源分配給框架。第二層，框架自己的排程器將資源分配給自己內部的任務。

當前Mesos支援三中語言編寫的排程器，分別是C++、Java、Python。

為了向各種排程器提供統一的接入方式，Mesos內部採用C++實現了一個MesosSchedulerDriver(排程驅動器)，framework的排程器可呼叫該driver中的介面與Mesos-master互動，完成一系列功能(如註冊，資源分配等。)

Executor主要用於啟動框架內部的task。由於不同的框架，啟動task的介面或者方式不同，當一個新的框架要接入mesos時，需要編寫一個Executor，告訴Mesos如何啟動該框架中的task。為了向各種框架提供統一的執行器編寫方式，Mesos內部採用C++實現了一個MesosExecutorDiver(執行器驅動器)，framework可通過該驅動器的相關介面告訴Mesos啟動task的方式。

整體架構如圖1.1-1所示：

圖1.1-1總體架構

圖1.1-1展示了Mesos的重要組成部分，Mesos由一個master程序管理執行著每個客戶端節點的slave程序和跑任務的Mesos計算框架。

Mesos程序通過計算框架可以很細緻的管理cpu和記憶體等,從而提供資源。每個資源提供都包含了一個清單(slave ID,resource1：amount1,resource2,amount2,…)master會根據現有的資源決定提供每個計算框架多少資源。例如公平分享或者根據優先順序分享。

為了支援不同種的政策，master通過外掛機制新增額一個allocation模組使之分配資源更簡單方便。

一個計算框架執行在兩個組建之上，一個是Scheduler，他是master提供資源的註冊中心，另一個是Executor程式，用來發起在slave節點上執行計算框架的任務。master決定給每個計算框架提供多少計算資源，計算框架的排程去選擇使用哪種資源。當一個計算框架接受了提供的資源，他會通過Mesos的任務描述執行程式。Mesos也會在相應的slave上發起任務。

資源提供案例,如圖1.1-2所示：

圖1.1-2資源提供案例

下面我帶大家一起熟悉圖1.1-2的流程步驟：

1. slave1報告給master他擁有4核cpu和4G剩餘記憶體，Marathon呼叫allocation政策模組，告訴slave1計算框架1應該被提供可用的資源。

2. master給計算框架1傳送一個在slave上可用的資源描述。

3. 計算框架的排程器回覆給master執行在slave上兩個任務相關資訊，任務1需要使用2個CPU，記憶體1G，任務2需使用1個CPU，2G記憶體。

4. 最後，master傳送任務給slave，分配適當的給計算框架執行器，繼續發起兩個任務(圖1.1-2虛線處)，因為任有1個CPU和1G記憶體未分配，allocation模組現在或許提供剩下的資源給計算框架2。

除此之外，當任務完成，新的資源成為空閒時，這個資源提供程式將會重複。

二、Zookeeper簡介

Zookeeper是一個分散式的，開放原始碼的分散式應用程式協調服務，是Google的Chuby一個開源的實現，是Hadoop和Hbase的重要元件。它是一個分散式應用提供一致性服務的軟體，提供的功能包括：配置維護、名字服務、分散式同步、組服務等。

1.2.1Zookeeper角色

• Leader(領導者)：負責投票發起和決議，更新系統狀態。

• follower(跟隨者)：Follower用於接收客戶請求並向客戶端返回結果，在選主過程中參與投票。

• ObServer(觀察者)：ObServer可以接受客戶端連線，將寫請求轉發給Leader節點，但ObServer不參加投票過程，只同步Leader的狀態，ObServer的目的是為了拓展系統，提高讀取速度。

• Client(客戶端)：請求發起方。

1.2.2Zookeeper工作原理

Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是恢復模式(選主)和廣播模式(同步)。當服務啟動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和Leader的狀態同步以後，回覆模式就結束了。狀態同步保證了Leader和Server具有相同的系統狀態。

為了保證事物的順序一致性，Zookeeper採用了遞增的事物ID號(zxid)來標識事物。所有的提議(proposal)都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識Leader關係是否改變，每次一個Leader被選出來，它都會有每一個Server在工作過程中三種狀態。

• q   LOOKING：當前Server不知道Leader是誰，正在搜尋。

• q   LEADING：當前Server即為選舉出來的Leader。

• q   FOLLOWING：Leader已經選舉出來，當前Server與之同步。

1.2.3Zookeeper選舉流程

當Leader崩潰或者Leader失去大多數的Follower，這時候zk進入恢復模式，恢復模式需要重新選舉出一個新的Leader，讓所有的Server都恢復到一個正確的狀態。

ZK的選舉演算法有兩種：

1. 基於Basic paxos實現

2. 基於fast paxos演算法實現

系統預設的選舉演算法為fast paxos。

1.2.4Zookeeper同步流程

選完Leader以後，zk就進入狀態同步過程。

• Leader等待server連線。

• Follower連線Leader，將最大的zxid傳送給Leader。

• Leader根據Follower的zxid確定同步點。

• 完成同步後通知Follower已經成為uptodate狀態。

• Follower收到uptodate訊息後，又可以重新接受client的請求進行服務。

1.2.5Zookeeper工作流程

Leader三大功能：

• 恢復資料

• 維持與learner的心跳，接收learner請求並判斷learner的請求訊息型別

• learner的訊息型別主要有PING訊息、REQUEST訊息、ACK訊息、REVALIDATE訊息，根據不同的訊息型別，進行不同的處理。

PING訊息是指Learner的心跳資訊；REQUEST訊息是Follower傳送的提議資訊，包括寫請求及同步請求；ACK訊息是Follower的對提議的回覆，超過半數的Follower通過，則commit該提議；REVALIDATE訊息是用來延長SESSION有效時間。

Follower主要四大功能：

• 向Leader傳送請求（PING訊息、REQUEST訊息、ACK訊息、REVALIDATE訊息）。

• 接收Leader訊息並進行處理。

• 接收Client的請求，如果為寫請求，傳送給Leader進行投票。

• 返回Client結果。

Follower的訊息迴圈處理如下幾種來自Leader的訊息：

• PING訊息：心跳訊息。

• PROPOSAL訊息：Leader發起的提案，要求Follower投票。

• COMMIT訊息：伺服器端最新一次提案的資訊。

• UPTODATE訊息：表明同步完成。

• REVALIDATE訊息：根據Leader的REVALIDATE結果，關閉待revalidate的session還是允許其接受訊息。

• SYN訊息：返回SYNC結果到客戶端，這個訊息最初由客戶端發起，用來強制得到最新的更新。

三、Marathon簡介

Marathon是一個Mesos框架，能夠支援執行長服務，比如Web應用等。它是叢集的分散式init.d能夠原樣執行任何Linux二進位制釋出版本，如Tomcat、Play等等。它也是一種私有的PaSS，實現服務的發現，為部署提供REST API服務，有授權和SSL、配置約束，通過HaProxy實現服務發現和負載平衡。

四、docker叢集實踐

1.4.1叢集環境準備

1.4.2Zookeeper偽叢集安裝部署

部署Zookeeper需要java支援, 主流1.7，穩定最新1.8，開發最新1.9，這邊選擇yum安裝即可支援Zookeeper

1.4.2.1Zookeeper配置檔案詳解

1.4.2.2Zookeeper配置檔案修改

由於是偽叢集的配置方式，B(IP地址)都是一樣，所以不同的Zookeeper例項通訊埠號不能一樣，所以要給它分配不同的埠號。

1、建立三個目錄來存放Zookeeper的資料

2、生成三份Zookeeper配置檔案

3、修改zk2、zk3對應的資料存放目錄以及埠

1.4.2.3Zookeeper角色檢視

1、啟動Zookeeper並檢視角色

 

2、連線Zookeeper

五、Mesos叢集部署

安裝Mesosphere倉庫，需要在Mesos Master和Mesos Slave節點安裝。

1.5.1Mesos_Master部署

1.5.2Mesos_Slave部署

1.5.3Mesos_Web介面

訪問：http://192.168.56.11:5050，如圖1.5-1所示：

圖1.5-1Tasks表格沒有任何條目

執行Mesos任務，可以在Web介面檢視task如圖1.5-2所示：

圖1.5-2執行Mesos任務

1.5.4Marathon呼叫Mesos執行Docker容器

通過marathon預設監聽8080埠,通過marathon建立專案，如圖1.5-3所示：

圖1.5-3Marathon介面

下面通過Mesos排程，使用marathon來建立一個nginx映象的Docker容器,Marathon啟動時會讀取/etc/mesos/zk配置檔案，Marathon通過Zookeeper來找到Mesos Master。

Marathon有自己的REST API，我們通過API的方式來建立一個Nginx的Docker容器。首先建立如下的配置檔案nginx.json

使用curl的方式呼叫

訪問Docker隨機啟動的埠31011，如圖1.5-4所示：

圖1.5-4成功訪問Nginx介面

在MarathonWeb介面檢視，如圖1.5-5所示：

圖1.5-5MarathonWeb介面檢視Nginx已經在執行

在Mesos介面檢視，如圖1.5-6所示：

圖1.5-5Mesos介面檢視Nginx Tasks

也可以點選Marathon左上角的建立進行建立容器。

注意：這裡哪Nginx來舉例，註冊中心的marathon+mesos+docker叢集是不適合用於服務的，也就是說不適合於對外開放埠的。比如說爬蟲，因為不開放埠，需要做的僅僅是從佇列中取資源，然後處理，存庫。

這個僅僅是job的釋出管理執行，還有沒CI，也就是說持續整合，後期我會發布jenkins+docker+mesos+marathon+git持續整合的方案，如果將程式碼釋出結合DCO框架。