基于網卡虛擬化的高性能容器網絡設計

臧迪，楊志剛，王晶，姚治成，張偉功

（1.首都師范大學信息工程學院，北京 100048；2.中國科學院計算技術研究所先進計算機系統研究中心，北京 100080；3.首都師范大學高可靠嵌入式系統技術北京市工程中心，北京 100048）

0 概述

云計算具有資源利用率高、靈活和部署便利等特點，因此，越來越多的企業逐漸從傳統模式過渡到云計算模式。然而，云計算需要數據中心做支撐，當數據包通過互聯網到達數據中心時，數據中心會采用防火墻、深度報文檢測、入侵檢測、網絡地址轉換等［1］技術對數據包進行處理。網絡中間件與Web 業務緊密耦合，能夠滿足運營商電信級的業務要求。隨著云平臺規模的不斷擴大，專用中間件的部署需求不斷增加，導致傳統軟硬一體化的封閉式結構功能單一、不靈活、價格昂貴的缺點逐漸顯現。然而，軟件定義網絡（Software Define Network，SDN）結合軟硬解耦原理對網絡功能進行虛擬化。這種網絡功能虛擬化（Network Function Virtualization，NFV）使得網絡架構更靈活、功能更豐富、價格更低廉，推動云計算平臺的發展，加快了容器技術、虛擬交換機技術和網卡虛擬化技術的成熟和推廣。

NFV 技術實現了軟硬件解耦，并且具有靈活的網絡部署和動態擴展的特點。傳統的NFV 平臺主要依靠虛擬機技術，基于虛擬機的NFV 架構能夠將空間資源隔離，具有較優的靈活性和按需分配性，但是虛擬機帶來的資源消耗較大［2］。例如，在NFV 開放平臺（OPNFV）［3］框架下，使用OpenStack 虛擬機技術與OpenDaylight 構建虛擬化基礎設施管理器，產生的資源消耗較大。

容器技術是一種基于內核命名空間的資源隔離技術，近年來，作為下一代虛擬化技術進入快速普及階段。由于容器技術沒有硬件損失，因此具有接近裸機的性能。此外，容器技術的啟動速度可以達到毫秒級，因此在資源利用率和靈活部署方面有很大優勢。采用容器技術構建虛擬網絡功能能夠有效解決資源開銷大的問題［4-5］。基于容器技術構建虛擬網絡功能通常采用Linux 自帶的橋接模式、overlay網絡或者虛擬交換機部署［6-7］。這種模式雖然可以實現流量轉發，但是在跨主機情況下，流量經過網卡需要兩次轉發，導致延遲敏感型應用產生較大的性能損失，并且CPU 的負載較大，導致帶寬下降。

本文提出目標感知的容器網絡用于NFV 長鏈場景。結合硬件虛擬化技術和軟件模擬技術判斷流量的目的地址，尋找最優的流量轉發路徑，優化NFV場景下經過每個業務節點的網絡延遲和吞吐量，同時利用基于腳本程序的自動化部署模塊對每個節點業務進行配置，便于用戶對網絡進行管理和修改。

1 相關工作

在NFV 部署中，NFV 服務鏈的優化技術和網絡I/O 虛擬化技術是影響網絡性能最直接的因素。

在NFV 服務鏈的優化技術方面，文獻［8］將整條服務鏈的網絡功能拆分成若干個子模塊，消除原有服務鏈中的冗余模塊，加快服務鏈的處理速度。文獻［9］通過拷貝、合并等方式對原有的串行處理且無依賴關系的網絡功能進行并行化包處理，優化整條服務鏈的延遲和吞吐量性能。文獻［10］提出IETF（Internet Engineering Task Force），在云數據中心通過優化虛擬網絡功能的調度完成時間來減少延遲。

