適用于電網(wǎng)調(diào)控系統(tǒng)的輕量級(jí)容器技術(shù)實(shí)現(xiàn)

顧雯軒，高 原，顧文杰，鄒 慶，董子奇

(1.南瑞集團(tuán)有限公司(國(guó)網(wǎng)電力科學(xué)研究院)，江蘇 南京 211106；2.國(guó)電南瑞科技股份有限公司，江蘇 南京 211106；3.智能電網(wǎng)保護(hù)和運(yùn)行控制國(guó)家重點(diǎn)實(shí)驗(yàn)室，江蘇 南京 211106)

0 引 言

近年來，容器化技術(shù)成為了云生態(tài)系統(tǒng)中最受關(guān)注的技術(shù)之一。容器能夠提供資源隔離、資源限制功能，提高了系統(tǒng)的穩(wěn)定性。容器通過鏡像技術(shù)對(duì)應(yīng)用運(yùn)行環(huán)境進(jìn)行封裝，通過容器云管理平臺(tái)可以方便地實(shí)現(xiàn)持續(xù)集成和持續(xù)部署，降低了系統(tǒng)運(yùn)維的工作量。

隨著特高壓電網(wǎng)的大規(guī)模建設(shè)，電網(wǎng)調(diào)度控制(簡(jiǎn)稱調(diào)控)系統(tǒng)實(shí)時(shí)數(shù)據(jù)規(guī)模快速增加，整個(gè)調(diào)控系統(tǒng)中的應(yīng)用數(shù)量也大量增加，對(duì)系統(tǒng)基礎(chǔ)資源管理能力和運(yùn)維能力提出了更高要求。以往調(diào)控系統(tǒng)應(yīng)用部署時(shí)不能有效限制應(yīng)用使用的資源[1]。引入容器技術(shù)后，可以實(shí)現(xiàn)更細(xì)粒度的資源分配。通過容器的資源限制和資源隔離功能，將業(yè)務(wù)服務(wù)限制在分配的資源范圍內(nèi)運(yùn)行，在保證了系統(tǒng)資源充分利用的同時(shí)實(shí)現(xiàn)系統(tǒng)穩(wěn)定運(yùn)行。

但是，傳統(tǒng)的開源容器[2-4]技術(shù)不能完全滿足電網(wǎng)實(shí)時(shí)調(diào)控系統(tǒng)的要求。比如容器網(wǎng)絡(luò)不支持廣播，不具備限制網(wǎng)絡(luò)帶寬的功能，容器鏡像較大導(dǎo)致應(yīng)用遷移和啟動(dòng)耗時(shí)長(zhǎng)。通過研究現(xiàn)有容器技術(shù)的實(shí)現(xiàn)原理，該文提出一種輕量級(jí)的容器服務(wù)技術(shù)，通過研究虛擬網(wǎng)橋技術(shù)實(shí)現(xiàn)了跨物理宿主機(jī)的廣播/組播通信；結(jié)合Linux流量控制內(nèi)核技術(shù)實(shí)現(xiàn)容器網(wǎng)絡(luò)帶寬限制，并通過對(duì)私有數(shù)據(jù)的封裝降低容器體積，實(shí)現(xiàn)輕量化。

1 現(xiàn)有開源容器技術(shù)

1.1 資源限制和資源隔離

容器的實(shí)現(xiàn)主要依賴于Linux的內(nèi)核技術(shù)CGroup[5]，NameSpace[6-7]和聯(lián)合文件系統(tǒng)[8]。CGroup(Control Group控制組)是Linux內(nèi)核提供的一種限制進(jìn)程組使用宿主機(jī)物理資源的機(jī)制。通過給容器分配資源的控制機(jī)制，避免某個(gè)異常容器占用過多的宿主機(jī)資源，確保同時(shí)運(yùn)行的多個(gè)容器對(duì)宿主機(jī)資源的合理利用?？刂平M可以提供內(nèi)存、CPU、磁盤IO等資源的限制和查詢管理，但是net_cls子系統(tǒng)不具備直接限制網(wǎng)絡(luò)資源的功能，即不能限制某個(gè)容器內(nèi)應(yīng)用占用宿主機(jī)的帶寬大小。

