龍芯平臺1.13版本Docker移植研究

吳平凡 劉顯德 吳少剛

1(東北石油大學計算機與信息技術學院 黑龍江 大慶 163318) 2(江蘇航天龍夢信息技術有限公司 江蘇 蘇州 215500)

0 引 言

虛擬化技術是一種被廣泛應用的硬件資源共享技術，不僅包括了以KVM、Xen、Hyper-V、VMware ESXi為代表的傳統硬件級虛擬化技術，近年來以Docker為代表的新一代容器技術，在克服了傳統容器技術難以標準化的困難后，憑借輕量級的特性在虛擬化領域形成了顛覆性的影響[1]。

事實上，傳統的容器技術數十年前就已經出現，比如常見的Chroot[2]命令在1979年就已經出現，被認為是最早的容器化技術之一，用來隔離一個進程的文件系統。還有BSD jails、LXC、OpenVZ、Linux VServer等技術都可以稱為傳統容器技術[3-4]。

由于傳統容器技術未能提供應用標準化的運行環境，因此在許多應用領域中隨著虛擬機技術的廣泛運用而逐漸銷聲匿跡。新一代的容器技術則從一開始就以提供標準化的運行時環境為目標，實現了底層操作系統與物理主機的解耦。因此Docker這一類新容器技術往往被稱作應用程序容器，旨在為單個進程進行打包和運行服務。

X86平臺上關于Docker技術的相關研究[5-7]很早便已經展開。龍芯[8-10]是我國第一個自主研發的通用微處理器，基于龍芯3A/3B 3000系列的計算機和服務器已經在國家核心部門的關鍵信息系統中得到了批量應用。隨著云計算模式的普及，對支持虛擬化技術的龍芯服務器系統的需求日益迫切。在龍芯平臺上的虛擬化技術研究方面，相關文獻進行了關于MIPS架構下的內存虛擬化研究[11-12]，以及支持跨指令集二進制代碼兼容性的虛擬機方案研究[13]。而在容器技術支持方面，龍芯平臺Fedora21系統支持1.6.0版本Docker方案，而Docker技術隨著Linux內核升級有了較大的架構級更新，本文工作源自龍芯平臺Fedora28系統對1.13版本Docker的需求，對國產龍芯服務器在云模式下的應用推廣具有重要的工程應用價值。

鑒于X86的Fedora28系統安裝源初始默認Docker1.13.1方案，所以本文針對該版本進行了面向龍芯平臺的移植優化，添加了NETNS相關的MIPS架構參數，變換了設備號存儲變量格式，去除了冗余的信號變量定義，支持新的存儲驅動模式，利用OVERLAY2存儲驅動重新構建了龍芯Fedora28系統的鏡像倉庫和常用鏡像。評測結果表明，移植優化后的1.13版本Docker方案在龍芯平臺上表現良好，相比老版本Docker方案系統調用消耗降低了10%左右，進程通信相關性能提升了50%左右。

1 Docker技術

1.1 Docker架構演化

從發布至今，Docker這個基于Go語言開發，利用Linux Container技術的核心管理引擎受到越來越多的關注和應用。在2017年3月，Docker分為兩種版本：提供給個人開發者和小型團隊使用的社區版CE，以及提供收費服務的企業版EE。同時分離了Github上托管的源代碼倉庫，將原Docker項目改名為Moby，由Moby這個新的用于推進軟件容器化運動的開源項目組織與社區開發者共同維護[14]。雖然版本號的變化十分劇烈，但是Docker 17.03+版本的接口仍然沿用1.13+并完全兼容。

Docker早期的架構是簡單的Client-Server架構，通過TCP或UNIX套接字向在Host上運行的Daemon守護進程發送請求命令獲取服務。

之后在1.10版本時推出了Libcontainer模塊，將底層實現都抽象化到Libcontainer的接口上，使得底層容器的實現變為一種可控方案。2015年6月，OCI(Open Container Initiative)組織成立以實現開放容器的標準化，主要包括容器運行時標準(Runtime Spec)和容器景象標準(Image Spec)。因此為適應OCI開放容器標準，Docker容器的運行不再是簡單地由容器守護進程Daemon來啟動，而是通過Dockerd集成Containerd、Runc等多個組件來實現容器的啟動，Daemon進程在不斷地重構過程中功能漸漸拆分細化，被分配到了各個單獨的模塊中，如圖1所示。

