[[386229]]

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

本文要介紹的是 2020 年 OSDI 期刊中的論文 —— Twine: A Unified Cluster Management System for Shared Infrastructure[^1]，該論文實(shí)現(xiàn)的 Twine 是 Facebook 過去十年生產(chǎn)環(huán)境中的集群管理系統(tǒng)。在該系統(tǒng)出現(xiàn)之前，F(xiàn)acebook 的集群由為業(yè)務(wù)定制的獨(dú)立資源池組成，因?yàn)檫@些資源池中的機(jī)器可能有獨(dú)立的版本或者配置，所以無法與其他業(yè)務(wù)共享。

Twine 的出現(xiàn)解決了不同資源池中機(jī)器配置不同的問題，提供了動態(tài)配置機(jī)器的功能，這樣可以合并原本獨(dú)立的資源池，提高資源整體的利用率，在業(yè)務(wù)申請資源時可以根據(jù)需要配置機(jī)器，例如：改變內(nèi)核版本、啟用 HugePages 以及 CPU Turbo 等特性。

圖 1 - Twine 設(shè)計(jì)決策

Kubernetes 是今天十分熱門的集群管理方案，不過 Facebook 的方案 Twine 卻做出了與 Kubernetes 相反的決策，實(shí)現(xiàn)了截然不同的解決方案。需要注意的是使用 Kubernetes 并不一定意味著要使用靜態(tài)集群、私有節(jié)點(diǎn)池和大容量機(jī)器，我們?nèi)匀豢梢酝ㄟ^引入其他模塊實(shí)現(xiàn)動態(tài)集群等特性，只是 Kubernetes 本身不支持這些設(shè)計(jì)。我們在這篇文章中僅會討論上述三大決策的前兩個以及 Twine 如何實(shí)現(xiàn)水平擴(kuò)容、管理大規(guī)模的集群。

架構(gòu)設(shè)計(jì)

作為可以管理上百萬機(jī)器、支撐 Facebook 業(yè)務(wù)的核心調(diào)度管理系統(tǒng)，Twine 的生態(tài)系統(tǒng)非常復(fù)雜，我們在這里簡單介紹該系統(tǒng)中的一些核心組件：

圖 2 - Twine 生態(tài)系統(tǒng)

分配器(Allocator)：對應(yīng) Kubernetes 中的調(diào)度器，負(fù)責(zé)為工作負(fù)載分配機(jī)器，它在內(nèi)存中維護(hù)了所有機(jī)器的索引和屬性并使用多線程處理資源的調(diào)度分配;

調(diào)度器(Scheduler)：對應(yīng) Kubernetes 中的控制器，它負(fù)責(zé)管理工作負(fù)載的生命周期，當(dāng)集群出現(xiàn)硬件故障、日常維護(hù)等情況時會推動系統(tǒng)做出響應(yīng);

應(yīng)用程序調(diào)度器(Application-Level Schedulers)：對應(yīng) Kubernetes 中的 Operator，如果我們想使用特殊的邏輯管理有狀態(tài)服務(wù)，需要實(shí)現(xiàn)自定義的調(diào)度器;

分配器、調(diào)度器和應(yīng)用程序調(diào)度器是 Twine 系統(tǒng)中的核心組件，然而除了這些組件之外，生態(tài)中還包含前端界面、優(yōu)化集群工作負(fù)載的平衡器和指定特定業(yè)務(wù)容量的服務(wù)。在了解這些具體組件之后，這里我們圍繞文章開頭提出的動態(tài)集群和自定義配置展開討論 Twine 的設(shè)計(jì)。

動態(tài)集群

Twine 的動態(tài)集群建立在其抽象出的權(quán)利(Entitlement)上，每個權(quán)利集群都包含一組動態(tài)分配的機(jī)器、屬于特定業(yè)務(wù)的偽集群。數(shù)據(jù)中心中的機(jī)器和任務(wù)之間建立其的這層抽象使機(jī)器的分配變得更加動態(tài)：

圖 3 - 任務(wù)、權(quán)利和數(shù)據(jù)中心

分配器不僅會將機(jī)器分配給權(quán)利集群，還會把同一個權(quán)利集群中的工作負(fù)載調(diào)度到特定的機(jī)器上。

需要注意的是，我們在這里簡化了 Twine 中的模型，F(xiàn)acebook 的數(shù)據(jù)中心會由幾十個主配電板(Main Switchboard、MSB)組成，它們具有獨(dú)立的電力供應(yīng)和網(wǎng)絡(luò)隔離，配電板上的機(jī)器可以看做屬于同一個集群。

自定義配置

私有的節(jié)點(diǎn)池很不利于機(jī)器的共享，但是確實(shí)有很多業(yè)務(wù)對機(jī)器的內(nèi)核版本和配置有要求，例如：很多機(jī)器學(xué)習(xí)或者數(shù)據(jù)統(tǒng)計(jì)的任務(wù)都需要使用 Linux 的 HugePages 優(yōu)化性能，但是 HugePages 可能會損害在線服務(wù)的性能。

