探索基於DPDK、Netflow的流量分析系統的容器化實現/黃成，黃亮，周浩波
本文選自《交易技術前沿》第二十九期 （2017年12月）
摘要：隨著互聯網和雲計算的發展，企業的網路環境變得越來越複雜，而且這種複雜性在將來還會持續增加。本文將探索利用DPDK來實現高速網路流量分析，並通過容器技術實現快速部署。DPDK具有高性能的優勢，容器技術具有開銷小，部署快的優勢，目前主流的研究方向是綜合利用兩種技術的特點來實現NFV，本文所實現流量分析系統，也屬於該方嚮應用的一種。
關鍵字:DPDK、Docker、NFV、Netflow
Abstract:With the development of the Internet and cloud computing, the network environment of the enterprise is becoming more and more complex, and this complexity will continue to increase in the future.This paper will explore the use of DPDK to achieve high-speed network traffic analysis, and through the container technology to achieve rapid deployment. DPDK has the advantage of high performance, the container technology has the advantages of small cost, fast deployment, the current mainstream research direction is the use of two technology features to achieve NFV, the flow analysis system in this paper, also belongs to this direction of application.
Key words:DPDK、Docker、NFV、Netflow
0 前言
作為企業的IT管理人員，在這種複雜的網路環境下，如何能度量應用性能、網路流量可視化、快速定位故障，就變成了一個巨大的挑戰。網路流量分析工具可讓企業IT管理人員，快速了解企業網路和業務應用的實時狀態，提高資源的可視性，同時也可以幫助分析用戶體驗，是企業IT部門重要的工具之一[1]。在網路管理領域，網路流量分析是一個快速發展的細分市場。
本文的研究內容基於證券信息技術研究發展中心（上海）的結合容器技術的行業雲可行性方案研究課題，本文所探索的高速流量分析系統的容器化實現屬於課題研究的一部分。雲計算平台下的流量巨大、且數據訪問關係複雜。在這種基礎背景下構建流量分析系統，必須要解決掉以下問題：
1、能夠高速處理雲平台網路內部的大量數據，這個流量起碼在10G/每秒或更高，如何處理10G以及更高帶寬的流量，是分析系統必須解決的問題；
2、雲平台流量模型為東西向流量，這部分數據無法通過傳統網路設備的原生功能進行分析處理；
3、在雲平台上以虛機方式部署網路基礎服務系統存在開銷大、啟動慢、部署慢的問題，在雲平台逐漸出現虛機和容器融合的趨勢下，如何實現流量分析系統的容器化，也是必須解決的問題。
本文的後續章節，將帶著這些問題，逐步探索構容器化的高性能流量分析系統。
1 流量分析系統相關技術支持
1.1容器技術
雲計算平台是虛擬化技術應用的主要環境[2]，目前在虛擬化領域存在兩個發展方向:
1、一種是硬體虛擬化或平台虛擬化，可以在一台主機上創建多台虛擬機，這些虛機上執行的軟體、包括操作系統都與底層硬體資源分開[3]，比如一台Windows計算機完全可能承載一台Linux系統虛擬機。
2、一種就是容器技術，利用操作系統內核本身的隔離機制，運行多個獨立用戶空間實例。從較早以前的chroot機制開始，後續又誕生了Linux-VServer、OpenVZ、LXC、Docker等一系列技術。
1.2數據流量分析技術
在進行網路流量分析時，目前有三種技術實現：Flow-Base、Packet-Base、SNMP[4]。如圖1所示，一套基於雲平台的流量分析系統主要包含這各個部分：高速流量引擎、Netflow輸出器、分析和展現平台[5]。網路底層將雲平台網路數據通過埠鏡像的方式抓發給流量分析系統，數據包進入系統伺服器後，將由高速流量引擎進行數據抓包，並根據云平台的特性，進行數據過濾、數據包合法性、VxLAN包頭剝離等基本操作[6]。
圖1：流量分析系統架構圖
1.3流量處理引擎
目前通用伺服器架構下流量分析主流抓包引擎有libpcap和winpcap，其中winpcap用於windows平台，而libpcap應用於各種類Unix、Linux平台[7]。因winpcap基於windows平台[8]，當前容器在windows平台支持還較弱，暫時無需考慮。
Libpcap是類Unix平台上網路數據處理的介面庫，其實由BPF和Libpcap兩部分組成，只是因為日常程序開發只與Libpcap部分交換，因此通常都用Libpcap來統一稱呼該介面庫。BPF工作在操作系統內核態，抓取並過濾網路數據，Libpcap工作在用戶態[9]。
2 基於DPDK、Netflow的流量分析系統的容器化實現
2.1技術實現
DPDK與容器的結合，與普通應用程序容器化實現不同[10]，DPDK需要直接操作底層網卡，而且容器化的主要目的之一就是需要將底層網路硬體被多容器共享，所以目前DPDK容器化有以下兩種思路[11]：一種是利用硬體虛擬化SR-IOV實現，一種是利用OVS-DPDK[14]軟交換實現：
SR-IOV 技術是一種基於硬體的虛擬化解決方案，是將PCI功能分配到多個虛擬介面上，這樣多個虛機或容器就可以共享PCI設備資源[12]。最直接好處就是無需虛擬化層模擬硬體，而直接由PCI設備硬體提供支持，為每個虛擬介面提供獨立中斷、DMA[13]。一個支持SR-IOV的設備可以虛擬出多個介面，虛機和容器可以像物理介面一樣使用虛介面。優點是硬體實現虛擬化，系統開銷小，虛擬介面性能幾乎與物理介面性能一致。缺點是一般PCI設備能支持的虛擬介面數比較受限，比如Intel 82599雙口10G網卡最多支持126個虛擬介面[14]。
OVS-DPDK是OVS使用DPDK來實現數據轉發層，相比於原來傳統的OVS實現，轉發性能大幅提高。OVS-DPDK支持DPDK vHost User介面，虛擬機支持virtio驅動時，可關聯到OVS生成的dpdkvhostuser介面，而容器因為不具備獨立驅動程序，目前只有基於容器的DPDK應用可以使用該介面[15]。因為OVS具有靈活的交換機管控功能，比如安全策略、VLAN、VxLAN、OpenFlow、GRE等等，適用場景比較廣。缺點是OVS本身是一套完整的虛擬交換機系統，支持的功能也越來越多，OVS本身存在較大開銷，特別在線速流量場景，OVS性能存在瓶頸。
從兩種實現方式的技術特徵我們可以知道，OVS-DPDK更適用於需要在容器中實現高吞吐量、高並發量用戶側應用。SR-IOV方式適合用於構建網路服務類應用，比如防火牆、路由器、IPS等，相對而言，SR-IOV的特性更適合本文所述流量分析系統的實現[16]。
2.2效果測試
通過綜合分析，我們選擇DPDK作為分析系統的高速流量處理引擎；雲平台內部網路流量模型複雜，流量巨大，所以我們選擇Flow-Base的技術對流量進行會話信息統計；我們選擇容器來實現系統的部署，避免虛機開銷大、啟動慢的問題[17]。
另外，我們選擇利用ELK平台進行流量的分析和展現，ELK中Logstash自帶Netflow解析和展現模板，可直接支持Netflow v5/v9/IPFIX，展示效果示意圖2下：
圖2：ELK流量視圖展現
本文以DPDK、Netflow為基礎，探索實現了容器化的流量分析系統。整體系統的性能表現受制於底層流量處理框架和數據包到Netflow轉換能力這兩個方面，底層框架的處理能力比較容易度量，但是Netflow的轉換能力度量是非常繁瑣的過程，在不同流量環境下性能差別很大。有鑒於此，在本文實現過程中，以探索技術可行性作為目標，僅就DPDK底層處理能力進行了標準的RFC2544丟包測試，未安排進行業務流量壓力測試。
表1：E5-2620 CPU，Ubuntu 16.04，單核CPU場景DPDK轉發性能測試。
從表1的測試數據我們可以看出，DPDK在64位元組的流量環境下，DPDK可實現22.1Mpps/每秒的數據處理，關於DPDK相關更多性能測試包括，通過本次流量分析系統的實現，我們驗證了以下信息：
利用Docker Compose工具實現了整體系統的快速編譯、部署，驗證了基於DPDK系統的容器化可行性;
在筆者實際網路環境中（2.6G左右網路流量，每秒約5萬數據包），利用DPDK實現了高速流量分析，在Intel E5-2620 CPU、16G內存，僅利用單核CPU就實現的Netflow統計輸出;
在進行項目研究的過程中，我們也發現DPDK與容器技術結合存在這些問題：
宿主機底層硬體訪問，本質是DPDK實現高速特性時，還是大量依賴底層硬體的特性，所以容器需要privileged授權才能訪問底層硬體，但這是否會引入新的安全風險，值得我們後續進行深入討論
因受網卡硬體資源限制，SR-IOV所支持虛擬介面數量有限的，這在一定程度上制約了宿主機所能提供的容器化NFV數量。
3 結語
在當前信息技術發展的環境下，雲計算以及容器技術的日益普及，上層應用的部署和開通變得越來越容易，網路流量模型也就變得越來越複雜。雲計算環境中的流量可視化分析，能給IT管理人員提供整體網路和業務的運行情況的視圖，這是實現流量分析系統的價值所在。本文僅探索了分析系統的容器化部署部分，鑒於雲平台的複雜性，要在雲計算平台中實現NFV還需要以下內容配合：
底層網路設備的設計是以數據轉發為目標的，流量的監控和分析並不是網路設備的主要任務，目前數據中心內部流量都通過交換機進行轉發，這部分流量無法無法通過交換機自帶的Flow-Base能力進行分析，這就需要通過第三方的流量分析方案來解決這個問題，本文的流量分析系統就屬於這種情況，這類系統都是通過交換機的流量鏡像功能，將流量複製一份傳遞給流量分析系統，進行後續處理。但這類系統應用的最大難點是需要為雲平台構架獨立的流量分析網路，否則鏡像流量在雲平台網路內部進行疊加傳輸，會為網路帶來極大的不確定因素，極端情況下可能影響網路穩定運行。
雲平台管理系統還有大量的工作需要完成，目前OpentStack的Tracker項目就是對ESTI所提出NFV框架中MANO平台的一種實現，隨著容器技術的發展，很多企業對於構架虛擬化和容器融合的雲平台越來越感興趣， 目前構架這種融合的雲計算平台還沒有統一的標準。所以目前比較可行的NFV實施方案仍是ESTI所提出的框架，NFV本身可以通過容器進行部署，但是生命周期的管控和調度還是利用MANO平台進行。
參考文獻
[1]曹建業,董永吉,冶曉隆,龔莉萍.基於NetFlow的流量統計系統的設計與實現[J].計算機工程與設計. 2014(02):20-22.
[2]周愛平,程光,郭曉軍.高速網路流量測量方法[J].軟體學報. 2014(01):114-115.
[3]劉德勝,黃芝平,唐貴林,劉純武.基於WinPcap的網路化測試通信層設計[J].自動化儀錶. 2012(07):51-53.
[4]王濤,余順爭.基於機器學習的網路流量分類研究進展[J].小型微型計算機系統. 2012(05):204-206.
[5]陳亮,龔儉.基於NetFlow記錄的高速應用流量分類方法[J].通信學報. 2012(01):44-46.
[6]趙寧,謝淑翠.基於dpdk的高效數據包捕獲技術分析與應用[J].計算機工程與科學. 2016(11):18-20.
[7]何佳偉,江舟.基於Intel DPDK的高性能網路安全審計方案設計[J].電子測試. 2016(Z1):117-119.
[8]張瑩,吳和生.面向多進程負載均衡的Hash演算法比較與分析[J].計算機工程. 2014(09):241-243.
[9]李彥君,鍾求喜,陳誠,陸華彪.多核平台入侵檢測系統負載均衡演算法設計與實現[J].計算機應用研究. 2012(04):37-39.
[10]梁偉,陳福才,李海濤.一種基於C4.5決策樹的VoIP流量識別方法[J].計算機應用研究. 2012(09):41-43.
[11]楊豐瑞,吳輝,張治中.基於DPI技術LTE-S1介面流量識別系統的設計與實現[J].重慶郵電大學學報(自然科學版). 2014(05):81-83.
[12]張棣興.下一代網路業務流量識別與控制的研究[J].電信網技術. 2006(11):118-119.
[13]肖玲玲,高林,張揚.基於DPI技術的VoIP流量識別[J].電腦知識與技術. 2013(27):74-76.
[14]丁要軍,蔡皖東,姚燁.基於UDP統計指印混合模型的VoIP流量識別方法[J].計算機科學. 2013(09):67-68.
[15]Myungjin Lee,Nick Duffield,Ramana Rao Kompella. Opportunistic flow-level latency estimation using consistent netflow[J] . IEEE/ACM Transactions on Networking (TON) . 2012 (1):654-667.
[16]Thomas M,Metcalf L,Spring J,et al.SiLK:A Tool Suite for Unsampled Network Flow Analysis at Scale. Proceedings of the2014IEEE International Congress on Big Data . 2014(6):1127-1137.
[17]TANG Lu,YAN JinLi,SUN ZhiGang,LI Tao,ZHANG MinXuan. Towards high-performance packet processing on commodity multi-cores: current issues and future directions[J]. Science China(Information Sciences). 2015(12):476-485.
作者簡介：
黃成（1983-），男，江蘇鹽城人，碩士，工作單位：上交所技術有限責任公司，主研方向為Docker、微服務、DevOps；
黃亮（1978.07-），男，四川人，本科，工作單位：東方證券股份有限公司，主研方向為Docker、網路；
周浩波（1973.12-），男，上海人，本科，東方證券股份有限公司工程師，主研方向為雲計算、Docker、網路。
--------------------------上海證券交易所為證券公司、基金管理公司等市場參與者及相關行業機構提供交易技術支持與服務，包括日常交易技術支持、技術交流研討、市場調查反饋、證券信息技術知識庫、測試等服務。
TAG:上交所技術服務 |