概述

在云上業(yè)務(wù)類型和硬件資源越來越豐富的背景下，對云原生系統(tǒng)提出了更高的管理要求，例如在概論[1]中提到的資源利用率問題，服務(wù)質(zhì)量保障問題，黑盒泛化問題，異構(gòu)算力效率問題等等。為了讓多樣性業(yè)務(wù)和算力混部系統(tǒng)以最佳狀態(tài)運行，Rubik 混部解決方案應(yīng)運而生，在 Rubik 解決方案中，包括了集群感知調(diào)度、單機混部引擎（rubik）和內(nèi)核隔離技術(shù)等多層次優(yōu)化系統(tǒng)。本文是對 rubik 混部引擎的概要性介紹。

Rubik 字面意思為魔方，魔方由 Rubik 在 1974 年發(fā)明，故 Rubik 既是人名也指代魔方，在我們的解決方案中，Rubik 象征著能夠?qū)⑷蝿?wù)和算力資源有條不紊的管理起來。

rubik 混部引擎的愿景是提供一套自適應(yīng)的單機算力調(diào)優(yōu)和服務(wù)質(zhì)量保障服務(wù)。包括如下能力目標：

兼容原生 kubernetes 系統(tǒng)：基于原生 kubernetes 的擴展接口進行能力擴展。

兼容 openEuler 系統(tǒng)：自動使能 openEuler 提供的增強特性（如內(nèi)核分級資源隔離技術(shù)），對于其他 linux 發(fā)行版，由于存在部分內(nèi)核特性缺失，僅提供受限管理能力。

注入式應(yīng)用畫像：通過干擾自動注入對業(yè)務(wù)進行畫像標記，指導調(diào)度及運行時干擾識別控制。

節(jié)點及業(yè)務(wù)特征收集：上報節(jié)點及業(yè)務(wù)特征信息指導集群資源規(guī)劃、調(diào)度策略優(yōu)化，實現(xiàn)集群負載均衡、節(jié)點資源錯峰互補使用。

運行時干擾識別控制：提供對關(guān)鍵業(yè)務(wù)性能干擾實時檢測能力、干擾源快速定位能力以及干擾快速控制能力。

自適應(yīng)動態(tài)調(diào)優(yōu)：例如對關(guān)鍵業(yè)務(wù)性能優(yōu)化，使其能能更高效穩(wěn)定的運行；動態(tài)在離線資源配比調(diào)優(yōu)，減少關(guān)鍵業(yè)務(wù) QoS 違規(guī)等等。

支持自定義擴展：支持高級用戶針對特定業(yè)務(wù)場景開發(fā)自定義擴展插件。

rubik混部引擎在系統(tǒng)中的位置

特性介紹

在保障在線業(yè)務(wù)服務(wù)質(zhì)量前提下實現(xiàn)資源利用率最大化提升是在離線混合部署的設(shè)計目標，rubik 混部引擎作為節(jié)點管理組件在整個混部解決方案中起到至關(guān)重要的作用，因此，rubik 混部引擎主要圍繞資源利用率提升、QoS 保障展開。

在資源利用率提升方面，rubik 提供以下機制指導集群資源調(diào)度、實現(xiàn)集群節(jié)點各維度資源均衡、錯峰互補、干擾打散。

基于注入式應(yīng)用畫像指導作業(yè)調(diào)度的調(diào)度及重調(diào)度機制

待調(diào)度作業(yè)通過干擾自動注入對業(yè)務(wù)進行畫像標記， 分析工作負載的資源敏感度及壓力度，調(diào)度階段結(jié)合節(jié)點各維度資源（CPU、內(nèi)存帶寬、緩存帶寬、磁盤帶寬、網(wǎng)絡(luò)帶寬等）預測使用情況，指導集群節(jié)點資源統(tǒng)籌管理調(diào)度，不同資源密集型業(yè)務(wù)交錯部署，均衡各維度平均資源利用率水平，同時也指導作業(yè)二次調(diào)度。

基于在線業(yè)務(wù)資源預測的節(jié)點資源超賣機制

通過對在線業(yè)務(wù)的各維度資源采樣，預測可/不可壓縮資源使用情況并上報，為在線業(yè)務(wù)準確預留所需資源保障其 QoS 的同時，將未使用資源盡可能多地分配給離線業(yè)務(wù)，最大化離線的吞吐率，提升節(jié)點的資源利用率。