NameSpace(命名空間)是Linux針對(duì)實(shí)現(xiàn)容器資源隔離而引入的特性。每個(gè)容器都可以擁有自己唯一的命名空間，運(yùn)行在其中的進(jìn)程都像是在獨(dú)立互不干擾的操作系統(tǒng)中運(yùn)行一樣，彼此不可見。這個(gè)機(jī)制保證了容器運(yùn)行環(huán)境的相互獨(dú)立，特別適合一個(gè)宿主機(jī)運(yùn)行很多微服務(wù)的應(yīng)用場(chǎng)景，能夠保證每個(gè)服務(wù)間使用操作系統(tǒng)資源以及服務(wù)自身數(shù)據(jù)的互不干擾。

1.2 容器網(wǎng)絡(luò)

開源容器Docker目前常用的三種網(wǎng)絡(luò)插件為Flannel[9]、Weave[10]、Calico[11]。Flannel通過給每臺(tái)宿主機(jī)分配一個(gè)子網(wǎng)的方式為容器提供虛擬網(wǎng)絡(luò)，使用UDP/VXLAN封裝IP包來創(chuàng)建overlay網(wǎng)絡(luò)，并借助etcd維護(hù)網(wǎng)絡(luò)的分配情況。Weave創(chuàng)建一個(gè)連接多個(gè)Docker主機(jī)的虛擬網(wǎng)絡(luò)，類似于一個(gè)以太網(wǎng)交換機(jī)，所有的容器都連接到這上面，互相通信。Calico在主機(jī)上創(chuàng)建了一堆的虛擬網(wǎng)卡，其中一端在主機(jī)上，另一端在容器的網(wǎng)絡(luò)命名空間里，然后在容器和主機(jī)中分別設(shè)置幾條路由，來完成網(wǎng)絡(luò)的互聯(lián)。

這三種插件都是通過給容器建立子網(wǎng)，給容器分配子網(wǎng)IP的方式，使得容器間可以互通。容器分配的IP與宿主機(jī)不是一個(gè)網(wǎng)段，跨宿主機(jī)的容器間可以進(jìn)行TCP和UDP通信。在一個(gè)宿主機(jī)內(nèi)部，容器之間可以進(jìn)行組播/廣播通信，但是跨宿主機(jī)節(jié)點(diǎn)的容器之間無法進(jìn)行組播/廣播通信。

1.3 容器鏡像

聯(lián)合文件系統(tǒng)的引入為構(gòu)建容器和快速遷移提供了有效機(jī)制。

一個(gè)典型的Linux系統(tǒng)運(yùn)行需要兩個(gè)文件系統(tǒng)：bootfs和rootfs。相同內(nèi)核版本的不同Linux發(fā)行版本的bootfs都是一致的，并且是用戶不可更改的。另一個(gè)rootfs文件系統(tǒng)包含典型的目錄，包括/dev,/proc,/bin等再加上一些需要運(yùn)行用戶程序的必要文件(配置文件，庫(kù)文件，可執(zhí)行文件)。這個(gè)文件系統(tǒng)在不同的Linux發(fā)型版本中是不同的，并且是用戶可更改的。

當(dāng)啟動(dòng)一個(gè)容器的時(shí)候，會(huì)將鏡像[12-13]的內(nèi)容加載到容器內(nèi)部。鏡像中的內(nèi)容主要是rootfs文件系統(tǒng)以及一些用戶程序依賴文件。從同一個(gè)鏡像啟動(dòng)多個(gè)容器時(shí)，rootfs文件系統(tǒng)會(huì)被加載重復(fù)加載多次，當(dāng)在宿主機(jī)上啟動(dòng)大量容器時(shí)，相同rootfs文件的重復(fù)加載對(duì)內(nèi)存資源是一種浪費(fèi)，并且對(duì)容器的啟動(dòng)時(shí)間也有一定的影響。

