解析使用 Mesos 管理虛擬機器

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

摘要

為了滿足渲染、基因測序等計算密集型服務的需求，UCloud 已推出了“計算工廠”產品，讓使用者可以快速建立大量的計算資源（虛擬機器）。該產品的背後，是一套基於 Mesos 的計算資源管理系統。本文主要介紹該系統的結構、Mesos 在 UCloud 的使用、我們的解決方案以及遇到的問題。

業務需求

我們的需求主要是兩個方面：

1. 同時支援虛擬機器和容器。在“容器化”的浪潮下，為什麼我們還需要支援虛擬機器呢？首先，一些業務有嚴格的安全隔離要求，容器雖好，但還做不到和虛擬機器同等級的隔離性。其次，一些業務程式不能運行在 Linux 上，比片、動畫的渲染軟體大都是 Windows 程式。

2. 整合多地區多資料中心。我們的資源來源於一些擁有閑置資源的夥伴，這些資源散佈於多個地區的多個資料中心中。我們的平台需要能夠支援全域的調度，同時儘可能減小運營、營運的成本。

簡單地說，我們需要有一個平台，統一封裝多個資料中心的計算資源，並且同時支援虛擬機器、容器等多種形式的資源使用方式。

                                                          圖1：計算資源管理平台的需求

說到虛擬機器，首先想到的就是 UCloud 自己的 UHost 和開源的 OpenStack，然而，這兩套系統都是針對大型公用雲端的情境，而且主要只針對於虛擬機器這一種業務。它們功能豐富、模組眾多，營運運營上都需要很大的成本。然而我們的業務並不需要這麼多功能。

最終，我們選擇了基於 Mesos 來實現這套平台。

為什麼選擇 Mesos

Mesos是Apache下的開源分布式資源管理架構，它是一個分布式系統的核心。

通過 Mesos，一個資料中心所提供的不再是一台台伺服器，而是一份份的資源。資源可以是 CPU 核心數、記憶體、儲存、GPU 等等。如果把一個資料中心當做一個作業系統的話，Mesos 就是這個作業系統的核心。

我們選擇 Mesos 的原因在於它擁有高度可擴充性，同時又足夠簡單。

作為核心，Mesos 只提供最基礎的功能：資源管理、任務管理、調度等。並且每一種功能，都以模組的方式實現，方便進行定製。架構上，Master 和 Agent 兩個模組就實現了資源相關的所有工作，使用者只需根據自己的商務邏輯實現 Framework 和 Executor 即可。這樣就支援我們能夠把計算資源封裝成虛擬機器、容器等各種形式。

採用 Mesos 來進行容器編排的方案已經被很多廠商使用，相關的資料文檔也比較豐富。然而用 Mesos 來管理虛擬機器，業內並沒有應用於生產環境的實踐。本文的餘下內容，主要向讀者分享一下 UCloud 用 Mesos 管理虛擬機器的思路和實踐經驗。

Mesos 簡介

Mesos 採用 Master-Agent 架構。Master 負責整體資源的調度並對外提供 API。Agent 部署在所有機器上，負責調用 Executor 執行任務、向 Master 彙報狀態等。

Mesos 提供了一個雙層調度模型：

1. Master 在 Framework 之間進行資源調度；

2. 每個 Framework 內部實現各自業務的資源調度。

整體架構如：

                                                        圖2：Mesos 的雙層調度結構圖

架構設計

整體架構

在 Mesos 的雙層調度模型上，平台的整體架構如：

                                            圖3：基於Mesos的資源管理平台整體架構圖

結構如下：

1. 每個 IDC 一套或多套 Mesos 叢集；

2. 每個 Mesos 叢集一個 Cluster Server，與 Mesos Master 以及 Framework 互動，負責叢集內部的調度、狀態收集和任務下發；

3. 一個Mesos叢集上有多個Framework，一個 Framework 負責一種業務，比如 VM Scheduler 管理虛擬機器，Marathon Framework 管理Docker任務；

4. VM Framework架構實現管理的 Excutor 是基於Libvirt，實現虛擬機器的建立、重啟、刪除等操作；