圖 4 - 主機(jī)配置

Twine 由此引入了主機(jī)配置的概念，為每個權(quán)利集群綁定獨(dú)立的主機(jī)配置，當(dāng)數(shù)據(jù)中心的機(jī)器被分配到某個偽集群時，會根據(jù)集群的配置更新機(jī)器，為工作負(fù)載提供最符合需求的運(yùn)行環(huán)境，這在 Facebook 內(nèi)將 Web 層的服務(wù)性能提高了 11%，也是目前的 Kuberentes 無法滿足的。

集群規(guī)模

Facebook 的集群規(guī)模也是目前世界領(lǐng)先的，雖然目前的集群規(guī)模還沒有突破百萬級，但是隨著業(yè)務(wù)的快速發(fā)展，Twine 很快就需要支持百萬級別的物理機(jī)管理，它會通過下面兩個原則支撐這個數(shù)量級的節(jié)點(diǎn)：

通過按照權(quán)利集群分片的方式水平擴(kuò)容;

通過分離關(guān)注點(diǎn)減少調(diào)度系統(tǒng)的工作量;

分片

分片是集群或者系統(tǒng)想要實(shí)現(xiàn)水平擴(kuò)容的最常見方式，Twine 為了支持水平擴(kuò)容就以權(quán)利集群的維度分片;作為虛擬集群，Twine 可以在分片之間遷移權(quán)利集群，不需要重啟機(jī)器上的任務(wù)，然而跨權(quán)利集群的遷移就需要滾動更新的支持了。

圖 5 - 調(diào)度器分片

通過分片，集群管理系統(tǒng)的水平擴(kuò)容就變得非簡單，而 Twine 最大的分片中管理了 170,000 臺機(jī)器，這與 Kubernetes 能夠支持 5,000 節(jié)點(diǎn)相比有將近兩個數(shù)量級的差距。

除了分片之外，聯(lián)邦也是解決集群管理規(guī)模的有效手段，Kubernetes 社區(qū)的聯(lián)邦可以讓同一個任務(wù)在多個獨(dú)立集群運(yùn)行，可以支持多地區(qū)、混合云甚至多云的部署，但是因?yàn)樾枰缂和叫畔ⅲ詫?shí)現(xiàn)相對比較復(fù)雜;Twine 的調(diào)度器可以在分片中的機(jī)器不足時動態(tài)遷移新的機(jī)器，所以可以使用單個調(diào)度器管理一個服務(wù)的所有副本。這里就不討論兩種方案的優(yōu)劣了，各位讀者可以自行思考，不過作者還是傾向于通過的聯(lián)邦管理多個集群。

分離關(guān)注

Kubernetes 是一種中心化的架構(gòu)，所有的組件都會從集群中的 API 服務(wù)器讀取或者寫入信息，所有的數(shù)據(jù)都存儲在獨(dú)立的持久存儲系統(tǒng)中，而中心化的架構(gòu)和存儲系統(tǒng)也成為了 Kubernetes 集群管理的瓶頸。

Twine 在設(shè)計(jì)上盡量避免了中心化的存儲系統(tǒng)并分離原本屬于單個組件的職責(zé)，拆分到了調(diào)度器、分配器、資源代理、健康檢查服務(wù)和主機(jī)配置服務(wù)中，每個服務(wù)也有獨(dú)立的存儲系統(tǒng)，這就能夠避免單存儲系統(tǒng)帶來的擴(kuò)容問題。

總結(jié)

在 Kubernetes 大行其道的今天，能夠看到 Facebook 分享其內(nèi)部集群管理系統(tǒng)的不同設(shè)計(jì)還是有很大意義的，這讓我們重新思考 Kubernetes 中設(shè)計(jì)帶來的潛在問題，例如：中心化的 etcd 存儲，很多使用 Kubernetes 的大公司為了讓其能夠管理更多節(jié)點(diǎn)，都會選擇修改 etcd 的源代碼或者替換存儲系統(tǒng)。

Kubernetes 對于集群規(guī)模較小的公司還是有很大好處的，而其本身確實(shí)能夠解決集群管理中 95% 的問題，Kubernetes 也不是銀彈，它沒法做到解決場景內(nèi)的全部問題。在應(yīng)用 Kubernetes 時，中小規(guī)模的公司可以全盤接收 Kubernetes 的架構(gòu)和設(shè)定，而大公司可以在 Kubernetes 的基礎(chǔ)上做一些定制，甚至參與到標(biāo)準(zhǔn)的制定中增加技術(shù)影響力、提高話語權(quán)并且?guī)椭喂緲I(yè)務(wù)成長。

[^1]: Tang C, Yu K, Veeraraghavan K, et al. Twine: A Unified Cluster Management System for Shared Infrastructure[C]//14th {USENIX} Symposium on Operating Systems Design and Implementation ({OSDI} 20). 2020: 787-803.

本文轉(zhuǎn)載自微信公眾號「真沒什么邏輯」，作者嵌入式系統(tǒng)。轉(zhuǎn)載本文請聯(lián)系真沒什么邏輯公眾號。