王志偉　楊超

摘 要：針對(duì)Docker容器缺乏對(duì)網(wǎng)絡(luò)帶寬資源進(jìn)行限制的能力的問題，提出了一種基于流量控制（TC）的Docker容器網(wǎng)絡(luò)帶寬控制機(jī)制。首先，基于CGroups文件系統(tǒng)的實(shí)時(shí)監(jiān)測(cè)機(jī)制，利用Linux內(nèi)核的虛擬文件系統(tǒng)（VFS）作為媒介，將Docker容器創(chuàng)建時(shí)設(shè)置的網(wǎng)絡(luò)控制參數(shù)傳遞給Linux內(nèi)核流量控制器TC;然后，通過引入IFB模塊實(shí)現(xiàn)上下行帶寬控制，并使用rate、ceil及prio參數(shù)進(jìn)行空閑帶寬共享及容器優(yōu)先級(jí)控制;最后，控制TC執(zhí)行具體的網(wǎng)絡(luò)限制，以實(shí)現(xiàn)容器之間靈活的網(wǎng)絡(luò)資源控制。實(shí)驗(yàn)結(jié)果表明，該機(jī)制在容器獨(dú)占帶寬場(chǎng)景下可有效地將實(shí)際容器帶寬限制在2%的波動(dòng)范圍內(nèi)，而在共享空閑帶寬場(chǎng)景下可在平均誤差0.5%的范圍內(nèi)精準(zhǔn)限制容器帶寬，同時(shí)該機(jī)制能夠基于優(yōu)先級(jí)彈性地管理資源。該機(jī)制具有提供更為原生的接口且無需額外工具配合的優(yōu)勢(shì)，可為基于Docker的云平臺(tái)的細(xì)粒度彈性網(wǎng)絡(luò)資源控制提供便捷有效的解決思路。

關(guān)鍵詞：Docker容器;資源控制;網(wǎng)絡(luò)帶寬;CGroups機(jī)制;流量控制

中圖分類號(hào)： TP393計(jì)算機(jī)網(wǎng)絡(luò)文獻(xiàn)標(biāo)志碼：A

Bandwidth control mechanism for Docker container network based on

traffic control

WANG Zhiwei1， YANG Chao2*

（School of Computer Science and Information Engineering， Hubei University， Wuhan Hubei 430062， China）

Abstract： As Docker container lacks the ability of limiting network bandwidth resources， a bandwidth control mechanism was proposed for Docker container network based on Traffic Control （TC）. Firstly， based on the real-time monitoring mechanism of CGroups file system， Virtual File System （VFS） of Linux kernel was used as a medium to pass the network control parameters set when Docker container was created to the Linux kernel controller TC. Then， the Intermediate Functional Block device （IFB） module was introduced to archive uplink and downlink bandwidth control， and the parameters （rate， ceil and prio） were used to achieve idle bandwidth sharing and container priority control. Finally， the specific network limitations were conducted by controlling the TC， and flexible network resource control between containers was realized. The experimental results show that the proposed mechanism can effectively limit the actual container bandwidth within 2% fluctuation range in the container exclusive bandwidth scenario， and can precisely limit the network bandwidth of the container with average 0.5% error range in the shared idle bandwidth scenario. Meanwhile， the mechanism can flexibly manage resources based on priorities. With the advantage of providing a more native interface for Docker and requiring no additional tools， this mechanism can provide a convenient and effective solution for fine-grained elastic network resource control on Docker-based cloud platform.

Key words： Docker container; resource control; network bandwidth; CGroups mechanism; Traffic Control （TC）

0 引言

Linux容器技術(shù)是一種輕量級(jí)操作系統(tǒng)層的虛擬化技術(shù)。相對(duì)于傳統(tǒng)的虛擬機(jī)，Linux容器具有快速部署、輕量化、低成本、低資源消耗等顯著優(yōu)勢(shì)。其中，Docker容器是目前最成功的開源容器產(chǎn)品[1-3]。Docker具備持續(xù)集成、版本控制、可移植性、隔離性和安全性等重要優(yōu)勢(shì)，眾多企業(yè)和個(gè)人使用Docker來部署、測(cè)試、開發(fā)應(yīng)用，同時(shí)基于Docker來部署云平臺(tái)已經(jīng)是主流趨勢(shì)[4-6]。Docker容器技術(shù)被應(yīng)用在越來越多的領(lǐng)域[7-10]。

