蔣筱斌, 熊軼翔, 張 珩, 侯朋朋, 武延軍, 趙 琛

1(中國科學(xué)院 軟件研究所, 北京 100190)

2(中國科學(xué)院大學(xué), 北京 100049)

1 引言

大數(shù)據(jù)時代主體表現(xiàn)為數(shù)據(jù)的整體體量、發(fā)展速度和種類都呈現(xiàn)井噴式增長, 隨著計算任務(wù)所需要處理的數(shù)據(jù)規(guī)模急劇增加, 計算模式從單機多處理器的并行計算發(fā)展到多機的分布式計算, 網(wǎng)格計算和云計算. 如今, 云計算以其最少的資源支持最大的用戶體量和提供彈性化服務(wù)的優(yōu)勢成為最為熱門的技術(shù)之一[1].云計算是基于TCP/IP通信協(xié)議的將多種計算機技術(shù)高度集成的產(chǎn)物, 提供對高性能處理器單元、大容量的分布式內(nèi)存、高速網(wǎng)絡(luò)等硬件資源的統(tǒng)一化服務(wù)抽象和虛擬系統(tǒng)架構(gòu)平臺[2]. 云計算的核心是虛擬化技術(shù), 將硬件資源抽象成一個巨大的資源池, 對資源進行統(tǒng)一的管理和調(diào)度、按需分配, 實現(xiàn)動態(tài)的、可彈性伸縮性的、安全的云服務(wù).

作為一種輕量級的虛擬化技術(shù), Docker具有高速、輕量、擴展性強、快速交付等特點[3]. 與傳統(tǒng)虛擬化技術(shù)不同, 傳統(tǒng)虛擬化技術(shù)需要虛擬出硬件并在硬件上運行一套完整的操作系統(tǒng); 而Docker類似于一個應(yīng)用進程直接運行在宿主機的內(nèi)核系統(tǒng)上, Docker容器本身沒有硬件虛擬和內(nèi)核系統(tǒng), 通過Linux Cgroups機制確定允許容器消耗的資源(如CPU、內(nèi)存和網(wǎng)絡(luò))限制[4,5]. Docker容器通過Docker Image鏡像進行創(chuàng)建, 容器中包含了應(yīng)用程序及其所需的整個工具鏈,并通過類似于Linux Namespace機制進行空間隔離, 以保證多個應(yīng)用程序之間隔離運行, 因此多個容器可以復(fù)用宿主機的硬件和內(nèi)核系統(tǒng), 極大的簡化了容器的創(chuàng)建、維護和遷移.

容器通過容器編排工具部署到集群的節(jié)點上, 目前較為流行的容器編排工具有Docker Swarm、Mesos、Kubernetes等. 考慮到Kubernetes是目前應(yīng)用最為廣泛的開源容器編排工具之一, 本文選擇以Kubernetes[6]為基礎(chǔ)開展RISC-V開源指令集架構(gòu)的適配和云任務(wù)調(diào)度器優(yōu)化研究工作. Kubernetes是一個可移植的、可擴展的開源平臺, 用于管理容器化的工作負載和服務(wù).Kubernetes工作過程由Master節(jié)點內(nèi)部的kubecontroller-manager組件對集群中Node (節(jié)點)、Pod、Namespace (命名空間)等對象資源進行統(tǒng)計和管理, 并將待調(diào)度的Pod交由kube-scheduler進行調(diào)度, 最終實現(xiàn)Pod與工作節(jié)點之間的綁定. 本文主要聚焦Kubernetes的任務(wù)調(diào)度器開展性能優(yōu)化和功能擴展方案研究.

RISC-V是2010年美國加州大學(xué)伯克利分校研發(fā)并推出的RISC (精簡指令集)第5代架構(gòu). 因為其開源性、簡潔性、模塊性和可擴展性, 吸引了無數(shù)產(chǎn)業(yè)界和工業(yè)界的研究人員的關(guān)注. 近幾年里國內(nèi)外涌現(xiàn)了許多突破性的成果, 如阿里巴巴平頭哥研發(fā)的基于RISC-V的高性能處理器“玄鐵-910”[7], 中國科學(xué)院計算技術(shù)研究所在RISC-V中國峰會上發(fā)布的開源高性能RISC-V 處理器核“香山”[8], 佐治亞理工大學(xué)在ACM微體系結(jié)構(gòu)國際會議上開源基于RISC-V的GPU實現(xiàn)Vortex GPU[9]等. 隨著云計算、邊緣計算等領(lǐng)域的不斷發(fā)展, 帶動了大量碎片化的IoT芯片需求, 這些微體系結(jié)構(gòu)且具有特定功能的IoT芯片與RISC-V開源性、簡潔性、模塊性和可擴展性的特點完美契合.隨著RISC-V指令集架構(gòu)的芯片設(shè)備日益增多, 亟需將RISC-V架構(gòu)計算節(jié)點加入基于容器的云服務(wù)環(huán)境,充分地融合這類RISC-V架構(gòu)設(shè)備算力, 以提供合理高效的資源分配和計算任務(wù)協(xié)作, 這類需求已成為目前分布式容器編排平臺的一大技術(shù)難點和挑戰(zhàn). 與ARM/X86架構(gòu)不同, RISC-V指令集并不是用一套統(tǒng)一的架構(gòu)來滿足各種不同的需求, 它采用模塊化的方式進行組織, 用以提供根據(jù)用戶計算需求的可擴展性指令集; 其中, 每一個模塊都使用一個英文來表示, 共包括4個基礎(chǔ)指令集和6個已獲批的擴展指令集. 除此之外, RISC-V還有多個正在不斷完善的擴展指令集.如最為廣泛應(yīng)用的V (向量)擴展[10], 比傳統(tǒng)的單指令多數(shù)據(jù)(SIMD)指令更具優(yōu)勢, 解決了SIMD指令集冗余和上層軟件適配的問題. H (Hypervisor)擴展[11]支持監(jiān)控程序, 提高了在單機上虛擬化部署多個操作系統(tǒng)的效率, 為搭載RISC-V芯片的虛擬化優(yōu)化提供了可能.

