在離線混部作業調度與資源管理技術研究綜述?

王康瑾,賈 統,李 影,2

1(北京大學 軟件與微電子學院,北京 102600)

2(北京大學 軟件工程國家工程研究中心,北京 100871)

3(北京大學 信息科學技術學院,北京 100871)

大規模數據中心是當今企業級互聯網應用和云計算系統的關鍵支撐.為保障日益增長的互聯網應用和云計算系統的計算需求,數據中心需要不斷擴容,其規模和服務器總量呈現快速增長趨勢.權威報告[1]指出,2020 年全球數據中心的服務器總量將達到1 800 萬臺,并且正以每年100 萬臺的速度增長.然而,伴隨著數據中心的急速擴容,其資源利用率卻始終處于較低狀態.統計數據表明[1],目前全球數據中心資源利用率僅為10%～20%,如此低的資源利用率意味著數據中心大量的資源浪費,導致目前數據中心的成本效率極低.因此,如何提升數據中心資源利用率成為一個亟需解決的關鍵性技術問題.

通常而言,數據中心以作業為抽象單位執行計算任務.按照計算任務的不同可將作業分為在線作業和離線作業.在線作業通常是以服務形態來處理用戶請求并執行計算任務,如網頁搜索服務、在線游戲服務、電商交易服務等,具備較高的實時性和穩定性需求.為保障上述需求,企業往往會對外提供明確的服務等級協議(service level agreement,簡稱SLA),以明確的條款約定服務質量.違反SLA 會給企業帶來經濟損失,因此數據中心往往為在線作業預留大量的服務器資源以保證其服務質量.離線作業通常是計算密集型的批處理作業,如MapReduce和Spark 作業[2,3]數據分析作業/機器學習模型訓練作業等.多數離線作業對于性能沒有嚴格的要求,可以容忍較高的運行延遲并支持失敗任務的重啟.按照集群上所運行的作業類型,數據中心可劃分為在線集群和離線集群.在線集群通常因在線作業對性能的高要求而采用過量資源供給策略,導致資源利用率較低;與之相反,隨著大數據[4-7]和人工智能的發展,離線作業的規模日益擴大,離線集群對計算資源的需求日益增長,導致現有集群資源供給不足[8].因此,提升數據中心整體資源利用率的理想方法是在保障在線作業性能的前提下,將在線集群的空閑資源分配給離線作業,即:將在線作業與離線作業混合部署于同一集群,簡稱“混部(colocation)”.目前,在離線混部已成為數據中心提升整體資源利用率的主流方法[9].

在混部作業運行過程中,由于在離線作業競爭共享資源(如CPU、緩存、內存帶寬、網絡帶寬等),往往會導致作業性能下降(performance degradation),該現象也被稱為性能干擾(performance interference)[10-15].性能干擾會嚴重影響在線作業的實時性和穩定性,降低離線作業的吞吐率,因此,混部集群管理系統必須有效控制性能干擾,并根據性能干擾快速、及時地做出調整.然而,性能干擾的程度受諸多因素影響,尤其是在超大規模的數據中心中,作業負載的動態性、資源需求的多樣性、硬件架構的異構性等導致性能干擾復雜性劇增.為降低復雜的性能干擾,混部集群管理系統必須能夠協調集群層的作業調度和節點層的資源管理,實現性能干擾的分層控制.集群層的作業調度,即決策作業運行的具體位置(具體某個服務器).混部作業調度是一個復雜的多目標優化問題,既需要兼顧集群的負載均衡、整體吞吐率、資源公平性等目標,又需要特別考慮性能干擾的影響,根據性能干擾的變化隨時調整調度策略;節點層的資源管理,即利用資源隔離技術根據性能干擾變化動態調整運行作業的資源供給.因此,集群層的作業調度和節點層的資源管理成為降低和控制性能干擾、提升資源利用率的重要手段.

本文首先分析了在離線作業的特征,深入探討了在離線作業在混合部署中競爭共享資源帶來的性能干擾及作業調度和資源管理問題,就作業性能干擾模型、集群層面的混部作業調度以及節點層面的資源管理等關鍵技術進行了詳細介紹和分析,并結合4 個系統實例探討了在離線混部關鍵技術在產業界的實現及其效果,最后就未來的研究方向進行了討論和展望.

1 概述

本節分析了在線作業和離線作業的各自特點,并探討了在離線混部集群管理上所面臨的主要問題與挑戰.

1.1 在線作業與離線作業

在線作業.在線作業通常是處理用戶請求的服務,典型的在線作業有網頁搜索、即時通信、語音識別、流式計算、電子商務、流媒體等,通常可為企業帶來直接的經濟利益.在線作業具有如下特點.

(1)運行時間長.在線作業通常以服務的形態持續運行,以請求(request)為單位觸發計算任務.例如,網頁搜索服務、數據庫服務、社交網絡服務等[16,17],運行往往持續數周甚至數月,因此在線作業也被稱為長服務(long runing service)[18].

(2)資源使用呈現動態變化.在線作業的資源使用量與用戶并發請求量呈正相關,會伴隨用戶并發請求量發生動態變化.圖1 所示為國內某互聯網公司的在線作業計算節點一個月內的CPU 使用量變化曲線,隨著時間的推進,該作業的CPU 使用量呈現了明顯的以天為周期的動態變化特征.此外,圖1 中還出現了多次CPU 利用率突變的現象,這是因為,某些社會事件,如突發熱點新聞、電商網站的促銷活動等會導致用戶并發請求突增[19].

(3)對性能變化敏感.在線作業的性能通常決定了企業對外服務質量,而服務質量則直接影響企業的經濟利益和用戶體驗.例如,Amazon 的統計數據顯示,Amazon 的網頁響應速度慢0.1s 便會導致1%的用戶放棄交易[20];也有研究表明,交互式應用的響應時間只有在100ms 以內時才能給用戶流暢的使用體驗[21].因此,在線作業又被稱為延時敏感型作業(LC(latency critical)Job 或 LS(latency sensitive)Job)[13,15].

Fig.1 Static software defect prediction research framework using defect-proneness as prediction target圖1 某在線作業所在服務器CPU 使用率波動曲線,采樣時間為1 個月

離線作業.離線作業是指數據中心中優先級較低的、對性能要求不高的批處理作業,如MapReduce 作業和機器學習訓練作業等,離線作業具有如下特點.

(1)運行時長較短.對Google 和阿里巴巴數據中心中的離線作業運行時長統計后發現[22-25],離線作業運行時長大多位于數分鐘到數小時這一區間.因此,與運行持續數周甚至數月的在線作業相比,離線作業的運行時長較短.

(2)計算密集.離線作業通常需要進行大量的計算操作,數據統計顯示,阿里MapReduce 作業的CPU:Mem約為1:4,即每使用4G 內存便會消耗1 個CPU 的全部計算能力;深度學習模型訓練作業也是典型的離線作業,此類作業通常需要進行大量的梯度計算,并且通過多次迭代直至模型收斂.

(3)對性能變化不敏感.離線作業通常為批處理作業,對于性能沒有嚴格的要求,可以容忍較大的運行延遲并支持任務的失敗重啟.