目前，Docker仍缺乏對(duì)容器網(wǎng)絡(luò)帶寬進(jìn)行限制的能力，增強(qiáng)Docker對(duì)于網(wǎng)絡(luò)帶寬資源進(jìn)行控制的能力，并且采用一種彈性和基于優(yōu)先級(jí)的網(wǎng)絡(luò)帶寬資源管理方式對(duì)Docker云平臺(tái)的資源管理至關(guān)重要[11]。Zheng等[12]指出Docker默認(rèn)的本地訪問控制是非常弱的，默認(rèn)的安裝策略包含對(duì)網(wǎng)卡設(shè)備和文件系統(tǒng)的全部訪問權(quán)限;但是相較于在單個(gè)容器級(jí)別限制對(duì)網(wǎng)卡的使用而言，對(duì)整個(gè)Docker限制網(wǎng)卡設(shè)備的使用是低效并且不夠靈活的。Khalid等[13]的研究表明如果不限制Docker容器對(duì)網(wǎng)絡(luò)的使用，攻擊者可以通過大量使用網(wǎng)絡(luò)資源來影響統(tǒng)一主機(jī)下其他用戶的使用。在此基礎(chǔ)上，Khalid等[13]又提出一種基于硬件的策略來改變Docker對(duì)網(wǎng)絡(luò)使用計(jì)時(shí)的方案，但是由于引入了特殊的硬件，所以對(duì)宿主機(jī)提出了新的要求。

本文在Linux內(nèi)核的層面設(shè)計(jì)一種精準(zhǔn)的Docker容器網(wǎng)絡(luò)帶寬（以Kb/s計(jì)算）控制系統(tǒng)，解決Docker對(duì)容器網(wǎng)絡(luò)帶寬資源缺少限制的問題，進(jìn)而有效地實(shí)現(xiàn)容器之間網(wǎng)絡(luò)資源的均衡，其優(yōu)勢(shì)在于：1）粒度細(xì)。限制是作用于容器實(shí)力級(jí)別而不是整個(gè)Docker系統(tǒng)。2）控制精準(zhǔn)。能夠以Kb/s的精準(zhǔn)程度控制容器的上行和下行速度。3）對(duì)系統(tǒng)要求低。能夠在不借助額外硬件的幫助下完成，更適合現(xiàn)行硬件條件的宿主機(jī)環(huán)境。該系統(tǒng)具備以下功能：

1）支持容器的網(wǎng)絡(luò)帶寬上行、下行帶寬在容器啟動(dòng)時(shí)被獨(dú)立設(shè)定。

2）保證能夠利用到被分配到的IO帶寬額度。

3）具備彈性資源控制能力，在網(wǎng)絡(luò)帶寬有空閑資源時(shí)，可以按照主機(jī)額度來均分其他CGroups的空閑帶寬，不會(huì)浪費(fèi)IO帶寬資源。

4）支持為不同服務(wù)的容器設(shè)定優(yōu)先級(jí)，確保對(duì)時(shí)延要求較高的服務(wù)的服務(wù)質(zhì)量。

1 相關(guān)工作

1.1 Docker現(xiàn)有資源限制的情況

在Docker中，默認(rèn)情況下容器的資源只受到host端內(nèi)核資源調(diào)度的限制，但是可以在使用Docker run命令啟動(dòng)容器時(shí)添加一些資源控制標(biāo)志來控制容器的Memory、CPU以及Disk IO資源的分配。Docker借助了Linux內(nèi)核的namespace對(duì)資源進(jìn)行隔離，例如CPU資源、磁盤資源、網(wǎng)絡(luò)資源，然后又借助Linux內(nèi)核的CGroups對(duì)隔離的資源施加限制。由于Linux內(nèi)核雖然支持對(duì)網(wǎng)絡(luò)資源進(jìn)行隔離，卻并沒有支持對(duì)網(wǎng)絡(luò)資源的使用進(jìn)行限制，所以現(xiàn)有的方案一般都采用Docker搭配其他網(wǎng)絡(luò)資源限制的工具使用。

本文基于Linux內(nèi)核流量控制（Traffic Control， TC）[14]為Docker建立TC隊(duì)列，并為Docker容器建立分類和過濾器，使得每個(gè)容器的數(shù)據(jù)包都通過過濾器來確定分類，并最終達(dá)到限制容器網(wǎng)絡(luò)帶寬的目的。該方案能較為精準(zhǔn)地控制容器的上行和下行帶寬，并且支持共享限制帶寬和為容器設(shè)置優(yōu)先級(jí)。同時(shí)該方案能為Docker提供更為原生的使用接口，直接通過Docker參數(shù)指定而無需額外工具的配合。

