面向動態(tài)負載的集群容器部署方法

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

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

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

0 引言

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

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

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

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

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

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

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

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

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

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

1 相關工作

1.1 虛擬機/容器負載刻畫

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

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

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

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

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

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

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

2 系統(tǒng)模型

2.1 場景定義

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

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

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

2.2 單容器資源需求模型

容器資源需求量是動態(tài)變化的，能被量化為多個狀態(tài)（如圖1 所示）。本文將該特性稱為容器的多狀態(tài)特性，并用多狀態(tài)的馬爾可夫鏈進行建模，如圖3所示。假設集群共創(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ù)所構成的是這臺容器的狀態(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

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

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

2.3 多容器的復合資源需求模型

對于n臺容器來說，每個V(k)有Nk種狀態(tài)，每臺容器的狀態(tài)變化相互獨立。因此，這n臺容器一共有N=種狀態(tài)。用S(k)表示容器V(k)當前的所有狀態(tài)，則這n臺容器在當前的復合狀態(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進行標號。更進一步，對于當前所處的狀態(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)的關系如定理所述。

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

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

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

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

集群有m臺宿主機，第l臺宿主機Hl的可用資源可以用其容量Cl來描述，即Hl=Cl，1 ≤l≤m。容器的部署過程實際上是從容器到宿主機的一個映射過程，用矩陣X=來表示，當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）），當t=0 時；滿足性能約束（式（7）），對所有t。

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

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

對任意一個給定的裝箱問題判定版本實例，構造一個面向動態(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)負載的容器部署與資源預留

3.1 容器的資源預留策略

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

此時的性能約束滿足:

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

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

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

算法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)部署了比較多（不妨假設為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的最小值和最大值，進而得到:

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

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

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

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

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

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

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

4 實驗與結果分析

4.1 實驗概述

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

4.1.1 測試床環(huán)境

基于國產(chǎn)軟硬件環(huán)境及開源系統(tǒng)，本文部署并測試環(huán)境運行的可行性。主要實驗環(huán)境配置及具體參數(shù)包括:測試床服務器為浪潮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 對比算法

在測試床的基礎上，通過模擬程序行為實現(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)遷移到其余空閑宿主機，記錄運行性能結果。

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）、容器資源需求相對大小（R1∶R2∶…）、容器資源需求的平穩(wěn)分布概率（P1∶P2∶…）、容器資源需求量的絕對大?。≧mean=宿主機容量（H）、宿主機允許的最大容器數(shù)（d）以及宿主機的性能約束（ρ）。

實驗主要驗證容器資源需求的分布區(qū)間（R1∶R2∶…）、絕對大小Rmean和平穩(wěn)分布（P1∶P2∶…）在不同配置下對部署效果的影響，得到部署策略最優(yōu)的參數(shù)配置范圍。實驗中容器有50%概率為二狀態(tài)，50%概率為三狀態(tài)。宿主機的容量H為（80，100）的均勻分布，d設為16，ρ設為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 模擬實驗結果

實驗1 的結果如表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］，所以模擬實驗的結果在R=5 時更貼近真實的情況。隨著R增大，MULTI 的PM增長速度大于RVP 的PM增長速度，這是因為R增大會導致單臺宿主機上放置容器數(shù)量減少，即式（10）的k減小，得到更大的Rq。

表5 PM與R的關系Tab.5 Relationship between PM and R

表6 MIG與R的關系Tab.6 Relationship between MIG and R

圖4 CVR與R的關系Fig.4 Relationship between CVR and R

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

表7 PM與P的關系Tab.7 Relationship between PM and P

表8 MIG與P的關系Tab.8 Relationship between MIG and P

圖5 CVR與P的關系Fig.5 Relationship between CVR and P

實驗3 的R分別取3、5、7 時，資源需求量的分布如表9 所示。實驗結果如表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的關系Tab.10 Relationship between PM and R

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

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

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

表11 MIG與R的關系Tab.11 Relationship between MIG and R

5 結語

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