一種最大化內(nèi)存共享與最小化運(yùn)行時(shí)環(huán)境的超輕量級(jí)容器[14]通過去除所有底層操作系統(tǒng)庫(kù)文件且單獨(dú)指定容器內(nèi)應(yīng)用依賴庫(kù)的方法構(gòu)建輕量化容器。這種方法是一種量身定制的方法，但是如果在電力系統(tǒng)中使用，需要每個(gè)應(yīng)用都能準(zhǔn)確指定所需要的依賴庫(kù)，這對(duì)電力系統(tǒng)的研發(fā)人員具有一定挑戰(zhàn)性，且通用性不好，實(shí)施難度大。

2 輕量級(jí)容器架構(gòu)

該文提出一種輕量級(jí)容器的實(shí)現(xiàn)方法，將容器運(yùn)行時(shí)的存儲(chǔ)空間分為兩部分：公共存儲(chǔ)空間和私有存儲(chǔ)空間。其中，公共存儲(chǔ)空間共享宿主機(jī)的文件資源，私有存儲(chǔ)空間存儲(chǔ)容器應(yīng)用或服務(wù)運(yùn)行需要的相關(guān)文件資源。各個(gè)容器之間的私有存儲(chǔ)空間相互隔離，互不干擾，并且容器之間共享宿主機(jī)的文件資源；在容器內(nèi)部，可以同時(shí)看到宿主機(jī)文件資源和自身的文件資源。

每個(gè)輕量級(jí)容器擁有獨(dú)立的工作目錄，工作目錄作為私有存儲(chǔ)空間是相互獨(dú)立的，容器只能訪問自己的工作目錄。各個(gè)輕量級(jí)容器在自身容器內(nèi)部觀察到的工作目錄的路徑和命名是一致的，這樣保證了電力上層應(yīng)用程序的通用性，即容器對(duì)應(yīng)用程序是透明的。通過Linux NameSpace中的mnt[15]掛載命名空間實(shí)現(xiàn)數(shù)據(jù)隔離，這樣對(duì)某個(gè)輕量級(jí)容器的私有工作目錄進(jìn)行操作不會(huì)影響到宿主機(jī)或其他輕量級(jí)容器的相同目錄。各個(gè)輕量級(jí)容器的工作目錄在宿主機(jī)上基于不同的路徑和目錄進(jìn)行管理，目錄命名與容器命名相關(guān)聯(lián)，輕量級(jí)容器進(jìn)行遷移打包的時(shí)候，只需要打包各自的工作目錄即可，因此容器鏡像的體積更小，整個(gè)鏡像封裝更加輕便。

輕量級(jí)容器結(jié)構(gòu)如圖1所示。

圖1 輕量級(jí)容器結(jié)構(gòu)

操作系統(tǒng)rootfs：宿主機(jī)文件系統(tǒng)包含bootfs和rootfs。其中bootfs和Linux內(nèi)核相關(guān)，所有容器共享。rootfs包括常見的/dev，/proc，/etc，/usr等，所有容器也共享rootfs，在容器中看到就是宿主機(jī)的rootfs。

輕量級(jí)容器：從存儲(chǔ)空間來說包含兩部分：容器中運(yùn)行的可執(zhí)行程序以及需要的依賴庫(kù)，配置文件。這些都是存放在容器的私有工作目錄中的，各個(gè)容器之間相互看不見；共享宿主機(jī)rootfs文件系統(tǒng)，這個(gè)為公共存儲(chǔ)空間。

Linux操作系統(tǒng)內(nèi)核：宿主機(jī)的操作系統(tǒng)內(nèi)核，所有運(yùn)行在該宿主機(jī)上的容器都共享Linux操作系統(tǒng)內(nèi)核。容器的資源限制，資源隔離以及流量控制功能都需要操作系統(tǒng)內(nèi)核的支持。

輕量級(jí)容器引擎：負(fù)責(zé)管理容器的整個(gè)生命周期，包括創(chuàng)建，啟動(dòng)，停止，銷毀，主要功能的實(shí)現(xiàn)都是依賴Linux內(nèi)核技術(shù)，包括控制組和命名空間。

3 輕量級(jí)容器架構(gòu)