1.2 Linux內(nèi)核流量控制器TC

Linux 操作系統(tǒng)中的TC用于Linux內(nèi)核的流量控制，它利用隊(duì)列規(guī)定建立處理數(shù)據(jù)包的隊(duì)列，并定義隊(duì)列中的數(shù)據(jù)包被發(fā)送的方式，從而實(shí)現(xiàn)對(duì)流量的控制。TC 模塊實(shí)現(xiàn)流量控制功能使用的隊(duì)列規(guī)定分為兩類：一類是無類隊(duì)列規(guī)定，另一類是分類隊(duì)列規(guī)定。無類隊(duì)列規(guī)定相對(duì)簡(jiǎn)單，而分類隊(duì)列規(guī)定則引出了分類和過濾器等概念，使其流量控制功能增強(qiáng)。無類隊(duì)列規(guī)定是對(duì)進(jìn)入網(wǎng)絡(luò)設(shè)備（網(wǎng)卡）的數(shù)據(jù)流不加區(qū)分統(tǒng)一對(duì)待的隊(duì)列規(guī)定。使用無類隊(duì)列規(guī)定形成的隊(duì)列能夠接收數(shù)據(jù)包以及重新編排、延遲或丟棄數(shù)據(jù)包。這類隊(duì)列規(guī)定形成的隊(duì)列可以對(duì)整個(gè)網(wǎng)絡(luò)設(shè)備（網(wǎng)卡）的流量進(jìn)行整形，但不能細(xì)分各種情況。常用的無類隊(duì)列規(guī)定主要有先進(jìn)先出（First Input First Output， FIFO）、令牌桶過濾器（Token Bucket Filter， TBF）、隨機(jī)公平隊(duì)列（Stochastic Fairness Queue， SFQ）等。這類隊(duì)列規(guī)定使用的流量整形手段主要是排序、限速和丟包。

分類隊(duì)列規(guī)定是對(duì)進(jìn)入網(wǎng)絡(luò)設(shè)備的數(shù)據(jù)包根據(jù)不同的需求以分類的方式區(qū)分對(duì)待的隊(duì)列規(guī)定。數(shù)據(jù)包進(jìn)入一個(gè)分類的隊(duì)列后，它就需要被送到某一個(gè)類中，也就是說需要對(duì)數(shù)據(jù)包作分類處理。對(duì)數(shù)據(jù)包進(jìn)行分類的工具是過濾器，過濾器會(huì)返回一個(gè)決定，隊(duì)列規(guī)定就根據(jù)這個(gè)決定把數(shù)據(jù)包送入相應(yīng)的類進(jìn)行排隊(duì)。每個(gè)子類都可以再次使用它們的過濾器進(jìn)行進(jìn)一步的分類，直到不需要進(jìn)一步分類時(shí)，數(shù)據(jù)包才進(jìn)入該類包含的隊(duì)列排隊(duì)。除了能夠包含其他隊(duì)列規(guī)定之外，絕大多數(shù)分類的隊(duì)列規(guī)定還能夠?qū)α髁窟M(jìn)行整形。這對(duì)于需要同時(shí)進(jìn)行調(diào)度（如使用SFQ）和流量控制的場(chǎng)合非常有用。Linux流量控制主要分為建立隊(duì)列、建立分類和建立過濾器三個(gè)方面，基本實(shí)現(xiàn)步驟如下：

1）針對(duì)網(wǎng)絡(luò)物理設(shè)備（如以太網(wǎng)卡eth0）綁定一個(gè)隊(duì)列qdisc，在該隊(duì)列上建立分類class;

2）為每一分類建立一個(gè)基于路由的過濾器filter;

3）最后與過濾器相配合，建立特定的路由表。

2 網(wǎng)絡(luò)帶寬控制系統(tǒng)實(shí)現(xiàn)

2.1 系統(tǒng)總體架構(gòu)

本文方案主要是基于TC來實(shí)現(xiàn)對(duì)Docker的網(wǎng)絡(luò)帶寬進(jìn)行限制，基于Linux的內(nèi)核模塊可以使依賴降到最低，同時(shí)通過在Docker內(nèi)集成TC能夠更加準(zhǔn)確地收集容器信息從而精準(zhǔn)地控制網(wǎng)絡(luò)帶寬，另外可以向Docker提供和原生類似的一致接口。