目前的容器編排工具都不具備調(diào)度RISC-V指令集架構(gòu)需求的任務(wù), 尤其是RISC-V提供了用戶自定義的擴展指令集的加入, 更是增加了調(diào)度的難度. 以最新版本Kubernetes為例, 將容器部署到具有異構(gòu)節(jié)點的集群中將會導(dǎo)致容器鏡像的拉取失敗或是應(yīng)用程序的運行失敗. 標簽式的調(diào)度方案可以解決粗粒度的架構(gòu)選擇, 但是無法實現(xiàn)RISC-V多種擴展指令集ISA匹配. 以V (Vector)擴展指令集為例, 與當前ARM/X86架構(gòu)不同, RISC-V的V擴展指令提供了向量化計算,能夠為向量計算和標量計算提供單指令多數(shù)據(jù)(SIMD)運算單元, 且不限于特定的向量長度, 能夠為矩陣運算、機器學(xué)習、多媒體分析等提供指令集加速. 然而,當前的Kubernetes無法根據(jù)計算任務(wù)的特征來匹配具有該指令集特征的計算單元, 即無法做到節(jié)點內(nèi)的指令集感知來調(diào)度至具備V擴展指令集的RISC-V計算節(jié)點, 因此將會導(dǎo)致Kubernates中集群的RISC-V計算資源浪費.

為解決上述問題, 本文提出了一種基于Kubernetes異構(gòu)ISA指令集感知的集群調(diào)度系統(tǒng), 它主要由指令集感知(ISAMatch)模型來處理任務(wù)在異構(gòu)ISA指令集架構(gòu)節(jié)點中的調(diào)度. 具體地, 本文所設(shè)計的Kubernetes集群調(diào)度系統(tǒng)通過對集群內(nèi)的計算節(jié)點的所有指令集提供探測核實, 并根據(jù)指令集親和性和任務(wù)優(yōu)先級來自動識別任務(wù)所需指令集架構(gòu)和節(jié)點架構(gòu)的親和程度,進而找到集群中匹配程度最高的節(jié)點. 本文整體系統(tǒng)設(shè)計基于開源項目Volcano調(diào)度器進行實現(xiàn), ISAMatch模型與Volcano調(diào)度器的其余插件完全兼容, 可由集群管理員動態(tài)選擇是否開啟ISAMatch模型. 在ISAMatch模型的支持下, Volcano調(diào)度器可以很準確的將任務(wù)部署到對應(yīng)架構(gòu)的節(jié)點上, 并提高了調(diào)度性能和集群資源利用率.

本文的主要貢獻總結(jié)如下:

(1) 調(diào)研Kubernetes的多種同構(gòu)和異構(gòu)資源調(diào)度策略和多種ISA指令集架構(gòu)特點.

(2) 提出ISAMatch模型, 它能夠準確的找到匹配任務(wù)ISA的節(jié)點列表并選擇最佳匹配節(jié)點.

(3) 基于Volcano調(diào)度器實現(xiàn)了一個具有ISA感知能力的分布式異構(gòu)云平臺調(diào)度系統(tǒng).

(4) 通過詳細實驗驗證, 本文對所實現(xiàn)的云計算調(diào)度平臺可以顯著地避免任務(wù)在異構(gòu)節(jié)點中的部署失敗,相對比默認調(diào)度器正確率62% (調(diào)度RISC-V基礎(chǔ)指令集任務(wù))、41% (調(diào)度RISC-V擴展指令集任務(wù))、67% (調(diào)度RISC-V擴展指令集任務(wù)且有“RISC-V”節(jié)點匹配標簽), 在不考慮資源限制的條件下, ISAMatch模型可以達到100%的任務(wù)調(diào)度正確率, 以此達到提高了集群資源利用率的效果.

2 相關(guān)工作及挑戰(zhàn)

2.1 同構(gòu)資源調(diào)度機制研究現(xiàn)狀

同構(gòu)資源的資源調(diào)度策略更注重資源調(diào)度的結(jié)果評估, 如資源利用率和集群負載均衡等. 目前, 云計算在同構(gòu)資源調(diào)度領(lǐng)域的研究都集中在兩個方向上.