圖1 容器運行時各組件間關系

Dockerd以Engine API(REST)的方式對外提供服務，將所有對于容器的創建和運行等操作都通過GRPC協議發送給Containerd來完成。Containerd收到容器發送的請求后，進行初始化然后啟動Containerd-Shim進程，并傳送相關的配置參數給它。Containerd負責宿主機上所有運行的容器，而相應的一個Containerd-Shim則只管理一個運行的容器，使整個容器管理過程更為穩定高效。

1.2 Docker容器原理

Docker的底層實現機制是通過Namespaces(命名空間)、Control Groups(控制組)等技術來實現操作系統級的虛擬化機制。同時Docker需要一種文件系統作為Docker鏡像的存儲方式。

OVERLAY2是所有Linux發行版的首選存儲驅動程序。但以前的Ubuntu內核不支持OVERLAY2，因此使用AUFS作為存儲驅動，而龍芯平臺以前的Fedora21系統上是使用DEVICEMAPPER作為存儲驅動的，性能差且穩定性不好，因此Fedora28上支持了OVERLAY2存儲驅動。

OVERLAYFS其實是一種與AUFS類似的聯合文件系統UFS[15](Union Filesystem)，它將單個Linux主機上的兩個目錄(lowerdir和upperdir)合并成一個目錄(merged)。這些目錄稱之為層(layer)，而這個統一過程則被稱為聯合掛載(Union Mount)。其中，OVERLAYFS的底層目錄稱為Lowerdir，可以將其看作是只讀的鏡像層，用戶無法直接進行操作。而高層目錄稱為Upperdir，可以看作是可讀寫的容器層，當需要修改一個文件時，需要將文件從只讀的底層目錄拷貝到可寫的頂層目錄中進行修改，同時將修改結果保存在頂層目錄中。而合并統一視圖則稱為Merged，如圖2所示。

圖2 Docker構造映射到OVERLAYFS結構

當文件系統掛載后，用戶就可以在Merge目錄下看到來自不同底層目錄中的內容，也無須感知這些文件來自具體的哪一個目錄，并保證上層目錄屏蔽下層目錄的同名文件。

2 Docker方案移植與優化

由于MIPS體系結構與X86間的差異性，為了完成1.13版本Docker的移植過程，首先需要調整Docker的底層模塊結構以解決架構差異性問題，主要移植過程和優化內容包括：

(1) 對Docker的一些底層模塊添加MIPS架構入口。

(2) 針對Docker部分結構代碼，添加MIPS下的特有參數以實現Docker方案對MIPS的支持。

(3) 根據Fedora28系統新的4.19.5版本內核變化，重構Docker關于信號機制部分的結構。

(4) 采用OVERLAY2存儲驅動用以鏡像存儲。

然后設計評測方案對優化效果進行評測，硬件環境的龍芯計算機參數配置如表1所示。

表1 龍芯計算機參數表

2.1 Docker移植過程

不同架構平臺，移植過程中會出現很多差異性問題，所以首先需要解決Docker方案的平臺差異性問題，Docker底層的模塊函數針對不同的架構需要不同參數以便識別。

2.1.1添加SETNS調用的識別

Docker方案中引用SETNS調用以允許進程更改命名空間，但是調用參數SYS_SETNS并沒有MIPS架構的相關標識，因此針對SETNS調用部分的代碼需要添加MIPS架構識別入口。

Docker利用命名空間機制(Namespace)將內核的全局資源封裝，使各容器在各自命名空間中對同一種資源的應用不會互相干擾，其中的Netns被用于實現網絡、計算等資源的隔離。

在Linux內核3.0版本之后引入了一個新的系統調用SETNS以更好地處理命名空間的相關操作。Linux為其句柄中的許多資源支持不同的命名空間，例如Docker方案向虛擬化進程展示了一個不同于真實PID的虛擬PID，還有文件系統目錄結構、網絡資源、IPC等也可以這樣做。設置不同命名空間配置的唯一方法是在CLONE系統調用中使用不同的標識，但該系統調用無法執行允許一個進程訪問另一個進程的命名空間之類的操作，而SETNS調用解決了這個問題。因此移植過程中需要在netns_linux.go文件中添加MIPS架構識別入口：

var SYS_SETNS=map[string]uintptr{

"386": 346,

"amd64": 308,

……

"mips": 5303，

}[runtime.GOARCH]