Linux內(nèi)核從2.2版本開始已經(jīng)支持使用TC命令實(shí)現(xiàn)了流量控制的功能，TC功能十分強(qiáng)大，利用TC完全能夠?qū)崿F(xiàn)對(duì)網(wǎng)絡(luò)帶寬的控制。但是為了使用戶態(tài)工具TC和Docker進(jìn)行協(xié)調(diào)配合，針對(duì)網(wǎng)絡(luò)帶寬設(shè)計(jì)了一種基于CGroups文件系統(tǒng)實(shí)時(shí)監(jiān)測(cè)機(jī)制，利用內(nèi)核CGroups系統(tǒng)實(shí)現(xiàn)的虛擬文件系統(tǒng)（Virtual File System， VFS）作為媒介，將Docker容器創(chuàng)建時(shí)設(shè)置的網(wǎng)絡(luò)控制參數(shù)傳遞給TC。所設(shè)計(jì)系統(tǒng)的技術(shù)流圖如圖1所示。

圖2展示了網(wǎng)絡(luò)帶寬控制系統(tǒng)的總體架構(gòu)。在用戶空間，通過定制Docker源碼，實(shí)現(xiàn)對(duì)混合CGroups的支持，同時(shí)利用CGroups文件系統(tǒng)為媒介，用戶態(tài)網(wǎng)絡(luò)帶寬控制模塊能夠感知Docker容器設(shè)置的變化，進(jìn)行相應(yīng)網(wǎng)絡(luò)帶寬控制。各模塊功能如下：

1）網(wǎng)絡(luò)帶寬Controller：作為用戶態(tài)Linux守護(hù)進(jìn)程，負(fù)責(zé)與Docker daemon配合進(jìn)行網(wǎng)絡(luò)帶寬的控制。

2）Net CGroups detector： 監(jiān)測(cè)CGroups文件系統(tǒng)內(nèi)net_ctls下Docker容器網(wǎng)絡(luò)控制的變化，能夠讀取網(wǎng)絡(luò)控制參數(shù)，將參數(shù)配置傳給TC controller模塊。

3）TC controller：接收從Net CGroups detector模塊傳遞的網(wǎng)絡(luò)控制指令和具體參數(shù)，控制TC執(zhí)行具體的網(wǎng)絡(luò)限制。

2.2 限制容器的上限帶寬

Docker啟動(dòng)容器時(shí)默認(rèn)的網(wǎng)絡(luò)模式是bridge，該模式也是業(yè)界應(yīng)用最廣泛的一種網(wǎng)絡(luò)模式，該網(wǎng)絡(luò)模式的拓?fù)淙鐖D3所示。Docker在主機(jī)中建立了一個(gè)叫作docker0的網(wǎng)橋，而后容器與主機(jī)之間的流量都是通過這個(gè)網(wǎng)橋進(jìn)行轉(zhuǎn)發(fā)的。由于TC工具只能對(duì)網(wǎng)卡的發(fā)送速率進(jìn)行限制，因此容器的上下行帶寬設(shè)置方法有略微的不同，這里分開討論。

對(duì)于容器的下行流量，數(shù)據(jù)包是從eth0發(fā)送到docker0，而后再通過docker0發(fā)送到docker1（172.17.0.2）上。因此只要限制了docker0發(fā)往docker1（172.17.0.2）的速率，就可以限制容器docker1 的下行帶寬了。具體要做的操作有：

1）使用TC工具為docker0網(wǎng)橋添加一個(gè)qdisc，具體使用的是分層令牌桶（Hierarchical Token Bucket， HTB）[15]。

2）在這個(gè)qdisc上建立一個(gè)根分類（例如2∶1），可以選擇設(shè)置docker0網(wǎng)橋的總可用帶寬。

3）為容器建立子分類（例如2∶2），同時(shí)設(shè)置該分類的帶寬。

4）利用TC filter將目的地址為容器的IP的流量都?xì)w類為2∶2。

對(duì)于容器的上行流量，使用了Linux內(nèi)核的IFB（Intermediate Functional Block device）模塊，手動(dòng)加載IFB模塊后，系統(tǒng)的網(wǎng)絡(luò)中將多出一個(gè)ifb0的設(shè)備，需要將docker0網(wǎng)卡從容器端接受到的所有流量都轉(zhuǎn)發(fā)到ifb0網(wǎng)卡，然后再用類似的方法限制帶寬。具體要做的操作有：1）加載IFB模塊;2）啟動(dòng)ifb0設(shè)備;3）將docker0的流量轉(zhuǎn)發(fā)到ifb0設(shè)備上;4）為ifb0添加了qdisc，本文使用的HTB;5）在這個(gè)qdisc上建立根分類（3∶1），可以選擇設(shè)置所有容器總可用上行帶寬;6）為容器建立子分類（3∶2），同時(shí)設(shè)置該分類的帶寬;7）利用TC filter將源地址為容器的IP的流量都?xì)w類為3∶2。

