基于SR-IOV 的Docker 網(wǎng)絡架構(gòu)研究

梁克會，董 龍，洪 華

（中國銀聯(lián)股份有限公司，上海 201201）

0 引言

Docker 是一個基于LXC（Linux Container）技術的開源容器引擎，具有跨平臺、移植性強和快速啟動等優(yōu)點［1］。開發(fā)人員可以使用Docker 打包應用程序并將所需的依賴項運行到便攜式容器中，使得每個Docker 應用都擁有獨立的CPU、存儲設備、內(nèi)存以及網(wǎng)絡空間。2014 年12 月，Docker 公司發(fā)布了基于Go 語言開發(fā)的原生態(tài)容器集群管理工具Swarm，用來對集群中的Docker 鏡像和容器進行統(tǒng)一的管理［2］。與Kubernetes 工具相比較，Swarm 可以滿足容器的在線擴縮容，尤其適合有狀態(tài)的容器管理［3］。Swarm 工具的發(fā)布促進了Docker 在集群中的運用，越來越多的公司利用Docker 和Swarm 工具部署私有的PaaS（平臺即服務），提供大規(guī)模基于容器的服務［4］。隨著越來越多的應用部署在Docker 容器中，對于Docker 網(wǎng)絡通信的需求也越發(fā)復雜［5］。目前Docker 支持的網(wǎng)絡架構(gòu)，在一個節(jié)點上部署多個容器時無法同時滿足網(wǎng)絡隔離、端口不沖突以及較好的性能和可管理性等目標，需要研究更加有效的架構(gòu)。

1 相關技術

1.1 Docker 網(wǎng)絡框架

Linux 內(nèi)核中提供6 種資源隔離技術，包括分時系統(tǒng)（UNIX Time-sharing System）命名空間，進程（process ID）命名空間，進程間通信（Inter-Process Communication）命名空間，掛載（mount）命名空間，網(wǎng)絡（network）命名空間和用戶（USER）命名空間。Docker 使用Linux 網(wǎng)絡命名空間作為網(wǎng)絡實現(xiàn)基礎，網(wǎng)絡命名空間主要提供了網(wǎng)絡資源的隔離，包括網(wǎng)絡設備、IPv4 和IPv6 協(xié)議棧、IP 路由表、防火墻等網(wǎng)絡資源。Docker 實現(xiàn)了4 種網(wǎng)絡模式滿足不同的場景，供用戶選擇［6］。

host 模式：容器和宿主機共用一個網(wǎng)絡命名空間，容器沒有獨立的網(wǎng)絡資源。這種方式可以很好的解決容器與外界的通信問題，但是沒有隔離性，同時還會引發(fā)網(wǎng)絡資源沖突。

container 模式：container 模式與host 模式類似，不同的是這種模式第二個容器共享另外一個容器的網(wǎng)絡命名空間，而不是宿主機的。這種模式同樣是降低了容器間網(wǎng)絡的隔離性，引發(fā)網(wǎng)絡資源沖突。

bridge 模式：容器默認的網(wǎng)絡模式，Docker 在啟動的時候會創(chuàng)建名稱為docker0 的網(wǎng)橋，然后使用虛擬設備接口（veth pair）連接到網(wǎng)橋上，這種模式下容器擁有獨立的網(wǎng)絡命名空間。容器會通過iptables NAT 將容器IP 地址映射出去，網(wǎng)橋負責轉(zhuǎn)發(fā)數(shù)據(jù)幀，使得容器通過宿主機與外界通信。Linux網(wǎng)橋使用靈活，是目前業(yè)界主流，但這種用軟件封裝的模式導致網(wǎng)絡性能下降，架構(gòu)復雜度高，出現(xiàn)問題排錯困難。

none 模式：容器擁有獨立的網(wǎng)絡命名空間，需要用戶為容器添加網(wǎng)卡、配置IP 地址、路由等信息。這種模式給了用戶最大的自由度，但是需要額外的網(wǎng)卡以及配置容器才能與外界通信。

