一種基于Docker容器的集群分段伸縮方法

苗立堯 陳莉君

(西安郵電大學(xué)計(jì)算機(jī)學(xué)院 陜西 西安 710061)

一種基于Docker容器的集群分段伸縮方法

苗立堯 陳莉君

(西安郵電大學(xué)計(jì)算機(jī)學(xué)院 陜西 西安 710061)

針對(duì)現(xiàn)有的虛擬機(jī)集群伸縮方法響應(yīng)慢、開銷大的問題，提出一種基于Docker容器技術(shù)的虛擬機(jī)集群伸縮方法。在檢測(cè)實(shí)時(shí)工作負(fù)載同時(shí)通過自回歸模型對(duì)未來工作負(fù)載進(jìn)行預(yù)測(cè)，最后使用排隊(duì)論模型計(jì)算所需伸縮量。首先從虛擬機(jī)自身進(jìn)行資源重分配，然后依據(jù)工作負(fù)載變化率選擇Docker容器級(jí)別的伸縮或虛擬機(jī)級(jí)別的伸縮，直到請(qǐng)求響應(yīng)時(shí)間在用戶可接受范圍之內(nèi)為止。實(shí)驗(yàn)結(jié)果證明，在面對(duì)不同的工作負(fù)載變化情況時(shí)，該方法可以提供更快的響應(yīng)速度和更低的開銷。

伸縮 虛擬機(jī) Docker容器

0 引 言

隨著網(wǎng)絡(luò)的飛速發(fā)展，基于Web的應(yīng)用在受到廣泛關(guān)注的同時(shí)，其性能也面對(duì)著前所未有的挑戰(zhàn)。Web應(yīng)用的性能經(jīng)常受制于動(dòng)態(tài)的工作負(fù)載[1-2]，而具有伸縮性的云計(jì)算環(huán)境為Web應(yīng)用動(dòng)態(tài)負(fù)載問題提供了解決方案。

目前，已有很多基于云計(jì)算環(huán)境下的集群伸縮性研究。這些集群的底層是由虛擬機(jī)搭建的，例如VMware、XEN等。文獻(xiàn)[3]將云計(jì)算環(huán)境中現(xiàn)有的彈性應(yīng)用自動(dòng)伸縮技術(shù)這些技術(shù)分為兩類：反應(yīng)式伸縮和預(yù)測(cè)式伸縮。另外對(duì)于突發(fā)式的工作負(fù)載變化，由于虛擬機(jī)部署、啟動(dòng)時(shí)間比較長(zhǎng)，一定程度上延長(zhǎng)了伸縮調(diào)整時(shí)間。文獻(xiàn)[4]介紹了對(duì)Web應(yīng)用進(jìn)行分層伸縮的原理。文獻(xiàn)[5]指出蟻群算法、蜂群算法在負(fù)載均衡和伸縮算法里的應(yīng)用。文獻(xiàn)[6]提出了一種基于工作流模型的虛擬機(jī)動(dòng)態(tài)分配、回收方法。但該方法并不能對(duì)未來的工作負(fù)載情況進(jìn)行預(yù)測(cè)。文獻(xiàn)[7]介紹了伸縮工具RightScale的伸縮算法原理。它是響應(yīng)式伸縮，總是處于被動(dòng)。

Docker是一個(gè)開源的引擎，可以輕松地為任何應(yīng)用創(chuàng)建一個(gè)輕量級(jí)的、可移植的、自給自足的容器[8]。它并不是虛擬機(jī)，但它可在提供堪比虛擬機(jī)性能的同時(shí)，更快地部署。但因Docker容器的穩(wěn)定性以及安全性還有待研究，目前很多企業(yè)并未將Docker容器大規(guī)模投入生產(chǎn)實(shí)踐，它們的云環(huán)境仍建立在虛擬機(jī)構(gòu)成的集群之上?；诖耍疚奶岢隽死肈ocker容器來完成集群的快速伸縮。

針對(duì)文獻(xiàn)[6-7]中僅依靠虛擬機(jī)伸縮響應(yīng)慢、開銷大，且不能進(jìn)行預(yù)測(cè)的問題，故本文采用Docker容器技術(shù)來代替只使用虛擬機(jī)的伸縮方法。首先對(duì)多層Web應(yīng)用進(jìn)行數(shù)學(xué)建模以得到工作負(fù)載與資源數(shù)量間的關(guān)系，并綜合利用預(yù)測(cè)式伸縮和響應(yīng)式伸縮實(shí)現(xiàn)在Web應(yīng)用面臨變化的工作負(fù)載時(shí)，從三種粒度進(jìn)行集群伸縮，以提高伸縮的響應(yīng)速度并減少額外的開銷。

