張可穎，彭麗蘋，呂曉丹，呂尚青

(1.貴州大學(xué) 大數(shù)據(jù)與信息工程學(xué)院，貴州 貴陽 550025；2.貴州大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，貴州 貴陽 550025；3.北京郵電大學(xué) 信息與通信工程學(xué)院，北京 100000)

0 引 言

云平臺通過虛擬化技術(shù)將計(jì)算機(jī)資源整合成資源池，以按需付費(fèi)的方式實(shí)現(xiàn)了用戶對計(jì)算資源的彈性需求[1]。云計(jì)算發(fā)展至今，虛擬化技術(shù)一直是云平臺中的關(guān)鍵技術(shù)[2]。Openstack是完全開源的云操作系統(tǒng)，在近幾年已經(jīng)占有私有云市場，是基于傳統(tǒng)虛擬化技術(shù)的私有云。傳統(tǒng)虛擬化技術(shù)啟動虛擬機(jī)時(shí)間過長，在彈性擴(kuò)容方面存在不足。

容器技術(shù)是一種新興的虛擬化技術(shù)[2]，它的出現(xiàn)給傳統(tǒng)虛擬機(jī)虛擬化技術(shù)帶來了挑戰(zhàn)，為構(gòu)建高效的云平臺提供了新思路[3-6]。容器與Openstack云平臺的結(jié)合受到國內(nèi)外企業(yè)的普遍關(guān)注[7]，如華為、Easystack、Redhat、Vmware等。Kubernetes是容器編排技術(shù)的代表，市場占有率越來越多，數(shù)據(jù)顯示2017年77%企業(yè)使用Kubernetes作為容器編排[8]。容器技術(shù)的高可擴(kuò)展性得到了行業(yè)內(nèi)的普遍認(rèn)可[4-7]，根據(jù)IBM測試報(bào)告顯示容器啟動時(shí)間平均是虛擬機(jī)的1/21[8]，這給Openstack高效彈性調(diào)度提供了新思路。IBM的研究人員比較了虛擬機(jī)與Docker容器的性能。他們使用一系列工具模擬CPU，內(nèi)存，存儲和網(wǎng)絡(luò)資源的工作負(fù)載進(jìn)行測試，結(jié)果表明幾乎在所有情況下，容器的性能都等于或優(yōu)于虛擬機(jī)。

Kubernetes是Google的Borg開源版本，一個(gè)通用的容器調(diào)度編排器，是典型的Master-Slave模型，使用一個(gè)Master管理多個(gè)Node(物理機(jī)或者虛擬機(jī))上的容器。通常應(yīng)用程序被分在一個(gè)或者多個(gè)容器中執(zhí)行。Kubernetes Scheduler是運(yùn)行在Master節(jié)點(diǎn)上的調(diào)度器，通過監(jiān)聽Apiserver將Pod調(diào)度到合適的Node上。調(diào)度過程簡述如下：

第一步：Predicate，過濾掉不滿足資源條件的節(jié)點(diǎn)。

第二步：Priority，計(jì)算各個(gè)節(jié)點(diǎn)的CPU和內(nèi)存使用率權(quán)重(目前Kubernetes最多支持CPU、內(nèi)存和GPU)。使用率越低，權(quán)重越高。計(jì)算鏡像權(quán)重，鏡像越大，權(quán)重越高，傾向于調(diào)度到已經(jīng)有需要用到的鏡像的節(jié)點(diǎn)。由此來對各個(gè)節(jié)點(diǎn)打分，以確定它們的優(yōu)先級順序，選擇打分最高的節(jié)點(diǎn)作為Pod運(yùn)行的Node。

由此可見，Kubernetes調(diào)度算法存在很大的局限性。第一，Kubernetes提供了一個(gè)只考慮CPU和內(nèi)存的動態(tài)資源配置機(jī)制[9]。這是不現(xiàn)實(shí)的，因?yàn)橛绊憫?yīng)用程序性能的因素有很多，如網(wǎng)絡(luò)、I/O和存儲。第二，Kubernetes的權(quán)重打分機(jī)制傾向于將Workload平均分布在各個(gè)節(jié)點(diǎn)，一方面在資源高效利用方面存在不足，除了應(yīng)用高峰期，其他時(shí)間整個(gè)集群都處于低負(fù)載狀態(tài)，同時(shí)也增加了數(shù)據(jù)中心的能耗；另一方面，資源均分一定程度造成資源碎片化，降低了集群資源利用率，也可能造成新進(jìn)大資源無法部署，永遠(yuǎn)處于Pending狀態(tài)[10]。另外，Kubernetes社區(qū)尚不成熟，本身在存儲、網(wǎng)絡(luò)和多租戶管理方面不完善[6]，因而與Openstack結(jié)合是對其良好的補(bǔ)充。