1.2 SR-IOV 技術

SR-IOV 是PCI-SIG 定義的IO 設備硬件虛擬規(guī)范，是一種基于硬件的輔助虛擬化I／O 技術［7］。SR-IOV 標準允許在虛擬機或者容器之間高效共享PCIe（Peripheral Component Interconnect Express，快速外設組件互連）設備，并且是在硬件中實現(xiàn)的。SR-IOV 具有兩種功能：物理功能（Physical Function，PF）和虛擬功能（Virtual Function，VF），PF包含SR-IOV 功能結(jié)構(gòu)，用于管理SR-IOV 功能；PF是全功能的PCIe 功能，可以像其他任何PCIe 設備一樣進行發(fā)現(xiàn)、管理和處理。PF 擁有完全配置資源，可以用于配置或控制PCIe 設備。VF 是一種輕量級的PCIe 功能，擁有獨立的配置空間，并具有數(shù)據(jù)通信的關鍵設備資源，如數(shù)據(jù)緩沖區(qū)、DMA 通道等，非關鍵的設備資源則與其他VF 共享。

SR-IOV 是一種基于硬件的網(wǎng)卡虛擬化解決方案，VF 設備可以直接訪問寄存器，具有較好的性能和穩(wěn)定性［8］。同時SR-IOV 還能夠減少使用交換機數(shù)量、簡化布線工作，節(jié)省數(shù)據(jù)中心的成本和能耗［9］。SR-IOV 通過硬件輔助實現(xiàn)不同對象間數(shù)據(jù)隔離，提升數(shù)據(jù)安全保護級別。目前很多主流的中高端網(wǎng)卡都支持SR-IOV 技術，如Intel 82576 網(wǎng)卡、I350 網(wǎng)卡、82599 網(wǎng)卡、X540 網(wǎng)卡等。

2 基于SR-IOV 的Docker 網(wǎng)絡

Docker 實現(xiàn)的網(wǎng)絡模式都存在一定的問題，在數(shù)據(jù)庫等對隔離性、性能以及網(wǎng)絡延時等都敏感的場景無法大規(guī)模使用。文獻［10］提出將Macvlan 應用在Docker 中，彌補Docker 網(wǎng)絡本身功能缺陷，同時提升數(shù)據(jù)傳輸?shù)男剩且环N較好的Docker 網(wǎng)絡解決方案。Macvlan 是利用Linux 內(nèi)核實現(xiàn)的虛擬網(wǎng)絡設備，將物理網(wǎng)卡虛擬出多個虛擬網(wǎng)卡，并保證虛擬網(wǎng)卡都具有獨立的MAC 地址。當物理網(wǎng)卡接收到數(shù)據(jù)后，會根據(jù)MAC 地址，將其發(fā)送到相應的虛擬網(wǎng)卡上。Macvlan 優(yōu)點是性能優(yōu)異，因為無須端口映射或者額外橋接，可以直接通過主機接口（或者子接口）訪問容器接口［11］。但是Macvlan 的缺點是需要將網(wǎng)卡設置為混雜模式，混雜模式下采用以太網(wǎng)廣播信道爭用的方式，網(wǎng)卡將接收所有經(jīng)過的數(shù)據(jù)包，而不管是不是發(fā)送給自己的，并傳遞給上層應用，這很難被允許，尤其是在公有云的場景下。為解決上述問題，本文提出在Docker 網(wǎng)絡中使用SR-IOV 技術，為容器分配獨立的VF，并由用戶為容器配置地址，配置過程無需將網(wǎng)卡設置為混雜模式。

為滿足關鍵業(yè)務高可用和高性能的要求，通常服務器上通過兩塊或者多塊網(wǎng)卡進行綁定。綁定是一種linux 系統(tǒng)下的網(wǎng)卡綁定技術，可以把服務器上n個物理網(wǎng)卡在系統(tǒng)內(nèi)部抽象（綁定）成一個邏輯上的網(wǎng)卡，能夠提升網(wǎng)絡吞吐量、實現(xiàn)網(wǎng)絡冗余、負載等功能。

