探索基于DPDK、Netflow的流量分析系统的容器化实现 / 黄成,黄亮,周浩波

本文选自《交易技术前沿》第二十九期 (2017年12月)
黄成1,黄亮2,周浩波2
1.上交所技术有限责任公司 上海 200120 chuang@sse.com.cn
2.东方证券股份有限公司 上海 200010

摘要:随着互联网和云计算的发展,企业的网络环境变得越来越复杂,而且这种复杂性在将来还会持续增加。本文将探索利用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、网络。

原文地址:上交所技术服务

发表评论

电子邮件地址不会被公开。 必填项已用*标注