Table 1 Comparisons of LC jobs and BE jobs表1 在線作業和離線作業對比

由于在線作業運行時的低延遲要求,為保證在線作業的性能,一般采用了在線作業獨占集群的方式,避免與其他作業共享計算資源,并且為在線作業分配過量的計算資源以應對在線作業動態的資源需求.圖1 所示在線作業的峰值CPU 需求可達80%,為滿足其在峰值負載時的計算資源需求,采用了一個在線作業實例獨占一臺服務器的部署方式.這種部署方式導致在線作業集群平均資源利用率較低(服務器月平均CPU 利用率僅為20%).與此同時,離線作業的規模日益擴大,對離線集群計算資源的需求呈現快速增長,導致離線集群資源不足[8].因此,混部成為提升數據中心資源利用率的理想方法[26],即在保障在線作業性能的前提下,將在線集群的空閑資源分配給離線作業.混部既可以滿足離線作業的資源需求,也可以提升在線集群的資源利用率,因此成為提升數據中心整體資源利用率的主流方法.

1.2 問題與挑戰

由于多個作業競爭共享資源(如CPU、緩存、內存、內存帶寬、網絡帶寬),導致作業間出現性能干擾[13,14].這種在離線混部作業間的資源競爭及性能干擾使得混部集群作業調度與資源管理變得十分復雜.圍繞如何減少和控制在離線混部作業間的性能干擾,同時提升混部集群的資源利用率,本節總結和分析了在離線混部集群管理面臨的主要問題與技術挑戰.

1.2.1 在離線混部作業性能干擾問題

在離線混部作業的性能受到諸多因素的影響,呈現出性能對干擾的敏感性具有動態變化、模式多樣復雜等特點,尤其是在超大規模混部集群中動態變化的作業負載、多樣化的資源依賴以及異構硬件架構等使得在離線混部作業的性能難以建模,在各種干擾模式下的性能預測變得極具挑戰性,也增加了集群作業調度和節點資源管理的難度.

首先,如前所述,在線作業的工作負載具有動態性,同一作業的性能在不同工作負載下對于干擾的敏感性并不相同,由于高工作負載時作業所需的計算資源高于其低負載時的需求,因而高負載下的在線作業對資源有更強的競爭,也對干擾更加敏感;其次,運行在數據中心的在離線作業數量龐大且種類繁多,對關鍵資源的依賴性因其運行邏輯不同而各異,若混合部署于同一節點上的在線作業與離線作業具有同樣或類似的關鍵資源依賴性,則會加劇其相互間的性能干擾;再次,節點上作業的細粒度資源共享主要依靠操作系統的資源調度機制,如分時共享或搶占式調度等,不同的資源調度機制會使得作業在運行時具有不同的抗干擾性,例如搶占式調度可減少作業在就緒進程等待隊列中的排隊時間,相比于分時共享的公平調度機制,搶占式調度的資源共享因其能使作業具有更好的抗干擾性而更適合于在線作業;最后,隨著計算機體系結構的發展,硬件架構出現了單核、多核、異構多核等多種架構,提供了多樣化的硬件級別的抗干擾機制,例如多核體系結構通過增加CPU 的數量來減少作業間對于CPU 的競爭,支持Intel CAT(cache allocation technology)的CPU 可為不同的進程劃分私有的L3 緩存空間,從而降低作業因競爭L3 緩存資源而引起的性能干擾.這種異構硬件架構所帶來的抗干擾機制的多樣化更進一步增加了在離線混部作業性能預測的難度.

1.2.2 在離線混部作業調度問題

作為數據中心管理的關鍵技術,作業調度一直是學術界和產業界研究的熱點領域,傳統作業調度研究工作側重于資源公平性[27,28]、負載均衡、提高吞吐率[29]或資源利用率等多目標.對于在離線混部作業調度而言,除了滿足這些目標以外,在線作業與離線作業兩種類型作業的特點及其混合部署所帶來的必然的資源競爭和性能干擾使得混部集群作業調度問題更具有挑戰性.

首先,如前所述,在離線混部作業的性能受到諸多因素的影響,呈現出性能敏感性動態變化、干擾模式多樣復雜等特點,在動態負載和復雜干擾模式下的作業性能預測模型難以構建;其次,在離線作業調度機制需要充分考慮到在線作業與離線作業兩種類型作業的運行特點和性能要求,對于離線作業而言,因其運行時間短,并行度高,需要較高的調度吞吐率和較低的調度延時;相對而言,在線作業則可接受一定程度的調度延時;最后,數據中心中在線作業與離線作業的數量龐大且種類繁多,其混合部署的組合數量將呈現指數爆炸狀態,如何在巨大的解空間中快速搜索到滿足多目標的在線作業與離線作業混部組合,進而進行作業調度,是一個難題.

1.2.3 在離線作業的共享資源隔離問題

導致性能干擾的一個重要原因是具有同樣或類似關鍵資源依賴性的在線作業與離線作業對共享資源的無序競爭.資源隔離技術通過軟件或軟硬件協同技術控制作業對資源使用的方式來降低甚至消除對資源的無序競爭,例如Linux CGroup 支持CPU、內存、磁盤等資源的隔離,NUMA(non uniform memory access architecture)架構采用多內存通道技術減少內存帶寬的競爭,Intel CAT 的Cache 隔離機制通過隔離不同作業所使用的緩存空間緩解作業在競爭L3 Cache 時發生的緩存相互替換.然而,在離線混部作業的資源隔離技術仍是一個難題.

首先,現有體系結構中的資源類型繁多,諸如現有的通用硬件在TLB 快表、L1/2 緩存、緩存帶寬、內存帶寬、總線帶寬等諸多關鍵資源仍然缺乏對應的軟硬件協同的資源隔離機制,尚無法實現應用級隔離;其次,在目前高度復雜的硬件上通過軟件方法精準控制作業對于硬件資源的競爭需要同時考慮操作系統和硬件架構的具體實現,而多數商用硬件具有黑盒性,極大地增加了使用軟件方法隔離硬件資源的難度,因此具有挑戰性.

1.2.4 資源動態分配問題

在離線作業的資源需求隨作業負載而發生動態變化[30].為保障在線作業的響應時間并提升集群資源利用率,需根據負載的變化動態分配相應的資源,優化資源配比.然而,一方面,在離線混部作業間存在的不可知且復雜的干擾會嚴重影響作業的性能;另一方面,作業資源配比的變化也會影響性能干擾的程度,進而產生作業的性能變化.因此,如何在資源動態分配過程中平衡資源利用率和作業性能也是一個難題,也稱為近年來的研究熱點[19].

首先,資源重分配帶來的性能干擾變化難以建模和量化,作業性能難以預測和保障.如前所述,動態變化的作業負載、多樣化的資源依賴以及異構硬件架構等均會影響作業性能,使得在各種干擾條件下的性能預測變得極具挑戰性.資源重分配改變了作業的關鍵資源瓶頸,刷新了資源依賴關系,重置了性能對干擾的敏感度,帶來了一系列不可控的連鎖反應,更加劇了性能干擾的變化和不確定性.其次,資源類型多樣復雜,資源間存在互補、互替代、單向依賴、多向依賴等復雜關系,使得資源分配策略搜索空間極大,限制條件極為復雜.最后,在線作業的實時負載波動和高性能需求要求資源動態分配具備精準和快速的特性.然而,由于復雜性能干擾導致作業性能難以預測,依靠有限的負載變化、混部作業組合變化等信息快速做出精準的資源分配決策極為困難.