以上通用技術(shù)實(shí)現(xiàn)的容器還不能直接滿足電力實(shí)時(shí)調(diào)控系統(tǒng)的需求，原因是電力調(diào)控系統(tǒng)對(duì)可靠性和實(shí)時(shí)性要求非常高，所以整個(gè)系統(tǒng)底層建立了提供高可用管理和高速通信功能的基礎(chǔ)平臺(tái)，這個(gè)平臺(tái)的高可用和通信模塊需要使用廣播和組播進(jìn)行通信。并且使用容器后，在一個(gè)物理機(jī)上不能發(fā)生某一個(gè)容器搶占了這個(gè)物理機(jī)所有帶寬的情況，否則實(shí)時(shí)系統(tǒng)的部分功能模塊可能就會(huì)失去作用。同時(shí)因?yàn)橄到y(tǒng)實(shí)時(shí)性要求高，容器啟動(dòng)的時(shí)效性就要很高的要求，啟動(dòng)時(shí)間越短越好。因此該文基于以下討論的三種技術(shù)實(shí)現(xiàn)了一種支持跨物理節(jié)點(diǎn)組播/廣播，并能提供網(wǎng)絡(luò)帶寬限制功能的輕量化容器。

3.1 網(wǎng)絡(luò)帶寬限制技術(shù)

網(wǎng)絡(luò)帶寬限制技術(shù)是通過控制組(Control CGroup)的net_ctl[16]子系統(tǒng)和Linux的流量控制(Traffic Control)[16]共同配合實(shí)現(xiàn)的。CGroup子系統(tǒng)net_cls可以給發(fā)送packet打上classid的標(biāo)簽，用于過濾分類。有了這個(gè)標(biāo)簽，流量控制器(tc)可以對(duì)分屬不同的CGroup進(jìn)程發(fā)送的packet起作用。每個(gè)容器擁有獨(dú)立的網(wǎng)絡(luò)命名空間，且為容器內(nèi)網(wǎng)卡配置的IP地址與宿主機(jī)的IP地址在一個(gè)網(wǎng)段上。如圖2所示，為了對(duì)該容器的發(fā)送數(shù)據(jù)進(jìn)行網(wǎng)絡(luò)流量限制，需要在容器內(nèi)的網(wǎng)卡上設(shè)置TC規(guī)則，其中eth1是容器內(nèi)的網(wǎng)卡。然后在該容器的CGroup子系統(tǒng)net_cls下的相應(yīng)目錄內(nèi)，將tc class規(guī)則的classid傳給net_cls.classid文件。通過這樣的操作，該容器內(nèi)所有的輸出網(wǎng)絡(luò)流量都會(huì)限制在tc class規(guī)則限定的value值內(nèi)，其中，value為字符串，格式為數(shù)值+單位(kbps/mbps/kbit/mbit)。

圖2 網(wǎng)絡(luò)帶寬限制原理

tc qdisc add dev eth1 root handle major:0 htb

tc class replace dev eth1 parent major: classid major: minor htb rate value

tc filter add dev eth1 protocol ip parent major:0 prio 1 handle major: minor cgroup

3.2 支持組播廣播的容器通信技術(shù)

電網(wǎng)調(diào)控系統(tǒng)目前多采用多機(jī)主備冗余機(jī)制，該機(jī)制使用廣播進(jìn)行通信。調(diào)控系統(tǒng)的消息總線使用組播進(jìn)行通信。因此，若需要輕量級(jí)容器運(yùn)用到電網(wǎng)調(diào)控系統(tǒng)中，必須確保各個(gè)容器之間能夠進(jìn)行組播/廣播通信，并且容器和物理節(jié)點(diǎn)之間也能對(duì)等地進(jìn)行組播/廣播通信。文中輕量級(jí)容器分配IP的方式結(jié)合虛擬網(wǎng)橋和虛擬網(wǎng)卡技術(shù)實(shí)現(xiàn)。

工作原理如圖3所示。

圖3 虛擬網(wǎng)橋/網(wǎng)卡實(shí)現(xiàn)原理