(1)根據(jù)各種調(diào)度算法及算法改進對資源進行合理調(diào)度; 同時, 還要對云平臺的實時狀態(tài)進行評估, 判斷部分任務(wù)是否需要重新調(diào)度. 例如, Ge等人[12]將系統(tǒng)工作負載、任務(wù)隊列和預(yù)測的執(zhí)行時間作為輸入,調(diào)度器運用遺傳算法生成最優(yōu)調(diào)度方案; Zuo等人[13]提出了一種改進的蟻群算法解決最優(yōu)調(diào)度問題, 使用任務(wù)完成時間和預(yù)算作為約束函數(shù)來評估成本以防止蟻群算法陷入局部最優(yōu)解困境, 最終對調(diào)度方案提供反饋.

(2)根據(jù)服務(wù)器負載的周期性, 通常采用機器學(xué)習算法, 對集群收集到的時序和歷史負載信息進行分析,尋找合適的調(diào)度方案. 何龍等人[14]通過記錄各個Pod對資源的使用情況, 在后續(xù)的調(diào)度過程中, 通過歷史數(shù)據(jù)對調(diào)度的打分策略提供指導(dǎo); Berral等人[15]采用機器學(xué)習算法, 對過往系統(tǒng)運行狀態(tài)進行分析, 通過模型預(yù)測得出的功耗、CPU負載和SLA時間調(diào)整調(diào)度決策.

2.2 異構(gòu)資源調(diào)度機制研究現(xiàn)狀

隨著數(shù)據(jù)中心的計算節(jié)點技術(shù)架構(gòu)和用戶服務(wù)需求的不斷變革, 為用戶特定任務(wù)提供特定計算單元的異構(gòu)資源系統(tǒng)已逐漸成為當前的主流計算模式, 例如GPU (graphic processing unit)服務(wù)器用于深度學(xué)習訓(xùn)練、NPU (neural processing unit)節(jié)點用于神經(jīng)網(wǎng)絡(luò)推測以及DPU (data processing unit)用于數(shù)據(jù)資源的存儲和計算服務(wù). 面向這類融合XPU算力資源的資源調(diào)度策略更注重異構(gòu)資源本身的算力特殊性. 近年的系統(tǒng)領(lǐng)域和計算機體系結(jié)構(gòu)領(lǐng)域的研究成果大量集中在GPU、FPGA等異構(gòu)計算單元的芯片設(shè)備上.

AntMan[16]是阿里巴巴提出的一款具有動態(tài)縮放機制的集群異構(gòu)資源調(diào)度器, 旨在解決在生產(chǎn)環(huán)境中GPU集群資源利用率低下的問題. AntMan從動態(tài)顯存管理和動態(tài)計算管理兩個維度進行設(shè)計. 動態(tài)內(nèi)存管理為了適應(yīng)深度學(xué)習作業(yè)中不斷變化的內(nèi)存需求,將部分顯存內(nèi)容轉(zhuǎn)移到CPU內(nèi)存中計算, 以實現(xiàn)高優(yōu)先級任務(wù)的優(yōu)先計算. 動態(tài)計算管理采用穿插運行模式, 高優(yōu)先級任務(wù)運行時, GpuOpManager組件實時監(jiān)控任務(wù)在GPU上運行的時間和空閑間隙, 低優(yōu)先級任務(wù)穿插間隙執(zhí)行.

GaiaGPU[17]是騰訊公司設(shè)計的一款細粒度異構(gòu)資源調(diào)度系統(tǒng). 一改傳統(tǒng)異構(gòu)設(shè)備的完整調(diào)度(1 GPU),將異構(gòu)設(shè)備進一步細粒度化的切分調(diào)度(0.x GPU). 在細粒度調(diào)度的基礎(chǔ)上, 充分考慮多異構(gòu)設(shè)備通信延遲,構(gòu)建GPU集群拓撲結(jié)構(gòu), 針對申請小于1 GPU、申請等于1 GPU和申請大于1 GPU三種狀態(tài)分別討論, 實現(xiàn)GPU資源的最大利用率和通信的最小延遲.

KubeHICE[18]是Yang等人提出的一款基于ARM/X86的異構(gòu)ISA指令集架構(gòu)的邊緣計算資源調(diào)度平臺. KubeHICE通過請求的YAML文件中鏡像的名稱以及鏡像詳細信息包括鏡像編號、架構(gòu)等是否帶有架構(gòu)相關(guān)信息來選擇合適的ISA指令集設(shè)備. 在ISA指令集架構(gòu)感知的基礎(chǔ)上, KubeHICE還討論不同ISA指令集架構(gòu)芯片的算力, 根據(jù)單核算力重新定義資源數(shù)量以實現(xiàn)集群計算資源的負載均衡. 然而, KubeHICE策略未考慮到同名異構(gòu)的鏡像調(diào)度, 同時, 指令集只針對了通用指令集, 未充分考慮到多種擴展指令集.

除了對具體異構(gòu)設(shè)備資源調(diào)度的研究, 還有在異構(gòu)環(huán)境下單任務(wù)切分的資源調(diào)度研究. Boran等人[19]通過將任務(wù)進行細粒度分割, 針對任務(wù)在不同階段的運行特性, 對任務(wù)遷移至不同的異構(gòu)設(shè)備中運行, 實現(xiàn)任務(wù)的最佳運行效率.

2.3 RISC-V概述

RISC-V作為RISC (精簡指令集)第5代架構(gòu), 于2012年由Berkeley團隊[20]提出, 旨在解決當前ISA指令集架構(gòu)的過于龐雜、商業(yè)化閉源、靈活性缺失等一系列技術(shù)問題. 與ARM/X86等主流指令集架構(gòu)相比,RISC-V指令集架構(gòu)作為新興指令集架構(gòu)具有精簡化、模塊化、開源化[21]3大突出特點.