2.3 支持容器共享空閑帶寬

在實(shí)際的生產(chǎn)環(huán)境中，有部分容器帶寬使用率很低，而有些容器的帶寬利用率很高，這就造成了資源的浪費(fèi)，因此需要支持容器共享空閑帶寬。在使用TC工具為容器建立子分類時(shí)，可以限制容器的帶寬，限制帶寬有rate和ceil兩種選項(xiàng)：rate選項(xiàng)設(shè)置的帶寬是容器能夠被保證的帶寬，而ceil選項(xiàng)設(shè)置的帶寬是在父分類有空閑帶寬時(shí)，容器能夠得到的最大的帶寬。因此，如果需要設(shè)置容器可以共享空閑帶寬，只要調(diào)整這個(gè)ceil值，讓它大于rate值;如果不想讓容器共享空閑帶寬，那么只要設(shè)置這個(gè)ceil值與rate值相等即可。

2.4 支持為每個(gè)容器設(shè)定優(yōu)先級(jí)

Docker提倡一個(gè)容器只負(fù)責(zé)一種服務(wù)，不同的服務(wù)對(duì)網(wǎng)絡(luò)帶寬和時(shí)延的要求也不同，因此需要支持為容器設(shè)立優(yōu)先級(jí)，在網(wǎng)絡(luò)出現(xiàn)擁堵的情況下，具有高優(yōu)先級(jí)容器的數(shù)據(jù)包將被優(yōu)先處理，確保較低的延時(shí)，保證容器的服務(wù)質(zhì)量。TC工具支持為分類設(shè)置prio參數(shù)，該參數(shù)即可實(shí)現(xiàn)我們的需求，參數(shù)值越小優(yōu)先級(jí)越高，優(yōu)先級(jí)高的分類數(shù)據(jù)包將被優(yōu)先發(fā)送。

3 實(shí)驗(yàn)結(jié)果與分析

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

為了驗(yàn)證本文系統(tǒng)在限制容器上限網(wǎng)絡(luò)帶寬、按優(yōu)先級(jí)分配網(wǎng)絡(luò)帶寬和彈性分配帶寬等方面的效果，在實(shí)際的物理機(jī)上進(jìn)行了實(shí)驗(yàn)驗(yàn)證。實(shí)驗(yàn)結(jié)果表明，本文系統(tǒng)能夠精確限制容器網(wǎng)絡(luò)帶寬，并按比例將空閑網(wǎng)絡(luò)帶寬分配給各個(gè)容器。

實(shí)驗(yàn)首先測(cè)試對(duì)容器帶寬的上限進(jìn)行限制。在未限制帶寬的基準(zhǔn)測(cè)試中，容器全力下載則會(huì)耗盡所有帶寬，所以下載速率非常高，通過限制上限之后，即使容器全力下載其下載速率也不能突破施加的限制，從而說明施加的上限是有效的。

在驗(yàn)證共享帶寬的實(shí)驗(yàn)中，主機(jī)中同時(shí)啟動(dòng)兩個(gè)容器，并且其對(duì)兩者施加的上限之和小于主機(jī)的帶寬上限。在這種資源閑置的情況下，通過設(shè)置不同的參數(shù)希望能夠使得容器突破上限使用閑置資源，所以容器的實(shí)際帶寬可能略大于上限，并且兩個(gè)容器實(shí)際使用的帶寬之和接近主機(jī)的帶寬上限，從而說明容器能夠有效利用空閑帶寬。

在驗(yàn)證容器優(yōu)先級(jí)的實(shí)驗(yàn)中，在上一個(gè)實(shí)驗(yàn)環(huán)境的基礎(chǔ)上進(jìn)行。對(duì)上一實(shí)驗(yàn)中的兩個(gè)容器設(shè)置不同的優(yōu)先級(jí)，原本兩個(gè)容器都能共享主機(jī)中空閑的帶寬，現(xiàn)在優(yōu)先級(jí)高的容器將優(yōu)先使用這些空閑帶寬，在高優(yōu)先級(jí)容器結(jié)束后低優(yōu)先級(jí)容器能繼續(xù)使用空閑帶寬，從而說明對(duì)容器的優(yōu)先級(jí)設(shè)定是有效的。

