尹 飛，龍玲莉，孔 崢，邵 涵，李 鑫，錢柱中

（1.江蘇方天電力技術(shù)有限公司，南京 211102；2.南京大學(xué)計算機科學(xué)與技術(shù)系，南京 210023；3.南京航空航天大學(xué)計算機科學(xué)與技術(shù)學(xué)院，南京 211106）

（?通信作者電子郵箱lics@nuaa.edu.cn）

0 引言

數(shù)據(jù)中心與集群以云計算的形式，根據(jù)用戶動態(tài)的資源需求變化，“按需式”地為其提供可配置的資源獲取服務(wù)，以實現(xiàn)索取資源的彈性伸縮，涵蓋了傳統(tǒng)的基礎(chǔ)設(shè)施即服務(wù)（Infrastructure as a Service，IaaS）［1］、平臺即服務(wù)（Platform as a Service，PaaS）［2］與新興的無服務(wù)計算［3］等。這些服務(wù)模型的支撐在于基于容器化［4］的資源管理技術(shù)，以容器為上層應(yīng)用提供相互隔離的計算資源。

為了應(yīng)對大規(guī)模用戶的訪問請求，同種應(yīng)用功能的多個運行實例往往被各自獨立地部署于預(yù)先創(chuàng)建的容器之中［5］。繼而，為了提升宿主機（承載容器的物理機）資源利用率，同時降低多個容器實例間的通信開銷，容器會被整合到少量宿主機之上［6-7］。這樣“緊致”的部署，能夠在滿足應(yīng)用服務(wù)的同時，極大提升集群的資源利用率。

不僅如此，在運行過程中，應(yīng)用的負載往往是動態(tài)變化的，文獻［8-10］表明集群內(nèi)各類應(yīng)用的請求訪問量在時間上的分布不均，如:淘寶在“雙十一”期間的訪問量會劇增；假期時社交網(wǎng)站的照片分享量會極大超出平時的均值水平；新聞事件也會使得應(yīng)用的瀏覽量產(chǎn)生大幅度的波動。為此，集群更需要根據(jù)應(yīng)用的負載變化，動態(tài)調(diào)整容器的資源配置，以滿足應(yīng)用業(yè)務(wù)的服務(wù)質(zhì)量。

然而，為了整合宿主機資源［11-15］，現(xiàn)有的工作主要從按需式、被動式［16-18］的容器遷移入手。一方面，已有工作探討了在宿主機上進行共享資源使用過程中，容器之間產(chǎn)生的資源干擾［9，19］；另一方面，一些研究在結(jié)合了共享資源使用特點［8，20］的基礎(chǔ)上，進行容器整合的策略制定，提升宿主機的資源利用率。雖然也有工作通過預(yù)測及刻畫應(yīng)用各異的資源需求［21-22］，幫助容器進行更好的整合，但這些工作均帶有較強的輸入分布假設(shè)。

即使現(xiàn)有的容器化技術(shù)已經(jīng)能較好地支持“應(yīng)對式”的資源彈性伸縮和配置，但是對于動態(tài)負載來說，在線化的配置需求增加了作出合理容器部署的難度。一個簡單的例子是，短期內(nèi)“近乎完美”的容器整合可能造成未來更多容器熱遷移。也就是，當(dāng)容器負載過高而宿主機沒有空閑資源進行拓展時，容器不得不采取熱遷移的方式，將實例轉(zhuǎn)移至其他空閑服務(wù)器。隨之而來，熱遷移不僅消耗大量計算與網(wǎng)絡(luò)資源［23］，也會增加應(yīng)用響應(yīng)時間，對服務(wù)質(zhì)量產(chǎn)生較大的影響。

結(jié)合針對集群負載的長期觀察，容器的資源需求往往是此消彼長。如果能將這些此消彼長的容器整合在一臺宿主機上，那么容器將會以較小的概率同時具有資源擴展需求。因此，只需為每一臺宿主機預(yù)留少量資源，即可避免后續(xù)大部分的容器熱遷移。然而，如何將合適的容器整合宿主機上，并確定合適的資源預(yù)留量是關(guān)鍵，其直接影響了宿主機的資源利用率與容器的服務(wù)質(zhì)量。