2 相關研究工作

2.1 研究框架

針對上述問題和挑戰,本文從在離線混部作業性能干擾模型、集群層面的作業調度以及節點層面的資源管理這3 個方面進行研究,如圖2 所示.

Fig.2 Research framework圖2 研究框架

性能干擾模型.為了解決在離線混部作業的性能干擾問題,須就作業的運行環境對性能的影響進行建模,以預測作業在動態負載、資源競爭及干擾模式等條件下的性能,為集群作業調度和節點資源管理提供指導.

集群層混部作業調度.混部作業調度所研究的內容是作業的放置問題,即決定作業的運行位置.混部作業調度是一個多目標優化問題,在傳統作業調度的優化目標上,還需要優化在離線作業間的性能干擾,同時滿足在線作業的SLA,兼顧作業吞吐率等要求.

節點層混部作業資源管理.混部作業資源管理須:(1)為作業的運行控制資源供給,在滿足作業資源需求的同時減少作業間的性能干擾;(2)根據作業運行狀況預測其資源需求并做出分配策略.前者涉及到操作系統和硬件架構的資源隔離技術,后者則涉及資源動態分配算法.

2.2 性能干擾模型

性能干擾模型就在離線混部作業的運行環境對作業性能的影響進行建模,以預測在動態負載、資源競爭及干擾模式等條件下的作業性能,為集群層面混部作業調度和節點層面混部資源管理提供指導.性能干擾模型的形式化描述由式(1)給出,式(1)代表作業的性能模型,性能模型的輸入包含4 部分:作業當前的負載load、作業當前所面臨的來自其他作業的資源競爭壓力pressure、作業當前的資源供給res、作業運行的硬件架構hw,輸出則為作業j在當前運行環境下所能達到的性能pf.

性能干擾模型的輸出代表了作業的性能,但在線離線作業通常具有不同的性能指標,例如,在線作業的性能評價指標通常是請求的響應時間(response time,簡稱RT),離線作業的性能評價通常是作業的運行時間或作業吞吐率等指標.上述指標與作業的具體邏輯相關,可以直接反映作業真實的性能狀況,因而被多個研究工作采用,如文獻[13,31-34].但是獲取作業級別的性能指標需要與具體應用對接,具有較差的可遷移性.并且,在公有云環境或大規模數據中心中,由于作業的黑盒性或隱私條款,獲取作業級性能指標并不可行,因此不少性能干擾模型采用了系統底層的性能指標作為作業的性能指標,如描述作業在每個CPU 時鐘周期可執行的指令數量IPC(instructions per cycle)或者CPI(cycles per instruction)、MIPS(million instructions per second).作業間的性能干擾可引起上述指標的變化,例如一個在線作業的緩存空間被離線作業替換掉后,后續的指令在執行過程中發生了緩存缺失(cache miss),導致執行訪存指令所需的處理器周期數增加,導致IPC 降低.底層性能指標由于具有通用性強、方便獲取等優點,被廣泛用于性能干擾模型中,如文獻[12,35-37].

性能干擾模型的第1 個參數load表示作業當前的負載,對于在線作業的負載表現為當前請求并發數,如RPS(requests per second)和QPS(queries per second),而離線作業的負載則與作業的輸入數據規模相關.性能干擾模型的第2 個參數pressure代表作業當前面臨的資源競爭壓力,即作業所遭受的性能干擾,目前關于資源競爭壓力并沒有統一的量化標準.文獻[14,35]采用了一個對性能敏感的程序(稱為reporter 或ruler)的運行時間并將其運行時間作為pressure.文獻[32,33]則使用當前的內存帶寬使用量作為pressure.文獻[38]則引入了服務內部的隊列長度作為pressure.第3 個參數res代表當前分配給作業的可用資源,由一個向量表示,可包括CPU、內存、Cache 在內的多種共享資源.不同的性能干擾模型由于面向的場景不同,在參數的取值范圍上有所不同,如面向異構集群的性能干擾模型需要在hw參數上具有多種取值,如文獻[39,40],而面向同構平臺的性能模型的hw參數則為定值;面向恒定作業負載場景的性能干擾模型的load為定值.

建立性能干擾模型的過程可分為兩步:(1)數據獲取;(2)模型構建.建立性能干擾模型的第1 步是獲取性能干擾數據,即獲取數據集D={d1,d2,...,dn},d={load,pressure,res,hw}.在數據獲取方法上,存在基于干擾注入的數據獲取方法和基于歷史監控數據的數據獲取方法兩種.

基于干擾注入的數據獲取方法的基本思想是在作業運行時向作業運行環境中注入性能干擾,通過不斷改變干擾的強度從而獲得該作業在不同干擾下的性能變化.注入干擾的方法是在作業運行環境中運行一個干擾者,干擾者通常是精心設計的一個資源密集型程序,可與作業競爭在多種共享資源上產生資源競爭.例如:作為作業運行中最主要的資源——CPU 時間片,其上的干擾可以使用大量的循環語句來產生;內存子系統是競爭最激烈的資源之一,由于內存子系統具有層次化的特點,對于不同層次的資源競爭可以通過讀寫不同大小的數組來產生;文獻[41]總結和列舉了15 種干擾源并提出了可在多種維度上產生性能干擾的工具iBench.使用iBench作為干擾注入工具的研究工作有文獻[39,40].文獻[14,32,33,35]專注于內存子系統上的干擾,使用了可產生內存帶寬干擾的干擾者用于獲取內存帶寬干擾和作業性能的變化關系.文獻[42]研究了超線程之間由于共享計算單元而引起的性能下降,并在性能模型中考慮了來自相鄰超線程的干擾.基于干擾注入的數據獲取方式理論上可以獲取作業在多種性能干擾下的性能數據,但其局限性在于:(1)造成干擾的資源類型多,采樣空間大,因此獲取較為全面的性能干擾數據所需采樣時間長;(2)由于操作系統和高級程序設計語言屏蔽了底層的硬件細節,實現能夠在特定資源上產生特定強度干擾的干擾者需要設計人員對體系結構和高級程序設計語言具有深入的了解,因此設計和實現有效的干擾者具有一定的難度.

基于歷史監控數據的數據獲取方法從作業運行產生的監控數據中提取出性能干擾模型所需要的數據集.在數據中心的運行過程中,積累了大量關于作業運行的監控數據,由于數據中心作業的動態性,作業在長期運行過程中會遭受不同程度的性能干擾,因此歷史監控數據中蘊含著可用于構造性能干擾模型的數據.基于歷史監控數據的數據方法具有如下優點:(1)無需運行作業,避免了額外的資源消耗和時間開銷;(2)數據易獲取;(3)數據量大.但是該方法同樣存在著如下局限性:(1)靈活性差,只能獲取歷史監控數據中監控的資源,如需新增監控維度則需要重新積累歷史數據;(2)無法獲取從未運行過的新作業;(3)適用范圍有限,僅適用于作業運行環境動態性高、資源競爭程度變化范圍大的集群,而對于作業運行環境穩定的集群,如在線獨占集群的部署策略,則由于作業運行環境缺乏足夠的性能干擾而無法獲得較為全面的性能干擾數據.