3.2 限制容器的上限帶寬

為了測(cè)試系統(tǒng)對(duì)容器帶寬的限制作用，在Docker中啟動(dòng)一個(gè)容器后，不對(duì)它進(jìn)行任何的限制，在10s的時(shí)間間隔內(nèi)，每0.5s打印該時(shí)段內(nèi)傳輸字節(jié)量以及平均的傳輸速率，作為基準(zhǔn)線。重新啟動(dòng)容器，并將rate設(shè)置為50Mb/s，其余ceil、prio參數(shù)默認(rèn)為無效，以同樣的時(shí)間間隔打印測(cè)試結(jié)果，結(jié)果如圖4所示。

從圖4中可以觀察到，剛啟動(dòng)容器時(shí)，傳輸速率較大，但會(huì)迅速下落。當(dāng)不作任何帶寬限制時(shí)，實(shí)際傳輸速率波動(dòng)幅度較大，總體保持在較高水平。當(dāng)限制帶寬為50Mb/s，啟動(dòng)容器后實(shí)際傳輸速率能迅速回落至設(shè)定值，且波動(dòng)幅度極小，不超過平均傳輸速率的2%，限制效果較為精準(zhǔn)。

3.3 容器共享空閑帶寬

前面提到，參數(shù)rate設(shè)置了容器的上限帶寬，若同時(shí)設(shè)置參數(shù)ceil（大于等于rate的一個(gè)值），則在父分類有空閑帶寬時(shí)，會(huì)實(shí)際達(dá)到不超過ceil值的帶寬利用。為測(cè)試容器共享空閑帶寬的情況，啟動(dòng)一個(gè)容器后，并建立兩個(gè)子分類，其中子分類1的參數(shù)設(shè)置為rate=20Mb/s，ceil=20Mb/s，即嚴(yán)格限制帶寬為20Mb/s;子分類2的參數(shù)設(shè)置為rate=50Mb/s，ceil=50Mb/s。同樣在10s的時(shí)間間隔內(nèi)，每0.5s打印該時(shí)段內(nèi)傳輸字節(jié)量以及平均的傳輸速率，作為參考基準(zhǔn)。

重新啟動(dòng)一個(gè)容器，建立兩個(gè)子分類，其中：子分類1的參數(shù)設(shè)置為rate=20Mb/s，ceil=120Mb/s（大于容器的總帶寬）;子分類2的參數(shù)設(shè)置為rate=50Mb/s，ceil=120Mb/s。兩次實(shí)驗(yàn)結(jié)果如圖5所示。

從圖5中可知，在設(shè)置ceil為一個(gè)較大參數(shù)的情況下，容器中的子分類會(huì)利用空閑帶寬，并且在默認(rèn)優(yōu)先級(jí)的情況下，幾乎等額分配空閑帶寬。圖中rate=ceil=20Mb/s的數(shù)據(jù)波動(dòng)不可忽視，原因在于：每個(gè)0.5s的時(shí)間段內(nèi)打印的傳輸數(shù)據(jù)并不準(zhǔn)確是這個(gè)時(shí)間段內(nèi)傳輸?shù)臄?shù)據(jù)，存在上個(gè)時(shí)間段部分傳輸?shù)臄?shù)據(jù)記錄到這個(gè)時(shí)間段，而這個(gè)時(shí)間段內(nèi)部分傳輸?shù)臄?shù)據(jù)被記錄到下一個(gè)時(shí)間段內(nèi)的情況，因此數(shù)據(jù)并不準(zhǔn)確維持在20Mb/s而略有波動(dòng)，但總體還是在20Mb/s附近。實(shí)驗(yàn)10s的總時(shí)間段內(nèi)平均傳輸速率為20.1Mb/s，誤差約為0.5%，與設(shè)置數(shù)據(jù)精準(zhǔn)符合，故上述波動(dòng)認(rèn)為是可接受的。

當(dāng)利用空閑帶寬時(shí)，測(cè)試數(shù)據(jù)波動(dòng)幅度增大，符合預(yù)期。當(dāng)rate=50Mb/s，ceil大于總帶寬，在測(cè)試的最后時(shí)段數(shù)據(jù)有明顯較大的增幅，原因在于：?jiǎn)?dòng)容器并建立子分類的過程中，由于是手動(dòng)設(shè)置參數(shù)并開始進(jìn)程，因此兩個(gè)子分類有可觀的時(shí)間先后差。在該數(shù)據(jù)的最后兩個(gè)測(cè)試時(shí)間點(diǎn)，rate=20Mb/s的子分類已結(jié)束進(jìn)程，釋放了帶寬空間，容器中有了更多的空閑帶寬，因此該子分類的傳輸速率迅速增大。