(1)宿主機(jī)建立虛擬網(wǎng)橋br0，將物理網(wǎng)卡eth0的ip地址賦予br0，橋接到br0；

(2)創(chuàng)建一對(duì)虛擬網(wǎng)卡veth pair，其中一個(gè)虛擬網(wǎng)卡加入容器的網(wǎng)絡(luò)命名空間中，并更名為eth1，配置IP地址和路由。另一個(gè)網(wǎng)卡橋接到br0上。

如圖3所示，每個(gè)容器擁有獨(dú)立的IP地址，與宿主機(jī)配置在同一網(wǎng)段上，容器和容器，容器和宿主機(jī)之間都能進(jìn)行廣播和組播通信。

3.3 容器輕量化技術(shù)

輕量化主要體現(xiàn)在相比Docker容器的鏡像(如圖4(a)所示)體積更小，層級(jí)更少。如圖4(b)所示，輕量級(jí)容器內(nèi)部雖然可以看到整個(gè)Linux的文件操作系統(tǒng)，但并不表示輕量級(jí)容器鏡像包含Linux文件操作系統(tǒng)的整個(gè)信息。鏡像中只存放了支持容器運(yùn)行的一些必備文件，包括依賴庫(kù)文件，程序執(zhí)行文件和配置文件。創(chuàng)建容器的時(shí)候，會(huì)在宿主機(jī)上創(chuàng)建一個(gè)目錄用于存放容器的私有數(shù)據(jù)，并將鏡像中的文件拷貝至容器私有目錄中。然后通過mount的bind操作將這個(gè)私有目錄掛載至容器的相應(yīng)目錄中。對(duì)于不同的容器來說，將私有目錄掛載至容器掛載空間的相同目錄中，由于容器擁有獨(dú)立的掛載隔離空間，這種操作是獨(dú)立的，互不干擾的。不同容器的相同掛載目錄中的內(nèi)容是不一樣的，在此目錄中做文件修改，文件刪除或文件增加操作都只限于本容器內(nèi)部，不會(huì)對(duì)其他容器的掛載目錄產(chǎn)生任何影響，同時(shí)對(duì)容器外面的宿主機(jī)而言也是不可見的。

(a)傳統(tǒng)容器鏡像結(jié)構(gòu)

4 性能分析

本節(jié)通過在網(wǎng)絡(luò)性能、帶寬限制能力、啟動(dòng)時(shí)間三方面將該文研究的輕量級(jí)容器與開源容器進(jìn)行了對(duì)比，說明了輕量級(jí)容器在三個(gè)方面均優(yōu)于開源容器。

4.1 帶寬限制

結(jié)合控制組的net_cls子系統(tǒng)和Linux流量控制功能，可以實(shí)現(xiàn)對(duì)容器發(fā)送數(shù)據(jù)的帶寬限制。通過scp跨主機(jī)拷貝大容量文本Text進(jìn)行測(cè)試驗(yàn)證，測(cè)試分兩組進(jìn)行(見圖5)：

圖5 帶寬使用對(duì)比

第一組在主機(jī)docker3上直接通過scp拷貝Text文本至主機(jī)節(jié)點(diǎn)docker1，通過iftop檢測(cè)網(wǎng)卡，發(fā)送速率約為800 Mb/s。

第二組測(cè)試是在輕量級(jí)容器中進(jìn)行。首先啟動(dòng)容器時(shí)通過參數(shù)設(shè)置，對(duì)該容器的帶寬值限制在20 Mb/s。然后通過scp拷貝和第一組中相同大小的文件Text文本至主機(jī)節(jié)點(diǎn)docker1，通過iftop檢測(cè)，發(fā)送速率控制在了20 Mb/s以內(nèi)。

4.2 網(wǎng)絡(luò)通信性能對(duì)比

本節(jié)對(duì)目前Docker主流的網(wǎng)絡(luò)開源組件和文中所述的輕量級(jí)容器網(wǎng)絡(luò)組件進(jìn)行性能對(duì)比。對(duì)比的方面包括帶寬和時(shí)延，通過發(fā)送不同KiB大小的數(shù)據(jù)包鏡像檢測(cè)。采用測(cè)試5次取平均值的方法。