1 分析與建模

1.1 Web應(yīng)用的分層結(jié)構(gòu)

現(xiàn)代的Web應(yīng)用大多采用多層結(jié)構(gòu)設(shè)計(jì)[9]，應(yīng)用主要分為表現(xiàn)層、業(yè)務(wù)層、數(shù)據(jù)層。每個(gè)應(yīng)用都擁有一組特定的需求和限制，這是應(yīng)用所有者制定的服務(wù)等級(jí)協(xié)議SLA(Service-Level Agreement)標(biāo)準(zhǔn)。

1.2 排隊(duì)論建模

排隊(duì)論是關(guān)于等待隊(duì)列的一種數(shù)學(xué)研究方法。通過如圖1所示的排隊(duì)論模型，可以計(jì)算得到等待時(shí)間和隊(duì)列長(zhǎng)度，甚至所需的資源數(shù)量[10]。為了精確計(jì)算在負(fù)載變化時(shí)，每層應(yīng)該伸縮多少資源，本文基于排隊(duì)論模型里的G/G/1模型建立了多層應(yīng)用的分析模型。本文提出的模型基于會(huì)話，每個(gè)會(huì)話包含多種交互操作。

圖1 排隊(duì)論示例

在G/G/1模型中，G/G/1分別表示請(qǐng)求到達(dá)間隔服從一般分布、服務(wù)時(shí)間服從一般分布、服務(wù)數(shù)量為1個(gè)，到達(dá)的服務(wù)請(qǐng)求按照先來先服務(wù)(FCFS)順序處理。令

λ

i

表示到第

i

層的請(qǐng)求到達(dá)率，

R

i

表示第

i

層的平均響應(yīng)時(shí)間，

S

i

表示該層的平均服務(wù)時(shí)間。由系統(tǒng)的監(jiān)測(cè)數(shù)據(jù)計(jì)算可以得到到達(dá)間隔時(shí)間和服務(wù)時(shí)間的方差，分別使用

和

來表示，那么該模型可通過下式表示：

(1)

(2)

這里的βi為與該層有關(guān)的常量系數(shù)，T和τ由經(jīng)驗(yàn)得出。

1.3Web應(yīng)用開銷分析

云服務(wù)提供商采用的收費(fèi)策略是“pay-per-use”模型，即Web應(yīng)用所有者只需按照他們使用的資源總額進(jìn)行結(jié)算[12]。目前常見的一種云平臺(tái)收費(fèi)規(guī)則是計(jì)時(shí)收費(fèi)：對(duì)于性能完全一樣的一組服務(wù)器，按單位時(shí)間計(jì)費(fèi)，不足一個(gè)單位時(shí)間的也取整數(shù)個(gè)。

本文提出的算法共采用了兩種云基礎(chǔ)設(shè)施作為底層，分別是虛擬機(jī)VMs和Docker容器?；谏衔乃鲈破脚_(tái)收費(fèi)規(guī)則由此本文提出如下計(jì)費(fèi)公式：

(3)

其中，CTotal表示開銷總額，CD表示Docker容器的使用單價(jià)，Dti表示第i個(gè)容器的使用時(shí)長(zhǎng)。同樣，CV表示虛擬機(jī)的使用單價(jià)，Vtj表示第j個(gè)虛擬機(jī)的使用時(shí)間，CExtra表示額外的開銷。

2 基于Docker容器的伸縮方法

云計(jì)算的伸縮性指的是系統(tǒng)適應(yīng)負(fù)載變化對(duì)資源進(jìn)行調(diào)整的能力。從伸縮的方式看，伸縮有縱橫之分[13]，如圖2所示。從伸縮的時(shí)機(jī)看，伸縮有預(yù)測(cè)式伸縮和響應(yīng)式伸縮。

圖2 縱向伸縮和橫向伸縮

2.1 預(yù)測(cè)式伸縮