在 QoS 保障方面，在混部作業(yè)的運行過程中，由于在離線作業(yè)競爭 CPU、緩存帶寬、內(nèi)存帶寬、網(wǎng)絡(luò)帶寬、磁盤帶寬等共享資源以及由于進程在不同 CPU 頻繁切換及負載流量突發(fā)等情況，往往會導致業(yè)務(wù)性能受損，為了保障在線業(yè)務(wù)服務(wù)質(zhì)量，防范關(guān)鍵業(yè)務(wù) QoS 違規(guī)，rubik 混部引擎規(guī)劃提供多重保障以提升工作負載的運行效率及穩(wěn)定性。

第一道防線 - 基于內(nèi)核特性的資源隔離搶占機制

openEuler Kernel 為了適配云原生混部場景，規(guī)劃了 CPU、cache、Disk I/O、Network I/O 等資源的分級搶占能力，rubik 作為用戶態(tài)組件，為在離線業(yè)務(wù)配置 QoS 優(yōu)先級，使得當在線業(yè)務(wù)流量上升時，內(nèi)核層面能為其快速搶占到所需資源，保障在線業(yè)務(wù)的服務(wù)質(zhì)量，當在線業(yè)務(wù)的流量下降時，放寬對離線業(yè)務(wù)資源的限制，提高離線業(yè)務(wù)的吞吐率。

第二道防線 - 基于資源預測的在離線資源配比調(diào)優(yōu)的預防機制

通過對在線業(yè)務(wù)相關(guān)資源的監(jiān)控采集，預測在線業(yè)務(wù)各資源的使用情況，并結(jié)合節(jié)點資源的使用情況，提前對資源進行規(guī)劃，降低在線業(yè)務(wù) QoS 違規(guī)風險。當預測在線業(yè)務(wù)資源需求變大時，根據(jù)節(jié)點資源的空閑情況，選擇是否對離線業(yè)務(wù)資源的配比調(diào)整。

第三道防線 - 基于資源編排與彈性限流的自適應(yīng)性能調(diào)優(yōu)機制

提供拓撲均衡&潮汐親和性編排，減少進程在不同 CPU 的頻繁切換、進程遷移開銷以及訪問遠程 NUMA 導致性能抖動，同時應(yīng)對關(guān)鍵業(yè)務(wù)流量突發(fā)，在保障整機負載水位安全穩(wěn)定前提下，允許臨時突破限制，協(xié)調(diào)資源進行自適應(yīng)調(diào)整，快速解決或者緩解對應(yīng)資源瓶頸，保障關(guān)鍵業(yè)務(wù)的服務(wù)質(zhì)量。

第四道防線 - 基于指標監(jiān)控的性能干擾檢測控制的反饋機制

在現(xiàn)有的計算機硬件體系結(jié)構(gòu)中，除了 CPU、Memory、Disk、Network 等資源，還有諸如 Memory Bus、 System I/O Bus、 DMA Bus、MMU-TLB 等關(guān)鍵資源，且這些資源尚無對應(yīng)的軟硬件協(xié)同的資源隔離機制，無法實現(xiàn)應(yīng)用級的隔離，僅僅對 CPU 等資源隔離搶占無法完全解決資源競爭帶來的 QoS 違規(guī)問題。因此節(jié)點管理組件需要提供對關(guān)鍵業(yè)務(wù)的性能干擾分析，然而在實際的生產(chǎn)環(huán)境上，通常無法直接獲得業(yè)務(wù)的 QoS 情況，因此，在預分析階段對底層性能指標與上層應(yīng)用 QoS 建模，在運行期根據(jù)模型實時檢測評估 QoS 是否違規(guī)，并在出現(xiàn) QoS 違規(guī)后基于異常指標定位干擾來源，最后對干擾源進行壓制甚至驅(qū)逐來保障在線業(yè)務(wù)的服務(wù)質(zhì)量。

rubik 混部引擎特性

部署

首先，需要準備一套基于 openEuler 22.03 完成部署的 kubernetes 集群，然后在 master 節(jié)點準備 rubik 的 yaml 部署文件，可以直接從 rubik 源碼倉下載 example：