3.4 容器優(yōu)先級(jí)設(shè)定

為了測(cè)試優(yōu)先級(jí)（即參數(shù)prio）對(duì)數(shù)據(jù)傳輸速率的影響，對(duì)容器中的兩個(gè)子分類配置如下參數(shù)：子分類1中rate=20Mb/s，prio=1;子分類2中rate=50Mb/s，prio=3。其中ceil設(shè)置為120Mb/s（大于容器總帶寬），同樣在10s的時(shí)間間隔內(nèi)，每0.5s打印該時(shí)段內(nèi)傳輸字節(jié)量以及平均的傳輸速率。將該數(shù)據(jù)與3.2節(jié)中得到的參考基準(zhǔn)數(shù)據(jù)對(duì)比，結(jié)果如圖6所示。

參數(shù)值越小優(yōu)先級(jí)越高，優(yōu)先級(jí)高的分類數(shù)據(jù)包將被優(yōu)先發(fā)送。在圖6中，即rate=20Mb/s、prio=1的子分類優(yōu)先級(jí)更高，在容器有空閑帶寬的情況下，占滿了空閑帶寬，而優(yōu)先級(jí)較低（prio=3）的子分類僅使用了保證的50Mb/s帶寬。

在測(cè)試的最后時(shí)段，優(yōu)先級(jí)更高的子分類先結(jié)束進(jìn)程（由于手動(dòng)設(shè)置而導(dǎo)致兩個(gè)子分類開始進(jìn)程的時(shí)刻存在時(shí)間差），優(yōu)先級(jí)低的子分類開始使用容器內(nèi)的空閑帶寬，因此子分類2（rate=50Mb/s、prio=3）的傳輸速率在最后略有提升。

4 結(jié)語(yǔ)

Docker并沒有給出網(wǎng)絡(luò)限制的方案，因?yàn)槟壳熬W(wǎng)絡(luò)是通過插件來實(shí)現(xiàn)的，和容器本身的功能相對(duì)獨(dú)立，不容易實(shí)現(xiàn)，擴(kuò)展性也很差。Docker社區(qū)已經(jīng)有很多呼聲并且有很多關(guān)于添加網(wǎng)絡(luò)帶寬限制的提議，騰訊的Docker云平臺(tái)GaiaStack也探索了一些對(duì)網(wǎng)絡(luò)資源進(jìn)行限制的方法。

本文系統(tǒng)基于CGroups文件系統(tǒng)實(shí)時(shí)監(jiān)測(cè)機(jī)制，利用內(nèi)核CGroups系統(tǒng)實(shí)現(xiàn)的VFS文件系統(tǒng)作為媒介，將Docker容器創(chuàng)建時(shí)設(shè)置的網(wǎng)絡(luò)控制參數(shù)傳遞給TC，進(jìn)而控制TC實(shí)現(xiàn)具體的網(wǎng)絡(luò)控制。經(jīng)測(cè)試可知，本文的系統(tǒng)對(duì)于網(wǎng)絡(luò)帶寬的限制可以達(dá)到精準(zhǔn)的控制，還可以對(duì)容器任務(wù)定義優(yōu)先級(jí)，在保證其他容器帶寬的前提下，優(yōu)先分配空閑帶寬給優(yōu)先級(jí)高的容器，保證優(yōu)先級(jí)高的分類數(shù)據(jù)包被優(yōu)先發(fā)送。但Docker中其他資源的限制都是在內(nèi)核層面實(shí)現(xiàn)的，因此本文的系統(tǒng)沒有從內(nèi)核的本質(zhì)上解決網(wǎng)絡(luò)限制的問題，未來將在內(nèi)核層面作更深入的研究。

參考文獻(xiàn) （References）

[1]BOETTIGER C. An introduction to docker for reproducible research， with examples from the renvironment [J]. ACM SIGOPS Operating Systems Review， 2015， 49（1）： 71-79.

[2]王亞玲，李春陽(yáng)，崔蔚，等.基于Docker的PaaS平臺(tái)建設(shè)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2016，25（3）：72-77.（WANG Y L， LI C Y， CUI W， et al. Construction of Docker-based PaaS [J]. Computer Systems & Applications， 2016， 25（3）： 72-77.）

[3]BERNSTEIN D. Containers and cloud： from LXC to Docker to Kubernetes [J]. IEEE Cloud Computing， 2014， 1（3）： 81-84.

