基于 Flow 的云网分析

在这几年和各个云的对接以及面向我们的客户、合作伙伴，帮他们解决网络故障检修以及提供网络的整体方案过程中，我们深切的感受到如果想给一个云提供一个高质量的 SLA 是非常不容易的。今天我们聚焦在一个很小的点，即如何用 flow 的技术去做网络的虚拟化、可视化并提高运维效率以及解决云的内网安全的问题。

业务云化的三大难题

图 1：云网络的拓扑结构

云的网络实际上是从传统的业务网络不断的向云端迁移和演进的过程。相比传统 IT 架构而言云非常大，要解决网络虚拟化必须引入 SDN、OpenFlow 或者各种比较复杂的技术。事实上，从逻辑上数据中心、云平台、租户网络是紧密耦合在一起的。举一个例子，两个 VM 的通讯有可能是在一个服务器内部，也有可能跨了机柜甚至数据中心等等，但是租户并不关心这个过程，他只关心网络的性能是否 OK、连接是否正常。但云的运维者必须非常了解这个过程，否则你就没有办法做 trouble shooting。

由于云规模的“大”随之而来的性能、高可用的难题便复现出来，具体表现为：

图 2：SDN 的关键因素

1. Scale 的问题：一般云的规模都会比较大，比如 100～200 个机柜左右。
2. VTEP 终结点：终结点在 Server/Tor 交换机上这会带来两个问题，性能和管理的问题。
3. 流量模型复杂：网络通信到底是二层还是三层，等等。

在长时间跟很多云沟通以后，大家形成了这样一个共识：在设计云的网络时，除了生产网络还应该考虑监控网络。

图 3：生产网络与监控网络

实际上监控网络后端的核心是一个分析平台，通过探针采集把云平台各种流包能够抓取过来，按照分析需求把采集到的流量导入相应的分析集群。但是不同的探针点在云平台里的部署难度是不一样的：

• 在南北向的接口做流量分光相对容易；
• 在接入层做做流量镜像 / 分光比较难。首先是架构设计上没有预留镜像的接口；其次做分光会引起业务中断，所以很难实施；
• 在 Open vSwitch 上引流会对租户网络性能有影响。

在我看来这是一个探针部署的问题，探针的部署应该是非侵入式的，最好是一个开源、开放的框架，这样 load 会比较轻。

云网分析的设计理念

那么从运维的角度来说，目前这样一个 Scale 比较大的网络分析的要求有哪些？

云网分析的需求

第一、可视化，这里面包括虚拟网络和物理网络。什么意思呢？就是不但能把租户的拓扑呈现出来，而且能把租户的流量映射到物理交换机上并做出关联分析、能做历史回溯，当有异常发生的时候立刻展现出来。

第二、扩展性。现在很多市场上的分析的产品，实际上就是一个分析能力有限的盒子，但是云的规模在不断扩大，堆盒子的做法显然是不可持续的，最好是一个弹性开放的架构；同时能和现有的很多分析工具结合在一起，而不需要自己开发。

第三、快速定位。从业务和运维的角度来讲，最重要的要把运维和业务的边界划分清楚。当别人告诉你出现问题的时候，你能迅速定位出来这是谁的问题。

第四、智能。所谓智能主要是一个自动化的呈现和报告。我们原来在设计的时候定了一个规格，大概能处理 10,000 个 IP ，但我们有一个 Scale 不大的金融行业客户的云里有 60,000 个 IP 超过 3000 个业务。在这样的一个场景里面，他的运维不可能把每一个业务都看一遍，他希望能够有一些智能的发现。另外，一些行为分析在做 DPI 的时候也需要智能的联动。

技术选型

在不改变原有生产网络的前提下部署监控网络的难点不一而足，具体到我们经历过的 Case 有以下四个方面需要重点考量。

1. 探针的选择，SFlow、Netflow/IPFIX、分光、镜像等各有优缺点。我们要考虑哪一种是最适合自己的。在云环境里当一个用户给你报障的时候，你需要快速定位出来，这个时间不能太长，否则用户会无法接受。
2. 数据的存储，云的流量非常大，尤其是东西向的流量。基础设施应该有能力做一些处理，再把流量送到后端。如果没有这种基础架构，现有的分析工具很难进行工作。
3. 多分析工具的支持，由于客户现有的业务和运维环境，我们不可能要求客户更改或重新开发相关的工具和插件，因此必须支持原有的分析工具。
4. 云感知与流量获取，在虚拟化环境里面资源经常在发生迁移，你怎么跟云的平台资源做联动，然后感知到目前问题发生的原因。

我们选择用 Flow 的方式来处理，根据我们的实践 Flow 做云网分析有较大的优势。并且我们通过分析从 Flow 中采集到的数据，发现很多有意思的事情。

• 轻量，Flow 只把五元组、连接状态、字节数、握手关闭、持续时间等信息，大概一个 Flow 有几百个字节。
• 适合行为分析，按需与 DPI 结合。
• 隐私安全，无需看用户数据。

用 Flow 做云网分析的过程中，一个很关键的技术点是探针。

软件定义探针

通过 SDN 的能力我们把智能探针（Traffic Intelligence）部署在生产网络中，使用 Flow 的技术我们能及时发现哪些流量有问题，一旦发现有问题便拎出它的包再放大——采用 DPI 分析。整个过程不看用户的 Payload 文件而只看 Packet “指纹”特征，这便是我们的 SDN。

图 4：软件架构"

这个是我们的一个软件架构，最底层是 Flow 的采集，这其中有一个缓存，在上面是数据关联，实际上数据从采集一直到展示出来是一个层层处理的过程。当数据处理到达 Elastic Search 以后，我们对上提供 Restful API，这样用户自己可以开发应用或者第三方的合作伙伴一起开发应用，从而更好地利用我们的分析结果。

说了这么多，还是举个例子证明一下吧。首先是我们与合作伙伴对上海一家客户几个月的 Flow 数据做了点分析。

图 5：内网分析

在这些 Flow 数据上做了大概 22 种攻击流量建模，得出来的其中一个结果就是这样。这个图下半部分大家能看到红线的数据是 0、蓝线是有数值的，这股流量只进不出，说明这是网络攻击。大家再对比一下这幅图中间部分的正常流量曲线数据，实际上底部所示的攻击流量是非常的小。这其实更说明了我们 Flow 分析的价值，因为在一个云的内部网络流量非常大，而我们能从如此巨大的流量（上百 G）中发现细微的流量（几个包、1000 多个字节）异常。经过我们这么一查，用户的问题就找到了。

图 6：外网攻击

绿盟基于我们的分析平台把各种安全模型全部统计出来，最典型的像检测 DDOS 攻击和恶意扫描。但是这两种攻击是完全不一样。DDOS 攻击流量大很容易被发现，而恶意扫描通常都是非常小的一个包，比如一个云网络里面有三台虚拟机给每个人的远程桌面（3389 端口）发了一个包，虽然只有三个包，但是这种行为很恶劣，在这种情况下把它检测出来其实难度还是比较大的。

作者简介

张天鹏，云杉网络（ http://www.yunshan.net.cn ）联合创始人兼 CTO，负责公司的产品和技术研发工作，曾任美国 Juniper 公司高级研发经理，负责当时世界最大防火墙 SRX 的研发。专注于 SDN、NFV 和云计算领域的相关产品和技术，对于 SDN 在云计算业务中的实施和应用有丰富的经验。

感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。