騰訊 TencentOS 十年雲原生的迭代演進之路

蔣彪，騰訊雲高級工程師，10+年專一於操做系統相關技術，Linux內核資深發燒友。目前負責騰訊雲原生OS的研發，以及OS/虛擬化的性能優化工做。

導語

TencentOS Server (又名 Tencent Linux 簡稱 Tlinux) 是騰訊針對雲的場景研發的 Linux 操做系統，提供了專門的功能特性和性能優化，爲雲服務器實例中的應用程序提供高性能，且更加安全可靠的運行環境。Tencent Linux 使用免費，在 CentOS（及兼容發行版）上開發的應用程序可直接在 Tencent Linux 上運行，用戶還可持續得到騰訊雲的更新維護和技術支持。

TencentOS 在騰訊內部已經經歷了超過10年的迭代和演進，承載支撐了騰訊全部業務，商用部署節點超300w，經受住了海量複雜業務模型在極端場景中的極限考驗。

通用 OS 架構

傳統 OS 的定義(盜用經典教科書內容)：

操做系統是控制應用程序執行的程序，是應用程序和計算機(硬件)間的接口。

操做系統有3個目標：

• 方便：讓計算機更易於使用
• 有效：容許以更有效的方式使用計算機資源
• 擴展：容許在不影響服務的前提下，有效的開發、測試和引入新的系統功能

傳統通用 OS(Linux) 的典型架構設計如上，操做系統中包含了爲實現上述3個目標而提供的各類功能模塊和接口，整體上，分爲兩大部分：

• 內核：提供底層硬件(計算機)的基本抽象，不一樣的內核模塊提供不一樣的硬件管理或相關的輔助功能，經過系統調用向上層應用提供服務。
• 基礎庫和相關服務組件(用戶態)：爲真實業務運行提供基礎運行環境

IaaS 場景中的 OS

IaaS 場景中，OS 主要用於爲雲主機(虛擬機)提供運行環境，在 IaaS 場景中，OS 中運行的任務類型和數量可控，場景相對通用場景簡單不少。任務類型基本就只有以下幾類：

• VM 相關線程(一般爲 Qemu + Vcpu 線程)
• 各類控制面的管理 Agents
• OS 自身必須的一些控制線程(好比 Per-cpu Workers)

IaaS 場景中，爲使虛擬機性能無限接近(甚至超越)物理機，一般會考慮作減法，經過無限減小虛擬化、OS 層面的開銷來提高性能，經常使用的一些典型手段如：

• CPU 層面的綁核
• 內存層面的預分配
• IO 層面的各類 Bypass Kernel 技術

對於 OS 來講，最終的結果是：

OS 愈來愈薄，最終可能會消失

換個角度看 OS (雲原生角度)

當雲原生浪潮襲來，換個角度(雲原生角度)再去審視 OS 時，看到的又是不同的視圖。雲原生場景對 OS 提出了新的挑戰，也爲 OS 相關技術的進一步發展和演進注入了新的動力。

雲原生場景中，OS 爲不一樣類型的應用(Apps，Containers，Functions，Sandboxes)，提供底層支撐和服務。此時，相比 IaaS 場景，最明顯的差異在於：

應用和系統的邊界大幅上移，應用之下皆爲 OS

對於 OS 來講，最終的結果是：

OS 愈來愈厚(孕育無限可能)，與 IaaS 場景造成鮮明對比

TencentOS For 雲原生

在雲原生浪潮席捲的行業大背景下，伴隨着騰訊自身的各類業務架構的快速轉身，業務的容器化、微服務化、Serverless 化，對底層的基礎設施(包括核心的 OS )提出了新的挑戰和要求，TencentOS 也隨之迅速轉型，針對騰訊自身的雲原生場景和需求，進行了深度的重構和從新設計，全面擁抱雲原生，向雲原生 OS 的目標一步步邁進。

整體架構

TencentOS (當前)主要實現( Kernel 層)了以下雲原生 Features (後文展開)