(1) RISC-V遵循“大道至簡”的設(shè)計哲學(xué)[22]. 主流指令集架構(gòu)在不斷發(fā)展中為了可以向后兼容, 在原有的指令集中添加新的指令, 使得指令集文檔過于冗余.據(jù)統(tǒng)計, X86指令集文檔約5 000多頁, 而同樣基于RISC架構(gòu)的ARM指令集文檔也擁有2 700多頁. RISC-V摒棄了向后兼容的歷史包袱, 采用“基本指令集+擴展指令集”的模式, 基礎(chǔ)的基本指令集僅40余條, RISC-V指令集手冊也只有200多頁[21].

(2) RISC-V采用模塊化的指令集設(shè)計模式, 采用“基本指令集+擴展指令集”的設(shè)計思想, 不僅精簡了指令集數(shù)量, 還可以自由定制所需的指令集. RISC-V架構(gòu)的處理器設(shè)計人員可以根據(jù)需要選擇是否需要添加這些擴展指令, 尤其適用于具有特定功能的物聯(lián)網(wǎng)芯片, 降低了芯片的開發(fā)周期和成本.

(3) RISC-V遵守開放開源原則, 與ARM和X86收取高額的專利費相比, 允許芯片開發(fā)人員根據(jù)自身需求自由修改開源代碼, 并可直接用于商業(yè)活動, 降低了RISC-V的開發(fā)成本和門檻.

2.4 挑戰(zhàn)

圖1展示了Kubernetes在異構(gòu)ISA指令集架構(gòu)環(huán)境下的任務(wù)創(chuàng)建時調(diào)度過程, 開發(fā)者將帶有應(yīng)用程序和開發(fā)環(huán)境的鏡像打包上傳至鏡像倉庫中, 通過編寫YAML文件生成Pod等待集群調(diào)度, controller整合Pod信息通過調(diào)度算法與具體工作節(jié)點進行綁定, 由綁定節(jié)點的kubelet從鏡像倉庫中拉取對應(yīng)架構(gòu)的鏡像生成執(zhí)行Pod, 通常鏡像倉庫針對某一基礎(chǔ)鏡像都有多種架構(gòu)選擇, kubelet會選擇與節(jié)點自身架構(gòu)相同的架構(gòu)進行拉取. 然而, 在調(diào)度過程中, 現(xiàn)有的調(diào)度器無法判斷應(yīng)用程序所需ISA指令集架構(gòu), 因此存在鏡像拉取失敗或者運行環(huán)境錯誤的調(diào)度失敗的可能性.

圖1 基于Kubernetes異構(gòu)ISA指令集架構(gòu)調(diào)度

圖2統(tǒng)計了在3種異構(gòu)ISA指令集架構(gòu)(RISC-V、ARM、X86)環(huán)境下部署100個RISC-V任務(wù)時的調(diào)度正確頻率, 實驗平臺見表1所示, 在調(diào)度RISC-V基礎(chǔ)指令集任務(wù)時, 由于3個RISC-V節(jié)點都可以對其進行正常部署, 調(diào)度正確率為62%; 而在調(diào)度沒有添加任何ISA相關(guān)標簽的RISC-V擴展指令集任務(wù)時, 任務(wù)不僅需要RISC-V指令集架構(gòu)環(huán)境, 還需要RISC-V節(jié)點具有特定擴展指令集架構(gòu), 調(diào)度正確率只有41%;即使添加了“RISC-V”的ISA標簽, 由于特定擴展指令集架構(gòu)的影響, 調(diào)度正確率也只有67%.

圖2 RISC-V任務(wù)在默認調(diào)度器下的調(diào)度正確率

表1 實驗集群設(shè)備參數(shù)

因此, 面對異構(gòu)ISA指令集架構(gòu)的云平臺, 當同時部署ARM、X86、RISC-V架構(gòu)節(jié)點, 現(xiàn)有Kubernetes調(diào)度方案都無法正常調(diào)度. 尤其是面對具有多種RISC-V擴展指令集, 當前的Kubernetes云服務(wù)調(diào)度平臺需要滿足如下的3點需求:

需求① (指令可編譯性): 在現(xiàn)有場景下, 支持對應(yīng)擴展的計算任務(wù)的交叉編譯模式.

需求② (執(zhí)行正確性): 合理分配滿足指令集架構(gòu)的節(jié)點.

需求③ (架構(gòu)兼容性): 適配多種指令集, 滿足指令集在云平臺節(jié)點上的架構(gòu)兼容性.

為了解決創(chuàng)建時多種架構(gòu)節(jié)點的分配問題, 本文設(shè)計了指令集感知與匹配(ISAMatch)模型來對節(jié)點ISA指令集進行匹配. 依次通過架構(gòu)過濾、指令集過濾和節(jié)點打分找出最佳匹配節(jié)點.

3 基于Kubernetes的ISA架構(gòu)匹配策略的設(shè)計與實現(xiàn)

