2013 年 Intel 将 DPDK 以 BSD 开源方式分享出来,同年 4 月,6wind 联合其他开发者成立 DPDK 开源社区,DPDK 是一组快速处理数据包的开发平台及接口,运行于 Intel X86 平台上 (现已支持 PowerPC)。2017 年 6 月 27 日,由 DPDK 社区和英特尔联合主办的 DPDK 中国技术峰会在上海虹桥万豪酒店顺利举行,来自 DPDK 上下游生态链的约 300 位从业者参加了峰会。云杉网络系统平台研发总监王凯在峰会上分享了《云数据中心网络监控与安全技术实践》,以下是分享内容。
先给大家讲个笑话。从前有个愚公,他家门口有太行、王屋两座大山,所以一直以来他家的 4G 和 WiFi 信号都不是很好,这就导致他每天下班回家后远程办公的效率不高。因此愚公决定把这两座大山挖掉,一劳永逸地解决问题,并立即开始行动。有一天挖山的时候被河曲智叟碰到了,智叟就问他说,你这样挖山,猴年马月才能挖得完呢?愚公说,我挖不完我儿子挖,儿子挖不完孙子挖,子子孙孙无穷匮也。智叟怔了一下,然后反问了一句,你有女朋友吗?愚公一听,默默地扔下铁锹走了。其实讲这个笑话,也为了告诉大家,在大家忙于攻坚工程和性能等问题的时候,也要适当考虑一下个人的终身大事:)
我来自云杉网络,我们是国内最早专注于 SDN 的技术团队。今天要说的是《云数据中心的网络监控与安全技术实践》,题目有点长也稍微有点大,但其实要讲的核心还是 SDN 和 DPDK,侧重于 DPDK 技术在新的应用场景下的实践。
云化环境带给网络极大的复杂性
数据中心的出现,主要目的在于整合 IT 资源,提高 IT 资源的利用率。而云计算是一种按需分配 IT 资源的新模式,其依赖的虚拟化技术,则通过一虚多的方式进一步提高硬件资源的利用率,因此现在的传统数据中心正在纷纷进行云化。云化带来的结果是租户随时可以按需购买、动态扩展相应的资源规模,而相应的租户网络也需要随之动态变化,这对云数据中心的网络运维提出了非常高的要求。SDN 的出现恰到好处地应对了这个挑战,SDN 通过分离控制面和数据面,能够集中地对云数据中心的网络进行灵活细粒度的管理和控制。但是 SDN 技术的引入,也带来了一些新的问题。
(点击放大图像)
- 虽然软件定义解决了动态组网的问题,但是网络逻辑变得更复杂了。因为网络虚拟化之后,物理网络之上还多了一层虚拟化的网络,网络的逻辑拓扑随着租户规模增长、资源动态变更而愈发复杂化。这个时候一旦出现网络故障,很难快速地发现并定位问题。
- 另外一个挑战是监控方面。传统的 Netflow、sFlow、IPFIX 等网络监控方案是基于采样的,在性能上有缺陷。在 OVS 里集成的这些技术是基于 Per-packet 中断和 netlink 上报实现的,性能上有瓶颈而无法满足云网监控的需求;另外它支持的域也是有限的,对于虚拟化网络来说,很多关键的以及感兴趣的网络数据它都没有。
- 第三个缺陷是对虚拟化的网络分析是不充分的。首先它没法按需进行灵活的、细粒度的数据采集,传统网络只需要五元组数据就可以了,而虚拟化网络里的租户五元组信息可能是一样的;传统网络的控制和转发没有剥离,我们无法通过控制面来定义要采集什么样的流量;对流的描述方式还是传统的五元组,没法描述虚拟化网络里多元组信息,比如带 tunnel 封装的和带 VLAN 封装的信息,因为相同 IP 对应的可能是不同的租户。对于 Overlay 的一些包和 IP 分片的处理也有局限。
- 此外,虚拟化使得云数据中心网络的物理边界消失了。原来基于物理边界的南北向安全防护,一旦通过租户授权绕过,那么内网之间就是无安全防护的。因此在云数据中心,内网节点之间应该是零信任的。
简化,是网络虚拟化及 SDN 之后的根本诉求
针对上面的这些挑战,我们首先给出的是一个网络监控的解决方案。对于云数据中心我们分别对其物理网络和虚拟网络进行了流量的采集、分析和可视化。物理网络一般采取分光和端口镜像的方式将流量送到我们的分析集群去分析。对于虚拟网络我们是通过 SDN 的方式用 OVS 把流量先导入到我们的采集器中,在采集器中完成网络流量的采集,然后将采集到的网络数据再导入到后端的分析集群。最终通过控制器进行可视化呈现,控制器部分主要负责应用可视化以及数据的采集和分析策略的下发。
(点击放大图像)
在安全防护方面,我们提出的解决方案是,首先通过导流将虚拟化网络中流量引到安全资源池中,通过安全服务链的编排,用SDN 的方式实现任意节点之间访问的安全防护。
上述两个解决方案中性能的挑战一个是在采集器部分,一个是在分析节点部分,安全部分主要是VNF 的处理。
利用数据和控制技术,导演这场“简化”之旅
我们的方案有这样一个演变历史,一开始我们对虚拟化网络的采集监控是通过部署在Hypervisor 上的DFI(Deep Flow Inspection)探针实现,这个是利用了OVS 的技术,我们在OVS 中去捕获所需要的Overlay 的流量。DFI 探针分为Kernel 模块和用户态的Agent,我们在OVS 本身的基础上扩展了一个DFI 的Action,将流量通过OVS Action 导给我们的DFI 探针处理来完成流量的采集。因为内核模块可以动态加载和移除,所以其采集的字段可以灵活地扩展,从而实现了弹性字段的流量采集和发送。但是这种方式对用户来说是一种侵入式的部署,一方面部署时需要更新用户平台上的OVS,一般用户是不大愿意接受这种修改的。另外一方面这个方案有内核部分的实现,用户会认为有安全风险。
所以我们改进了上述方案,基于虚拟机来部署DFI 探针。其实相当于把我们前面在Hypervisor 上实现方案移到虚拟机中去,再通过OVS 镜像或者通过流表的方式将虚拟化网络里的流量导给虚拟机,在虚拟机里面完成我们的流量采集。但这里有一个显而易见的问题,就是在虚拟机里面进行采集的话性能会有瓶颈。
DPDK,应用于网络数据采集和分析
因此我们想到了借助 DPDK,这也是我们现在正在做的方案,我们要利用的就是 OVS-DPDK。其实我们的目标并不是要把虚拟机的性能全部发挥出来,而是想通过 DPDK 提高包的处理效率。因为在客户的云平台上,业务是最重要的,监控是作为辅助,当出现问题的时候能帮助用户定位问题。因此,监控是不能影响业务的,毕竟业务是卖钱的,所以客户的要求一般是对业务的影响要尽可能小。我们采用 DPDK 的目的就是把虚拟机里的计算资源尽可能多的利用起来。我们利用了 OVS-DPDK 中基于流会话处理的 Conntrack 模块,实现了不同层次的流量数据采集功能,比如 ACL(按需采集)、Flow generation(比 Netflow 采集的更全面)、包头的采集和压缩(有客户需求)、DPI(基于包粒度的处理)、NPB(将数据分发给第三方分析工具去处理)等等。
这么做带来的好处除了高效,就是更加灵活。另外由于没有内核的部分,所以 debug 起来更容易。不但能解决虚拟化网络的采集性能问题,也能在物理网络的南北向流量镜像到我们的分析集群时采用。
另外我们还进一步做了一些优化方案。一个是通过多队列和对称 RSS 先把流量分摊给 OVS 的不同 PMD 进行并行处理,另外就是 OVS-DPDK 中实现的 Conntrack 是集中式的,我们对其做了并行化的处理。另外熟悉 OVS 的人都知道,OVS 中有个快速通道和慢速通道,我们也在对快速通道中的 dpcls 算法进行优化。OVS 的设计注重在 Hypervisor 上用尽可能少的资源实现转发的功能,而我们要考虑的是如何基于 OVS-DPDK 提高采集的性能,并且我们不存在 OVS 用于转发时那么频繁的流表更新,所以我们可以通过牺牲一定的控制面策略更新的效率来提高转发面 dpcls 的性能。另外我们还借助英特尔 vTune 工具来帮助我们分析性能的瓶颈以进一步优化。
在分析层面,我们的分析集群是一个分布式的集群,用 Storm 做一些实时的安全分析处理,比如一些 DDoS、端口扫描,异常登录分析等。同时我们也基于一些安全模型用 Spark 做离线的分析。另外,我们还通过 ElasticSearch、Kibana 实现采集及分析数据的分布式存储和可视化展示。不仅如此,通过 NPB,我们可以将指定流量分发给第三方分析工具进行相应分析处理,比如 SQLUIL 等。
构建分析与安全的闭环,实现 SDN 细粒度控制之目标
通过上述监控方案,可以总览云数据中心网络存在的问题和安全风险。根据发现的问题和风险,通过进一步的分析我们可以快速定位问题根源。定位之后可以生成对应的安全策略,通过控制器下发到云环境中,通过 SDN 的控制,有安全风险的节点或区域的流量,会先经过我们的安全服务链进行处理以实现安全防护。
安全服务链已经很成熟了,基本上都是基于 VxLAN 做的。基于 VxLAN 来做有一个问题就是会增加 x86 服务器的负载,同时也影响转发的性能。安全服务链另外一个问题是缺乏可扩展性,此外 vSwitch 和 VNF 的性能也有问题。
(点击放大图像)
对于一般采用的VxLAN 的引流,我们的做法是用VLAN 替代,而把VxLAN offload 给ToR 交换机去做,其目的是为了保证多租户,并非引流。既然东西向流量那么大,为了实现性能的扩展,我们还引入了负载均衡机制。我们设置了一个伪节点,通过VLAN 引流将虚拟机的流量转发到伪节点,而伪节点上其实就是一组SDN 的负载均衡策略。负载均衡可以基于某个字段做掩码,使符合我们给定字段的流量转发到指定的安全服务节点(也就是不同服务链)中去。
针对VNF 每个节点的性能限制,我们借助DPDK 进行了优化。这部分内容有很多成熟的方案,前面的专家也都讲了不少,我就不再重复了。
(点击放大图像)
基于上面的方案,我们可以实现一个安全云的架构。基于这个安全云架构,可以对客户的云平台进行南北向流量的高性能可扩展防护,而不用堆硬件安全设备。
相关答疑
Q:问一下你们是怎么处理 OVS-DPDK 的虚拟机迁移问题的?
王凯:我刚才也在讲,这是我们正在做的事,目前还没有完成。另外,我们只是在自己的采集器里用到了 OVS-DPDK,外面是否用 OVS-DPDK 取决于用户云平台的状态,因此迁移对于我们采集器来说并不是问题。
Q:你们对 OVS 的快速通道的优化具体是什么样的优化?
王凯:其实是 OVS 里分三级查找,第一级是精确查找,当这里查找不到的时候会进行 dpcls 查找,也可以叫网包分类查找,如果再查找不到就会上升到控制面去查找流表或者控制器的策略。实际 OVS 处理中,查找主要集中在 dpcls 这,因此优化也是针对中间这层网包分类查找的算法。由于 OVS 上配置的流表策略是动态变化的,数据面生成的数据结构是随控制面下发的策略动态更新的,因而原来 OVS 使用 TSS(Tuple Space Search)算法主要是因为考虑到策略更新的效率,但代价是转发面的性能不够高。因此这里可以用更高性能包分类算法代替,比如 Hypersplit,充分针对策略规则进行分类性能优化,这方面有学术论文可以查阅。
作者简介
王凯,云杉网络研发部系统平台研发总监,清华大学信息技术研究院博士后。读书期间在 Elsevier Computer Communications、ACM SIGCOMM CCR、IEEE ICC、ICCCN 等国际期刊和学术会议上发表学术论文 6 篇,已申请国家发明专利 4 项。王凯主要从事网络安全、软件定义网络、数据中心网络虚拟化等算法和系统方面的研究工作。先后参与了国家 863 目标导向项目等国家级课题,以及 Intel- 清华、IBM 共享大学等企业联合研究项目。设计并实现了面向网络安全的高性能正则表达式匹配算法与系统 FREME,对于大规模复杂正则表达式攻击特征规则集合实现了高速网络入侵检测,获得了学术界和工业界的充分肯定。
感谢木环对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们。
评论