• 雲原生調度器 - Tencent Could Native Scheduler(TCNS)
• 雲原生資源 QoS - RUE
• Quality Monitor
• 雲原生 SLI
• Cgroupfs

雲原生調度器 - Tencent Could Native Scheduler(TCNS)

TCNS 是 TencentOS 針對雲原生場景，提供的內核調度器總體解決方案，能夠覆蓋容器、安全容器和通用場景，對於多優先級業務混部中對 CPU 隔離的需求，以及對實時性/穩定性有極致要求的業務場景，有奇效。有關混部場景中對於CPU隔離性的需求和可能的解決方案，本篇《混部之殤-論雲原生資源隔離技術之CPU隔離(一)》有詳細解說，有關內核調度器的實時性保障的相關技術討論，在後續的 os 系列文章中會再講到，請陸續關注。

TCNS 主要包括3個模塊：

• BT Scheduler
• VMF Scheduler
• ECFS

BT Scheduler

BT Scheduler 是 TencentOS 針對(容器)混部場景的 CPU 隔離設計的新的調度類，位置以下圖所示：

其核心設計爲：全新設計新的調度類，優先級比默認的 CFS 低，僅當沒有其餘更高優先級的任務運行時才能運行，專用於運行離線任務(在線任務使用 CFS 類)。

如此設計的核心收益爲：可實如今線業務對離線業務的絕對搶佔，在混部場景中能夠獲得近乎完美的 CPU 隔離效果。

BT 調度類自己仍是一個功能完整的新調度類，在 BT 調度類內能夠提供相似 CFS 的功能全集。

除此以外，BT 調度類還實現了以下諸多特性：

有關 BT 的其餘信息，能夠戳以下連接瞭解：

【https://cloud.tencent.com/dev...】

注：內容雖然有些老，新版本已經迭代了幾輪，供參考。有關 BT 的最新介紹，也會在後續陸續推出相應文章，敬請期待。

VMF Scheduler

VMF (VM First) 調度器，是 TencentOS 針對安全容器場景(和虛擬機場景)專門設計的內核調度器解決方案(從新實現了一個全新的內核調度器)。

重寫調度器的主要背景是：現有的 CFS 調度器基於「徹底公平」的原則，沒法保證虛擬機(安全容器)線程調度的實時性。

VMF 的核心設計包括：

• 不公平的調度器，經過將 CPU 資源向虛擬機進程傾斜，從而保障虛擬機(安全容器)線程能優先獲得調度
• 基於任務類型進行調度，而沒有細粒度的優先級。相比之下，咱們認爲，CFS 的優先級並不能準確的描述不一樣進程的運行特徵，典型的就是內核線程，這類進程的特徵很明顯，首先他很重要，其次他的單次執行時間很短，但卻很難定義他們的優先級，高低都不合適，僅僅經過優先級並不能準確描述他們運行行爲。在 VMF 中，咱們經過對不一樣進程的特徵進行畫像和建模，將全部進程進行分類，並對不一樣類型進程設計精細的調度策略，能夠知足雲原生場景下，對實時性的極致需求。
• 單向激進搶佔，即 VM 進程能夠在任何狀況下儘快搶佔其餘任務，而反過來則不行，這樣能夠在不損害調度器的吞吐性能的狀況下，最大程度保障 VM 進程的實時性。

另外，咱們還針對其餘的場景和需求設計了許多其餘的特性，篇幅有限，沒法展開詳述，計劃後續另起話題單獨介紹。

總體來看，經過自研的VMF調度器，咱們能夠得到幾個關鍵收益：

• 極致調度延遲指標(實時性好)，極端狀況下的最大延遲都在微妙級
• 新調度器相比 CFS ，要輕量許多，總體代碼量不到 CFS 的 1/3
• 在存在部分干擾的狀況下，保證虛擬機(安全容器)線程的實時性
• 基於 VMF 的分類設計，能夠實現對不一樣類型進程提供不一樣級別的 CPU QoS 保障
• 經過徹底自研的調度器，能夠作不少很炫的、平時不敢想象的定製。若是你們有優化 CFS 的經驗，應該都能體會，要在 CFS 上作定製能有多難受。