ISAMatch模型是一種針對異構(gòu)ISA指令集架構(gòu)節(jié)點環(huán)境下的集群調(diào)度方案. 如圖3左側(cè)所示, controller-manager作為集群內(nèi)部的管理中心, 負責管理集群的節(jié)點、作業(yè)和資源等信息, 并整合用戶申請的YAML信息交由調(diào)度器進行調(diào)度; scheduler 獲取待調(diào)度Pod信息后由ISAMatch模型讀取Pod和候選Node節(jié)點列表的ISA指令集架構(gòu)數(shù)據(jù), 并選擇合適的Node節(jié)點進行綁定, 根據(jù)綁定信息將Pod交由對應(yīng)節(jié)點kubelet,從鏡像庫中拉取與宿主機架構(gòu)匹配的鏡像.

圖3右側(cè)是ISAMatch模型的整體工作流程,ISAMatch模型可以分為兩個階段, 兩個階段以是否需要交叉編譯作為分隔.

圖3 基于Kubernetes的ISA架構(gòu)匹配策略架構(gòu)和流程圖

第1步(交叉編譯), 判斷當前任務(wù)是否具有交叉編譯需求.

第2步(ISA指令集), 判斷當前任務(wù)是否有具體ISA指令集架構(gòu)需求.

第3步(架構(gòu)過濾), 粗粒度的過濾不匹配的頂層指令集架構(gòu)節(jié)點.

第4步(指令集過濾), 細粒度的過濾RISC-V特有的擴展指令集架構(gòu).

第5步(節(jié)點打分), 綜合指令集親和性、同種指令集架構(gòu)節(jié)點數(shù)量、資源利用率對節(jié)點打分, 選取得分最高的節(jié)點作為候選綁定節(jié)點.

任務(wù)進入集群后首先判斷其是否具有交叉編譯需求, 如果有則直接跳過第2步, 根據(jù)其交叉編譯所需要的ISA指令集依次執(zhí)行架構(gòu)過濾、指令集過濾和節(jié)點打分操作. 當任務(wù)不具有交叉編譯需求或通過交叉編譯判斷未能找到合適的調(diào)度節(jié)點, 則繼續(xù)執(zhí)行第2步判斷其是否有具體ISA指令集需求, 如果有, 則ISAMatch會根據(jù)任務(wù)所需ISA指令集依次執(zhí)行架構(gòu)過濾、指令集過濾和節(jié)點打分操作, 最終選出合適Node節(jié)點. 如果同時不具備交叉編譯和ISA指令集需求時, 任務(wù)將交由Kubernetes默認調(diào)度器進行調(diào)度.

綜合上述流程, 本小節(jié)將對交叉編譯和ISAMatch模型進行詳細描述.

3.1 交叉編譯

截至目前, RISC-V擴展指令集中有12個指令集已獲批, 12個指令集處于草案狀態(tài), 另有5個指令集已凍結(jié). 因此, 應(yīng)對多種還未完成的擴展指令集, 市場上尚未有對應(yīng)指令集擴展的芯片, 應(yīng)對復(fù)雜指令集需求的Pod請求, 云端集群也不可能完備地集成具有所有指令集模塊組合芯片的節(jié)點.

為了解決需求① (指令可編譯性), 本文設(shè)計了采用交叉編譯的模式來解決復(fù)雜指令集請求, 以滿足上述復(fù)雜指令集動態(tài)組合的條件. 本系統(tǒng)主要分兩種編譯模式: 1) 混合編譯模式QEMU; 2) 節(jié)點指令集架構(gòu)屬性的同構(gòu)編譯ARCH, 如圖4所示, 節(jié)點ARCH標簽代表節(jié)點具有的指令集架構(gòu)屬性; 任務(wù)ARCH標簽代表任務(wù)所請求的指令集架構(gòu)屬性; 節(jié)點QEMU代表節(jié)點具有的交叉編譯指令集架構(gòu)屬性; 任務(wù)QEMU標簽代表任務(wù)所請求的指令集架構(gòu)屬性. 本系統(tǒng)通過對用于匹配交叉編譯模式下的架構(gòu)屬性進行標記, 標記為混合編譯模式QEMU (以圖4為例, 節(jié)點具有RV64IMFDV的交叉編譯屬性, 即具有該指令集架構(gòu)需求的任務(wù)可以在該節(jié)點上交叉編譯運行). 如圖3右側(cè)流程圖, 在架構(gòu)過濾階段判斷Pod是否具有QEMU標簽請求. 當一個具有QEMU標簽請求的Pod進入調(diào)度器時, 調(diào)度器會根據(jù)節(jié)點QEMU標簽進行粗粒度架構(gòu)過濾, 進入指令集過濾階段后根據(jù)QEMU標簽的擴展指令集部分進一步細粒度的過濾不匹配架構(gòu)節(jié)點, 最后由節(jié)點打分模型分別對指令集親和性、節(jié)點數(shù)目、節(jié)點資源利用率進行評估選出合適綁定節(jié)點. 若QUME標簽的ISAMatch模型沒有找到候選節(jié)點, 即所有候選節(jié)點QEMU標簽中沒有匹配的節(jié)點, 那么會進行常規(guī)的通過ARCH標簽的調(diào)度.

圖4 Pod和Node標簽設(shè)置

3.2 ISAMatch模型

