[[389059]]

『看看論文』是一系列分析計算機(jī)和軟件工程領(lǐng)域論文的文章，我們在這個系列的每一篇文章中都會閱讀一篇來自 OSDI、SOSP 等頂會中的論文，這里不會事無巨細(xì)地介紹所有的細(xì)節(jié)，而是會篩選論文中的關(guān)鍵內(nèi)容，如果你對相關(guān)的論文非常感興趣，可以直接點(diǎn)擊鏈接閱讀原文。

本文要介紹的是 2011 年 NSDI 期刊中的論文 —— Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center[^1]，該論文實(shí)現(xiàn)的 Mesos 能夠在集群中管理不同的計算框架，例如 Hadoop 和 MPI 等。雖然 Mesos 集群管理系統(tǒng)是 10 多年前發(fā)布的技術(shù)，今天已經(jīng)逐漸被更主流、更通用的容器編排系統(tǒng) Kubernetes 取代，但是它確實(shí)可以解決集群管理上的部分問題。

Apache Mesos 和 Kubernetes 都是優(yōu)秀的開源框架，也都支持大規(guī)模的集群管理，但是它們兩個管理的集群規(guī)模仍然差一個數(shù)量級，單個 Mesos 集群可以管理 50,000 節(jié)點(diǎn)，而 Kubernetes 集群卻只能管理 5,000 節(jié)點(diǎn)，需要做很多優(yōu)化和限制，才能達(dá)到相同的數(shù)量級。

圖 1 - Kubernetes 和 Mesos 集群

雖然 Kubernetes 是今天集群管理的主流技術(shù)，但是 Mesos 在剛剛出現(xiàn)時也是很先進(jìn)的集群管理系統(tǒng)，它想要取代的是當(dāng)時更為常見的靜態(tài)分片集群。靜態(tài)分片集群雖然可以同時運(yùn)行屬于不同框架的工作負(fù)載(例如：Hadoop、MPI)，但是因?yàn)榭蚣艿漠悩?gòu)性，使用靜態(tài)分片技術(shù)會將集群中的機(jī)器預(yù)先分配給不同的框架，再由這些框架分配和管理資源。

圖 2 - 靜態(tài)分片

Mesos 在最初設(shè)計時并不會直接管理和調(diào)度開發(fā)者提交的工作負(fù)載，而是提供一組接口暴露集群的資源，并通過這組輕量級的接口同時對接 Hadoop、MPI 等框架。

架構(gòu)

如下圖所示的 Mesos 集群同時運(yùn)行了 Hadoop 和 Mesos 兩個框架，如果忽略圖中與 Hadoop、MPI 框架的相關(guān)模塊，我們會發(fā)現(xiàn)架構(gòu)會變得非常簡單，它僅由 Zookeeper 集群、Mesos 主節(jié)點(diǎn)和工作節(jié)點(diǎn)組成。

圖 3 - Mesos 架構(gòu)圖

• Zookeeper 集群提供了高可用的數(shù)據(jù)存儲和選舉等功能;
• Mesos 主節(jié)點(diǎn)收集工作節(jié)點(diǎn)上報的數(shù)據(jù)并向框架的調(diào)度器提供資源;
• Mesos 工作節(jié)點(diǎn)上報數(shù)據(jù)并通過框架的執(zhí)行者在本地啟動任務(wù);

每個 Mesos 集群中運(yùn)行的框架都由調(diào)度器和執(zhí)行者兩部分組成，調(diào)度器會處理主節(jié)點(diǎn)提供的資源，與 Kubernetes 的調(diào)度器有著相同的作用，當(dāng)調(diào)度器接受主節(jié)點(diǎn)提供的資源后，它會返回待運(yùn)行任務(wù)的相關(guān)信息;而執(zhí)行者會在工作節(jié)點(diǎn)上運(yùn)行框架創(chuàng)建的任務(wù)。

Mesos 為了保證更好的可擴(kuò)展性，它定義了一套能夠滿足資源共享的最小接口，將任務(wù)調(diào)度和執(zhí)行的控制權(quán)都通過如下所示的接口交給框架，其本身僅保留較粗粒度的調(diào)度和資源管理功能。

圖 4 - Mesos 接口

因?yàn)?Mesos 中的任務(wù)調(diào)度是分布式的過程，所以為了保證該過程的效率和可靠性，它引入了下面的這三種機(jī)制：

節(jié)點(diǎn)過濾器：框架使用過濾器剔除集群中不滿足自身調(diào)度條件的節(jié)點(diǎn);

資源主動分配：為了提高框架的調(diào)度速度，會將預(yù)先提供給框架的資源計入框架的總分配資源，直到框架完成調(diào)度，這能激勵框架實(shí)現(xiàn)更快的調(diào)度器;

資源撤回：如果框架在一段時間內(nèi)沒有處理主節(jié)點(diǎn)提供的資源，Mesos 會撤回資源并提供給其他框架;

除了提供良好的擴(kuò)展性和性能之外，作為集群調(diào)度管理系統(tǒng)，Mesos 也面臨著隔離不同任務(wù)資源的問題。在 Mesos 剛剛發(fā)布時，容器技術(shù)還沒有像今天這么普及，但是它也利用操作系統(tǒng)的容器隔離不同工作負(fù)載的影響[^2]，并利用可插拔式的隔離模塊支持多種隔離機(jī)制。

調(diào)度模型