有關 VMF 的說明，也計劃另文討論，也請期待。另 OS2ATC 2020 大會中的虛擬化專場，主題：《Tianus Hypervisor - 「零損耗」的騰訊雲輕量級虛擬化技術》中也有部分說明

https://www.bilibili.com/vide...

< 注：1:24:00開始 >

ECFS Scheduler

ECFS 是針對通用場景( Upstream 路線)，基於社區主流的 CFS 調度器作優化，核心的優化(設計)點：

• 引入新的任務調度類型，用於區分在線和離線任務。
• 優化搶佔邏輯，保障在線對離線的搶佔。避免離線對在線的沒必要要搶佔
• 絕對搶佔設計
• 超線程干擾隔離

具體原理暫不展開，請期待後續的 os 系列文章中再說明。

雲原生資源 QoS - RUE

RUE (Resource Utilization Enhancement)，中文品牌」如意「，是 TencentOS 產品矩陣中一款專爲雲原生場景下服務器資源 QoS 設計，提高資源利用率，下降運營成本的產品。如意是統一調度分配雲上機器的 CPU、IO、網絡、內存等資源，相比傳統的服務器資源管理方案，如意更適用於雲場景，可以顯著提高雲上機器的資源使用效率，下降雲上客戶的運營成本，爲公有云、混合雲、私有云等客戶提供資源增值服務。如意的核心技術能作到不一樣優先級的業務之間不互相干擾，實現資源利用率、資源隔離性能、資源服務質量的高效統一。

架構

RUE 包括以下主要模塊：

Cgroup Priority

在內核中引入全局統一的 Pod 優先級概念，同時貫穿於 CPU、Memory、IO、Net 全部資源的處理棧，提供統一的優先級控制。

CPU QoS

基於上一節說起的 TCNS 實現，能實現 CPU 層面的絕對搶佔和完美隔離。

Memory QoS

經過在分配和回收路徑上的優先級感知，爲不一樣優先級的容器提供不一樣級別的內存分配 QoS 保障(犧牲低優容器的內存可用性，以保障高優容器的內存 QoS )。其中實現了多個原創特性，總體上能最大程度保障高優容器的內存分配延遲，而這也是 Upstream Kernel 缺少的關鍵能力之一。

IO QoS

容許用戶將容器從 IO 角度劃分紅不一樣優先級，根據優先級分配 IO 資源，保障低優先級容器不會對高優先級容器形成干擾，同時容許低優先級容器使用空閒 IO 資源，從而提高資源利用率。IO 資源 QoS 包含三個方面：帶寬 QoS，延遲 QoS 以及回寫 QoS。另外，還提供最低帶寬保障功能，防止低優飢餓致使可能的優先級反轉。

Net QoS

容許用戶將服務器上網卡的帶寬按照優先級分配給不一樣的容器，容許低優先級容器使用空閒的帶寬資源，同時不會對高優先級容器的網絡帶寬形成干擾。另外，還提供最低帶寬保障功能，防止低優飢餓致使可能的優先級反轉。

RUE 的總體結構比較複雜，對 Upstream Kernel 進行了大量的改動和優化，相關特性涉及內容較多而普遍，本文沒法一一展開，後續會專文展開逐一討論，敬請期待。

整體效果

• 引入全局統一的 Pod 優先級概念，提供統一的優先級控制
• 適用於多優先級容器( Pod/任務)混合部署，可極大提高資源利用率

Quality Monitor

混部場景中，爲提高整機資源利用，傾向於最大化 Overcommit。在底層的隔離技術(資源 QoS )保障的前提下，能必定程度保障干擾隔離。但仍面臨兩個主要挑戰：

• 如何評估 QoS 效果和感知「干擾」？
• 出現「干擾」後，如何有效排查？