為了解決需求② (執(zhí)行正確性)和③ (架構(gòu)兼容性)的云平臺任務(wù)調(diào)度技術(shù)挑戰(zhàn), 本文創(chuàng)新地定義了RISC-V指令集親和性, 用以描述任務(wù)請求指令集模塊和節(jié)點指令集模塊匹配程度的量化指標. 與ARM/X86指令集向后兼容不同, RISC-V具有模塊化和可擴展的指令集架構(gòu), 除了4組基本指令集外, 還具有多個擴展指令集, 這也使得RISC-V架構(gòu)的處理器設(shè)計人員可以根據(jù)自身需求選擇是否添加這些擴展指令. 以指令集架構(gòu)RV64IMFDV為例, 其表示該架構(gòu)支持RV64I的基礎(chǔ)指令集與M、F、D、V四種擴展指令集, 那么類似于RV64I、RV64IM、RV64IMFD等12種架構(gòu)組合需求的Pod都能在該架構(gòu)的處理器節(jié)點上運行. 指令集親和性值最大的節(jié)點即表示Pod指令集架構(gòu)需求層面匹配最優(yōu)的Node節(jié)點.

定義(指令集親和性): 用于描述任務(wù)請求指令集模塊和節(jié)點指令集模塊的相似程度:

instructionAffinity=Pod模塊數(shù)/Node模塊數(shù)

其中, 模塊數(shù)是除去RV和處理器位數(shù)后的字母模塊的數(shù)目即IMFDV, Pod指令集模塊表示Pod請求的指令集架構(gòu), Node指令集模塊表示Node具有的指令集架構(gòu). 當兩者數(shù)目越接近, 則指令集親和性越高, 指令集匹配程度越高.

在具有多種混合架構(gòu)的Kubernetes集群中, 指令集架構(gòu)匹配是Pod正常運行的硬性指標. 由于Kubernetes的節(jié)點選擇(nodeSelector)約束和親和性約束都屬于完全約束, 且不支持模糊匹配, 所以本文設(shè)計的ISAMatch模型采用Kubernetes的標簽屬性, 旨在識別具有共同特征或?qū)傩缘馁Y源對象. ISAMatch模型具有兩類標簽屬性: ARCH標簽和QEMU標簽. 當Pod進入調(diào)度器時, 如圖3右側(cè)流程圖所示ISAMatch模型會首先判斷待調(diào)度Pod是否具有QEMU即是否具有交叉編譯需求, 如若沒有QEMU標簽則繼續(xù)判斷是否具有ARCH標簽即是否具有特定指令集架構(gòu)需求, 如若沒有QEMU標簽和ARCH標簽則轉(zhuǎn)入Kubernetes默認調(diào)度器進行調(diào)度. QEMU標簽過濾和ARCH標簽過濾的實現(xiàn)過程相似, 均采用架構(gòu)過濾、指令集過濾和節(jié)點打分依次執(zhí)行.

對所有候選Node節(jié)點執(zhí)行架構(gòu)過濾, 粗粒度的選出同族ISA指令集架構(gòu)節(jié)點, 而對于具有特有擴展指令集架構(gòu)的RISC-V節(jié)點, 還需要執(zhí)行指令集過濾, 對同族ISA指令集架構(gòu)節(jié)點進一步對擴展指令集的模塊名稱進行過濾, 必須具備Pod請求模塊是Node支持模塊子集的特點:

instructionPod?instructionNode

選出的候選節(jié)點為細粒度的同族ISA指令集節(jié)點. 候選節(jié)點進一步進行節(jié)點打分. 節(jié)點打分會選出具體綁定的節(jié)點, 打分機制將綜合考慮指令集親和性、同種指令集架構(gòu)節(jié)點的數(shù)量和節(jié)點資源利用率. 其優(yōu)先級為:

指令集親和性＞同種指令集架構(gòu)節(jié)點數(shù)量

＞節(jié)點資源利用率

具體示例如圖5所示, 在14個異構(gòu)ISA指令集架構(gòu)節(jié)點的集群中任務(wù)申請為RV64IMF. 架構(gòu)過濾會根據(jù)任務(wù)YAML文件中的ARCH標簽字段過濾粗粒度指令集架構(gòu)為9個RISC-V節(jié)點. 指令集過濾根據(jù)細粒度的擴展指令集架構(gòu)進一步過濾節(jié)點為7個支持IMF模塊的RISC-V節(jié)點. 節(jié)點打分策略依據(jù)優(yōu)先級順序首先計算候選節(jié)點的指令集親和性, 親和性結(jié)果會選出一組或多組指令集親和性相等的指令集架構(gòu)節(jié)點. 由于指令集親和性存在一定幾率選出多組指令集親和性相等的節(jié)點族, 因此, 本文設(shè)計了統(tǒng)計滿足條件的同種指令集架構(gòu)節(jié)點數(shù)量作為打分標準, 選擇擁有節(jié)點數(shù)量更多的指令集架構(gòu)節(jié)點將會為集群剩下更多的其余指令集架構(gòu)節(jié)點, 以方便之后對于其余指令集架構(gòu)需求任務(wù)的調(diào)度. 當具體選定了某一細粒度擴展指令集架構(gòu)時, 從候選節(jié)點中選擇資源利用率最小的節(jié)點進行綁定, 以提高在滿足調(diào)度申請條件的前提下的資源負載均衡程度和任務(wù)計算效率.

圖5 ISAMatch模型工作流程圖

