|
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，充分针对策略规则进行分类性能优化，这方面有学术论文可以查阅。 |