現有的網絡I/O 虛擬化技術分為單根I/O 虛擬化（Single Root I/O Virtualization，SR-IOV）技術、軟件模擬虛擬化技術和網卡直通技術。SR-IOV 技術是由PCI-SIG 制定的輸入輸出虛擬化標準［11］，通過直接I/O 技術減少額外包復制帶來的性能損失，達到接近主機的性能。文獻［12］提出在標準X86 服務器上使用SR-IOV 技術部署虛擬化網絡功能，以達到提高吞吐量的目的。基于軟件模擬的網絡I/O 虛擬化技術又稱虛擬交換機技術。虛擬交換機技術的工作原理與物理交換機類似，其兩端分別連接著物理網卡和多塊虛擬網卡，同時虛擬交換機內部會維護一張映射表，根據MAC 地址尋找對應的虛擬機鏈路進而完成數據轉發。文獻［13］提出一種虛擬交換機開源軟件OpenVSwitch。文獻［14］對NFV 場景下虛擬交換機的性能進行評估與分析。網卡直通技術使用硬件輔助虛擬化技術，將宿主機中的物理PCI 設備直接分配給客戶機使用，客戶機以獨占方式訪問該宿主機的PCI/PCI-E 設備［15］。文獻［16］對X86 的網卡直通技術進行分析，指出物理網卡直通更容易受到“拒絕攻擊”，從而影響每個服務器的性能。由于網卡直通技術只能被一個虛擬機獨享，安全性也存在隱患，因此逐漸被單根虛擬化技術和軟件模擬虛擬化技術所取代。

單根I/O 虛擬化技術和軟件模擬虛擬化技術已成為主流技術，為容器提供網橋的功能。但是單根I/O虛擬化技術在主機內部傳輸方面比軟件模擬虛擬化技術性能差，而單根虛擬化技術在跨主機的性能要優于軟件模擬虛擬化技術。在NFV 長鏈的場景下，需要同時采用主機內部的傳輸和主機外部的傳輸，使用單一某種技術難以滿足NFV 長鏈場景的需求。針對上述問題，本文提出一種目標感知的容器網絡，通過優化SR-IOV 技術在NFV 場景下的性能，降低NFV 場景下網絡的延遲并且提高網絡吞吐量。

2 目標感知的容器網絡

目標感知的容器網絡設計方案主要是對硬件虛擬化進行改進。傳統的SR-IOV［17］技術是通過驅動把單一的物理網卡虛擬出獨立的虛擬網卡，并通過驅動將網卡劃分為多個地址段。SR-IOV 技術主要有虛擬功能（Virtualization Function，VF）和物理功能（Physical Function，PF）。SR-IOV 技術原理示意圖如圖1 所示。

圖1 SR-IOV 技術原理示意圖Fig.1 Schematic diagram of SR-IOV technology principle

SR-IOV 技術主要分為3 層，最底層是支持SR-IOV 技術的硬件網卡，中間層是操作系統內核，最上層是提供某種服務的容器。SR-IOV 技術的原理是網卡通過SR-IOV 技術虛擬出多個虛擬功能，虛擬出的VF 可以跨過操作系統內核直接分配給提供某種服務的容器，但是在NFV 級聯的場景下，單獨使用SR-IOV 技術會導致其性能下降，因此針對NFV場景，本文設計目標感知的容器網絡。

在NFV 場景下需要將各容器相互級聯，但是對于圖1 的設計，單獨使用SR-IOV 技術的網絡性能會出現瓶頸。因此，為解決SR-IOV 技術在NFV 場景下的性能瓶頸問題，本文提出目標感知的容器網絡，其結構如圖2 所示。

圖2 目標感知的容器網絡結構Fig.2 Structure of container network for target perception

該網絡結構的最頂層是使用容器技術把每個NFV 獨立應用分別放在不同的容器中，使得容器之間的應用相互隔離，如果需要某種應用，可以直接使用特定功能的容器鏡像，以便于維護，例如容器應用支持防火墻、深度包檢測、網絡地址轉換和負載均衡等功能。本文網絡利用SR-IOV 技術跨過操作系統內核，通過軟交換實現容器與容器之間的交互，因此在網卡流量發送到主機時需要判斷流量發送位置。當網卡跨過操作系統內核到容器的網絡中間件時，目標感知的容器網絡通過轉發模塊判斷目標的目的地址，通過目的地址判斷網絡流量的方向，之后提交給最頂層。

2.1 轉發模塊

目標感知的容器網絡結合網絡地址轉換（NAT）和OpenFlow［18-19］對轉發模塊進行設計，主要依據軟件虛擬技術實現流量轉發。OpenVSwitch 是目前主流的軟件模擬技術，它提供OpenFlow 協議并且OpenVSwitch 的轉發性能比Linux 下的網橋模式較優。因此，轉發模塊使用基于NAT 和OpenVSwitch的網絡設計實現流量的轉發。當前轉發分為單根虛擬化的虛擬網卡和OpenVSwitch 的虛擬網卡2 個方向。流量轉發會判斷發送的目的地址是否在NFV長鏈中，如果在NFV 長鏈中，轉發模塊將流量提交到上層并對數據包進行處理，例如深度包檢測或者負載均衡等服務，如果不在NFV 長鏈中，轉發模塊就會丟棄該流量。轉發模塊還可以根據用戶輸入的OpenFlow 語法更改路徑，使用戶調整轉發路徑，實現靈活轉發，即可以對容器的流量進行靈活規劃。