預(yù)測(cè)式伸縮的目的是通過對(duì)過去的歷史數(shù)據(jù)的計(jì)算和分析，來完成對(duì)將來的預(yù)測(cè)。鑒于Web應(yīng)用的工作負(fù)載情況可能隨時(shí)間呈現(xiàn)一定的規(guī)律，故本文采用自回歸模型AR(Auto-Regression)[14]來進(jìn)行預(yù)測(cè)。模型函數(shù)用下式表示：x(n)+a1x(n-1)+a2x(n-2)+…+apx(n-p)=w(n)

(4)

(5)

再根據(jù)Yule-Walker方程組可以解得系數(shù)：a1,a2,…,ap

(6)

代入式(1)即可得到一個(gè)用過去時(shí)刻數(shù)據(jù)預(yù)測(cè)將來時(shí)刻值的計(jì)算式[15]。

基于上述數(shù)學(xué)分析，本文首先假設(shè)一個(gè)固定的時(shí)間間隔v，記錄時(shí)刻同時(shí)監(jiān)控當(dāng)時(shí)的工作負(fù)載值，并維持一個(gè)長(zhǎng)度為T的歷史數(shù)據(jù)表。將表內(nèi)離當(dāng)前時(shí)刻最近的p個(gè)數(shù)據(jù)代入上文所述的自回歸模型，計(jì)算得到p個(gè)自相關(guān)系數(shù)r1,r2,…,rp，接著求解Yule-Walker方程組，解得系數(shù)a1,a2,…,ap，最終得到AR模型的方程，由此可以繼續(xù)計(jì)算出下一時(shí)刻工作負(fù)載的預(yù)測(cè)值。

2.2 響應(yīng)式伸縮

由于預(yù)測(cè)式伸縮不適用于突發(fā)式的工作負(fù)載。本文將采用響應(yīng)式伸縮來彌補(bǔ)預(yù)測(cè)式伸縮的不足。

本文提出的方法首先要維持一張長(zhǎng)度為L(zhǎng)的近期負(fù)載表，表里記錄了當(dāng)前時(shí)間往前P時(shí)間內(nèi)的負(fù)載變化情況。假定此刻監(jiān)控得到的工作負(fù)載值為γo，將其與近期負(fù)載表里的工作負(fù)載值計(jì)算平均斜率得到此刻的負(fù)載變化率λ。如果λ大于上限λtu，說明此刻迎來突發(fā)的工作負(fù)載驟增，需要進(jìn)行擴(kuò)展。同理，當(dāng)λ小于下限λtl，說明此刻迎來突發(fā)工作負(fù)載驟降，則需要進(jìn)行收縮。

綜上，預(yù)測(cè)式伸縮和響應(yīng)式伸縮結(jié)合使用可以應(yīng)對(duì)周期性工作負(fù)載變化和突發(fā)式的工作負(fù)載變化。

2.3 算法概述

本文通過t時(shí)刻的請(qǐng)求率γo(t)來反映當(dāng)時(shí)的工作負(fù)載情況(后面用工作負(fù)載代替請(qǐng)求率)，同時(shí)監(jiān)控請(qǐng)求響應(yīng)時(shí)間to。維持兩張表：長(zhǎng)度為T的歷史負(fù)載表H和長(zhǎng)度為L(zhǎng)的近期負(fù)載表P。通過對(duì)H的數(shù)據(jù)代入AR模型可以對(duì)下個(gè)時(shí)刻的工作負(fù)載進(jìn)行預(yù)測(cè)γp(t)，同時(shí)對(duì)P的數(shù)據(jù)進(jìn)行計(jì)算可得到工作負(fù)載的變化率λ。

本文提出的伸縮算法包括兩部分：擴(kuò)展算法和收縮算法。在擴(kuò)展算法里，當(dāng)監(jiān)測(cè)到的γo(t)大于上限γtu時(shí)，如果此時(shí)工作負(fù)載變化率λ也大于上限λtu，此時(shí)部署Docker容器來完成擴(kuò)展。如果此時(shí)λ介于上限λtu和下限λtl之間，部署虛擬機(jī)來擴(kuò)展，或者預(yù)測(cè)的工作負(fù)載γp(t)大于請(qǐng)求率上限γtu時(shí)，直接部署虛擬機(jī)來擴(kuò)展，收縮算法與擴(kuò)展算法類似。

在伸縮調(diào)整時(shí)，先在虛擬機(jī)自身進(jìn)行資源重新分配。如果調(diào)整后響應(yīng)時(shí)間不能滿足SLA要求，再判斷部署虛擬機(jī)還是部署Docker容器。調(diào)整操作直到請(qǐng)求響應(yīng)時(shí)間重新滿足SLA為止。