我們在文章開篇就已經(jīng)介紹過 Mesos 和 Kubernetes 能夠管理的集群規(guī)模有數(shù)量級的差距，這里簡單對比分析下兩者在調(diào)度器上的差異，這能幫助我們理解 Kubernetes 調(diào)度器在設(shè)計時做出的決策，以及這些決策是如何影響它的可擴(kuò)展性。

需要注意的是，提升系統(tǒng)可擴(kuò)展性往往都是復(fù)雜的問題，而在 Kubernetes 這樣龐大的系統(tǒng)中會顯得更加復(fù)雜，Kubernetes 的調(diào)度器不是影響其可擴(kuò)展性的唯一因素，想要提升單個集群的規(guī)模要從多個方面入手。

Mesos 的調(diào)度器選擇了兩層的調(diào)度設(shè)計，其中頂層調(diào)度器僅會根據(jù)底層框架調(diào)度器的需求粗粒度地過濾集群中的節(jié)點(diǎn)，而框架調(diào)度器會執(zhí)行真正的任務(wù)調(diào)度，將任務(wù)綁定到相應(yīng)的節(jié)點(diǎn)上。

圖 5 - 兩層調(diào)度器

這種兩層的調(diào)度器設(shè)計看起來雖然很復(fù)雜，但是實(shí)際上它能夠降低 Mesos 調(diào)度器的復(fù)雜度并提高了它的可擴(kuò)展性：

• 降低復(fù)雜度：頂層調(diào)度器不需要處理真正的調(diào)度過程，它僅通過資源提供(Resource Offer)機(jī)制將一組節(jié)點(diǎn)交給底層調(diào)度器控制;
• 提高可擴(kuò)展性：兩層調(diào)度器設(shè)計可以更方便地接入新的框架調(diào)度器，兼容不同復(fù)雜的調(diào)度策略，不同框架調(diào)度器內(nèi)部可以串行為任務(wù)選擇節(jié)點(diǎn)，提高整體調(diào)度的吞吐量;

雖然 Mesos 通過兩層調(diào)度器設(shè)計提供了很強(qiáng)的擴(kuò)展性，但是它卻不能為調(diào)度決策提供全局最優(yōu)解。這是因?yàn)樗械恼{(diào)度決策都是在整個集群中的一部分節(jié)點(diǎn)中做出的，所有的調(diào)度決策都只是局部最優(yōu)的，而這也是多調(diào)度器中的常見問題[^3]。

在調(diào)度系統(tǒng)中，想要實(shí)現(xiàn)更好的擴(kuò)展性就一定面臨著分片，分片必然導(dǎo)致調(diào)度器無法提供全局最優(yōu)解并且顯著地增加系統(tǒng)的復(fù)雜性。我們從 Linux、Go 語言等 CPU 調(diào)度器的演進(jìn)可以觀察到這點(diǎn)，最初的調(diào)度器大多數(shù)都是單線程的，為了提高調(diào)度器的性能，會使用多調(diào)度器并引入工作竊取機(jī)制處理多調(diào)度器中待調(diào)度任務(wù)隊列的不平衡。

Kubernetes v1.21 版本的內(nèi)置調(diào)度器仍然是單線程的，它為了在全局 5,000 個節(jié)點(diǎn)中做出最優(yōu)的調(diào)度決策，需要使用不同的插件遍歷這 5,000 個節(jié)點(diǎn)并排序，而這也是影響其擴(kuò)展性的重要原因之一。全局最優(yōu)解聽起來是非常美好的設(shè)計，但是在調(diào)度這種比較復(fù)雜的場景中，局部最優(yōu)解往往也都可以滿足需求，在業(yè)務(wù)上不需要保證該約束時，就可以通過多調(diào)度器來提升性能了。

總結(jié)

當(dāng)對比 Mesos 和靜態(tài)分片集群的資源利用率時，我們會發(fā)現(xiàn) Mesos 在 CPU 和內(nèi)存的集群資源利用率上都明顯高于使用靜態(tài)分片的集群，而這個結(jié)果也不會造成太多的意外，因?yàn)閯討B(tài)的資源分配策略一般都能夠提高集群的資源利用率。

圖 6 - Mesos 和靜態(tài)集群的資源利用率對比

了解 Mesos 出現(xiàn)時解決的問題以及它的設(shè)計可以讓我們更好地理解今天面臨的挑戰(zhàn)，Mesos 在剛剛出現(xiàn)時是非常新穎的技術(shù)，與同期的其他產(chǎn)品來講確實(shí)提供了很強(qiáng)的靈活性，但是隨著 Yarn、Kubernetes 等技術(shù)的出現(xiàn)，它的很多場景也都被新技術(shù)取代，而這也是技術(shù)發(fā)展的必然趨勢。

[^1]: Benjamin Hindman, Andy Konwinski, Matei Zaharia, Ali Ghodsi, Anthony D. Joseph, Randy Katz, Scott Shenker, and Ion Stoica. 2011. Mesos: a platform for fine-grained resource sharing in the data center. In Proceedings of the 8th USENIX conference on Networked systems design and implementation (NSDI'11). USENIX Association, USA, 295–308.

[^2]: What's LXC? https://linuxcontainers.org/lxc/introduction/

[^3]: 調(diào)度系統(tǒng)設(shè)計精要 https://draveness.me/system-design-scheduler/

本文轉(zhuǎn)載自微信公眾號「真沒什么邏輯」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系真沒什么邏輯公眾號。