2.2 自動化部署模塊

本文網絡在原有的基礎上增加了軟件交換技術和轉發模塊配置，因此提高了部署的復雜性。為便于部署，本文使用基于腳本程序的自動化部署方案，無需手動干預，并且對每個節點業務進行配置。配置包括整體網絡框架配置、轉發模塊配置、網絡中間件設計以及服務節點設計。自動化部署序列圖如圖3 所示。

圖3 自動化部署序列圖Fig.3 Sequence diagram of automatic deployment

自動化部署模塊主要分為3 個部分：1）部署選擇，主要是配置容器環境以及虛擬交換機和單根虛擬化；2）部署的環境配置，當用戶啟動自動化部署模塊時，自動化部署會讓用戶選擇自動化部署模式，進而選擇中間件，例如容器提供的服務（防火墻服務、深度包檢測服務、負載均衡服務、網頁服務以及無服務等）；3）對轉發模塊進行配置，轉發模塊分為使用網絡地址轉換和使用OpenFlow 協議自定義轉換。轉發模塊配置完成之后，整體網絡實現自動化部署。

自動化部署模塊的整體架構如圖4 所示。從圖4 可以看出，最底層使用SR-IOV 技術生成虛擬網卡，應用層使用Docker 容器技術，系統內核層中的軟交換使用OpenVSwitch。自動化部署模塊能夠自動配置轉發模塊規則以及整體的網絡拓撲。

圖4 自動化部署模塊的整體架構Fig.4 Overall architecture of automatic deployment module

3 實驗與結果分析

3.1 實驗環境與配置

本文使用兩個測試工具，分別是對網絡性能進行測試的Netperf［20］和對請求數進行測試的Apache Benchmark，測試的內容為長鏈NFV 的網絡延遲帶寬和每秒請求數。

Web 服務器軟件Apache2 網頁應用和Haproxy［21］負載均衡應用主要是用于測試負載。Haproxy 具有較高的可用性和負載均衡能力，適用于負載大的Web 站點。

本文選擇Docker容器［22-23］，在容器中運行Netperf 網絡性能評測工具，主要針對TCP 或UDP 的傳輸，針對不同應用進行不同模式的網絡性能測試。軟件虛擬化使用開源OpenVSwitch，硬件虛擬化使用SR-IOV 技術。本文實驗的硬件環境采用型號Intel E5620 X2 和主頻2.4 GHz 的CPU，內存16 GB，內存頻率1 333 MHz，型號82599 和帶寬為10 Gb/s的網卡。

本文實驗的基本環境是使用2 臺服務器。每臺服務器有2 個主頻2.4 GHz 的E 5620 處理器，使用Intel 82599 網卡，選擇Centos 系統。

3.2 實驗設計

本文配置了SR-IOV 和OpenVSwitch 的實驗環境，并在容器中運行Netperf 應用、防火墻、Apache2網頁和Haproxy 負載均衡應用。目標感知的容器網絡拓撲結構如圖5 所示。

圖5 目標感知的容器網絡拓撲結構Fig.5 Topology structure of container network for target perception

在NFV 長鏈下，如果外部請求需要訪問Apache2 網頁，經過NAT、Haproxy、防火墻等一系列長鏈服務才能夠請求成功。在這種情景下，如果單獨使用SR-IOV 會存在一定的不足，但是目標感知的容器網絡可以解決這個問題。

當外部只訪問NFV 長鏈中的某一個應用時，本文網絡能夠解決OpenVSwitch 經過操作系統內核后性能降低的問題。

本文網絡主要使用內網轉發技術，在容器中增加兩個網卡，外部提供訪問的網卡使用SR-IOV 網卡，內部使用OpenVSwitch 網卡，通過內網轉發將OpenVSwitch 網卡相連接。從圖5 可以看出，當外部訪問時，在整個長鏈NFV 的請求中選擇一條最優的路徑。當外部請求NFV 長鏈中的某一項服務時，可以抽象為圖5 的網絡拓撲結構，這種情況通常出現在排查網絡故障和內部數據維護的時候。

3.3 實驗結果