雖然容器的資源需求量在不斷變化，但是在彈性資源伸縮的時候，其申請增加或是釋放的資源量往往具有最小的變化單位，如一個CPU 核、1 GB 內(nèi)存等。相較于傳統(tǒng)“非忙即閑”的資源模型，有限的資源使用狀態(tài)及其間的變化關(guān)系更能作為細粒度描述容器資源動態(tài)變化的依據(jù)。例如，聊天應(yīng)用包含有文字、語音等多種媒介，以至于信息傳輸負載的呈現(xiàn)也僅在這幾個狀態(tài)間切換。

為此，本文首先以細粒度的方式刻畫容器的動態(tài)資源變化，即用馬爾可夫鏈中的狀態(tài)和狀態(tài)間的轉(zhuǎn)移，對應(yīng)建模容器可能的資源需求量和不同資源需求量之間的切換。圖1 展示了一個具有3 種資源需求狀態(tài)的容器示例。然后，本文在基于資源預(yù)留的基礎(chǔ)上提出面向動態(tài)負載的容器部署問題，以在限定動態(tài)遷移概率的約束下，最小化宿主機的使用數(shù)量。本文提出了面向動態(tài)負載的容器部署策略，并通過估計容器資源需求，提高部署效率。大規(guī)?；趪a(chǎn)軟硬件的實驗結(jié)果表明，所提出的部署策略能在提高宿主機資源利用率和減少容器動態(tài)遷移次數(shù)間取得平衡，在長效時間上以至多26 臺宿主機的增加換取至多7次容器遷移。

圖1 容器隨時間變化的資源需求Fig.1 Resource demand of dockers varying with time

本文的主要工作有:1）用馬爾可夫鏈建模容器的多狀態(tài)資源需求變化；2）提出面向多狀態(tài)負載的容器部署策略，利用資源需求量的估計值提高部署效率；3）進行大量實驗，通過與其他部署策略比較，評估本文所提出的部署策略的性能。

1 相關(guān)工作

1.1 虛擬機/容器負載刻畫

動態(tài)負載的變化是虛擬機/容器部署過程不可忽視的特征。由于容器是輕量級的虛擬機，因此，本文只考慮針對容器的相關(guān)部署與應(yīng)用。文獻［8］統(tǒng)計了Google 集群中不同資源的利用率以及各自對應(yīng)的總時間占比，表明了資源需求變化的動態(tài)性和可描述性；文獻［19］研究了負載激增的模式，提出有關(guān)激增負載測試的方法；文獻［9］調(diào)研了資源需求量波動對服務(wù)質(zhì)量的影響；文獻［20］優(yōu)化了數(shù)據(jù)中心與集群針對容器負載變化而產(chǎn)生的重配置資源的開銷。上述工作對資源配置的某方面開展了研究，但未考慮合理調(diào)整資源利用的方式。

近期工作主要致力于把變化的負載建模成為隨機變量，即非確定量。文獻［21］提供了在資源需求量服從特定隨機分布下的近似算法；文獻［22］主要研究了資源需求服從正態(tài)分布的情況；文獻［14-15］提出針對資源需求量服從高斯分布的近似算法。這些相關(guān)方法可以提供一定的資源需求描述能力，但難以支撐容器部署的穩(wěn)定性要求，易引發(fā)容器遷移。

然而針對服從特定概率分布的資源需求量而設(shè)計的算法不具有普遍性。雖然文獻［24］把激增的資源需求量建模為二狀態(tài)馬爾可夫鏈，但該算法對資源需求量的狀態(tài)數(shù)等有較大限制。

1.2 虛擬機/容器整合與遷移