Table 2 Comparisons of performance interference models表2 性能干擾模型對比

獲取到性能干擾數據后,進入性能干擾模型構建階段.目前性能干擾模型的構建方法主要包括基于統計方法和基于機器學習兩種.基于統計的方法通過數理統計求得模型中各變量的變化關系,如文獻[14,35]建立了描述資源競爭壓力(使用reporter 測量得到)和作業性能的映射關系,稱為“敏感函數(sensitive function)”;文獻[43]使用統計模型建立了內存帶寬和作業性能的變化關系;文獻[37]則通過構建作業和作業之間的混部運行性能的二維表,通過查表的方式即可實現性能干擾的預測.基于統計方法的優點是:(1)計算量小,模型構建和更新速度快;(2)可解釋性強,便于優化.但其局限性在于:(1)模型的設計需要先驗知識,構造和優化具有一定的難度;(2)當數據維度增多時傳統的統計方法無法適用.隨著機器學習方法的發展,研究人員嘗試將機器學習模型應用于性能干擾模型,采用了諸如隨機森林回歸模型[31]、協同過濾算法[39,40]、線性回歸[32,33]、聚類算法[12,36]、深度神經網絡[38,44]等方法完成從作業運行時信息到作業性能的映射,基于機器學習算法建立的性能干擾模型可以學習到人類無法察覺的特征,并且具有良好的預測結果.缺點是:(1)需要高質量的訓練數據;(2)缺乏可解釋性,難以優化;(3)在建立模型時需要較長的訓練時間和計算開銷.

2.3 在離線混部作業調度

作業調度是數據中心和云計算領域的研究熱點,在離線混部作業向傳統的作業調度提出了新的挑戰.本節圍繞第1.2.2 節中總結的3 點挑戰,討論近年來在離線混部作業調度領域的相關研究工作.

與傳統作業調度相比,在離線混部作業調度需要考慮如何放置待調度作業使得作業間的性能干擾最小,尤其是對在線作業的性能干擾最小.這就需要調度器從集群的所有節點中篩選出待調度作業對其上運行的在線作業性能干擾最小的節點.本文總結了篩選節點的兩種常用方法.

(1)基于性能模型篩選節點.該方法首先對在線作業建立性能模型,進而使用性能干擾模型來預測混部后作業所能達到的性能指標,通過搜索的方法尋找產生干擾較小的節點.例如:文獻[14,34]在使用性能干擾模型預測不同作業混部運行時的性能,以預測數據為依據判斷該混部作業組合是否“安全”(“安全”的混部組合是指混部組合中的每個作業都能達到其要求的性能指標);文獻[28,39,40,45]使用協同過濾模型預測一個作業與其他作業混部時所能達到的性能,進而使用貪心算法搜索作業的最佳運行位置.使用預訓練的性能干擾模型作為調度的依據取得了較好的效果,例如文獻[14]在保證在線作業QoS(quality of service)的情況下提升了50%～90%的集群整體資源利用率;文獻[39]可以保持52%的作業的QoS 不被影響,而另外33%的作業的QoS 波動低于10%.雖然可以有效地避免作業之間的性能干擾,但是該方法依賴了預構建的性能模型,而獲取性能干擾數據和構建性能模型所帶來的開銷是不可忽略的問題;

(2)基于空閑資源篩選節點.由于干擾和資源的相關性,空閑資源多的節點意味著該節點目前負載較少,因而有可能承受更多的資源競爭.文獻[46,47]通過預測未來一段時間集群的空閑資源數據,進而用于作業調度;文獻[48]提出一種作業偷取機制,當在線作業集群位于較低負載時可從待運行離線作業隊列中調度一部分作業至在線集群運行;文獻[49]在調度時首先對作業的CPU 和I/O 資源需求進行聚類,然后在作業間進行資源的匹配,進而完成調度.根據作業資源調度簡單實用,因此適合在大規模混部系統中使用[9,50].本文在第2.2 節中指出,作業間的性能干擾還與作業本身資源的使用特征相關,因此僅考慮將作業調度至空閑資源多的節點并不能完全保證該節點上在線作業的QoS,因此仍存在一定的風險.

在離線混部調度不僅要減少作業間的性能干擾,還要滿足傳統作業調度中存在的資源公平性、作業資源需求、集群負載均衡、集群吞吐率等多個優化目標,為解決在離線混部作業調度面臨的多目標優化問題,相關工作中使用了3 類算法.

(1)啟發式算法.基于專家直觀經驗構造算法用于尋找最優調度結果,啟發式算法由于其簡單直觀,易于理解和修改,被多種在離線混部作業調度算法所采用,如文獻[34,39,40,48,49];文獻[14]通過性能干擾模型預測作業在每個機器上運行時產生的干擾,然后尋找干擾最小的節點作為作業的部署節點.文獻[52]將博弈論應用于在離線混部作業調度,使用Shapley 算法尋找作業和節點之間穩定的婚姻匹配組合(如果A喜歡b的程度比喜歡自己的配偶更高,并且b同樣對A的喜好程度比自己的配偶更高,則他們很可能組成新的家庭,這樣的組合是不穩定婚姻,不存在不穩定婚姻的組合被稱為穩定婚姻組合),在保證作業性能的同時保證資源分配的公平性.啟發式算法的局限性在于:(a)當需要優化的目標較多時,調度問題的復雜度上升,設計兼顧多個目標的啟發式算法具有一定的難度;(b)啟發式算法難以保證算法給出的解是全局最優解;

(2)打分規則,當調度優化目標較多時,對每個目標設定量化規則,并使用這些規則對每個節點進行打分,將最終的加權分數作為節點最終得分,最后將作業調度至得分最高的節點.常見的打分規則有:根據負載打分,負載最低時節點得分為10,滿負載時得分為0 等.節點的最終得分是所有規則的得分加權和,調度算法選擇得分最高的節點作為調度決策,基于打分規則的調度算法有文獻[47,52].該方法的優點是易于擴展(如果有新的優化目標只需添加新的打分規則即可),計算開銷低,但其局限性在于:(a)每個規則的權重作為調度算法的超參數,對調度結果影響較大,尋找最佳的超參數設置需要經過不斷的調試;(b)基于打分規則的調度算法同樣難以保證算法給出的解是全局最優解;

(3)整數線性規劃.作業調度問題可以抽象為組合優化問題,而整數線性規劃問題(integer linear program,簡稱ILP)作為組合優化的一種解決方法,可用于解決作業調度問題.文獻[18]通過對減少親和性違反、最大化成功調度的作業數量、最小化資源碎片、集群負載均衡、最大化資源利用率等多種目標進行量化后,并使用加權的方式將多個優化目標統一在一個全局目標函數中,使用CPLEX 優化器求解.基于整數線性規劃的調度算法的局限性在于:(a)算法開銷較大,文獻[18]通過實驗證明,在同等規模下,整數線性規劃算法的求解時間開銷均高于啟發式算法和基于打分規則的調度算法;(b)目標函數的構造對調度質量至關重要,對多個優化目標進行量化表示具有一定的難度.