[4]LIU D， ZHAO L. The research and implementation of cloud computing platform based on Docker [C]// Proceedings of the 11th International Computer Conference on Wavelet Active Media Technology and Information Processing. Piscataway： IEEE， 2014： 475-478.

[5]KAN C. DoCloud： an elastic cloud platform for Web applications based on Docker [C]// Proceedings of the 18th International Conference on Advanced Communication Technology. Piscataway： IEEE， 2016： 478-483.

[6]ISMAIL B I， GOORTANI E M， AB KARIM M B， et al. Evaluation of Docker as edge computing platform [C]// Proceedings of the 2015 IEEE Conference on Open Systems. Piscataway： IEEE， 2015： 130-135.

[7]ABDELBAKY M， DIAZ-MONTES J， PARASHAR M， et al. Docker containers across multiple clouds and data centers [C]// Proceedings of the 2015 IEEE/ACM 8th International Conference on Utility and Cloud Computing. Piscataway： IEEE， 2015： 368-371.

[8]BELLAVISTA P， ZANNI A. Feasibility of fog computing deployment based on Docker containerization over RaspberryPi [C]// Proceedings of the 18th International Conference on Distributed Computing and Networking. New York： ACM， 2017： Article No. 16.

[9]CHUNG M T， QUANG-HUNG N， NGUYEN M T， et al. Using Docker in high performance computing applications [C]// Proceedings of the 2016 IEEE 6th International Conference on Communications and Electronics. Piscataway： IEEE， 2016： 52-57.

[10]LIU Q， ZHENG W， ZHANG M， et al. Docker-based automatic deployment for nuclear fusion experimental data archive cluster [J]. IEEE Transactions on Plasma Science， 2018， 46（5）： 1281-1284.

[11]XIE B， SUN G， MA G. Docker based overlay network performance evaluation in large scale streaming system [C]// Proceedings of the 2016 IEEE Advanced Information Management， Communicates， Electronic and Automation Control Conference. Piscataway： IEEE， 2016： 366-369.

[12]ZHENG Z， WU X， ZHANG Y， et al. QoS ranking prediction for cloud services [J]. IEEE Transactions on Parallel and Distributed Systems， 2013， 24（6）： 1213-1222.

[13]KHALID J， ROZNER E， FELTER W， et al. Iron： isolating network-based CPU in container environments [C]// Proceedings of the 15th USENIX Symposium on Networked Systems Design and Implementation. Berkeley， CA： USENIX Association， 2018： 313-328.[EB/OL]. [2019-03-20]. https：//www.usenix.org/system/files/conference/nsdi18/nsdi18-khalid.pdf.

[14]龍恒.Linux流控工具TC的原理及實(shí)用案例分析[J].計(jì)算機(jī)與現(xiàn)代化，2010（11）：80-84，88.（LONG H. TC principle of Linux traffic control tool and its practical case analysis [J]. Computer and Modernization， 2010（11）： 80-84， 88.）

[15]李曉利，郭宇春.QoS技術(shù)中令牌桶算法實(shí)現(xiàn)方式比較[J].中興通訊技術(shù)，2007，13（3）：56-60.（LI X L， GUO Y C. Comparison between token bucket algorithms in QoS technology [J]. ZTE Communications， 2007， 13（3）： 56-60.）

This work is partially supported by the National Natural Science Foundation of China （61170306）， the Hubei Province Key Laboratory of Intelligent Information Processing and Real-time Industrial System （znxx2018MS05）.

WANG Zhiwei， born in 1982， M. S. candidate. His research interests include information security.

YANG Chao， born in 1982， Ph. D.， associate professor. His research interests include information security.

收稿日期：2019-05-06;修回日期：2019-07-12;錄用日期：2019-07-19。

基金項(xiàng)目：國(guó)家自然科學(xué)基金資助項(xiàng)目（61170306）;智能信息處理與實(shí)時(shí)工業(yè)系統(tǒng)湖北省重點(diǎn)實(shí)驗(yàn)室開放基金資助項(xiàng)目（znxx2018MS05）。

作者簡(jiǎn)介：王志偉（1982—），男，北京人，碩士研究生，主要研究方向：信息安全; 楊超（1982—），男，湖北武漢人，副教授，博士，CCF會(huì)員（會(huì)員編號(hào)：94791M），主要研究方向：信息安全。

文章編號(hào)：1001-9081（2019）12-3628-05DOI：10.11772/j.issn.1001-9081.2019040765