4 實現(xiàn)與優(yōu)化

本文通過基于Volcano調(diào)度器實現(xiàn)了支持多種ISA指令集架構(gòu)任務(wù)的調(diào)度需求. 在不破壞Volcano源代碼結(jié)構(gòu)的前提下, 以插件的形式設(shè)計并實現(xiàn)ISAMatch模型.

4.1 標簽自動機

由于ISAMatch模型依賴于Pod和Node的ARCH標簽和QEMU標簽, 其中Pod所具有的標簽是由用戶在提交YAML文件時主動設(shè)置, 代表用戶提交任務(wù)所需要的指令集架構(gòu), 而集群中節(jié)點所支持的標簽需要集群管理員手動添加, 需要在集群部署完成后為所有節(jié)點添加節(jié)點支持的ISA指令集架構(gòu)和節(jié)點支持的ISA指令集交叉編譯架構(gòu). 在規(guī)模較大的Kubernetes集群場景下, 這種由集群管理員手動添加標簽的方式非常麻煩, 因此, 本文設(shè)計實現(xiàn)了自動標簽設(shè)置腳本.

自動標簽設(shè)置腳本運行在集群Master節(jié)點上, 通過kubectl命令工具從ETCD中獲取所有節(jié)點信息, 并由正則表達式過濾出節(jié)點IP. 同時, 在將節(jié)點部署進集群后, 節(jié)點會自動生成kubernetes.io/arch標簽用于識別節(jié)點指令集架構(gòu), 腳本從節(jié)點詳細信息中讀取節(jié)點IP和粗粒度節(jié)點指令集架構(gòu). 而對于RISC-V指令集架構(gòu)節(jié)點, 標簽顯示為kubernetes.io/arch=riscv64, 因而無法細粒度的識別RISC-V的具體擴展指令集架構(gòu), 因此需要從節(jié)點gcc-v中的--with-arch標簽獲取更詳細的ISA信息(如圖6).

圖6 gcc中的ISA信息

最后腳本模擬手動通過kubectl命令“kubectl label node $node ARCH=$ISA”添加ARCH標簽方式.

交叉編譯環(huán)境被默認安裝在/opt/RISCV/bin/路徑下, 同樣的, 由/opt/RISCV/bin/riscv64-unknown-linuxgnu-gcc-v獲取詳細擴展指令集架構(gòu), 最后通過kubectl命令工具由腳本模擬添加QEMU標簽.

4.2 架構(gòu)和指令集過濾以及節(jié)點打分流程優(yōu)化

架構(gòu)過濾和指令集過濾偽代碼如算法1所示.

算法 1. 架構(gòu)過濾和指令集過濾1. candidateNodes={}2. IF Contains(PodARCH, “RV”) THEN 3. FOR node in nodeList do 4. IF node→nodeARCH[:2]==“RV”&&ContainIns(node→nodeARCH[4:], PodARCH[4:]) THEN 5. candidateNode=append(candidateNodes, node)6. END IF 7. END FOR 8. END IF 9. ELSE

10. FOR node in nodeList do 11. IF Contains(node→nodeARCH, PodARCH) THEN 12. candidateNodes=append(candidateNodes, node)13. END IF 14. END FOR 15. END ELSE 16. return candidateNodes

架構(gòu)過濾是對系統(tǒng)指令集架構(gòu)進行的粗粒度過濾,是對Pod和Node節(jié)點設(shè)置的ARCH標簽或QEMU標簽進行的模糊匹配, 過濾不符合Pod任務(wù)申請的架構(gòu)的Node節(jié)點.

指令集過濾是針對RISC-V特有的擴展指令集的細粒度過濾, 由于擴展指令集兼容性的情況, 通過containIns函數(shù)判斷Pod任務(wù)申請的指令集架構(gòu)是否為Node支持的指令集架構(gòu)的子集.

如圖7, 打分機制綜合考慮指令集親和性、同種指令集架構(gòu)節(jié)點數(shù)量和節(jié)點資源利用率. 分別計算各個節(jié)點與請求Pod之間的指令集親和性、同種ISA指令集架構(gòu)數(shù)量和各個節(jié)點資源利用率, 并組合形成NodeISAInfo結(jié)構(gòu)體. 針對NodeISAInfo依次對指令集親和性、同種指令集架構(gòu)節(jié)點數(shù)量和節(jié)點資源利用率進行排序,依據(jù)優(yōu)先級公式選擇指令集親和性最大的一組或多組ISA指令集架構(gòu)節(jié)點, 在多組ISA指令集架構(gòu)節(jié)點中比較同種指令集架構(gòu)節(jié)點數(shù)量, 選擇多者, 最后在單組中選取資源利用率最低的節(jié)點作為候選的綁定節(jié)點.

圖7 打分機制函數(shù)流圖

5 評估實驗和結(jié)果分析

本文以Linux平臺最為常見的3種架構(gòu)作為研究對象(ARM、X86、RISC-V)進行分析, 主要進行:

(1) 評估在異構(gòu)RISC-V指令集架構(gòu)的集群環(huán)境下, 部署不同架構(gòu)(含X86、ARM和RISC-V指令集架構(gòu)芯片)需求任務(wù)的調(diào)度正確性;

(2) 統(tǒng)計在調(diào)度中與傳統(tǒng)調(diào)度器相比的性能延遲.