作為提高資源利用率的重要方式，虛擬機/容器整合［11，25］已被學(xué)術(shù)界和工業(yè)界廣泛地研究與認可。工業(yè)界代表性的產(chǎn)品有VMware 分布式資源調(diào)度［12］和IBM（International Business Machine）服務(wù)工具［13］。大多數(shù)研究把這個問題視作:在服務(wù)器容量、服務(wù)等級協(xié)議等限制條件下最小化所使用的物理服務(wù)器數(shù)量。這些工作均將容器資源需求量表示為定值，使用一系列類似裝箱的啟發(fā)式策略，如降序首次適應(yīng)（First Fit Decreasing，F(xiàn)FD）［6］、隨機裝箱等［14-15］，卻無法應(yīng)對集群環(huán)境中動態(tài)的容器資源變化需求。

當(dāng)宿主機資源無法滿足容器資源擴張需求時，容器熱遷移隨即進行。文獻［16］以同時最小化遷移傳輸能耗及容器服務(wù)時延作為目標；文獻［17］旨在設(shè)計具有時延保障的熱遷移策略；另有文獻［18］考慮集群間利用傳輸控制協(xié)議（Transmission Control Protocol，TCP）的路徑多樣性進行熱遷移。但這類工作往往是被動地進行容器的調(diào)整，沒有在長效時間維度上進行容器整合與遷移的優(yōu)化。

針對上述工作的局限，本文使用多狀態(tài)馬爾可夫鏈為容器的資源需求量變化進行建模，以設(shè)計有效的面向動態(tài)負載的容器部署策略。

2 系統(tǒng)模型

2.1 場景定義

集群有大量的物理機，通過在物理機（宿主機）上部署容器來向用戶提供服務(wù)。如圖2 所示，容器與宿主機的關(guān)系由部署策略決定。

圖2 容器部署示意圖Fig.2 Schematic diagram of docker deployment

一方面，盡管用戶通常會聲明容器的最大資源需求量，但由于物理機的購置成本、維護成本和運行成本都較高，總是為每個容器預(yù)留足夠的計算資源在經(jīng)濟上是不合理的。運營者總是希望盡可能減少宿主機的占用量。另一方面，若沒有為容器預(yù)留一定的計算資源，當(dāng)其資源需求量發(fā)生變化時，集群必須通過動態(tài)遷移來保證容器的性能不受影響，由此會帶來較大的遷移代價?；谶@兩點考慮，本文旨在為集群設(shè)計一種容器部署策略，使得宿主機資源利用率較高、數(shù)量較少，同時把容器動態(tài)遷移次數(shù)控制在較小的范圍內(nèi)。

2.2 單容器資源需求模型