本文提出的基于SR-IOV 的Docker 網(wǎng)絡架構(gòu)如圖1 所示。宿主機兩塊物理網(wǎng)卡，分別連接AB兩路交換機，啟用SR-IOV 技術后虛擬出多個虛擬網(wǎng)卡。虛擬網(wǎng)卡命名以VF 開頭，數(shù)字中第一位代表物理網(wǎng)卡序號，后面數(shù)字代表VF 序號，如物理網(wǎng)卡1 的第一個VF 命名為VF11，物理網(wǎng)卡2 的第63個VF 命名為VF263。使用物理網(wǎng)卡1 和2 中對應序號的VF 進行綁定，通過抽象形成若干個邏輯bond 網(wǎng)卡，命名為cbond 和序號，如VF11 和VF21通過綁定后的邏輯網(wǎng)卡命名為cbond1。在容器調(diào)度階段為容器分配未使用的邏輯網(wǎng)卡，并且按照需求設置IP 地址以及VLAN ID。

圖1 基于SR-IOV 的容器網(wǎng)絡架構(gòu)Fig.1 Container network architecture base on SR-IOV

基于SR-IOV 的容器網(wǎng)絡配置包括宿主機SRIOV 功能啟用、網(wǎng)卡虛擬化、VF 雙網(wǎng)卡綁定以及容器配置虛擬化網(wǎng)卡過程，具體流程如下：

Step 1進入BIOS 設置，找到Advance -＞PCI Subsystem -＞SR-IOV Support 選項，選擇Enabled，啟用SR-IOV 功能。同時找到Advanced-secure Virtual Machine Mode，選擇為Enabled，啟動VT-d 技術；

Step 2進入ESXi 硬件配置頁面，找到需要進行配置的SR-IOV 網(wǎng)卡，設置Virtual functions 數(shù)量為64，保存配置之后重新啟動；

Step 3找到需要虛擬化的網(wǎng)卡eth0，執(zhí)行：echo 63 ＞／sys／class／net／eth0／device／sriov_numvfs，虛擬出63 個VF，并按照命名規(guī)則對VF 進行命名。如果有多塊物理網(wǎng)卡，依次執(zhí)行網(wǎng)卡虛擬化；

Step 4執(zhí)行雙網(wǎng)卡綁定，將不同物理網(wǎng)卡虛擬化的VF 進行bond，采用負載均衡模式；

Step 5容器創(chuàng)建時設置網(wǎng)絡模式為none。如創(chuàng)建一個mysql 數(shù)據(jù)庫容器，并且容器網(wǎng)絡模式設置為node，則執(zhí)行：docker run --name mysql -d mysql：5.7.19 --net＝none；

Step 6根據(jù)上一步驟創(chuàng)建的容器ID 號，為容器配置一個邏輯網(wǎng)卡，命令如下：ip link set cbond1 netns ＄container_id。同時將這個邏輯設備在容器內(nèi)進行重命名，執(zhí)行命令如下：ip netns exec＄container_id ip link set cbond1 name eth0；

Step 7對于容器內(nèi)的網(wǎng)絡設備配置ip 地址，執(zhí)行命令如下：ip netns exec ＄container_id ip addr add ipv4／ipv4_prefix dev eth0，如果需要配置IPv6 地址方法類似，此處不在贅述。

3 實驗與結(jié)論

3.1 實驗環(huán)境

本文實驗采用Intel Xeon Gold 5118，CPU 主頻2.3 GHz，內(nèi)存256 GB，內(nèi)存頻率1333 MHz，配置2塊Intel 82599 10-Gigabit 網(wǎng)卡。使用3 臺服務器搭建一個Swarm 集群，驗證本文提出的容器網(wǎng)絡方案可行性以及性能；操作系統(tǒng)版本為CentOS 7.5，Swarm版本為1.2.9，Docker 版本為1.13.1，3 臺服務器中一臺為Swarm 管理節(jié)點，其余兩臺為工作節(jié)點。

