使用 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 的理解和掌控也越來越深入。伴隨著持續的實踐，我們對 Mesos 的理解和掌控也越來越深入，我們會持續輸出我們的使用經驗，期待得到各位讀者的反饋。

?