2.1.2添加BoltDB的MIPS參數

Bolt是一個基于Go語言編寫的純粹Key/Value模型的項目。Bolt項目的目標是為那些不需要完整數據庫服務器的項目提供便捷、快速、可靠的數據庫。由于BoltDB的設計是源自LMDB，因此主要具有可以直接使用API進行數據的存取的特點，沒有像SQL一樣的查詢語句，而且沒有線程壓縮、垃圾回收和wal，而是直接將數據保存在內存映射的文件里。并且BoltDB支持完全可序列化的ACID事務，具有比LevelDB更強的特性，同時通過COW技術實現了無鎖的讀寫并發，但不能實現無鎖的寫寫并發，因此BoltDB更適合于讀多寫少的應用場景。

在Docker的底層結構里，BoltDB被應用于Containerd等組件的ID信息存取，由于BoltDB在Github上不再維護，因此目前Docker項目已經將BoltDB模塊合并到了Libnetwork當中，但是由于BoltDB在Docker的底層實現結構里與許多組件耦合度很強故無法刪除。Docker方案里BoltDB的函數文件需要為不同的架構平臺單獨定義兩個變量maxMapSize和maxAllocSize，分別表示Bolt支持的最大MMAP大小和創建數組指針時使用的大小兩個參數，1.6版本Docker方案添加了bolt_mips64le.go后設置的是：

const maxMapSize=0x3FFFFFFF

const maxAllocSize=0x7FFFFFFF

經過實際應用狀況的反饋并結合新的Feodra28系統我們需要設置一個合理的參數：

const maxMapSize=0x8000000000

const maxAllocSize=0x7FFFFFFF

2.1.3設備號存儲變量格式轉換

由于X86和龍芯Fedora28系統中使用了不同的設備號存儲變量格式，需要針對涉及相應變量引用部分的模塊代碼進行修改和重構。

Linux下的數據成員st_dev的值記錄了文件主次設備號的信息，而一些字符特殊設備和塊特殊設備還含有st_rdev的值，st_rdev包含了實際設備的設備號。主設備號可以區分擁有相同驅動程序的同一類設備，而次設備號則用于具體指向某一個設備以區分同一類型的不同設備。文件的主次設備號雖然是兩個信息，但全部包含于st_dev的值里，而st_dev的基本數據類型是dev_t，內核用dev_t類型來保存設備編號。在不同的架構下其實際占用的位數可能不盡相同，如X86下的dev_t是64位，默認編碼是MMMM Mmmm mmmM MMmm，8位表示主設備號，8位表示次設備號。而龍芯的Fedora28系統中使用了32位的dev_t，編碼為mmmM MMmm，3位表示主設備號，5位表示次設備號。

由于Docker方案默認使用64位無符號整型格式的變量rdev讀取設備號信息，所以為解決MIPS架構下的差異性，需要對rdev變量的格式進行轉換，在stat_linux.go文件中修改rdev：

func fromStatT(s*syscall.Stat_t)(*StatT,error){

return &StatT{size:s.Size,

……

rdev:uint64(s.Rdev)，

……

}}

2.2 Docker信號機制優化

每一個信號都有一個以SIG開始的獨特名字，但MIPS架構下的Fedora28系統與X86架構下存在大量的差異，即使是信號名字相同的信號在不同操作系統中的編號ID也不一致，而且許多信號在新的Fedora28系統里已不存在。因此在移植過程中結合新系統的特性優化Docker方案對信號機制的設計，去除在MIPS下冗余的信號。

首先是協處理器堆棧錯誤信號SIGSTKFLT，這個信號在新的Fedora28系統被去除。協處理器是一種協助中央處理器完成其無法執行或執行效率低下的處理工作而應用的處理器，在MIPS體系結構里能夠最多支持4個協處理器。在X86系統中有14個16位寄存器，這14個寄存器主要劃分為四類：通用寄存器、指令指針寄存器、標志寄存器和段寄存器。而在MIPS體系結構[16]里，寄存器要比X86多，達到了35個，其中有32個通用寄存器，兩個用于存儲整數乘除和累加操作的特殊功能寄存器和一個由特定指令直接操作的特殊功能程序計數器PC(program counter)，以及一個FPU寄存器。同時，在MIPS體系結構中協處理器CP0有32個寄存器，主要用于更好地控制CPU，實現MMU、乘除法或者異常處理等功能。