容器資源需求量是動態(tài)變化的，能被量化為多個狀態(tài)（如圖1 所示）。本文將該特性稱為容器的多狀態(tài)特性，并用多狀態(tài)的馬爾可夫鏈進行建模，如圖3所示。假設(shè)集群共創(chuàng)建了n臺容器，并考慮第k臺容器。用Nk表示第k臺容器的狀態(tài)總數(shù)，并令R(k)=(R1(k)，R2(k)，…，，其中Ri(k)表示第k臺容器中狀態(tài)i的資源需求大小。本文用Pij(k)表示第k臺容器中狀態(tài)i到狀態(tài)j的轉(zhuǎn)移概率，那么這些參數(shù)所構(gòu)成的是這臺容器的狀態(tài)轉(zhuǎn)移概率矩陣。本文用Sij(k)表示第k臺容器在兩個連續(xù)時間段從狀態(tài)i轉(zhuǎn)換到狀態(tài)j的次數(shù)，那么有Pij(k)=以圖1 所示為例，分別用R1(k)、R2(k)、R3(k)表示由少到多的三種資源需求量，則S11(k)=2，S12(k)=2，S13(k)=1，且能計 算轉(zhuǎn)移 概率為P11(k)=0.4，P12(k)=0.4，P13(k)=0.2。

圖3 基于馬爾可夫鏈的容器資源狀態(tài)模型Fig.3 Markov chain based resource state model for docker

一般來說，上述描述的馬爾可夫鏈通常是非周期不可約的，因為實際應(yīng)用中任兩個狀態(tài)都有可能相互切換。而任何狀態(tài)都可能在下一刻保持不變，故存在有平穩(wěn)狀態(tài)的分布，即μ(k)=(μ1(k)，μ2(k)，…有:

因此，容器k的描述可由其資源需求量R(k)和平穩(wěn)分布μ(k) 組成，構(gòu)成的是2×n維矩陣，定義為V(k)=[R(k)，μ(k)]T，1 ≤k≤n。

2.3 多容器的復(fù)合資源需求模型

對于n臺容器來說，每個V(k)有Nk種狀態(tài)，每臺容器的狀態(tài)變化相互獨立。因此，這n臺容器一共有N=種狀態(tài)。用S(k)表示容器V(k)當(dāng)前的所有狀態(tài)，則這n臺容器在當(dāng)前的復(fù)合狀態(tài)可以用S=(S(1)，S(2)，…，S(n))來表示。那么，從狀態(tài)S轉(zhuǎn)移到S'=(S(1)'，S(2)'，…，S(n)')的概率為:

這里需要說明，本文將總共N種狀態(tài)用1～N進行標號。更進一步，對于當(dāng)前所處的狀態(tài)(S(1)，S(2)，…，S(n))，本文用i1表示S(1)，i2表示S(2)，以此類推。從而有狀態(tài)轉(zhuǎn)移矩陣P=[Pij]N×N。這個馬爾可夫鏈通常也是無周期不可約，故存在唯一的可達的平穩(wěn)分布:

根據(jù)2.2 節(jié)所述，容器V(k)的平穩(wěn)分布定義為μ(k)=(μ1(k)，μ2(k)，…，μNk(k))。則π和μ(k)的關(guān)系如定理所述。

定理1令有π=π'，即n臺容器平穩(wěn)處于某一狀態(tài)的概率等于所有容器各自平穩(wěn)時處于對應(yīng)狀態(tài)概率的乘積。

證明 因為πP=π解得的π是唯一的，所以只需要證明π'P=π'，即證也即:

定理1 說明，在實際計算中，只需要預(yù)先算出每臺容器的平穩(wěn)狀態(tài)分布，再進行簡單乘法運算就能得到n臺容器的平穩(wěn)狀態(tài)分布。

2.4 動態(tài)負載容器的部署與資源預(yù)留問題

集群有m臺宿主機，第l臺宿主機Hl的可用資源可以用其容量Cl來描述，即Hl=Cl，1 ≤l≤m。容器的部署過程實際上是從容器到宿主機的一個映射過程，用矩陣X=來表示，當(dāng)V(k)放置在Hl上時有Xkl=1，否則Xkl=0。

令W(k，t)表示容器V(k)在t時刻的資源需求量。理想情況下，所有宿主機在t時刻都能提供充足的計算資源。該約束條件可以表示為:

特別地，在初始時刻，即t=0 時，該約束滿足。如果在t時刻該約束被破壞，則定義為發(fā)生了一次沖突。用vio(l，t)表示Hl是否在t時刻沖突，即:

沖突率為長時間運行過程中發(fā)生沖突的時間占總時間的比率，宿主機Hl的沖突率為:

CVR越小意味著容器動態(tài)遷移的幾率越小。本文的策略目標是保證所有宿主機的沖突率保持在一個較低的值ρ以下，即使得:

上述約束為宿主機的性能約束。下面給出面向動態(tài)負載的容器部署問題的定義。

定義1面向動態(tài)負載的容器部署問題是指，給出所有容器和宿主機參數(shù)V和H，找到一個從容器到宿主機的映射，使得在初始時刻滿足容量約束以及在任意時刻滿足性能約束的同時，總共使用的宿主機數(shù)量最少，也即:

滿足容量約束（式（4）），當(dāng)t=0 時；滿足性能約束（式（7）），對所有t。

定理2面向動態(tài)負載的容器部署是NP（Non Polinomial）完全的。

證明 通過將NP 完全的裝箱問題判定版本歸約到所提出的面向動態(tài)負載的容器部署問題的判定版本來完成定理證明。裝箱問題判定版本為:給定n個物品，第k個物品的大小是gk∈(0，1]，能否用m個單位容積箱子裝下物品？

對任意一個給定的裝箱問題判定版本實例，構(gòu)造一個面向動態(tài)負載的容器部署問題（判定版）實例:令Nk為任意正整數(shù)，?k∈{1，2，…，n}；令Ri(k)=gk，?k，?i∈{1，2，…，Nk}；再令Cl=1，?l∈{1，2，…，m}；令ρ=0。這樣可在多項式時間內(nèi)完成歸約，因此所提問題是NP完全的。 證畢。

3 面向動態(tài)負載的容器部署與資源預(yù)留

3.1 容器的資源預(yù)留策略

在單臺宿主機上部署n臺容器，這n臺容器一共有N個狀態(tài)，用Ri表示標號為i的狀態(tài)的資源需求。不失一般性，不妨設(shè)R1≤R2≤…≤RN，則可以導(dǎo)出這n臺容器最小所需容量Rq，其中q為滿足如下關(guān)系的整數(shù):

此時的性能約束滿足:

根據(jù)式（8），判斷n臺容器能否同時放置在某臺宿主機l上的算法De(V，Hl)，具體描述見算法1 所示，其輸出為能否放置的結(jié)果。

算法1 宿主機能否容納容器（Determination）。

輸入 特定宿主機l，容器的馬爾可夫模型V={V(1)，V(2)，…，V(n)}；

輸出n臺容器能否放于特定宿主機l。

如果PI＞ρ，輸出0（否）；否則輸出1（是）。

3.2 面向動態(tài)負載的容器部署策略

現(xiàn)在考慮多臺宿主機的情況。將n臺容器部署到m臺宿主機上，基于FFD 啟發(fā)式算法設(shè)計部署策略，將n臺容器按資源需求量的期望R(k)·μ(k)降序排序，并將m臺容器按其容量降序排序。對給定的一個容器，依次嘗試每個宿主機，若當(dāng)前宿主機滿足約束條件，則將容器部署在該宿主機上，否則嘗試下一個宿主機直到這臺容器被部署成功。算法MultiCons（n，m，d，V，H）的具體描述見算法2 所示，其中向量H包含所有可用的宿主機，d為單個宿主機上所能允許部署的最大容器數(shù)量。

記Nmax為n臺容器各自的狀態(tài)數(shù)的最大值，即Nmax=maxNk(1 ≤k≤n)。容器排序時間復(fù)雜度為O(nlbn)，宿主機排序復(fù)雜度為O(mlbm)，部署一臺容器的復(fù)雜度為部署n臺的復(fù)雜度為而容器部署算法總的復(fù)雜度由部署時間所決定，即Nmax一般是比較小的常數(shù)，d是確定的整數(shù)，故只是一個系數(shù)，算法的復(fù)雜度為O(nm)。然而，當(dāng)實際運行中nm的規(guī)模不夠大時是一個相當(dāng)大的系數(shù)，直接導(dǎo)致部署時間延長。為了縮短部署時間，在3.3 節(jié)將提出一種估算最小資源預(yù)留量的預(yù)判方法。

算法2 面向動態(tài)負載的容器部署（MultiCons）。

輸入 容器總數(shù)n，宿主機總數(shù)m；單宿主機允許部署最大容器數(shù)d；容器的馬爾可夫模型V={V(1)，V(2)，…，V(n)}；宿主機模型H={H1，H2，…，Hm}。

輸出 容器到宿主機的映射X=

3.3 面向動態(tài)負載的容器部署加速

在算法2 中，如果前面l臺宿主機上已經(jīng)部署了比較多（不妨假設(shè)為d-1臺）容器，其將不再容納任何有較大資源需求的其他容器。但算法2 在部署一臺明顯無法放置在這l臺宿主機上的容器時，仍需要從第一臺宿主機開始嘗試，直到付出了的代價，才判斷出前l(fā)臺宿主機都無法容納。顯然，這種情況是對計算的極大浪費。本文考慮尋找一個可以簡單計算出的參數(shù)，來判斷容器是否有很大概率無法部署在特定宿主機上。本文先考慮所有容器的資源需求為獨立的二項分布，如表1所示。

表1 容器的資源分布Tab.1 Resource distribution of dockers

正態(tài)分布的累積概率為Fz(zα)=P(Z≤zα)=1-α?，F(xiàn)有一臺宿主機上已部署k臺容器，需要判斷第k+1 臺容器能否部署在該宿主機上。用X表示這k+1 臺容器的總資源需求量，即X=X1+X2+…+Xk+1，根據(jù)中心極限定理，有:

本文分別用Xmin、Xmax表示Xk的最小值和最大值，進而得到:

當(dāng)Rq＞Hl時，可以判斷第k+1 臺容器無法放置在宿主機l上。這里Rq的計算有兩個假定:1）所有的容器服從相似的概率分布。由于FFD將所有容器按照其資源需求量的期望排序，所以放置在同一臺宿主機上的大多數(shù)容器具有相似的期望。在實際情況下，可以將容器按分布聚簇，再排序部署，使其更加準確。2）所有容器都是二狀態(tài)的。在實際情況中，容器狀態(tài)數(shù)會大于2，Xmax會導(dǎo)致實際結(jié)果偏大，在Xmax前加上修正α，得:

對于修正系數(shù)α，可以利用容器的分布估算。先考慮只有一臺的情況:對于二狀態(tài)的容器，易知α=1。對于N狀態(tài)的容器(N≥3)有:

當(dāng)有n臺容器具有不一樣的狀態(tài)數(shù)時，有:

以式（14）、（15）計算出的α作為參考值，若在當(dāng)前α下算法運行結(jié)果準確率比較低時，可以通過減小α來提高準確率；當(dāng)運行時間較長且準確率較高時，可以通過增大α來縮短運行時間。據(jù)此，提出面向動態(tài)負載的容器加速部署策略（如算法3 所示），該算法能夠結(jié)合宿主機和容器各自不同的狀態(tài)進行動態(tài)部署。

這里提出用中心極限定理估算Rq方法的合理性在于:一般來說，若n≥9×max中心極限定理就可以得到較好的擬合效果。在實際的部署中，當(dāng)容器的數(shù)量比較小時，資源需求量和計算出的Rq都遠小于H，所以估算效果的好壞不影響結(jié)果；但當(dāng)容器的數(shù)量比較大時，這種方法的估算效果好，得到比較準確的結(jié)果。

算法3 容器的加速部署（QuickMultiCons）。

輸入 容器總數(shù)n；宿主機總數(shù)m；單宿主機允許部署最大容器數(shù)d；容器的馬爾可夫模型V={V(1)，V(2)，…，V(n)}；宿主機模型H={H1，H2，…，Hm}。

4 實驗與結(jié)果分析

4.1 實驗概述

為驗證部署策略的有效性，在基于國產(chǎn)軟硬件環(huán)境的基礎(chǔ)上，結(jié)合開源系統(tǒng)，設(shè)計了一系列實驗，驗證不同參數(shù)配置下所提設(shè)計算法的效果。

4.1.1 測試床環(huán)境

基于國產(chǎn)軟硬件環(huán)境及開源系統(tǒng)，本文部署并測試環(huán)境運行的可行性。主要實驗環(huán)境配置及具體參數(shù)包括:測試床服務(wù)器為浪潮SN5160M4（IntelE5-2680V4 CPU*2、256 GB（8*32 GB RDIMMG）DDR4 內(nèi)存、1.2 TB 熱插拔SAS 硬盤2.5"*6）；系統(tǒng)為中標麒麟（kernel-2.6.32；KVM-0.12）；資源管理系統(tǒng)為OpenStack R版本；語言環(huán)境為Python 3.8。

4.1.2 對比算法

在測試床的基礎(chǔ)上，通過模擬程序行為實現(xiàn)了所提容器部署策略MULTI（MULTIple），并與三種常用的容器部署策略進行了比較:1）按谷值配置容器的策略RV（Resource with Valley）；2）按峰值配置容器的策略RP（Resource with Peak）；3）按谷值峰值的平均配置容器的策略RVP（Resource with Valley and Peak）。三種部署策略也都使用了FFD策略。在部署完成后，按照真實容器的分布，產(chǎn)生1 000 組實時數(shù)據(jù)進行仿真，出現(xiàn)沖突時測試床將容器動態(tài)遷移到其余空閑宿主機，記錄運行性能結(jié)果。

4.1.3 驗證指標

衡量部署策略的性能的參數(shù)包括部署一定臺數(shù)容器所需的宿主機數(shù)（Physical Machines，PM）、沖突率（Capacity Violation Rate，CVR）和動態(tài)遷移次數(shù)（MIGration，MIG），其中PM、CVR、MIG分別是1 000組數(shù)據(jù)產(chǎn)生宿主機數(shù)目的最大值、沖突率平均值、動態(tài)遷移次數(shù)最大值。

4.1.4 實驗參數(shù)

實驗涉及的參數(shù)包括:容器數(shù)量（VM）、容器資源需求相對大?。≧1∶R2∶…）、容器資源需求的平穩(wěn)分布概率（P1∶P2∶…）、容器資源需求量的絕對大小（Rmean=宿主機容量（H）、宿主機允許的最大容器數(shù)（d）以及宿主機的性能約束（ρ）。

實驗主要驗證容器資源需求的分布區(qū)間（R1∶R2∶…）、絕對大小Rmean和平穩(wěn)分布（P1∶P2∶…）在不同配置下對部署效果的影響，得到部署策略最優(yōu)的參數(shù)配置范圍。實驗中容器有50%概率為二狀態(tài)，50%概率為三狀態(tài)。宿主機的容量H為（80，100）的均勻分布，d設(shè)為16，ρ設(shè)為0.04。三狀態(tài)容器和二狀態(tài)容器的資源需求量平穩(wěn)分布分別如表2和表3所示，容器資源需求量分布如表4 所示。表2 的含義是對每一臺容器，其P1在0～P內(nèi)等概率隨機取值，P2在0～(1-P1)內(nèi)等概率隨機取值，P3取1-P1-P2。表3和表4的含義類似。

表2 三狀態(tài)容器的資源需求量平穩(wěn)分布Tab.2 Resource demand stationary distribution of dockers with three states

表3 二狀態(tài)容器的資源需求量平穩(wěn)分布Tab.3 Resource demand stationary distribution of dockers with two states

表4 容器資源需求量分布Tab.4 Distribution of docker resource demand

累計進行了4組綜合實驗:

1）調(diào)節(jié)容器資源需求量的絕對大小:固定P=1，R分別取3～7，從而改變Rmean。

2）調(diào)節(jié)容器資源需求的平穩(wěn)分布概率:分別在P等于0.2、0.4、0.6、0.8、1.0的情況下進行實驗，并通過改變R固定Rmean=6.125。

3）調(diào)節(jié)容器資源需求的分布區(qū)間:固定P=1 和Rmean=6.125，改變R值調(diào)節(jié)容器資源需求。

4）部署策略運行的時間代價:取P=1和R=5，將10 000臺容器分成100批，每批100臺，按批次進行部署，并記錄下每批容器部署的時間。

4.2 模擬實驗結(jié)果

實驗1 的結(jié)果如表5～6、圖4 所示。RV 使用最少的宿主機，動態(tài)遷移次數(shù)最多。RP 動態(tài)遷移為零，使用的宿主機最多。RVP使用較少的宿主機，但動態(tài)遷移次數(shù)較多，沖突率會隨容器條件的變化而產(chǎn)生較大起伏。MULTI 使用少于RP 的宿主機數(shù)，并且保持較少的遷移次數(shù)和較小沖突率。RV 與RVP 在R＜5 時的沖突率很小，R≥5 時更能體現(xiàn)MULTI 算法的性能效果。在現(xiàn)實中，一般宿主機上都會布置10 臺以上容器［24］，所以模擬實驗的結(jié)果在R=5 時更貼近真實的情況。隨著R增大，MULTI 的PM增長速度大于RVP 的PM增長速度，這是因為R增大會導(dǎo)致單臺宿主機上放置容器數(shù)量減少，即式（10）的k減小，得到更大的Rq。

表5 PM與R的關(guān)系Tab.5 Relationship between PM and R

表6 MIG與R的關(guān)系Tab.6 Relationship between MIG and R

圖4 CVR與R的關(guān)系Fig.4 Relationship between CVR and R

實驗2的結(jié)果如表7～8、圖5所示。隨著P的增大，MULTI策略下的PM略有增大，但幅度比較小。增大的原因是:根據(jù)式（10）、（12），資源預(yù)留量Rq與容器資源需求的期望和方差有關(guān)，當(dāng)保持Rmean恒定時，Rq的大小由容器資源需求的方差大小決定，經(jīng)過簡單計算可知基于表4的分布，P越大，容器資源需求的方差也越大，所需要的資源預(yù)留量越大，進而所使用的宿主機數(shù)量越多。RV、RP、RVP 三種算法的PM增大是因為R的增大。RV、RVP 的MIG和CVR都相當(dāng)?shù)卮笄也环€(wěn)定，MULTI 的MIG一直保持在較小數(shù)值7，CVR也均保持在0.04以下，意味著當(dāng)容器需要資源擴張的時候，其與宿主機的沖突率一直保持較低水平，也能夠體現(xiàn)在宿主機上提前預(yù)留資源的好處。