針對上述問題，首先將Openstack虛擬機(jī)容器化，作為Kubernetes集群中的Docker容器，以獲得容器的彈性擴(kuò)展，高效在線遷移的特性。用Kubernetes自帶的掛在卷Volume集群作為后端跨主機(jī)的塊存儲，一定程度保證冷數(shù)據(jù)的安全性。然后建立一個(gè)基于Openstack的Kubernetes集群資源調(diào)度優(yōu)化模型，在綜合考慮資源負(fù)載和應(yīng)用服務(wù)性能的前提下，對集群資源進(jìn)行了細(xì)粒度劃分，實(shí)現(xiàn)了Openstack集群的容器化的虛擬機(jī)的調(diào)度和應(yīng)用容器的在線遷移。

1 相關(guān)工作

對Openstack和Kubernetes結(jié)合進(jìn)行數(shù)據(jù)中心彈性調(diào)度的研究目前較少。但在相關(guān)領(lǐng)域，學(xué)者和企業(yè)進(jìn)行了大量研究。

Chia Chen等[9]提出了一種基于資源利用率和應(yīng)用QoS度量指標(biāo)的Kubernetes資源調(diào)配算法，在原本Kubernetes考慮CPU的基礎(chǔ)上，又加入了系統(tǒng)其他的資源利用率(如內(nèi)存和磁盤訪問)和QoS指標(biāo)(如響應(yīng)時(shí)間)，在一定程度上完善了Kubernetes的調(diào)度機(jī)制。唐瑞[11]改進(jìn)了一種搶占式的Pod調(diào)度策略，通過將Pod劃分為三個(gè)優(yōu)先級，在資源不足時(shí)有效提高了高優(yōu)先級Pod的運(yùn)行比例。楊鵬飛[12]提出一種基于訓(xùn)練融合ARIMA模型和神經(jīng)網(wǎng)絡(luò)模型的動態(tài)資源調(diào)度算法，有效提高了Kubernetes調(diào)度資源利用率和應(yīng)用服務(wù)質(zhì)量。彭麗萍等[13]在Ceph集群研究中指出集群除了在應(yīng)用高峰期外，集群中大多數(shù)點(diǎn)都處于低負(fù)載狀態(tài)，這就造成資源浪費(fèi)并增加了系統(tǒng)能耗，并基于Docker和Ceph加權(quán)平均的調(diào)度策略，在保證數(shù)據(jù)安全性的前提下，提出一種盡量使少量節(jié)點(diǎn)處于高負(fù)載，休眠低負(fù)載節(jié)點(diǎn)的數(shù)據(jù)中心節(jié)能的彈性調(diào)度算法[10]。

在企業(yè)界，相關(guān)的云平臺調(diào)度策略有Borg、Yarn、Meros等等。Borg把應(yīng)用程序分成兩類—批處理作業(yè)和長服務(wù)。批處理作業(yè)是類似于MapReduce和Spark的作業(yè)，在一定時(shí)間內(nèi)會運(yùn)行結(jié)束，長服務(wù)則類似于Web Service、HDFS Service等，可能會永久運(yùn)行下去，永不停止[14]。Borg對長服務(wù)的支持細(xì)節(jié)未知，因?yàn)槭情]源的，但是Meros和Yarn對長服務(wù)存在以下問題：由于Yarn和Meros和Kubernetes具有相似的打分機(jī)制，傾向于將Workload平均分配在集群，會造成長服務(wù)永遠(yuǎn)占著資源，預(yù)留資源可能永遠(yuǎn)不足于分配給新服務(wù)的情況。

長服務(wù)運(yùn)行一段時(shí)間以后，可能需要的資源會有動態(tài)變化。資源伸縮有兩個(gè)維度：一個(gè)是橫向的，即增加實(shí)例數(shù)目；另一方面是縱向的，即原地增加正在運(yùn)行實(shí)例的資源量[15]。

以上的彈性調(diào)度策略完善了云平臺資源監(jiān)控的度量，優(yōu)化了數(shù)據(jù)中心資源調(diào)度算法，在一定程度上提高了數(shù)據(jù)中心資源利用率。但并沒有細(xì)分考慮服務(wù)類型，僅僅考慮初始資源分配，沒有考慮服務(wù)運(yùn)行的時(shí)間對集群資源調(diào)度的影響，以及應(yīng)用長時(shí)間運(yùn)行而導(dǎo)致資源碎片化問題。因此，針對長服務(wù)，實(shí)現(xiàn)了Openstack使用Kubernetes彈性調(diào)度容器化的虛擬機(jī)云平臺調(diào)度的彈性策略。