wget-Orubik-daemonset.yamlhttps://gitee.com/openeuler/rubik/raw/master/hack/rubik-daemonset.yaml

下載之后，正確配置 yaml 里面的鏡像地址，讓它能夠正確下載 rubik 鏡像。

?

需要注意：

yaml 里需要正確配置 rubik 容器鏡像的地址。假如前面采用的是 rubik 源碼倉的 example，則需要修改 yaml 文件中的image: rubik_image_name_and_tag 為 image: hub.oepkgs.net/cloudnative/rubik:latest

yaml 中主要包含 ClusterRole、ClusterRoleBinding、ConfigMap、DaemonSet 四部分。其中 rubik 的啟動配置參數(shù)包含在 ConfigMap 里，詳細的配置說明可以參考rubik 配置說明（https://gitee.com/openeuler/rubik/blob/master/docs/config.md）

?

然后，一鍵部署 rubik daemonset：

kubectlapply-frubik-daemonset.yaml

部署完成后，通過 kubectl 可以查詢名為rubik-agent的 pod：

#kubectlgetpods-A
NAMESPACENAMEREADYSTATUSRESTARTSAGE
kube-systemrubik-agent-jhjdg1/1Running04d

使用示例

以下演示如何啟動一個 nginx Pod 并將對其設(shè)置為在線業(yè)務(wù)，rubik 為該業(yè)務(wù)使能 kernel 資源 QoS 保障機制。

首先，需要在工作節(jié)點上使能 memory QoS 特性：

echo1>/proc/sys/vm/memcg_qos_enable

然后，在部署文件 yaml 添加 volcano.sh/preemptable 的 annotation 以標識業(yè)務(wù)屬性：

#catnginx-online.yaml
apiVersion:v1
kind:Pod
metadata:
name:nginx-online
annotations:
volcano.sh/preemptable:"false"#volcano.sh/preemptable為true代表業(yè)務(wù)為離線業(yè)務(wù)，false代表業(yè)務(wù)為在線業(yè)務(wù)，默認為false
spec:
containers:
-name:nginx
image:nginx
resources:
limits:
memory:"200Mi"
cpu:"1"
requests:
memory:"200Mi"
cpu:"1"

接著，部署 nginx 業(yè)務(wù)：

#kubectlapply-fnginx-online.yaml
#kubectlgetpods
NAMEREADYSTATUSRESTARTSAGE
nginx-online1/1Running04d

最后，查找并進入nginx-online Pod 對應(yīng)的 cgroup 下，查看cpu.qos_level是否生效（在線業(yè)務(wù)為 0，離線業(yè)務(wù)為-1），具體運行效果可以查閱典型應(yīng)用下的效果中案例 1[2]：

#cat/sys/fs/cgroup/cpu/kubepods/pod59f1cdfa-a0ad-4208-9e95-efbef3519c00/cpu.qos_level
0

展望

在離線混合部署作為提升數(shù)據(jù)中心資源利用率的重要手段，得到學術(shù)界和工業(yè)界的關(guān)注，成為了研究的熱點領(lǐng)域，但目前也面臨著諸多技術(shù)挑戰(zhàn)，尚有許多亟待解決的問題，如黑盒業(yè)務(wù)混部、異構(gòu)資源混部等，需要在作業(yè)感知調(diào)度、性能干擾建模、資源隔離搶占等領(lǐng)域逐個突破。為了達成泛型混部及融合部署的目標，節(jié)點管理層面對關(guān)鍵業(yè)務(wù)進行性能干擾建模，提供精確的 QoS 量化模型，指導干擾實時檢測與定位，并基于干擾檢測與定位實現(xiàn)更精確的動態(tài)資源配比控制以及探索更精準普適的動態(tài)監(jiān)測指標數(shù)據(jù)對應(yīng)用畫像以指導感知調(diào)度，這些方面具有著至關(guān)重要的作用，也是 rubik 后續(xù)研究的重點所在。

本文簡要介紹 rubik 混部引擎的愿景、目標、設(shè)計原則及特性機制，后續(xù)計劃對其中涉及的性能調(diào)優(yōu)技術(shù)，資源隔離搶占技術(shù)，干擾檢測及控制技術(shù)等進行詳細介紹，敬請期待！