混部作業調度算法對比見表3.

Table 3 Comparisons of hybrid job scheduling algorithms表3 混部作業調度算法對比

調度性能方面,當集群規模較小時使用集中式調度(centralized scheduling)即可滿足作業對于調度延時的要求,集中式調度的特點是所有作業由一個中央調度器進行調度,該方法的優點是全局信息共享,可獲得較好的調度質量,采用集中式調度的在離線混部作業調度算法有文獻[14,18,34,40,43,47,49,51];當集群規模逐步擴大時,中央調度器成為作業調度的性能瓶頸,分布式調度(distributed schedulig)和層次化調度(hierachical scheduling)采用分治的思想,使用多個調度器共同承擔作業調度的壓力.分布式調度是指在一個集群中同時運行多個調度器,每個調度器只負責將作業調度至集群中的部分節點,可以實現并發作業調度.分布式調度的優點是可用性和吞吐率高,局限性在于各調度器無法感知集群的全局信息,因此可能產生次優的調度決策.層次化調度是集中式調度和分布式調度的折中方案,層次化調度通常設置兩層調度器,作業首先由頂層調度器調度至底層調度器,再由底層調度器將作業調度至計算節點.每個底層調度器只管理一部分計算節點,因此縮小了調度算法的搜索空間.文獻[39]采用了層次化的調度方法;文獻[48]采取了集中式化調度和分布式調度相結合的調度方法,在線作業由集中式調度器調度以獲得較高的調度質量,離線作業則由分布式調度器調度以獲得較短的調度延時.

2.4 在離線混部作業資源管理

本節詳細介紹在離線混部作業資源管理中的資源隔離技術和資源動態分配的相關研究工作.

2.4.1 資源隔離技術

混部集群單個節點通常會部署多個作業,如Google 的混部集群有50%的節點同時運行超過9 個作業[12].這些作業在運行過程中依賴系統中的多種共享資源,進而產生共享資源競爭.目前解決共享資源競爭的主要方法是通過限制作業對于共享資源的使用量,進而減少作業之間在使用共享資源時發生沖突的可能性.但是,根據排隊論原理,多個作業在競爭同一資源時的排隊時間是影響作業性能的重要因素,例如多個作業同時競爭CPU、內存帶寬、網絡帶寬等資源,在這種情況下僅對于作業做資源使用量限制并不能完全消除作業間的資源競爭,因此還需要對作業進行優先級劃分以減少高優先級作業在競爭共享資源時的排隊時間(通常在線作業會被分配高優先級).本文根據共享資源在系統中的層次將資源隔離技術分為操作系統層的資源隔離技術和硬件層的資源隔離技術.

操作系統層的資源隔離技術對操作系統中的共享資源進行隔離,如:

(1)CPU 時間片資源.為解決多個作業對于CPU 的競爭,最直接的方法是利用多核體系結構的特性(如圖3所示),將不同的作業綁定在不同的CPU 上運行.但是作業獨占CPU 的部署方式會導致較低的CPU 利用率,進一步提升CPU 利用率須運行更多的作業并在多個作業間共享CPU.Linux CGroup 提供了CPU Share 和CPU Quota 機制,可通過操作系統的進程調度機制限制作業單位時間內可使用的CPU 時間片長度;CPU 上的優先級劃分則表現為進程優先級(如進程的Nice 值),文獻[53-55]在進程調度中增加了搶占機制,即在線作業可搶占離線作業的CPU 時間片,增強了在線作業與離線作業共享CPU 時的抗干擾性.

(2)網絡帶寬資源.網絡帶寬資源作為互聯網基礎設施中的核心資源,被在線和離線作業高度依賴.在線作業需要通過網絡接收用戶請求,處理完成后再通過網絡將結果發送給用戶,因此網絡帶寬競爭會引起在線作業發送網絡包時排隊時間的上升,進而影響在線作業的服務質量;離線作業在處理數據前首先需要通過網絡讀取大量數據,如MapReduce 作業需要從遠端HDFS 讀取數據.因此,離線作業會在網絡帶寬上產生資源競爭.在MapReduce 與Memcached 的混部實驗中,MapReduce 在數據讀取階段所產生的網絡帶寬競爭會使Memcached 的延遲上升83 倍[56].網絡帶寬資源隔離目前存在兩種方法:(a)帶寬劃分,即為每個作業設定最大網絡帶寬限制以防止作業過度使用網絡帶寬而引起過度的資源競爭,采用這種方法的有文獻[57-59];(b)網絡包優先級劃分,網絡包優先級劃分方法的主要思想是高優先級作業發送的網絡包可以直接越過低優先級作業的發送隊列,可有效減少高優先級作業網絡包的排隊時長,如文獻[55,60-62].

(3)磁盤I/O 帶寬資源.Linux CGroup 提供了作業級別的磁盤I/O 控制,可限制作業的最大磁盤I/O 帶寬使用量.

Fig.3 Classical multi-cores memory architecuture and recent Intel CPU microarchitecutre[63]圖3 經典多核存儲體系結構與Intel CascadeLake 微架構[63]

硬件層的資源隔離技術通過軟硬件協同技術從協調多個作業在硬件資源上的競爭,減緩甚至消除多個作業在硬件資源上的相互干擾.目前硬件層的資源隔離技術涉及的資源包括:

(1)內存通道.內存通道(memory channel)是競爭激烈的共享資源之一,對作業的性能影響巨大[64-66].目前數據中心中所使用的微架構通常采用了多通道設計,如圖3(右)所示的Intel Cascade Lake 架構采用了6 通道設計,可同時支持6 個CPU 獨立地訪問內存.多個CPU 在單個內存通道上的訪問過程可用排隊模型描述,單次內存訪問請求的完成時間Tmem_req=TQueue+TR/W,其中,TQueue代表請求在等待內存通道的排隊時間,TR/W代表內存的存取時間,通常為定值;排隊時間TQueue則取決于隊列長度,即隊列中位于該請求之前的請求個數.因此,當一個作業占用過多的內存帶寬時,會使同一時段內其他作業的訪存請求的排隊時間變長,從而產生性能干擾.在馮諾依曼體系結構中,內存作為核心資源,被所有程序所依賴,因此從CPU 到內存的內存帶寬資源對程序至關重要.但對于內存帶寬上的干擾隔離目前的硬件缺乏相應的機制,因此,文獻[67]提出了一種基于反饋機制的內存帶寬保留技術MemGuard,將內存帶寬區分為在線作業和離線作業兩部分,使用中斷機制控制作業訪存請求的發送速率,進而間接控制內存帶寬.但是該方法的局限性在于其只能控制單個CPU 核心的帶寬,對于共享CPU 的作業則不適用.文獻[68]提出了一種動態調整作業訪存優先級的方法,實現了內存帶寬上的動態優先級控制;