2 私有云調(diào)度模型的建立與求解

模型假設(shè)：假設(shè)已知各類應(yīng)用CPU、內(nèi)存、網(wǎng)絡(luò)和I/O的最低需求；假設(shè)容器遷移時(shí)存儲可靠且啟動時(shí)間和初次容器拉起時(shí)間一樣，運(yùn)行一段時(shí)間后不造成額外重啟開銷。

2.1 Kubernetes集群系統(tǒng)建模

假設(shè)集群內(nèi)共有K臺服務(wù)器serveri(0

基于以上，建立一個(gè)資源調(diào)度優(yōu)化模型：

(1)

Palloc=Pnode-(Psys+Pkube+Ptake)

(3)

WCPU=Wcpu+λtwait

(4)

WM=Wm+λtwait

(5)

WN=Wn+λtwait

(6)

WI/O=Wi/o+λtwait

(7)

WALL=WCPU+WM+WN+WI/O

(8)

Wi表示服務(wù)器的平均使用率，由于應(yīng)用往往對資源要求不是均勻的，一個(gè)服務(wù)器節(jié)點(diǎn)往往在內(nèi)存占用密集時(shí)，CPU、網(wǎng)絡(luò)或I/O處于空閑狀態(tài)。針對這種情況，對應(yīng)用類型進(jìn)行分類排序使服務(wù)器負(fù)載盡可能均勻，將應(yīng)用占用最多的資源進(jìn)行分類，在各個(gè)分類內(nèi)從大到小排列分類資源，形成四個(gè)應(yīng)用鏈表。δ描述負(fù)載是否均勻。

Palloc表示系統(tǒng)可分配，Pnode表示服務(wù)器節(jié)點(diǎn)總的可用資源，Psys表示操作系統(tǒng)保留資源，Pkube表示Kubernetes系統(tǒng)保留資源，Ptake表示Kubernetes已分配資源。當(dāng)Ptake=0表示該服務(wù)器上沒有任何應(yīng)用在運(yùn)行。

模型中λ是可調(diào)等待時(shí)間權(quán)重，twait是任務(wù)的等待時(shí)間，WALL用于排序等待的待分配任務(wù)隊(duì)列。WCPU、WM、WN、WI/O綜合考慮了應(yīng)用負(fù)載和等待時(shí)間，用于優(yōu)先級調(diào)度通過分類排序每一項(xiàng)資源等待的待分配任務(wù)隊(duì)列。Si是改進(jìn)的打分算法，盡可能將應(yīng)用部署在得分小，即在保證有預(yù)留資源的情況下，提高服務(wù)器資源負(fù)載，最終達(dá)到提高集群資源利用率的目的。

2.2 調(diào)度策略

2.2.1 初始調(diào)度算法

根據(jù)以上系統(tǒng)模型，以Δt為時(shí)間周期，采集serveri上各個(gè)已經(jīng)部署應(yīng)用及其總占用的真實(shí)CPU、內(nèi)存、網(wǎng)絡(luò)和I/O的數(shù)據(jù)。通過對采集的數(shù)據(jù)進(jìn)行加工整理，可知服務(wù)器適合部署哪種應(yīng)用。再根據(jù)應(yīng)用對CPU、內(nèi)存、網(wǎng)絡(luò)和I/O的最低資源需求可初步判斷應(yīng)用是什么類型。如果服務(wù)器任一資源占用率大于80%，表示該服務(wù)器節(jié)點(diǎn)處于高負(fù)載，則用Kubernetes命令cordon將此節(jié)點(diǎn)設(shè)置為不可調(diào)度，一方面是為了保證服務(wù)器性能，一方面是預(yù)留部分資源給已經(jīng)運(yùn)行在該節(jié)點(diǎn)的應(yīng)用。也將Ptake=0的服務(wù)器用cordon命令設(shè)置為不可調(diào)度(未分配容器應(yīng)用的服務(wù)器)，隨后將該臺服務(wù)器休眠，以提高集群資源利用率，同時(shí)節(jié)省數(shù)據(jù)中心資源。當(dāng)集群中無法滿足新應(yīng)用最低資源要求，再重新喚醒添加休眠中的一臺服務(wù)器進(jìn)入集群，隨后使用uncordon命令恢復(fù)節(jié)點(diǎn)為可調(diào)度節(jié)點(diǎn)。具體調(diào)度流程如圖1所示。

2.2.2 服務(wù)器上應(yīng)用遷移算法

對于服務(wù)器實(shí)際任意資源占用率大于90%在ΔT時(shí)間內(nèi)(ΔT由云平臺管理員設(shè)置)，或δ>k(k是衡量服務(wù)器各項(xiàng)資源是否負(fù)載均勻的可調(diào)參數(shù))，表示該節(jié)點(diǎn)單種資源負(fù)載過高，或者四種資源嚴(yán)重不均勻，需要遷移應(yīng)用。前者為了保證服務(wù)器性能和預(yù)留安全資源，后者是為提高集群資源利用率。詳細(xì)的應(yīng)用遷移過程如下：

(9)

a+b+c+d=1

(10)

圖1 容器部署流程

選擇serverm需要遷移容器的具體算法如下：

step1:按e=(Δe1,Δe2,Δe3,Δe4)的δ'將容器從大到小排成隊(duì)列，依次選取隊(duì)列容器進(jìn)行下一步計(jì)算；

step2:計(jì)算當(dāng)前容器以及隊(duì)列前面容器累計(jì)遷移應(yīng)用后serverm的各項(xiàng)資源利用率并判斷Wcpu、Wm、Wn、Wi/o是否均小于90%，或者滿足δ≤k。若成立，進(jìn)行下一步；不成立選擇隊(duì)列中下一個(gè)應(yīng)用，重新計(jì)算step2；

3 實(shí)驗(yàn)及對比分析

3.1 實(shí)驗(yàn)環(huán)境

為了驗(yàn)證調(diào)度策略的可行性和有效性，搭建了一個(gè)基于Openstack的Kubernetes集群。在實(shí)驗(yàn)中使用9臺戴爾R710服務(wù)器(其中Kubernetes集群7臺，一臺作為Master，七臺作為Slave)。K8s使用1.9.2版本，Docker使用1.17.03版本，操作系統(tǒng)為Centos7.4。

為了模擬云平臺負(fù)載，用以下工具模擬云平臺各項(xiàng)資源負(fù)載。

(1)CPU和內(nèi)存:對于CPU負(fù)載使用Linux下標(biāo)準(zhǔn)負(fù)載測試工具包Stress-ng模擬CPU和內(nèi)存負(fù)載。

(2)網(wǎng)絡(luò)：在容器里使用tomcat搭建簡單網(wǎng)站，使用專業(yè)網(wǎng)站測壓工具Apache Bench模擬網(wǎng)站用戶并發(fā)訪問負(fù)載。

(3)I/O：用專業(yè)磁盤測試工具fio模擬和監(jiān)測磁盤負(fù)載。

3.2 實(shí)驗(yàn)過程及對照分析

3.2.1 實(shí)驗(yàn)一：容器和虛擬機(jī)的開機(jī)時(shí)間對比

對Openstack啟動虛擬機(jī)和Kubernetes啟動centos7.4容器所需的時(shí)間分別進(jìn)行測試，結(jié)果如表1所示。

表1 Openstack容器和虛擬機(jī)開機(jī)時(shí)間對比 s

續(xù)表1

實(shí)驗(yàn)證明了在此云平臺上，容器從創(chuàng)建命令開始到成功創(chuàng)建啟動時(shí)間是虛擬機(jī)創(chuàng)建到啟動時(shí)間的約四分之一。

3.2.2 實(shí)驗(yàn)二：首次部署調(diào)度和遷移對照實(shí)驗(yàn)

實(shí)驗(yàn)組1：容器初次調(diào)度算法對照實(shí)驗(yàn)。

假設(shè)在Δt時(shí)間內(nèi)有以下應(yīng)用，分別按照Kubernetes默認(rèn)算法和改進(jìn)后的調(diào)度算法調(diào)度以下應(yīng)用。用Centos命令sar獲取CPU服務(wù)器系統(tǒng)占用率；vmstat獲得內(nèi)存占用數(shù)據(jù)；用iftop獲取網(wǎng)絡(luò)帶寬數(shù)據(jù)；用iostat獲得磁盤iops數(shù)據(jù)，采集時(shí)間間隔為10 s，共采集10次，將命令執(zhí)行結(jié)果寫成腳本重定向到指定文件，然后整理數(shù)據(jù)，計(jì)算出各項(xiàng)負(fù)載平均值作為serveri的Wcpu、Wm、Wn、Wi/o。應(yīng)用情況和部署每一個(gè)應(yīng)用集群內(nèi)每一臺服務(wù)器狀態(tài)轉(zhuǎn)移情況如圖2所示。

圖2 部署應(yīng)用過程優(yōu)化前后集群資源占用率對比

最開始，優(yōu)化后的算法集群內(nèi)只有一個(gè)激活節(jié)點(diǎn)，當(dāng)部署第三個(gè)應(yīng)用時(shí)再激活第二個(gè)節(jié)點(diǎn)；而Kubernetes自帶算法最開始集群內(nèi)所有節(jié)點(diǎn)都被激活，導(dǎo)致整體集群負(fù)載率很低，造成服務(wù)器資源的大量浪費(fèi)。

實(shí)驗(yàn)組2：容器遷移算法。

由于隊(duì)列中應(yīng)用任務(wù)大多數(shù)時(shí)都是隨機(jī)的，且應(yīng)用真實(shí)負(fù)載是未知的，serveri節(jié)點(diǎn)在經(jīng)過一段時(shí)間的運(yùn)行，資源有可能存在不足即某一個(gè)或多個(gè)資源占用率超過節(jié)點(diǎn)資源的90%，即Palloc<10%Pnode,或者節(jié)點(diǎn)資源嚴(yán)重分配不均勻，δ>k，此次實(shí)驗(yàn)設(shè)置k為16。

在時(shí)間內(nèi)隨機(jī)順序?qū)ubernetes部署應(yīng)用，由于應(yīng)用的不可預(yù)知性，所以此時(shí)節(jié)點(diǎn)真實(shí)負(fù)載不均勻，需要進(jìn)行二次調(diào)度即遷移調(diào)整。