在每次伸縮調(diào)整操作之后，會(huì)有一個(gè)短暫的冷卻時(shí)間以防止頻繁伸縮對(duì)系統(tǒng)性能帶來的消耗。

表1列出本文提出的算法將會(huì)用到的各個(gè)變量及其含義。

表1 各個(gè)變量及其含義

算法的偽代碼如下：

算法1 服務(wù)器調(diào)度算法

Input:s,γtu，γtl,λt

Output: Scaling Plan1. Begin

2. While(App is running)

3. Monitortoat a fixed interval

4. Maintain 2 tables: History TableH(LengthT) & Present TableP(Length L).

5. Calculateλ,γp(t)

6. Ifγo(t)>γtu||γp(t)>γtu,Then

7. Scaling-Up(S)

8. Else ifγo(t)<γtu,Then

9. Scaling-Down(S)

10. ColdDown(period)

11. End

2.3.1 擴(kuò)展算法

擴(kuò)展算法的目標(biāo)是提高服務(wù)器的性能或增加服務(wù)器的數(shù)量以在面臨高工作負(fù)載時(shí)仍能提供滿足SLA的服務(wù)。算法偽代碼如下：

算法2 擴(kuò)展算法

Input:S

Output: updatedS

1. Begin

2. Ifγp(t) >γtu,then

3. Invoke VM Scaling Up

4. Monitorto

5. Whileto>ttu

6. Invoke Self Scaling Up

7. Calculateλ

8. Ifλ>λtu,then

9. Invoke Docker Scaling Up

10. Else ifλ<λtu,then

11. Invoke VM Scaling Up

12. Invoke Self Scaling Up

13. End

Self-Scaling屬于縱向伸縮，算法通過對(duì)部署在同一臺(tái)物理機(jī)h上的多臺(tái)服務(wù)器之間進(jìn)行資源重分配來提高服務(wù)器的性能。算法偽代碼如下：

算法3 自調(diào)整算法

Input: pair(Sa,Sb)

Output: updated pair(Sa,Sb)1. Begin

2. Monitorto

3. Ifto>ttu,then

4. Whiles≠updated(s)

5. IfSa?updated(s)&&sb?updated(s)&&u(sa,ri)>utu(ri) &&u(sb,ri)

6. Remove one unit of resourcerifromsb,

7. Add one unit of resourceritosa

8. IncludeSaandSbtoupdated(s)

9. End

Docker-Scaling和VM-Scaling算法屬于橫向伸縮。通過比較λ與上限λtu來確定是否屬于突發(fā)式的工作負(fù)載，從而確定是增加Docker容器還是虛擬機(jī)。算法偽代碼實(shí)現(xiàn)如下：

算法4 Docker容器擴(kuò)展

Input:S

Output: newS1. Begin

2. Monitorto

3. Calculateλ

3. Whileto>ttu&&λ>λtu

4. for each tier of m-tiers :

5. Using QueueTheoryModel to calculate the desirednServers at tieribased on the observed request rateγo(t)

6. DeploynDocker Containers as Servers to tieri

7. Include the new Servers to the list ofS

8. End

算法5 虛擬機(jī)擴(kuò)展

Input:S

Output: newS1. Begin

2. Monitorto

3. Whileto>ttu

4. for each tier of m-tiers :

5. Using QueueTheoryModel to calculate the desirednServers at tieribased on the observed request rateγo(t)

6. AddnVMs as Servers to tieri

7. Include the new Servers to the list ofS

8. End

2.3.2 收縮算法

收縮算法通過對(duì)請(qǐng)求率γ°(t)和響應(yīng)時(shí)間t° 的監(jiān)測(cè)，當(dāng)γ°(t)低于上限γtu，若γ°(t)還低于下限γtl，則關(guān)閉虛擬機(jī)。否則關(guān)閉Docker容器。關(guān)閉的時(shí)候需要保持t°滿足SLA。算法偽代碼如下：

算法6 收縮算法

Input:S

Output: newS1. Begin

2. Monitorto<γo(t)&&γo(t)<γtu

3. Whileto

4. Ifγo(t)<γtl,then

5. Exclude one VM fromS& Shut it down

6. Else

7. Exclude one Docker fromS& Shut it down

8. End