5. 所有 Cluster Server 統一向 API Server 彙報，上報狀態、擷取任務；

6. API Server 負責主要商務邏輯，以及叢集間的調度、資源和任務的管理等等；

7. API Gateway 提供 API 給 UCloud 控制台（Console）。

基於 HTTP 的通訊

系統內的所有通訊都基於 HTTP。

首先，Mesos 內部基於 libprocess 各組件之間的通訊都依賴 libprocess 庫，該庫用 C++ 實現了 Actor 模式。每個 Actor 會監聽 HTTP 要求，向 Actor 發訊息的過程就是把訊息體序列化後放在 HTTP 報文中，然後請求這個 Actor。

其次，業務相關的各個組件API Server、Cluster Server 等也都通過 Restful 的 API 提供服務。

HTTP 的優點在於簡單可靠、易於開發調試和擴充。

VM Scheduler

對於 Docker 容器，我們採用 Marathon Framework 進行管理。而對於虛擬機器，我們則採用自己開發的 VM Scheduler Framework 。

VM Scheduler 從 Master 擷取一個個的資源 Offer 。一個資源 Offer 包含了某個 Agent 上可用的資源。當有虛擬機器任務需要執行的時候，Cluster Server 會把任務的具體資訊發送給 VM Scheduler。

任務分為兩類：

1. 建立/刪除一個虛擬機器。此時需要傳入虛擬機器的配置資訊、包括鏡像、網路、儲存等。VM Scheduler 根據這些資訊，匹配滿足要求的 Resource Offer，然後產生 Task 提交給 Mesos Master 去執行。

2. 操作一個虛擬機器，如開關機、重啟、鏡像製作等。此時 VM Scheduler 會和 VM Executor 通過 Framework Message 通訊，告訴後者去執行具體的操作。

VM Executor

Task 是 Mesos 中資源分派的最小單位。Master 會告訴 Agent 需要執行哪些 Task，Agent 也會把 Task 的狀態彙報給 Master。根據 Task 的資訊，Agent 會下載並啟動所需的 Executor，然後把具體的 Task 描述傳給它。

VM Executor 是我們開發的對虛擬機器的生命週期進行管理的 Executor，實現了對虛擬機器建立、刪除、開關機、鏡像製作等功能。

VM Executor 啟動後，根據 Task 的描述，動態產生虛擬機器需要的設定檔，然後調用 libvirt 進行虛擬機器建立。當收到來自 VM Scheduler 的 Framework Message 時，又調用 libvirt 進行開關機等操作。

狀態的管理是實現虛擬機器管理的關鍵區段。通過 Mesos 我們只能拿到 Task 的狀態，RUNING 表示虛擬機器建立成功，FAILED 表示虛擬機器失敗，FINISHED 表示虛擬機器成功銷毀。然而除此之外，一個虛擬機器還存在“開機中”、“關機中”、“關機”、“鏡像製作中”等其他狀態。我們通過在 VM Executor 和 VM Scheduler 之間進行心跳，把這些狀態同步給 VM Scheduler。後者對狀態進行判斷，如果發現狀態改變了，就發送一條狀態更新的訊息給 Cluster Server，然後再轉寄給 API Server，最終更新到資料庫。

虛擬機器的調度

首先看一下一個 Task 在 Mesos 中是怎麼調度的：

                                                       圖4：Mesos 資源調度過程

上面的樣本中：

1. Agent 向 Master 彙報自己所擁有的資源；

2. Master 根據 Dominant Resource Fairness(DRF) 調度演算法，把這份資源作為一個 Resource Offer 提供給 Framework 1；

3. Framework 1 根據自己的商務邏輯，告訴 Master 它準備用這份資源啟動兩個 Task；

4. Master 通知 Agent 啟動這兩個 Task。

對應到虛擬機器的情況，調度分兩個部分：

1. 選擇叢集。預設情況下，API Server 根據資源需求，從註冊上來的叢集中選擇一個擁足夠資源的叢集，然後把資源需求分配給該叢集。另外，還可以針對不同的公司、項目等維度制定在某個叢集運行；