這個信號變量是一個在早期的Linux系統中存在的信號，用于數字協處理器的堆棧錯誤，在內核中并不會產生，但是為了系統的兼容性考慮在X86的系統中仍然被保留了下來。而在龍芯平臺的Fedora28系統中，由于架構的差異并出于標準化和穩定性的考量便去除了那些沒有價值的冗余信號。如今在MIPS中取代SIGSTKFLT信號作用的是SIGEMT信號。同時，由于平臺的差異性，在MIPS平臺下SIGUNUSED信號也變為了SIGSYS來表示系統的無效調用，Docker方案中使用SignalMap數組對應Linux信號的映射：

SignalMap=map[string]syscall.Signal

所以在移植過程中，根據不同平臺信號機制的不同，我們需要修改signal_linux.go文件中的SignalMap數組，刪除SIGSTKFLT和SIGUNUSED信號的映射"STKFLT"和"UNUSED"，同時設置64位MIPS系統下的SIGRTMAX參數為127。

2.3 Docker存儲驅動優化

Docker鏡像是由一系列的層(Layer)組成的，同時支持多種Graphdriver，如AUFS、DEVICEMAPPER、OVERLAY、OVERLAY2，而1.6版本的Docker方案由于Fedora21系統內核原因，無法支持當時主流的AUFS系統，因此采用了DEVICEMAPPER用作鏡像的存儲模式，而Fedora28系統內核滿足支持目前主流的OVERLAY2存儲驅動的要求。

在經過詳細的性能比較之后，確定OVERLAY和OVERLAY2兩種驅動的性能表現都比傳統的AUFS和DEVICEMAPPER強很多，因此Docker在移植方案中選擇OVERLAY2作為鏡像存儲的首選。

盡管OVERLAYFS十分優秀但當前仍不夠完美。由于OVERLAY是使用硬鏈接在層之間共享文件的，每一層都構建了一個完整的鏡像而增加了磁盤的Inode負擔，并且會由于系統對硬鏈接的限制在容器數量多至一定程度時出現問題，而增加文件系統可用Inode數量的唯一方法就是重新格式化。所以，OVERLAY2在鏡像層之間共享數據的方法改成了通過每層的lower文件，每一層都是完全獨立通過多層Lowerdir進行掛載。這種方法會消耗更少的磁盤Inode，但Inode的限制并未發生根本性改善，但是大量使用IF語句能夠對OVERLAY2有一定程度優化。同時由于OVERLAYFS的兼容性限制，OVERLAYFS僅能實現POSIX標準的子集，所以，如COPY操作等將違反POSIX標準，目前的解決方法是遷移到Upperdir層進行操作。還有關于系統調用Rename的問題，因為OVERLAYFS不完全支持此調用的緣故，暫時無法使用。

3 Docker評測方案設計

移植過后的1.13版本Docker方案需要一套便捷全面的評測方法來驗證新存儲驅動和信號機制的優化效果。故設計了兩個測試方案，設計方案一對比具體優化效果，設計方案二評測多容器數量下的穩定性。測試方案一，結合Unixbench工具在龍芯平臺上制作相關測試鏡像，然后分別對優化前后的Docker方案進行性能測試以對比優化的效果；測試方案二，利用方案一中的測試鏡像，測試容器數量對系統性能的影響。

3.1 Docker移植優化效果評測

首先對Docker方案的移植優化效果進行評測，因此設計測試方案一如下。

先分別在搭載Fedora21系統的龍芯單路主機上制作1.6版本Docker的測試鏡像和搭載Fedora28系統的龍芯單路主機上制作優化后的Docker方案的測試鏡像，鏡像中嵌入Unixbench測試工具，并設置好相關參數以便測試啟動。然后分別在搭載Fedora21系統和Fedora28系統的龍芯單路主機上利用測試工具進行基準性能測試，確認系統環境的狀態，各記為F21′和F28′；之后分別在Fedora21系統和Fedora28系統中啟動測試鏡像進行性能評測，測試結果分數分別記為F21和F28。為了減少誤差影響，兩個Docker方案的測試至少重復執行三次，性能數據結果取平均值為最終值，即每個測試項最終的測試數據結果Datai計算如下：

(1)

式中：Datai表示第i項性能測試數據的分數；xij表示第i項性能測試項第j次的數據結果。

最終測試數據如表2所示。