另外一方面，上層調度( K8s )也須要基於底層(內核)能提供更有意義的指標(服務質量評估及更細緻指標)，進行精細化運營，提高混部集羣的總體表現，提高混部技術方案的總體競爭力。

現有系統中存在一些分散的、不一樣維度的統計數據，但：

• 不夠「友好」，對於上層調度( K8s )來講，不能理解，須要一些更有意義的抽象數據，做爲「基礎」的調度依據。
• 不夠「專業」，對於混部場景，還須要一些針對性的監控數據，K8s能夠基於這些數據作更「精細」的運營。

另外一方面，現有系統缺少常態運行的調測手段，能在出現「干擾」(或者高優容器抖動)時，第一時間抓到現場，有效分析定位的手段。現有手段的不足：

• 多需過後部署( Ftrace/Kprobe 等)，但業務抖動可能難以復現，或者瞬時偶現，難以捕捉。
• 開銷大，難以常態化部署。

隨 Cgroup V2 一塊兒出現的 PSI 是一種很是好的嘗試，必定程度上反應了系統的 Health 狀態，但如用於混部場景的 QoS 效果評估，還略顯單薄。

TencentOS 設計了Quality Monitor，專用於評估容器各方面的服務質量( QoS )，並提供常態化、低開銷、事件觸發的監控機制，在出現服務質量降低(不達標)時，能夠及時、有效的捕獲異常上下文。

Quality Monitor 主要包含兩個模塊：

Score

服務質量評分，具體定義爲：

Per-Prio score = 100 - 因其餘優先級( Cgroup )進程干擾(資源搶佔)而 Stall 的時間佔比

Per-Cg score = 100 - 因其餘 Cgroup 進程干擾(資源搶佔)而 Stall 的時間佔比

注：這裏的干擾包括軟件和硬件層面的干擾

Monitor Buffer

常態監控干擾和抖動的內存區，當關鍵指標(依賴於雲原生 SLI )不符合預期(超限)時，自動記錄相關上下文信息。

整體效果：

• 提供優先級和 Pod 兩個維度的服務質量評分，用於評估容器的服務質量( QoS )
• 當出現服務質量降低(干擾)時，能夠經過 Monitor Buffer 捕獲到異常上下文

雲原生 SLI

定義

SLI (Service Level Indicator) 是用於觀測 Service level 的指標，好比  Latency、吞吐、錯誤率等；

SLO 是基於 SLI 指定的目標；

從雲原生的角度看，雲原生 SLI 能夠(狹義的)理解爲針對容器的可用於觀測 Service level 的指標，即容器視角的的一些關鍵指標，這也是定義容器 SLO 的基礎。

另外一方面，現有 Upstream Kernel 在 Cgroup 基本的統計和監控還比較原始和粗糙，僅有一些基本的統計信息，好比 Memory/Cpu 的 Usage 信息，缺少可用的、容器視角的 SLI 數據採集和抽象。

TencentOS 設計了雲原生 SLI，經過在內核中實時的蒐集和計算(低開銷方式)，提供充分的、專業的、不一樣維度的 SLI 指標，供上層( K8s )使用，用戶可基於此定個相應的 SLO。

雲原生 SLI 包括以下模塊：

CPU SLI

收集並計算 CPU 維度的 SLI，具體包括調度延遲、內核態阻塞延遲、Load、Context-switch 頻率等。

Memory SLI

收集並計算 Memory 維度的 SLI，具體包括內存分配延遲、內存分配速度、直接回收延遲、內存Compaction 延遲、內存回收延遲、內存分配失敗率等。

IO SLI

收集並計算 IO 維度的 SLI，具體包括 IO 延遲、IO 吞吐、IO 錯誤率等。

NET SLI

收集並計算網絡維度的 SLI，具體包括網絡延遲、網絡吞吐、IO 錯誤率等。

整體效果

• 提供容器級別級別的細粒度的 SLI 指標
• K8s 或其餘模塊(如 Quality Monitor )能夠基於相關指標作精細化運營

Cgroupfs