3 實(shí)驗(yàn)驗(yàn)證

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

本文的實(shí)驗(yàn)環(huán)境基于TPC Benchmark W(TPC-W)[16]。TPC-W是一款交互式的網(wǎng)絡(luò)性能測(cè)試工具,它提供的工作負(fù)載模擬了常見電子商務(wù)的業(yè)務(wù)活動(dòng)。本文基于此構(gòu)建一個(gè)由4臺(tái)虛擬機(jī)組成的云計(jì)算環(huán)境，并在之上搭建一個(gè)三層的電子商務(wù)平臺(tái)，一臺(tái)作為HTTP服務(wù)器，一臺(tái)作為數(shù)據(jù)庫(kù)服務(wù)器，剩余兩臺(tái)作為Web應(yīng)用服務(wù)器。

3.2 實(shí)驗(yàn)設(shè)計(jì)及結(jié)果

在TPC-W的基礎(chǔ)上，本文從負(fù)載變化維度列出了兩種典型的工作負(fù)載變化情況：突發(fā)負(fù)載、周期負(fù)載。如圖3所示。

(a) 突發(fā)負(fù)載 (b) 周期負(fù)載

本文在上述兩種工作負(fù)載變化情況下，選取了3個(gè)實(shí)驗(yàn)對(duì)象見表2所示。

表2 實(shí)驗(yàn)對(duì)照

其中A和B、A和C分別構(gòu)成對(duì)照組。它們分別運(yùn)行各種工作負(fù)載變化，每種負(fù)載運(yùn)行3次，每次運(yùn)行2小時(shí)，計(jì)算它們的平均響應(yīng)時(shí)間、平均開銷，并加以比較。實(shí)驗(yàn)結(jié)果如圖4、圖5所示。

圖4 突發(fā)負(fù)載下的比較

圖5 周期負(fù)載下的比較

分析實(shí)驗(yàn)結(jié)果可知，在突發(fā)負(fù)載情況下，A、B、C的請(qǐng)求響應(yīng)時(shí)間會(huì)隨著負(fù)載變化產(chǎn)生波動(dòng)，其中A的請(qǐng)求響應(yīng)時(shí)間明顯小于B、C是由于A在伸縮時(shí)的部署，啟動(dòng)時(shí)間小于B、C。在周期負(fù)載情況下，A、B、C的請(qǐng)求響應(yīng)時(shí)間隨著負(fù)載變化而波動(dòng)，B和C在每個(gè)負(fù)載周期時(shí)的表現(xiàn)都幾乎不變。A隨著周期到來請(qǐng)求響應(yīng)時(shí)間明顯降低，是由于A的預(yù)測(cè)算法可以提前為周期負(fù)載做好準(zhǔn)備。3個(gè)實(shí)驗(yàn)對(duì)象的平均開銷如圖6所示。

圖6 平均開銷的比較

圖6中1、2分別表示2種工作負(fù)載變化情況。從圖可以看出，本文提出的方法可以減少突發(fā)性工作負(fù)載和周期性工作負(fù)載下的伸縮開銷。

實(shí)驗(yàn)結(jié)果表明，本文提出的算法可以使Web應(yīng)用在面臨不同工作負(fù)載的情況下滿足SLA標(biāo)準(zhǔn)，在降低開銷的同時(shí)加快伸縮響應(yīng)速度。

4 結(jié) 語(yǔ)

本文通過建立自回歸模型預(yù)測(cè)未來工作負(fù)載變化情況，并結(jié)合響應(yīng)式伸縮協(xié)同做出伸縮調(diào)整決定。伸縮的資源數(shù)量由工作負(fù)載量在排隊(duì)論模型里計(jì)算得到。該伸縮方法在自身、Docker容器、虛擬機(jī)三種粒度上對(duì)面臨工作負(fù)載變化的虛擬機(jī)集群進(jìn)行了調(diào)整。

通過實(shí)驗(yàn)可知，本文提出的方法可以有效完成在兩種典型工作負(fù)載變化下對(duì)虛擬機(jī)集群的伸縮調(diào)整。在保證了Web應(yīng)用的SLA標(biāo)準(zhǔn)的同時(shí)，相比只有虛擬機(jī)來完成伸縮的集群，伸縮調(diào)整速度得到了提升，在一定程度上節(jié)省了Web應(yīng)用所有者的開銷。