首先搭建SR-IOV 與OpenVSwitch 的環境，分別在SR-IOV 和OpenVSwitch 環境下部署不同應用，使用Netperf 和Apache Benchmark 壓力測試工具進行精確測試并分析SR-IOV 的性能；然后部署SR-IOV與OpenVSwitch 混合策略，與未優化前的數據進行對比，在NFV 長鏈下，對目標感知容器網絡技術與單獨的SR-IOV 與OpenVSwitch 技術的性能進行對比。

在對外提供服務的場景中，網絡需要訪問NFV長鏈中的所有節點，以保證服務的安全性和完整性。

3.3.1 延遲測試

本文使用Netperf 測試工具分別測試SR-IOV 網絡、OpenVSwitch 網絡和本文網絡的延遲。每個實驗測試次數為10 次，最終結果為10 次的平均值，測試結果如圖6 所示。

圖6 NFV 長鏈下不同網絡的Netperf 延遲測試結果對比Fig.6 Netperf delay test results comparison among different networks in NFV long chain

從圖6 可以看出，在NFV 長鏈下，單獨使用SR-IOV 技術的網絡延遲為 9.745 ms，使 用OpenVSwitch 技術的網絡延遲為7.406 ms，使用本文技術得到的網絡延遲為7.637 ms。因此，本文網絡性能比單獨的SR-IOV 性能提高21.6%。在NFV 長鏈的應用場景中，OpenVSwitch 技術的延遲最優，本文網絡與OpenVSwitch 持平。

3.3.2 NFV 長鏈下每秒請求數測試

本文在NFV 長鏈應用場景下，使用Apache Benchmark 對SR-IOV、OpenVSwitch 和本文網絡進行請求數測試，測試結果如圖7 所示。

圖7 不同網絡的每秒請求數測試結果Fig.7 Test results of requests per second for different networks

從圖7 可以看出，在Apache Benchmark 的負載下，當本文訪問NFV 長鏈服務時，其請求數是每秒12 718 個，OpenVSwitch 網絡的每秒請求數12 812 個，SR-IOV 網絡的每秒請求數10 310 個。在NFV 長鏈的應用場景下，SR-IOV 的每秒請求數是最差的，本文網絡的每秒請求數與OpenVSwitch 持平，本文網絡比SR-IOV 性能提高了23.35%。

3.3.3 某一項服務延遲測試

在Netperf 負載下，不同網絡訪問NFV 長鏈中某一項服務的延遲對比如圖8 所示。

圖8 不同網絡訪問NFV 長鏈某一項服務的延遲對比Fig.8 Comparison of delay of accessing a service in NFV long chain by different networks

從圖8 可以看出，當訪問NFV 長鏈某一項服務時，SR-IOV 的延遲為1 983 μs，OpenVSwitch 的延遲為2 312 μs，本文網絡的延遲為1 964 μs。因此，當訪問單獨服務時，OpenVSwitch 的性能最差，本文網絡的性能與SR-IOV 的性能持平。

3.3.4 某一項服務的請求數測試

本文實驗對NFV 長鏈中單獨Apache2 服務進行請求數測試，測試結果如圖9 所示。

圖9 不同網絡的Apache2 服務請求數Fig.9 The number of Apache2 service requests of different networks

從圖9 可以看出，在Apache Benchmark 負載下，本文網絡訪問單獨服務的請求數是每秒50 937 個，OpenVSwitch 的每秒請求數是45 068 個，SR-IOV 的每秒請求數是50 132 個。本文在訪問單獨服務時與SR-IOV 的結果持平。

綜上可知，本文網絡在長鏈NFV 下的性能優于單獨使用SR-IOV 和OpenVSwitch 的性能，并且綜合OpenVSwitch 和SR-IOV 的優點。在長鏈NFV 中，本文網絡比SR-IOV 的性能提高約20%，在直通訪問時，本文網絡比軟件模擬網絡性能提高15%。

4 結束語

針對網絡功能虛擬化場景下網絡I/O 性能瓶頸，本文設計一種目標感知的高性能容器網絡，通過轉發模塊和基于腳本程序的自動化部署模塊，尋找最優的流量轉發路徑，并對每個節點進行業務配置，實現容器網絡流量的靈活轉發，便于用戶對網絡進行管理和修改。實驗結果表明，本文設計的容器網絡能夠有效提高NFV 長鏈場景下的網絡性能，為解決數據中心網絡I/O 虛擬化問題提供新思路。下一步將在單根I/O 虛擬化技術的基礎上增加OpenFlow 流量轉發規則，以提高平臺流量轉發的效率。