譯<容器網路中OVS-DPDK的效能>
本文來自對Performance of OVS-DPDK in Container Networks的翻譯。
概要——網路功能虛擬化(Network Function Virtualization,VFV)是一種突出的（prominent）技術,用虛擬化的網路軟體來代替傳統硬體網路節點。伴隨著軟體領域細分到微服務應用這一過程的發展，容器似乎(appear to)適應了應用程式的可靠性，可獲得性，可操作性。為了促進(facilitate)在高稠密(high-denisty)容器環境中IO密集(intensive)應用的發展，OVS和DPDK的聯合完美地增加了其效能指標。在本文中，我們在容器網路中設計與整合了OVS-DPDK，被寫為兩個案例。在第一個案例中，我們在一個物理機器中部署了兩個容器並且使用OVS-DPDK作為虛擬網橋來連線它們。在第二個案例中，我們在兩個物理機器上配置系統。然後我們測算(measure)吞吐量(throughput),CPU佔用率以及評估兩個案例中的OVS和OVS-DPDK。
關鍵詞——NFV, OVS, DPDK
1.Introduction
近些年，電信工業已經向網路功能虛擬化方向變革(evolve), 傳統的“硬體密集型(hardware heavy)”網路節點功能正被虛擬化的能跑在通用硬體(指x86架構晶片)上的軟體代替。當前的軟體虛擬化的實現(implementation)相比虛擬機器正在快速地朝向輕量級的容器[1]。原始的NFV意圖沿用軟體標準來部署，部署到虛擬機器中就稱作虛擬化網路功能(Virtualized Network Function, VNF)，部署到容器中就被稱作容器網路功能虛擬化(Containerized Network Function)。用高階的容器化技術，CNF能夠輕鬆地在不同的網路裝置上被建立，遷移(migrate)，備份和刪除，而不依賴特殊的軟體。
基於容器技術的快速發展，網路功能(像防火牆，路由器等)被分為許多叫做微服務的塊並且每個元件都被連線來建立一個服務功能鏈來代替已存在的大整塊(monolithic)應用。例如，領英在2011年用微服務代替了他們的大整塊應用，結果獲得了更少的複雜軟體並且更短的開發週期(shorter development cycles)。當前，容器網路面對許多挑戰去使用這個改變。高密集(high-density)容器會導致建立網路的延遲時間和容器啟動時間的消耗(The high-density container causes the latency time to establish its network and time-consuming to container launch time.)
網路功能虛擬化基礎設施(Network Function Virtualization Infrastructure)是重要的元件——虛擬交換機。虛擬交換機有在VM之間或者容器之間連線的功能。有許多中虛擬交換機，例如OpenVSwitch(OVS)[4], hyper-V 虛擬交換機[5]，OFSoftSwitch[6], Lagopus[7]等等。我們的實施基於OVS是因為它豐富的特性，多層次，分散式的虛擬交換被廣泛地用於主要網路層和其他的SDN應用。OVS傳統上已經被分到了一個快速的基於核心的資料路徑(datapath, 或者叫 fastpath), 該路徑基於流表(a flow table)和一個稍微慢一點的使用者空間資料路徑，該路徑處理在快速路徑中。 為了從使用者空間轉向快速路徑，英特爾已經整合了資料平面開發套件(DPDK)到OVS。
DPDK是一個框架，提供了有效的實施，在廣泛的一系列一般功能例如網路介面控制器(Network interface controller, NIC)包輸入輸出， 硬體功能的輕鬆訪問 (easy access to hardware features,例如 SR-IOV,FDIR)等，記憶體分配和佇列。與Linux網路棧比較起來而言，DPDK有突出的特性，那就是能夠繞過核心網路棧從而給使用者空間的應用帶來高效能。DPDK提供了資料平面庫，該庫優化了網路卡驅動，例如輪詢模式驅動(Polling Mode Drivers, PMD)用於高速處理，無鎖快取(lockless ring buffers), 大頁用於分配和管理記憶體。開發者能夠基於在應用中被打包的庫來得到高收益(high achievement)。
通過用DPDK與OVS整合，快速路徑也在使用者區，最大限度減少了核心與使用者空間的互動，同時充分利用了DPDK提供的高效能(By intergrating OVS with DPDK, the fastpath is also in userland, minimizing kernel to userland interactions as well as leveraging the high performance offered by DPDK.)。當前一些文章提到實施DPDK連線VM和VM來提高網路傳輸效能。在[8]中，作者發展了NetVM平臺，該平臺利用了DPDK的效能(capability)優勢來為"VNF鏈"獲得高效能吞吐。Wang, L.M, Miskell,T[9]使用了OVS-DPDK來抓取和轉發(transport)虛擬機器的流量。Yang,M.,和Huang,Y[10]比較了部署在物理機器上的OVS-DPDK和部署在Docker容器上的區別，試驗檯(testbed)環境測試了內部虛擬機器的吞吐效能。
在這篇文章中，我們聚焦了設計與整合了OVS-DPDK用於容器網路的兩個案例。在第一個案例中，我們在host中部署了容器並且使用OVS-DPDK作為虛擬網橋來連線它們(指容器)。在第二個案例中，我們在兩個host中部署了系統，然後我們測算了吞吐量，CPU使用率並且在兩個案例中評估OVS和OVS-DPDK。
II.背景
A.資料平面開發套件(Data Plane Development Kit)
DPDK意圖提供簡單的和完備的框架用於再資料平面應用中的快速資料包處理。它採取一種“執行時競爭模型用於包處理(run to completion model for packet processing)”, 意為著所有資源需要優先分配到呼叫資料平面應用。那些專用的資源被執行在了專用的邏輯處理核上。
該技術對應Linux核心，在核心中我們有排程和中斷用於切換程式，在DPDK架構中裝置進入是通過持續輪詢(polling)。這避免了上下文切換和過多的中斷而通過CPU和部分的100%佔用來處理資料包。
在實踐中，DPDK提供了一系列輪詢模式驅動(PMDs)，該驅動能夠使得資料包在使用者空間和物理介面之間直接轉發，繞過核心網路棧。該方法提供了重要效能促進核心轉發，通過減少中斷操作做和繞過核心棧。DPDK是一系列庫。於是，為了使用它們，你需要一個應用與這些庫連線以及與相關(relevant)API進行關聯。
B.OpenVSwitch
OVS 是一個軟體交換機，它使包在核心中轉發。它由使用者空間和核心空間兩部分組成:
- 使用者空間(User space) - 包括一個資料庫(ovsdb-server)和一個OVS守護程式(daemon)用於管理和控制交換機(ovs-switch)
- 核心空間 - 包括ovs核心模式對資料路徑或者轉發平臺負責。
OVS核心模式包含了簡單的流表用於轉發收到的資料包。仍然，一小部分的資料包被稱作例外的(exception)包(在Openflow流中的第一個包)並不匹配一個存在的入口(existing entry)在核心空間並且被髮送到使用者空間OVS守護者(ovs-vswitched)用於管理控制。守護者程式將會分析資料包然後更新OVS核心流表。因此流上額外的包將會直接通過OVS核心模式轉發表。該方法減少了使用者空間和核心空間絕大部分流量的上下文切換，然後我們仍然被Linux網路核心棧限制住,核心棧並沒有很好的與高速包轉發需求相適應。
C.整合DPDK到OVS
整合DPDK到OVS能夠大幅提高(leverage)PMD驅動和移動先前的OVS核心模組轉發表(OVS kernel module forwarding table)到使用者空間。此外，為了促進(boost up)網路容器，vhost-user/virtio-pmd架構被實施到ovs-dpdk。Vhost-user(後端)跑在host的使用者空間作為OVS-DPDK使用者空間應用的一部分。被提到的DPDK是一個庫，Vhost-user模組是庫中額外的API。OVS-DPDK是與庫和API關聯的實際應用。Virtio-pmd(前端)跑在容器上，它是使用特定CPU核以及無中斷高效能輪詢。對於一個跑在使用者空間的應用來說，要去消耗virtio-pmd 就也需要被連線到DPDK。圖1展示了這些元件整合到一起。
III.設計和實施
在這一節，我們設計實施了CNF和OVS-DPDK在兩個案例上並且評估他們。在第一個案例中，我們在host上部署了系統。第二個案例被部署到了兩個host上。然後，我們測試來從容器到容器的包轉發吞吐量，比較累OVS和OVS-DPDK之間的結果。
我們使用英特爾i5-6300(基礎頻率2.4GHz，超頻3.00GHz帶8執行緒)處理器，6GB記憶體，英特爾82540EM Gigabit 網路卡(1G/s)在每個host上。作業系統為Ubuntu16.04(核心4.4.0)。OVS(版本2.6.1)和DPDK(版本16.11.1)被使用在系統中。
A.Testbed on a single host
資料包被PKtgen[3]和IPerf[11]生成,pktgen是基於DPDK快速包處理框架, iperf是廣泛用於各種平臺上網路效能測算的工具。為了在容器網路中實施OVS-DPDK, 我們部署了兩個由Docker[2]和OVS-DPDK執行的在host使用者空間的容器。一個容器有功能產生流量，它被安裝了包生成工具。另一個(容器)抓包並且檢查效能。每秒鐘的吞吐量和CPU利用率被測算。圖2顯示了實驗結果。
圖3展示了OVS和OVS-DPDK的平均吞吐量。總體上，吞吐量隨著包尺寸增加而增加。OVS吞吐量的增加穩定地(steadily)從104到165Mbits/每秒，同時伴隨著包大小從64bytes到1518bytes。在64bytes, OVS-DPDK比OVS有更低的吞吐量因為資料包越小，CPU的消費更大。圖4展示了OVS-DPDK比OVS消耗更多的CPU佔用率。
B.多個host試驗
在第二個案例中，如圖5展示， OVS-DPDK和兩個容器被部署到兩個host中。在該案例中使用的測量單位(metric)與實驗1中使用的一樣。
圖6展示了部署在兩個host上的內部容器的平均吞吐量。總體上，在OVS和OVS-DPDK上的吞吐量都在增長。OVS的吞吐量是穩定增長的，從7到17Mbit/s，隨著包大小從64到1518byte。同時OVS-DPDK有明顯的吞吐量提升。隨著包從64bytes到1518bytes, 吞吐量從7到141Mbit/s。與host上的實驗相比，吞吐量有了明顯增加，因為與第二個案例相比，第一個案例中，所有的連線都被host上的虛擬裝置配置了，包沒有通過物理連線。
IV.結論
在兩個案例中，我們實施了OVS-DPDK用於內部容器網路。在第一個案例中，實驗部署在host上，使用了虛擬網路介面和虛擬交換機來連線容器。然而第二個案例用了兩個host給內部容器網路。兩個案例展示了DPDK相較於原始OVS的突出(outstanding)能力，但是DPDK比OVS更消耗CPU。
即使如此，OVS-DPDK也比原始的OVS具有更高效能，但是它仍然在總體上不是最好的。在未來工作中，我們將擴充套件和其他技術的實驗，例如DPDK與SRIOV和NUMA結合，SRIOV允許一個網路卡裝置分成多個網路卡裝置，NUMA用於CPU管理用來獲得內部容器網路的高速包處理。
ACKNOWLEDGMENT
(略)
REFERENCES
[1] Bernstein, David, “Containers and cloud: From lxc to docker to
kubernetes,” IEEE Cloud Computing 1.3, pp. 81-84, 2014.
[2] https://www.docker.com
[3] Olsson, Robert, “Pktgen the linux packet generator,” Proceedings of the
Linux Symposium, Ottawa, Canada, Vol. 2, 2005.
[4] http://www.openvswitch.org
[5] Hyper-V Virtual Switch project, https://docs.microsoft.com/enus/windows-server/virtualization/hyper-v-virtual-switch/hyper-v-virtualswitch
[6] OFSoftSwitch project, https://github.com/CPqD/ofsoftswitch13
[7] Lagopus switch project, http://www.lagopus.org
[8] Hwang, Jinho, K. K_ Ramakrishnan, and Timothy Wood, “NetVM: High
performance and flexible networking using virtualization on commodity
platforms,” IEEE Transactions on Network and Service Management 12.1
(2015): 34-47
[9] Wang, Liang-Min, et al, “OVS-DPDK Port Mirroring via NIC
Offloading,” NOMS 2020-2020 IEEE/IFIP Network Operations and
Management Symposium, IEEE, 2020.
[10] Yang, Muhui, and Yihua Huang, “OVS-DPDK with TSO feature running
under docker,” 2018 International Conference on Information
Networking (ICOIN). IEEE, 2018.
[11] Traffic generator, https://iperf.fr