[[386229]]

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

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

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

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

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

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

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

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

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

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

應(yīng)用程序調(diào)度器(Application-Level Schedulers)：對(duì)應(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ù)。在了解這些具體組件之后，這里我們圍繞文章開(kāi)頭提出的動(dòng)態(tài)集群和自定義配置展開(kāi)討論 Twine 的設(shè)計(jì)。

動(dòng)態(tài)集群

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

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

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

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

自定義配置

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

圖 4 - 主機(jī)配置

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

集群規(guī)模

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

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

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

分片

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

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

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

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

分離關(guān)注

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

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

總結(jié)

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

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

[^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)載自微信公眾號(hào)「真沒(méi)什么邏輯」，作者嵌入式系統(tǒng)。轉(zhuǎn)載本文請(qǐng)聯(lián)系真沒(méi)什么邏輯公眾號(hào)。