表7 PM與P的關(guān)系Tab.7 Relationship between PM and P

表8 MIG與P的關(guān)系Tab.8 Relationship between MIG and P

圖5 CVR與P的關(guān)系Fig.5 Relationship between CVR and P

實驗3 的R分別取3、5、7 時，資源需求量的分布如表9 所示。實驗結(jié)果如表10～11，四種算法的MIG和CVR都比較穩(wěn)定，RVP的MIG與MULTI的MIG保持著4倍左右的差距。

表9 P不變時資源需求量的分布Tab.9 Distribution of Resource Demand with fixed P

表10 PM與R的關(guān)系Tab.10 Relationship between PM and R

實驗4的結(jié)果如圖6所示，部署時間與當(dāng)前已放置的容器數(shù)量呈線性關(guān)系，當(dāng)已部署的容器數(shù)量過大時，部署時間也會變得非常長，表明容器遷移開銷也相應(yīng)變大。

圖6 部署時延與部署容器數(shù)量的關(guān)系Fig.6 Relationship between deployment delay and number of deployed dockers

綜上所述，實驗1 體現(xiàn)了容器資源需求分布的期望對部署結(jié)果的影響，實驗2、3 用兩種方式調(diào)節(jié)了容器資源需求分布的方差并研究了它對部署結(jié)果的影響，進而一方面也驗證了式（10）、（11）、（12）結(jié)論的可靠性。面向多狀態(tài)負載的容器部署策略的最大優(yōu)點在于能夠保持動態(tài)遷移次數(shù)和沖突率均穩(wěn)定在一個較小的范圍。

表11 MIG與R的關(guān)系Tab.11 Relationship between MIG and R

5 結(jié)語

容器技術(shù)在集群中發(fā)揮著重要作用，為用戶提供按需式的資源服務(wù)。然而，傳統(tǒng)被動的容器整合或是遷移無法應(yīng)對動態(tài)的容器負載，給集群容器部署帶來挑戰(zhàn)。本文針對長效時間上容器整合與遷移的整體優(yōu)化，提出了利用多狀態(tài)馬爾可夫鏈模型描述容器資源狀態(tài)，并在宿主機資源預(yù)留的基礎(chǔ)上提出了部署策略，還進一步優(yōu)化部署的時延。實驗結(jié)果表明，本文提出的策略能夠在宿主機使用數(shù)量和動態(tài)容器遷移次數(shù)間達到較好的平衡。本文主要針對靜態(tài)場景下的動態(tài)部署問題進行了探討，但所提出的方法難以適用于在線場景，且資源需求類型的描述一定程度上影響了資源的分配策略，而資源需求的類型數(shù)量難以確定，這兩方面將是下一步研究的重點方向。