雲原生場景中，基於 Namespace、Cgroup 等底層資源隔離技術，作了資源的基礎隔離(容器視角)，但容器的總體隔離性還很是不完整，其中，/proc、/sys 文件系統中的一些資源統計信息，尚未完整的容器化(或者說 Namespace 化)，致使在物理機/虛擬機中的一些經常使用命令(好比 free / top )在容器中運行時，不能準確展現容器視角的信息(默認展現系統級別的全局信息，好比系統總內存和 free 內存)，這也是雲原生(容器)場景中一直存在的一類頑疾。

直接緣由是由於相關信息還沒有容器化，本質緣由仍是因爲容器的隔離性還存在不足。

針對/proc文件系統中關鍵信息沒有容器化的問題，社區推薦的解決方案是：

lxcfs

lxcfs 是針對上述場景而量身定製的一個虛擬文件系統，其底層基於 FUSE 實現了一個用戶態的文件系統，提供容器化視角的 /proc 文件系統中的統計信息，還包括一點點 /sys 文件系統的個別信息，實現比較簡單直接。

lxcfs 基本解決了在容器中使用經常使用基礎命令( free / top / vmstat等)的困擾，但仍存以下不足：

• 須要依賴額外的組件 lxcfs，難與容器深度融合，不可控。
• 用戶態基於 FUSE 實現。開銷相比內核更大，信息準確度不如內核。
• lxcfs 穩定性比較差(據用戶反饋)，常常出問題：卡死(開銷大)、信息獲取不到等。
• 定製能力差，當前的實現徹底基於用戶態可見的一些基本信息(當前信息還比較有限)，若是須要更深層次的定製(基於用戶需求)，就會遇到能力瓶頸(受限於用戶態實現)。

TencentOS 在內核態提供了相應的解決方案，取名爲：_Cgroupfs_

其核心設計爲：設計一個新的虛擬文件系統(放置於根文件系統中)，其中包含咱們須要實現的容器視角的 /proc、/sys 等 fs，其目錄結構保持與全局 procfs 和 sysfs 保持一致，以保證對於用戶工具的兼容性。實際讀取相關文件時，經過 cgroupfs 的讀者進程的上下文來動態生成對應的容器信息視圖。

目錄結構以下所示：

整體效果

• 內核態容器視角的虛擬機文件系統( /proc，/sys )，隔離全局信息，支持常規命令( top，free，iotop，vmstat 等)
• 面向 Cgroup V2 設計，統一層次結構
• 可根據需求作深層次的定製和擴展

TencentOS For Kubernetes

在雲原生浪潮下，Kubernetes 做爲行業事實標準首當其衝。隨着雲原生進入深水區，業務也更關注上雲後的實際增益，資源利用率與成本也日益被重視。在原有 Kubernetes 體系中，經過 Service QoS Class 和 Priority 可將不一樣優先級 workload 混部在同一集羣中，以增長資源利用率，減小資源運營成本。但這種「用戶態」行爲受限於 Linux kernel cgroups 設計，天生隔離粒度不足。業務會因混部後資源爭搶受損，有時每每得不償失。

在這種背景下，TencentOS 面向雲原生與 Prioirty 的設計，能完美解決這個問題。咱們經過將 Kubernetes Service QoS Class 與 TencentOS Priority 一一對應，在內核層原生感知優先級，在底層提供強隔離機制，最大程度保證混部後業務的服務質量。並且這種優先級機制是貫穿在整個 cgroups 子系統中。

騰訊雲容器團隊已在外部開源了TKE 發行版，該 Feature 會在下個版本支持，用戶可持續關注社區動態。

More

除關注雲原生以外，TencentOS Server 自己爲一款通用服務器 OS，在10餘年堅持專一內核的過程當中，也開發/定製過不少或大或小的 Features，有關 TencentOS 其餘說明、以及代碼，若有興趣，歡迎繼續戳以下連接瞭解：

【https://github.com/Tencent/Te...】

結語

TencentOS 一直在思考、探索本身的雲原生之路，旅程已開始，但遠未結束！