導語
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/developer/article/1519558
注：內容雖然有些老，新版本已經迭代了幾輪，供參考。有關 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/video/BV1Ky4y1m7yr/?spm_id_from=333.788.recommend_more_video.1
注：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/任務)混合部署，可極大提升資源利用率
另一則廣告：Qcon 北京2021-全球軟體開發者大會，有相應的 Topic 《騰訊 Kubernetes 大規模離線上混部與核心隔離實踐》分享，歡迎圍觀(回放視訊暫時還沒有)
https://qcon.infoq.cn/2021/beijing/presentation/3253
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/TencentOS-kernel
結語
TencentOS 一直在思考、探索自己的雲原生之路，旅程已開始，但遠未結束！
容器服務 TKE：無需自建，即可在騰訊雲上使用穩定， 安全，高效，靈活擴充套件的 Kubernetes 容器平臺。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！