(2)LLC(last level cache)緩存.緩存資源作為影響作業性能的重要資源,其上的干擾同樣不可忽略.多個作業在共享緩存時可能出現相互替換的現象,LLC 失效時原本訪存指令的執行時間將從15ns 上升至70ns,假設CPU 主頻為3Ghz,則一條訪存指令需要多消耗200 多個周期才能完成[69].消除此類干擾的方法是使用資源劃分技術,在物理上劃分多個作業對共享資源的使用.圖3(左)所示為經典的多核體系結構,多個CPU 共享了LLC,運行于不同CPU 上的作業會在LLC 上發生競爭,圖3(右)所示的Intel Cascade Lake 微架構,通過為每個核設置獨立的LLC 以減少核間對于LLC 的資源競爭;但是,同一CPU上的多個作業在混部運行時仍然會出現緩存相互替換問題,因此需要作業級別的緩存劃分技術.為了實現作業級別的緩存劃分,Intel 提出了RDT 技術[70],其中,CAT(cache allocation technology)[71]可為進程或者CGroup 分配私有的緩存空間,避免緩存相互替換;

(3)緩存帶寬.RDT 技術中的MBA(memory bandwidth allocation)提供了作業級別的L2 Cache 帶寬劃分(即L2 與L3 緩存之間的帶寬),RDT 技術僅在Intel 較新型號的處理器上可以使用.

資源隔離技術降低了多個作業在競爭的共享資源時的相互干擾,隨著操作系統和硬件架構的不斷更新和發展,出現了越來越多的軟件或軟硬件協同的資源隔離技術,如GPU 隔離技術[72].但是,由于硬件結構的復雜性,在某些關鍵資源上仍然缺乏通用且有效的資源隔離技術,如TLB 快表、L1/2 緩存、總線帶寬等,有待進一步深入研究加以解決.

2.4.2 資源動態分配算法

現有的操作系統和虛擬化技術提供了一系列資源隔離技術,可在作業運行時動態調整該作業的可用資源.例如:Linux 提供的CGroup 提供了包括CPU、內存、磁盤I/O、網絡I/O 等多種資源在內的資源彈性伸縮機制;多數商用CPU 提供了動態調節處理器頻率的功能(dynamic voltage and frequency scaling,簡稱DVFS),如Intel系列處理器[73];緩存方面,Intel 公司推出了CAT 技術,可為作業分配私有緩存并支持運行時修改作業可用的緩存容量.以現有資源隔離技術為基礎,研究人員研究了資源動態分配算法,在作業運行時動態調整各個作業對于共享資源的使用量,進而實現控制和減少作業間性能干擾,提升作業運行效率等目標.圖4 所示為資源動態分配算法的基本工作流,作業在運行過程中所產生的監控數據被輸入到資源動態分配算法,算法結合作業性能干擾模型給出資源動態調整決策(如增加資源、減少資源、遷移作業等操作),資源動態調整決策經資源隔離技術修改作業的資源分配,往復循環直至作業結束.

Fig.4 Taxonomy of dynamic resource management algorithms圖4 資源動態分配算法基本工作流

從算法目標的角度,可將資源動態分配算法分為解決干擾和預防干擾兩種.以解決干擾為目標的資源動態分配算法首先持續監控在線作業的性能指標并判斷是否發生性能干擾,如果發生,則需要動態調整在離線作業的資源以減少性能干擾,防止在線作業的性能持續受到影響.解決干擾的相關研究有:

文獻[12]中CPI2 通過數據分析發現了在線作業CPI 和在線作業RT 的相關性,因此可以使用硬件級別的指標CPI 作為性能指標,通過監控和檢測CPI 的波動判斷作業是否被干擾,檢測到干擾后使用干擾模型識別干擾者,最后使用限制干擾者CPU 或者殺死干擾者解決干擾.該方法的局限性在于:(1)整個系統的運行效率依賴于干擾模型對于干擾者的識別準確率;(2)僅限制干擾者的CPU 資源而忽略了其他共享資源會導致無法有效地找到干擾源,因此無法準確、有效地處理其他資源上的性能干擾問題.

文獻[36]提出了資源管理框架DeepDive,通過監控底層的性能指標(如CPI)預測VM 之間的性能干擾,并識別造成干擾的VM,隨后采用遷移的方法將干擾者遷移到其他節點.實驗證明了DeepDive 中的干擾預測準確率高達90%以上.但是DeepDive 針對干擾采取虛擬機遷移的技術可能會使某些資源競爭較高的容器被反復遷移,考慮到遷移容器的開銷相對較高,反復遷移可能會引起系統抖動.

Table 4 Comparisons of resource dynamic allocation algorithm表4 資源動態分配算法對比

文獻[13]提出了Heracles,其核心思想是獨立地控制多個維度的資源,在多個作業混部運行時使得每種資源的使用率不超過指定閾值.Heracles 使用CGroups 提供的CPU Set 隔離CPU 資源,使用Intel 處理器提供的CAT技術實現緩存動態劃分,內存帶寬由于沒有有效的控制技術,則通過使用調整CPU 配額的方式間接地控制內存帶寬.Heracles 通過DVFS 動態調控CPU 的運行頻率,網絡帶寬則使用Linux 系統提供的traffic control 進行作業的帶寬限制.Heracles 采取了兩層結構,頂層控制器基于SLO 監控數據控制離線作業是否可以增長,底層資源控制器根據具體的資源使用量增加或者減少作業的資源配額.實驗中,Heracles 提升了機器的資源利用率,雖然在線作業的性能降低了20%～30%,但仍然有99%的tail latency 滿足SLO 要求.Heracles 的局限性在于每個節點只能支持一個在線作業和多個離線作業的混部,無法在同一節點的不同在線作業之間分配資源.

以解決干擾為目標的資源動態分配算法雖然可以減少或者消除作業間的性能干擾,但是性能干擾事件已經發生,在線作業的性能已經受到不可挽回的損害,可能對于某些至關重要的在線作業是無法接受的.因此研究人員提出了以預防干擾為目的的資源動態分配算法,這類算法在作業運行時根據作業的性能變化趨勢進行相應的資源分配.這種方法的優勢在于可最大化地保證作業的性能,但其也有過多分配資源從而導致不必要的資源浪費的可能.相關工作包括:

文獻[10]提出QoS 感知的資源管理框架PARTIES,支持多個在線作業和多個離線作業混部,在作業運行時感知并保證所有在線作業的QoS.PARTIES 動態調整兩大類資源:(1)計算資源,包括:CPU、LLC、CPU 頻率;(2)存儲資源,內存空間、磁盤帶寬.在作業運行過程中,PARITES 持續監控作業的請求響應時間RT,然后使用預定義的狀態機決定是否應該增加或減少資源,直到滿足作業的QoS.在PARTIES 的管理下,混部節點吞吐率相比于Heracles 提升了61%,并且可以支持單節點運行更多的服務.但其局限性在于:(1)由于其無法感知到作業的性能模型和資源偏好,可能會造成資源分配的不均衡,比如過度分配內存給一個計算密集型作業;(2)需要作業級別的RT,在公有云環境中,作業通常具有黑盒性,無法獲取作業的RT.