3.2 實驗結(jié)果與分析

通過實驗環(huán)境驗證，使用本方案可以為容器配置不同的邏輯網(wǎng)卡，實現(xiàn)為容器配置獨立的網(wǎng)絡。同時在關閉網(wǎng)卡混雜模式的情況下，實現(xiàn)容器間網(wǎng)絡隔離，方案可行。

為模擬真實的業(yè)務場景，驗證容器跨服務器訪問的網(wǎng)絡性能，使用本方案在兩個工作節(jié)點各創(chuàng)建5 個容器，并為容器配置不同的IP 地址和vlan id。在容器中運行iperf3 網(wǎng)絡性能評測工具，針對TCP或UDP 的傳輸，測試其網(wǎng)絡性能。測試中將其中1個容器定義為iperf3 服務端，其余的容器定義為iperf3 客戶端。通過客戶端向服務端發(fā)送大小不同的數(shù)據(jù)包，測試其TCP 吞吐量（Throughput）、UDP網(wǎng)絡延遲（Latency）和UDP 丟包率（Packet loss rate），并以此為依據(jù)進行網(wǎng)絡性能的測定并與物理網(wǎng)卡（NIC）以及macvlan 方案進行對比。

3 種網(wǎng)絡方案TCP 吞吐量實驗結(jié)果如圖2 所示，可以看到SR-IOV 方案在不同消息窗口大小場景下與物理網(wǎng)卡和macvlan 具有基本相同的吞吐量。隨著消息窗口增大，吞吐量不斷增加。當消息窗口為80 K 時，基本到達網(wǎng)卡流量上限。

圖2 3 種網(wǎng)絡方案TCP 吞吐量實驗結(jié)果Fig.2 Experimental Results of TCP Throughput of Three Network Schemes

3 種網(wǎng)絡方案UDP 網(wǎng)絡時延實驗結(jié)果如圖3所示，SR-IOV 方案在不同的讀寫緩沖區(qū)大小的場景下與物理網(wǎng)卡和macvlan 具有基本相同時延，并且隨著讀寫緩沖區(qū)增加時延不斷增加，當讀寫緩沖區(qū)大小為32 K 時時延在28 μs 左右。

圖3 3 種網(wǎng)絡方案UDP 時延實驗結(jié)果Fig.3 Experimental Results of UDP legacy of Three Network Schemes

3 種網(wǎng)絡方案UDP 網(wǎng)絡丟包率實驗結(jié)果如圖4所示，SR-IOV 和macvlan 兩種方案具有基本相同的丟包率，都在2‰左右，比物理網(wǎng)卡丟包率稍高。

圖4 3 種網(wǎng)絡方案UDP 丟包率實驗結(jié)果Fig.4 Experimental results of UDP packet loss rate of three network schemes

4 結(jié)束語

本文提出基于SR-IOV 的Docker 網(wǎng)絡架構(gòu)，能夠解決容器網(wǎng)絡面臨無法通訊、無法隔離、性能差和管理復雜等難題，也能解決Macvlan 方案中將網(wǎng)卡設置為混雜模式的問題，并且基于硬件虛擬化的SRIOV 技術也具備較好的穩(wěn)定性，適合應用在大規(guī)模、對網(wǎng)絡敏感的容器集群。當然SR-IOV 技術也存在一定的不足，主要表現(xiàn)SR-IOV 需要軟硬件的支持，對于存量不支持SR-IOV 的設備無法利用這項功能。另外，目前物理網(wǎng)卡能夠虛擬出來VF 數(shù)量有限，一般萬兆網(wǎng)卡能夠虛擬出63 個VF，但是在一些無狀態(tài)應用場景下，單個服務器上部署大量容器，可能出現(xiàn)VF 數(shù)量不足等情況。如何結(jié)合其它網(wǎng)絡方案，比如VXLAN（Virtual Extensible LAN）或者在服務器上配置更多支持SR-IOV 網(wǎng)卡，滿足單臺服務器上部署大量容器場景，這是后續(xù)需要研究的課題。