(a)host宿主機(jī)帶寬 (b)Flannel帶寬

帶寬性能檢測(cè)結(jié)果如圖6所示，圖中的橫坐標(biāo)表示發(fā)送數(shù)據(jù)包的大小，從1到64遞增，單位為KiB；縱坐標(biāo)為帶寬，單位為MB/sec。從圖中對(duì)比可知，F(xiàn)lannel和Weave的帶寬性能較差，Calico和網(wǎng)橋方式與主機(jī)性能差不多，其中網(wǎng)橋方式性能最優(yōu)。

時(shí)延性能測(cè)試結(jié)果如圖7所示，圖中的橫坐標(biāo)表示發(fā)送數(shù)據(jù)包的大小，從1到64遞增，單位為KiB；縱坐標(biāo)表示時(shí)延，單位是μs。從對(duì)比中可知，Calico和網(wǎng)橋方式與主機(jī)性能差不多，且網(wǎng)橋方式性能最優(yōu)，Weave和Flannel會(huì)隨著數(shù)據(jù)包越來越大而時(shí)延越來越大。

(a)host宿主機(jī)時(shí)延 (b)Flannel時(shí)延

4.3 啟動(dòng)時(shí)間性能對(duì)比

這里從容器中的進(jìn)程啟動(dòng)時(shí)間來對(duì)比分析一下文中的輕量級(jí)容器和Docker容器的性能。

測(cè)試中使用的rocky_cloud:latest開源docker容器包含了運(yùn)行電網(wǎng)調(diào)控系統(tǒng)所需的最小化國(guó)產(chǎn)操作系統(tǒng)模塊，輕量級(jí)容器因?yàn)榕c底層宿主機(jī)操作系統(tǒng)共享模塊，所以大小要小很多。采用測(cè)試5次取平均值的方法，輕量級(jí)容器和Docker中只啟動(dòng)一個(gè)測(cè)試程序，見表1。測(cè)試程序單獨(dú)啟動(dòng)時(shí)需要1 022 ms。

表1 鏡像大小對(duì)比

通過輕量級(jí)容器啟動(dòng)測(cè)試程序需要1 025 ms，Docker啟動(dòng)該測(cè)試程序需要2 133 ms。圖8中，橫坐標(biāo)標(biāo)識(shí)同時(shí)啟動(dòng)容器的個(gè)數(shù)，分別測(cè)試了同時(shí)啟動(dòng)2個(gè)容器，4個(gè)容器，8個(gè)容器，16個(gè)容器，32個(gè)容器時(shí)?？v坐標(biāo)標(biāo)識(shí)容器啟動(dòng)需要花費(fèi)的時(shí)間，單位是μs。從圖8中分析可知，基本上用Docker啟動(dòng)進(jìn)程需要花費(fèi)的時(shí)間是輕量級(jí)容器的2倍。

圖8 啟動(dòng)時(shí)間性能對(duì)比

5 結(jié)束語

提出了一種適用于電網(wǎng)調(diào)控實(shí)時(shí)系統(tǒng)的輕量級(jí)容器技術(shù)實(shí)現(xiàn)方法，在網(wǎng)絡(luò)帶寬限制，跨物理機(jī)通信方式和輕量化方面都進(jìn)行了相關(guān)工作。主要的工作包括：結(jié)合Linux內(nèi)核技術(shù)實(shí)現(xiàn)容器網(wǎng)絡(luò)帶寬的限制功能；結(jié)合虛擬網(wǎng)橋網(wǎng)卡技術(shù)，為容器分配獨(dú)立的IP地址并支持跨主機(jī)的組播廣播通信方式；提出了輕量級(jí)容器私有工作空間的概念，通過共享Linux文件操作系統(tǒng)的方式實(shí)現(xiàn)容器的輕量化。最后通過實(shí)驗(yàn)結(jié)果分析，該輕量級(jí)容器在支持組播/廣播通信的同時(shí)具備帶寬限制的功能，且體積小，遷移快速方便，啟動(dòng)性能上優(yōu)于傳統(tǒng)容器。