表2 Docker方案優化前后的性能測試數據表

續表2

然后為了驗證優化后的Docker方案對系統性能的影響，需要在不同容器的數量下進行測試。測試方案二如下。

記(Containers Numbers)容器編號為N時表示同時運行的N個測試容器進行測試，對每次測試至少重復執行三次以減少誤差帶來的影響，每項測試結果取所有數據結果的平均值為最終值，即每次最終的測試分數DataN計算如下：

(2)

式中：uij表示在N個容器同時運行情況下第j個容器第i次的測試數據。

最終測試數據如表3所示。

表3 不同容器數量下的性能測試數據表

3.2 性能測試數據分析

首先結合圖3(a)，能清晰地看見優化后的Docker方案整體性能分數F28是960.3，而優化前的Docker方案性能分數F21是920.3，綜合性能提高了5%左右。而且各個測試項數據來看，容器內的系統性能與宿主機操作系統不相上下，較傳統的虛擬化技術而言有明顯的優勢。

(a) 測試方案總分

(b) 進程通信相關測試分數1

(c) 進程通信相關測試分數2圖3 測試方案總分和進程通信相關測試分數

值得注意的是Pipe-based Context Switching(基于管道的上下文交互)測試，這個測試項測試了兩個進程每秒鐘通過一個管道交換一個不斷增長的整數的次數。從圖3(b)可以看到1.6版本Docker方案中容器內測試分數是374.4，而主機下的基準測試值是479.2，容器內測試程序運行效率約是主機環境下的78.13%，而優化后的Docker方案中，容器內測試分數為703.4，而主機環境下測試項分數是778.2，容器內測試程序運行效率約是主機環境下的90.39%，證明了優化后的Docker方案在進程間通信中的性能損失更少，同時可以看出優化后的Docker方案較之前的1.6版本性能提升較為明顯，在進程間通信測試項上性能比1.6版本提升了53.0%。

再根據System Call Overhead測試項分數變化，如圖3(c)所示。這一項測試通過反復調用getpid函數測試了進入和離開系統內核的代價，即一次系統調用的代價，測試分數越高說明系統調用消耗越小。可以看出來優化后的Docker方案較1.6版本Docker在系統調用測試項上性能更為優越。1.6版本Docker方案系統調用代價測試項的分數F21是1 073.2，而優化后的Docker方案測試項分數是1 201.5，優化后的Docker方案系統調用消耗測試項是1.6版本的89.32%，在系統調用的效率上提升了10%左右。

Dhrystone和Whetstone兩項測試是測試處理器運算能力的基準測試程序，可以看到優化后的Docker方案依然保證了容器內優秀的計算性能，CPU計算性能并沒有因為容器虛擬化方案而產生損耗。而且容器中的測試分數抖動更小，各項測試結果都比主機環境下更為穩定，由此表明容器的系統運行環境對于測試程序來說穩定性更高。

從表3可以發現，在同時運行N個容器的系統環境下，CPU計算性能測試項分數是線性下降而非曲線下降的，在同時運行四個測試容器時測試項分數是753.5，是單容器時測試分數的25.4%，由于單路主機是四核機器，所以這是符合預期的，說明優化后的Docker方案穩定可靠，不會出現由于資源搶占產生的額外性能損失。結合Whetstone測試分數的抖動頻率，更能驗證移植優化后的Docker方案不會對CPU計算性能產生太大影響。

4 結 語

本文完成了龍芯Fedora28系統上1.13版本Docker方案的移植，解決了一些平臺差異性問題，并優化了Docker方案映射的系統信號機制，對于鏡像文件應用了新的OVERLAY2存儲驅動，并設計了評測方案分析移植優化的效果。經過評測發現優化后的Docker方案在進程間通信的相關測試項中性能比1.6版本提升了53%，并且容器內測試程序的性能損耗更小，同時發現優化后的Docker方案系統調用消耗更小，降低了10%左右，而且優化后的Docker更加穩定。但是容器技術深深依賴內核特性的特點并未根本性改善，可以預測在高數量級下容器集群系統性能會產生很大損失，僅依賴內核特性進行資源管理是遠遠不夠的，所以下一步的研究將集中在MIPS架構下的容器集群模式構建和相關負載均衡策略與調度算法的設計上，并結合龍芯平臺的特殊性進一步研究MIPS架構下Docker方案的各個模塊的優化策略。