5.1 實驗平臺及數(shù)據(jù)

實驗平臺: 在5臺部署有Kubernetes集群的虛擬環(huán)境上進行驗證實驗. 其中包括一臺X86的虛擬主機、一臺ARM64的虛擬主機和3臺RISC-V的虛擬主機. 具體參數(shù)見表1.

實驗數(shù)據(jù): 實驗數(shù)據(jù)由隨機函數(shù)生成了90個服務(wù)型任務(wù)和10個計算型任務(wù), 100個任務(wù)所申請的CPU和Memory資源如圖8所示.

圖8 100個任務(wù)的資源分布情況

5.2 ISAMatch模型正確性測試

本文通過部署100個RISC-V任務(wù)對集群進行ISA架構(gòu)匹配的測試. 分別測試驗證: 1)部署100個RISC-V基礎(chǔ)指令集任務(wù), 即只需要在RISC-V節(jié)點上就能正常運行; 2)部署100個未帶有指令集架構(gòu)相關(guān)標簽的RISC-V擴展指令集任務(wù); 3)部署100個帶有“RISC-V”標簽的RISC-V擴展指令集任務(wù).

實驗表明(如圖9), RISC-V基礎(chǔ)指令集任務(wù)只需要部署到RISC-V節(jié)點上就能正常運行, 調(diào)度正確率為62%; 而未帶有指令集架構(gòu)相關(guān)標簽的RISC-V擴展指令集任務(wù)需要精確到具體的擴展指令, 如RV64IMFD只能運行在節(jié)點3和節(jié)點5上, 調(diào)度正確率為41%; 帶有“RISC-V”標簽的RISC-V擴展指令集任務(wù)雖然排除了ARM和X86兩種架構(gòu), 但部分調(diào)度未能精確找到匹配的擴展指令架構(gòu)的節(jié)點, 調(diào)度正確率為67%. 而在ISAMatch模型下, 調(diào)度正確率達到100%,ISAMatch模型可以準確的將Pod調(diào)度到合適的節(jié)點,并能夠更細粒度的通過指令集親和性找到最佳匹配節(jié)點, 如圖10所示, RV64IMFD可以成功運行在節(jié)點3和節(jié)點5上, 而根據(jù)指令集親和性, ISAMatch模型會選取更為匹配的節(jié)點3作為最佳匹配節(jié)點, 而只有當節(jié)點3無法滿足調(diào)度需求時才會選用節(jié)點5進行調(diào)度.

圖9 RISC-V任務(wù)在默認調(diào)度器下的調(diào)度正確率

圖10 指令集親和性下RISC-V擴展指令集任務(wù)調(diào)度選擇

5.3 調(diào)度延遲分析

進一步, 為了驗證具有ISAMatch模型調(diào)度器和傳統(tǒng)調(diào)度器的調(diào)度延遲, 實驗測試了調(diào)度1-100個Pod.其中, 調(diào)度單個Pod所需的調(diào)度延遲是統(tǒng)計待調(diào)度Pod在Volcano調(diào)度器中從調(diào)度起始函數(shù)OpenSession開始到綁定具體節(jié)點后的CloseSession結(jié)束所用的時間. 從圖11可以得出當部署40個以內(nèi)的Pod數(shù)時, 傳統(tǒng)調(diào)度器和具有ISAMatch模型的調(diào)度器調(diào)度所用延遲在誤差范圍內(nèi)接近, 大約在1 ms左右. 而當部署40個以上Pod時, 具有ISAMatch模型的調(diào)度器所消耗的調(diào)度延遲略大于傳統(tǒng)調(diào)度器, 并隨著Pod數(shù)量的增加, 兩者之間的差值也逐步增大, 在部署100個Pod時, 具有ISAMatch模型的調(diào)度器比傳統(tǒng)調(diào)度器多耗時約6 ms.這是由于隨著Pod數(shù)目的增加, 每一輪Session對單個Pod進行調(diào)度時都需要額外對其ISA指令集架構(gòu)進行匹配, 經(jīng)測量, 對單個Pod進行ISA指令集架構(gòu)匹配的平均耗時為60.57 μs. 部署100個Pod有無ISAMatch模型耗時的差值與Pod個數(shù)不構(gòu)成線性關(guān)系(如圖12),且與平均耗時不成倍數(shù)關(guān)系, 其原因是隨著Pod數(shù)目增大后無法在同一個Session中完成調(diào)度, 需要開啟多個Session進行調(diào)度, 因此會有額外的調(diào)度損耗.

圖11 ISAMatch模型調(diào)度延遲

圖12 有無ISAMatch模型延遲差與單任務(wù)延遲線性對比

6 結(jié)語

針對目前Kubernetes集群無法支持異構(gòu)ISA指令集架構(gòu)任務(wù)調(diào)度的問題, 提出了一種具有ISA指令集感知能力的異構(gòu)資源調(diào)度方案. 應(yīng)對多種RISC-V擴展指令集架構(gòu)需求任務(wù), 提出了指令集親和性標準, 并在此基礎(chǔ)上通過架構(gòu)過濾、指令集過濾和節(jié)點打分3個維度的綜合評價, 在保證調(diào)度性能的前提下, 提高集群調(diào)度正確性和資源利用率, 使集群有能力應(yīng)對更多復(fù)雜場景.