[1] Farokhi S,Jamshidi P,Brandic I,et al.Self-adaptation Challenges for Cloud-based Application s:A Control Theoretic Perspective[C/OL].(2015-02-18) [2015-06-29].http://www.infosys.tuwien.ac.at/staff/sfarokhi/soodeh/papers/Soodeh-Farokhi_CameraReady_FeedbackComp-2015.pdf.

[2] 朱志祥，許輝輝，王雄.基于云計(jì)算的彈性負(fù)載均衡方案[J].西安郵電大學(xué)學(xué)報(bào),2013,18(6):43-47.

[3] Lorido-Botran T,Miguel-Alonso J,Lozano J A.A Review of Auto-scaling Techniques for Elastic Applications in Cloud Environments[J].Journal of Grid Computing,2014,12(4):559-592.

[4]VaqueroLM,Rodero-MerinoL,BuyyaR.DynamicallyScalingApplicationsintheCloud[J].ACMSIGCOMMComputerCommunicationReview,2011,41(1):45-52.

[5]KukadePP,KaleG.SurveyofLoadBalancingandScalingapproachesincloud[J].InternationalJournalofEmergingTrendsandTechnologyinComputerScience,2015,4(1):189-192.

[6]MaoM,HumphreyM.Auto-ScalingtoMinimizeCostandMeetApplicationDeadlinesinCloudWorkflows[C]//2011InternationalConferenceforHighPerformanceComputing,Networking,StorageandAnalysis,2011:1-12.

[7]RightScale.SetupAutoscalingusingVotingTags[EB/OL].(2012-12-14) [2015-06-29].http://support.rightscale.com/12-Guides/Dashboard_Users_Guide/Manage/Arrays/Actions/Set_up_Autoscaling_using_Voting_Tags/index.html.

[8]Docker.WhatisDocker?[EB/OL].(2014-02-15) [2015-06-29].http://www.docker.org.cn/book/docker/16_what-is-docker.html.

[9]UrgaonkarB,ShenoyP,ChandraA,elal.AgileDynamicProvisioningofMulti-TierInternetApplications[J].ACMTransactionsonAutonomousandAdaptiveSystems,2008,3(1):217-228.

[10]Wikipedia.QueueingTheory[EB/OL].(2015-06-19) [2015-06-29].https://en.wikipedia.org/wiki/Queueing_theory.

[11]Wikipedia.Little’slaw[EB/OL].(2015-06-24) [2015-06-29].https://en.wikipedia.org/wiki/Little%27s_law.

[12]HanR,GhanemMM,GuoL,elal.Enablingcost-awareandadaptiveelasticityofmulti-tiercloudapplications[J].FutureGenerationComputerSystems,2014,32:82-98.

[13] 龔強(qiáng).云計(jì)算關(guān)鍵技術(shù)之彈性伸縮控制技術(shù)認(rèn)知研究[J].信息技術(shù),2014(1):1-2,6.

[14]Wikipedia.Autoregressivemodel[EB/OL].(2015-06-24) [2015-06-29].https://en.wikipedia.org/wiki/Autoregressive_model.

[15] 丁玉美,闊永紅,高新波.數(shù)字信號(hào)處理-時(shí)域離散隨機(jī)信號(hào)處理[M].西安：西安電子科技大學(xué)出版社,2002:152-153.

[16]TPC-W.TPC-WSummary[EB/OL].(2005-04-28) [2015-06-29].http://www.tpc.org/tpcw/.

A CLUSTER SCALING METHOD BASED ON DOCKER CONTAINER

Miao Liyao Chen Lijun

(SchoolofComputerScienceandTechnology,UniversityofPostsandTelecommunications,Xi’an710061,Shaanxi,China)

A scaling method of cluster is proposed based on Docker container technology to solve the problems of present scaling method,such as slow response and heavy cost.It uses auto-regressive model to predict future workload while monitoring the real-time workload,and calculates the need of resource with one queue theory model.This method first relocates resources by itself,then it chooses the Docker scaling or VM scaling depending on the workload change rate until the response time is within an acceptable range of users.The experimental results show that this method can provide faster scaling response and less cost when dealing with fluctuating workloads.

Scalability Virtual machine Docker container

2015-11-02。苗立堯，碩士生，主研領(lǐng)域：大數(shù)據(jù)與高性能計(jì)算。陳莉君，教授。

TP319

A

10.3969/j.issn.1000-386x.2017.01.006