文獻[35]提出基于反饋機制的資源管理器BubbleFlux,在作業運行時持續監控作業的IPC,根據在線作業IPC 的大小動態調控在線作業和離線作業的CPU 時間比例,以達到LC 作業QoS 和整體資源利用率最大化的目的.實驗結果表明,BubbleFlux 管理下的資源利用率比Bubble Up[14]提升了2.2 倍.但是,BubbleFlux 僅能管理CPU 資源,無法處理其他資源上的資源競爭.

文獻[74]提出了PerfIso 資源管理系統.PerfIso 管理了兩類資源以消減干擾:CPU 和磁盤I/O.在CPU 的動態分配中,PerfIso 通過保持系統中持續存在空閑的核以處理在線作業的突發流量;在磁盤I/O 的隔離上,PerfIso 采用的策略是使用Defict-weighted round-robin 算法動態調整優先級,該算法的基本思想是磁盤I/O 越多的作業優先級越低.在實驗中,作者將Bing 搜索服務和離線作業進行了混部,在PerfIso 的管理下CPU 使用率最多提升到47%左右.但是該方法的局限性在于:使用隔離CPU 和預留資源的方法會使系統中永遠存在空閑狀態的CPU,進而限制了CPU 使用率的上限.

隨著強化學習的發展,也有研究人員將強化學習應用于資源動態分配算法.文獻[76]使用強化學習算法動態調整作業的CPU 配額和CPU 的頻率.強化學習的優勢在于無需人為制定規則,算法會根據預先指定的reward函數學習出最佳的策略,結合深度神經網絡有著強大的學習能力.其局限性在于:(1)算法需要的訓練時間長;(2)神經網絡的黑盒性導致算法不易調優;(3)有限的Action 空間難以應對復雜多變的云計算環境.

3 系統實例

提升集群利用率有利于降低企業數據中心的TCO(total cost of ownership,總體擁有成本),大幅度提升數據中心的成本效率.因此,在離線混部集群管理系統成為工業界關注的重點領域.國外方面,Google 在其集群管理系統Borg 中率先嘗試了大規模在離線混部[9].國內方面,互聯網公司百度、騰訊、阿里均在混部集群管理系統上有所實踐,并開源了相應的數據集[78,79].本節就4 個混部系統實例進行對比分析.

表5 列舉并對比了Google(Borg)、阿里(Fuxi&Sigma)、百度(Matrix)、騰訊(YARD)的在離線混部作業管理系統.其中,“-”表示現有公開數據中無相關描述.可以看到:

在性能干擾模型方面,4 個系統實例均未將性能干擾模型應用于大規模實踐.本文認為造成這一現狀的原因為:上述4 個混部系統實例均進行了大規模部署,運行了海量的在線作業和離線作業,為這些作業構建精準的性能干擾模型所需計算開銷過高.雖然性能干擾模型在Borg 的公開文檔中并未提及,但其大規模作業混部環境支撐了多個性能干擾模型的研究,如文獻[14,35].

Table 5 Comparisons of co-location systems表5 混部系統實例對比

在在離線混部作業調度方面,Google 的Borg(如圖5 左所示)和騰訊的YARD 采用了統一調度的架構,即在線作業和離線作業由一個調度器統一調度,而百度Matrix 和阿里Fuxi&Sigma(如圖5 右所示)則采用了在線離線分離調度的方式,即在離線作業由各自的調度器調度(Sigma 和Fuxi 分別為阿里內部原有的在線和離線作業管理系統,Sorlaria 和Normandy 分別為百度內部原有的在線和離線作業管理系統).在離線分離調度的架構復用了原有系統的代碼,減少了工程實現的復雜度,但也存在著一定的局限性:(1)在離線作業調度器以及底層資源管理器信息不共享,需要引入額外的組件進行在離線資源的協調(如Fuxi&Sigma 中的Level-0)[25];(2)系統架構較統一調度更為復雜,每個節點至少運行了3 個Agent,帶來了額外的資源開銷.從調度算法來看,Borg 和Sigma采用了基于打分規則的調度算法,打分規則包括:根據負載高低打分、根據資源碎片量打分、根據作業優先級組合打分等.Fuxi、Matrix、YARD 則是對YARN[4]調度算法的改進,在調度時考慮了節點空余資源,并使用作業畫像、節點畫像等預測作業的資源需求和節點未來可用資源.

從資源隔離技術來看,4 個混部系統實例均采用了多種資源隔離技術.容器技術作為輕量級的虛擬化技術被廣泛使用;CPU 作為最重要的計算資源,CPU 隔離和搶占式調度成為所有混部系統的選擇;CAT 技術也被較多地采用;Fuxi&Sigma 支持更多資源的隔離,如磁盤、網絡、超線程上的資源隔離.

從資源動態分配算法來看,基于反饋機制的資源調整算法被廣泛應用于實際系統中.其基本思想是:當在線作業的性能受到影響時殺死離線作業或動態調整離線作業的資源配額[84].基于這一思想,Borg 采用了如下策略以降低作業間的性能干擾:(1)在線作業與物理核(physical CPU cores)綁定,并且同一個物理核只綁定一個在線作業,在線作業運行時可使用CPU 的全部資源;離線作業被允許運行在任意核上,運行時存在CPU 使用上限;(2)根據在線作業資源利用率變化曲線,Borg 預測并動態調整在線作業的資源配額使得并將剩余資源分配給離線作業.基于Borg 提供的在離線混部環境,Google 公司的研究人員還進行了多種資源動態分配算法的研究,如文獻[12,13,35,36];Fuxi&Sigma 則在內存共享方面提出了彈性內存策略,通過在線作業的負載動態調整在離線作業各自的內存配額.

從運行效果來看,4 個系統實例對集群利用率均有明顯提升.在Borg 的管理下,Google 集群的資源使用效率大幅度提高,在15 個集群上的測試表明,Borg 最多可將一個集群壓縮為原有集群規模的65%,即:使用原有集群65%的機器便可完成原有集群的所有計算任務;Fuxi&Sigma 混部系統將原有集群的利用率從10%提升至40%左右,節約總體成本30%以上;Matrix 則為百度節省了數萬臺服務器的成本;YARD 集群CPU 利用率提升至45%左右,并且在實踐中將深度學習的訓練作業與在線作業集群混部,為2018 年人工智能圍棋大賽冠軍PhoenixGo的訓練提供了14w+CPU 的計算能力.

Fig.5 Architecture of Google Borg[9] (left)and Fuxi&Sigma[80] (right)圖5 Google Borg 系統架構[9](左)與阿里Fuxi&Sigma 系統架構[80](右)

4 未來研究方向展望

作為學術界和工業界研究的熱點領域,在離線混部作業調度與資源管理技術的相關研究近來得到關注,并在實際應用中一定程度地提高了數據中心的資源利用率.但尚有許多亟待解決的問題,本文總結了4 個未來值得研究的方向,包括:細粒度的性能干擾模型、微服務架構下的混部作業調度算法、軟硬件協同的內存帶寬干擾隔離技術、面向在離線混部作業的調度模擬技術.

4.1 細粒度的性能干擾模型