應(yīng)用運(yùn)行一段時(shí)間后每個(gè)節(jié)點(diǎn)詳細(xì)資源使用率如圖3所示，節(jié)點(diǎn)的平均資源使用率和方差如表2所示。

圖3 應(yīng)用運(yùn)行一段時(shí)間后每個(gè)節(jié)點(diǎn)詳細(xì)資源使用率

調(diào)度節(jié)點(diǎn)Wi/%δnode241.4519.08node344.8815.11node441.4519.08node559.610.83node729.7326.54node855.858.3

表3 node7上應(yīng)用按負(fù)載最高資源從小到大排列

由表3確定遷移應(yīng)用1，遷移后node7的δ=8.87滿足δ≤15，將應(yīng)用一加入到2.1中調(diào)度模型重新調(diào)度。

同理，篩選出node2、node4和node3上需要遷移的應(yīng)用，加入到2.1中調(diào)度模型鏈表中，重新分配，最后運(yùn)行狀態(tài)如圖4所示。

在實(shí)現(xiàn)遷移算法后，運(yùn)行同樣數(shù)目的容器應(yīng)用，能減少運(yùn)行應(yīng)用的服務(wù)器節(jié)點(diǎn)，從而提高集群資源利用率，節(jié)約數(shù)據(jù)中心能耗。