2. 叢集內調度。Cluster Server 從 API Server 處擷取到資源需求，比如說需要 200 個核，於是根據 Mesos 當前資源使用方式，建立出一個“資源計劃”，200個核被分配為4個48核虛擬機器和1個8核虛擬機器。然後通知 Framework 按照這份計劃來建立5個Task。

資源的標識

伺服器之間除了 CPU、記憶體、硬碟等可能不同外，還會存在其他的差別。比如有時候業務要求一定要用某個型號的 CPU，有時候要求一定要擁有 SSD等等。為了支援更多維度調度，我們利用了 Mesos 的 Resource 和 Attribute 來標識不同的資源。

Resource是 Mesos 中的一個概念，表示一切使用者需要使用的東西。Agent 預設會自動添加 cpus、gpus、mem、ports 和 disk 這5種資源。另外還可以在 Agent 啟動時，通過參數指定其他資源。

Attribute 以 Key-Value 形式的標籤，標識一個 Agent 擁有的屬性，同樣可以在啟動時通過參數指定。

通過 Resource 和 Attribute 的靈活運用，可以標識出更多的資源情況，滿足各種資源調度需求。比如通過 Resource 指定 SSD 大小、CPU型號，通過 Attribute 標識機架位、是否擁有外網 IP，是否支援超執行緒等等。Framework 收到一個 Resource Offer 後，與待執行的任務需求進行匹配，通過 Resource 判斷資源是否夠用，再通過 Attribute 判斷是否滿足其他維度需求，最終決定是否用這個 Offer 來建立 Task。

鏡像、儲存和網路管理

平台提供了一些基礎鏡像，另外使用者也可以基於自己的虛擬機器建立自己的鏡像。這些鏡像檔案統一儲存在一個基於 GlusterFS 的分部署儲存服務中，該服務掛載在每台物理機上。

有些業務情境需要部分虛擬機器能夠共用同一份儲存，於是我們還是基於 GlusterFS 開發了使用者儲存服務，能夠根據使用者的配置，在虛擬機器建立時自動掛載好。

在網路方面，每個使用者可以建立多個子網，各個子網之間做了網路隔離。建立虛擬機器時，需要指定使用哪個子網。

其他問題

在使用 Mesos 的過程中，我們也遇到了其他一些問題。

問題一：Marathon選主異常

當機器負載比較高，尤其是 IO 較高時，我們發現 Marathon 叢集有機率出現不能選主的情況。

我們懷疑是由於 Marathon 節點和 ZK 的網路不穩定，觸發了 Marathon 或 Mesos 的 Bug導致。於是通過 iptables 主動屏蔽 Leader ZK 連接埠的方式，成功複現出問題。

通過在 Marathon 的代碼中加上一些 Leader 選舉相關的最終日誌，成功定位到了問題，原來是由於 Mesos Driver 的 stop() 方法沒有成功引起 start() 方法退出阻塞導致。

由於我們的所有程式都是通過守護進程啟動的，所以我們採用了一個最簡單的解決方案：修改 Marathon 代碼，當 ZK 發生異常時，直接自殺。自殺後守護進程會把程式再啟動起來。

問題二：go-marathon問題

我們的服務採用 Golang 開發，使用 go-marathon 庫與 Marathon 進行互動。使用過程中發現該庫有一些問題：

不支援多 Marathon 節點。於是我們自己建立了一個分支，採用節點主動探測的方式，實現了多節點的支援。（原庫 v5.0 版本以後也支援了該功能）

使用設有 Timeout 的 http.Client 進行 go-marathon 的初始化時，訂閱 SSE 會產生逾時問題。於是我們做了修改，普通的 HTTP API 和 SSE 不使用同一個 http.Client，操作 SSE 的 http.Client 不設定 Timeout。

網路異常時，go-marathon 的方法調用會 Hang 住。於是我們所有對 go-marathon 方法的調用都加上逾時控制。

結語

Mesos 在 UCloud 有著廣泛的應用，對外有“計算工廠”和 UDocker 等產品，對內則支撐著公司內網虛擬機器管理平台。伴隨著持續的實踐，我們對 Mesos 的理解和掌控也越來越深入。