针对上面的这些挑战,我们首先给出的是一个网络监控的解决方案。对于云数据中心我们分别对其物理网络和虚拟网络进行了流量的采集、分析和可视化。物理网络一般采取分光和端口镜像的方式将流量送到我们的分析集群去分析。对于虚拟网络我们是通过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,这也是我们现在正在做的方案,我们要利用的就是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的控制,有安全风险的节点或区域的流量,会先经过我们的安全服务链进行处理以实现安全防护。
安全服务链已经很成熟了,基本上都是基于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,充分针对策略规则进行分类性能优化,这方面有学术论文可以查阅。
来源: http://www.infoq.com/cn/articles/cloud-data-center-network-and-security-technology-solutions