目前在混部作業管理系統中使用的性能干擾模型將作業執行(或請求處理)看作一個整體,進而刻畫作業整體在不同干擾下性能的變化.例如,描述在下一時段內請求的平均完成時間,或者描述作業的執行時間.性能干擾模型中的資源競爭pressure也是作業混部期間的平均壓力.實際上,作業的運行過程中包括多個階段[26],如Hadoop 作業存在Map 階段和Reduce 階段,基于深度神經網絡的智能語音助手Sirius 在處理請求的過程中存在解析語音-分析語音-生成回復等多個階段[85].作業在不同階段因其計算任務不同,存在著不同資源需求和性能敏感度.現有的性能干擾模型針對應用的整體性能特征進行建模,忽略了作業不同階段的干擾敏感性變化,因此需要細粒度的性能干擾模型描述這種變化.

研究細粒度的性能模型對于混部作業調度和資源管理具有重要意義:在作業調度階段,基于細粒度干擾模型提供的豐富信息,規劃不同作業階段與階段之間的有序混部運行,有利于減少資源競爭,降低性能干擾;對于混部資源管理,細粒度的性能干擾模型可提供更豐富的作業運行時資源與性能的變化信息,基于這些信息可以設計更為精細的資源動態算法,合理利用作業運行期間的碎片資源,進一步提高資源利用率.

4.2 面向微服務架構的在離線混部作業調度

隨著微服務架構的發展,數據中心出現了越來越多的采用微服務架構的作業[86,87].微服務提升了作業的可擴展性、容錯性和可維護性,但是服務間的服務依賴(service dependency)使微服務作業的性能變化特點與傳統單體作業有明顯不同[38,88,89].在微服務架構中,單個微服務的性能下降會引起其他服務的級聯性能下降(cascading performance degradation)[90].例如,某在線作業包含兩個微服務,分別是微服務A和微服務B,微服務A是用戶直接訪問的服務,微服務A在處理用戶請求的過程中會調用微服務B.如果B的性能下降,那么A等待B的返回結果的時間變長,導致A的對于用戶請求的響應時間變長.典型的級聯性能下降,如:(1)網頁搜索服務[91],其響應時間取決于最慢的搜索節點;(2)Memcached[92]和Redis[93]等廣泛使用的數據緩存系統,其性能下降會引起上層服務的性能下降.因此,在面向微服務架構的在離線混部作業調度算法不僅需要考慮作業在混部時產生的性能干擾,還需考慮性能干擾引起的級聯性能下降,使得在離線混部作業調度問題更加復雜.

面向微服務架構的在離線混部作業調度面臨的挑戰包括:(1)構建端到端的請求執行路徑具有挑戰性.端到端的請求執行路徑描述了請求在多個微服務之間處理和轉發的過程,是請求級服務依賴關系的表示,與作業的具體執行邏輯相關,是上層調度器的重要數據基礎.在大規模微服務集群中,僅憑專家經驗或者用戶提供的先驗知識構建端到端的服務依賴關系并不可行,并且現有的分布式追蹤系統仍然存在著數據讀寫依賴問題和通用性問題[94],因此,如何從海量微服務運行過程中精準、高效、實時地構建端到端的請求執行路徑,具有挑戰性;(2)構建面向微服務架構的性能干擾模型具有挑戰性.首先,由于作業間的服務依賴關系,原本相互獨立的性能干擾模型需要根據服務依賴關系進行聯動;其次,需要對微服務之間的通信過程建立性能模型以反映作業性能的真實變化,但是通信性能受RPC 協議、網絡架構、集群負載等多方面影響,具有高度復雜性.因此,構建面向微服務架構的性能干擾模型具有挑戰性.

隨著微服務架構的廣泛使用,越來越多的應用向微服務架構遷移,研究面向微服務架構的在離線混部作業調度將日益重要.

4.3 軟硬件協同的內存帶寬資源隔離技術

目前,CPU 的運行速率遠大于存儲器的運行速率,二者性能的不匹配稱為“存儲墻(memory wall)”[95].雖然多級緩存和緩存預取技術在一定程度上緩解了CPU 和內存的性能鴻溝,但是并不能從根本上解決這一問題.在目前數據中心廣泛采用的多核架構中,存儲墻導致內存帶寬成為多核架構中競爭最激烈的資源,嚴重影響了混部作業的運行效率,但是目前的操作系統和硬件技術并不能提供相應的干擾隔離技術.

解決這一問題需要從軟件和硬件兩方面進行研究.硬件方面需要在內存控制器(memory controler)上進行改進,對每次內存訪問進行標簽化,進而使得內存控制器可根據標簽對內存訪問請求進行調度;軟件層面需要研發相應的軟件配置和動態調整不同作業內存訪問的優先級.內存作為馮諾依曼體系結構中最重要且使用最為頻繁的計算資源之一,高效隔離內存帶寬上資源競爭對上層作業的性能至關重要,該方向的研究成果對進一步提高混部作業的運行效率具有重要意義.

4.4 面向在離線混部作業的調度模擬器

在作業調度算法研究中,使用模擬器驗證由于具有快速、低成本等優點已成為重要的驗證和評價手段.在離線混部作業調度需要模擬器對作業間的性能干擾進行模擬,但是目前主流的調度模擬器,如CloudSim[96]以及以CloudSim 衍生模擬器[97,98]對于作業性能的模擬僅依據作業的資源分配,無法模擬混部作業在體系結構層次競爭資源而引起的性能干擾.計算機體系結構模擬器(如SMARTS[99]、SimGodon[100]、ZSim[101]、Gem5[102]等)雖然通過指令級模擬提供了精細再現作業的執行過程,可模擬多個作業在硬件上的資源競爭,但其缺點在于運行速度慢,模擬一個主頻為3Ghz 的CPU 一秒鐘內執行的所有指令需要數分鐘甚至更長時間,高額的開銷使其無法應用于大規模數據中心的模擬.文獻[103]提出了微服務模擬器uqSim,基于排隊論模型模擬基于微服務架構的在線作業的運行,但其局限性在于:(1)只能模擬在線作業,無法模擬離線作業;(2)無法模擬作業間的性能干擾.

因此,目前仍缺乏面向在離線混部作業的調度模擬器.全方位模擬應用之間的依賴、干擾、競爭等關系,快速分析和驗證混部作業調度算法在不同場景下的運行效果,降低調度算法的調試與測試難度,是未來重要的研究方向之一.

5 結束語

大規模數據中心是當今企業級互聯網應用和云計算系統的關鍵支撐.然而,目前數據中心的服務器資源利用率較低(僅為10%～20%),導致大量的數據中心資源的浪費.將數據中心中的在線作業和離線作業混合部署在同一節點上運行是提升數據中心資源利用率和數據中心成本效率的有效方法,具有較高的經濟價值和研究價值.但是,將在線作業和離線作業混合部署面臨著諸多問題與挑戰,包括:在離線混部作業性能干擾問題;在離線混部作業調度問題;在離線作業的共享資源隔離問題;資源動態分配問題.

本文首先分析了上述問題與挑戰,隨后圍繞在離線混部作業調度與資源管理技術研究框架,詳細分析和總結了已有研究工作,并結合多個系統實例分析了在離線混部關鍵技術在實際系統中的具體應用及運行效果.最后,本文就未來的研究方向進行了展望.