優(yōu)化后的調(diào)度策略更細(xì)粒度地劃分了數(shù)據(jù)中心資源和增加了調(diào)整云平臺的參數(shù)，在提高集群資源利用率的條件下綜合考慮了各種資源的負(fù)載均勻以及遷移時(shí)間代價(jià)，有效優(yōu)化了基于Openstack的Kubernetes私有云調(diào)度模型。

圖4 集群中運(yùn)行應(yīng)用的節(jié)點(diǎn)數(shù)對比

4 結(jié)束語

改進(jìn)了Kubernetes原有的調(diào)度策略，結(jié)合Openstack云平臺，提出一種基于Openstack的Kubernetes私有云彈性調(diào)度策略，細(xì)粒度劃分了調(diào)度資源。通過對每種資源需求從多到少的排序輪轉(zhuǎn)調(diào)度和運(yùn)行一段時(shí)間后監(jiān)測負(fù)載過高以及資源嚴(yán)重分配不均的服務(wù)器節(jié)點(diǎn)應(yīng)用二次調(diào)整遷移算法，實(shí)現(xiàn)了對私有云的彈性調(diào)度，有效提高了云平臺資源利用率，達(dá)到合理使用數(shù)據(jù)中心硬件資源和降低數(shù)據(jù)中心運(yùn)營成本的效果。下一步將研究復(fù)雜的調(diào)度、混合云調(diào)度，通過更加細(xì)粒度地劃分服務(wù)類型如有無持久存儲需求，服務(wù)時(shí)長以及在可知和不可知應(yīng)用最大資源上限的調(diào)度等，結(jié)合現(xiàn)有開源云架構(gòu)如Hadoop、Kubernetes、Openstack和更高級算法解決實(shí)際問題。