DeepFlow®网络全景图 打开云数据中心网络流量的黑盒

【本文是云杉网络研发总监向阳在2019北京SDN/NFV/AI大会上的演讲】

今天论坛的主题是人工智能和自动化，我想和大家分享一下我们在虚拟网络监控与分析领域的一些思考。人工智能和自动化的前提是要有数据，当我们有了相关的数据之后，这个智能化的系统才能去做一些决策。那么，对于数据中心虚拟网络来说，这些数据又来自哪里呢？

云数据中心网络东西向流量成黑盒

近年来数据中心流量的变化有一些特征，来自思科的数据显示，到2020年，数据中心内部东西向网络流量占到了77%，再加上数据中心之间的（例如灾备场景下，同城的光纤）流量，我们可以认为这也是东西向的，那么数据中心东西向流量占比高达86%之多，因此我们可以说，东西向流量已经成为数据中心的主角。

通常一个数据中心云网络规模的流量是TB级别，出口流量低1~2个数量级。另外一个数据是，数据中心在不断云化，思科预计2015~2020年数据中心流量会翻两番。如果我们把数据中心分为传统数据中心和云化的数据中心（包括虚拟化环境、微服务环境、自服务环境），思科对此的预测是云化数据中心的流量是占全球数据中心总流量的92%，这是一个非常大的数字。这时带来的问题是，对数据中心流量的采集，传统的分光/镜像/采样（sFlow、NetFlow等）的方法，其缺点是只能覆盖到物理网络，其对接的后端NPM/安全分析能力也只是GB级别。

对于一个整体的Fabric网络，其流量是能轻松达到TB级别的，当我们将这些流量全部采集下来之后，如何将流量和消费端对接起来（因为后端的分析能力是无法消化TB级流量的）也是一个严肃的问题日。这两个因素叠加起来，跟传统网络一层层漂亮的规划图相比起来，云数据中心的多租户的各种业务跑在一张网里，这里有不同的VPC、IP重叠，我们很难再用一幅清晰的图来表示这个网络，此时的数据中心网络无疑是一团乱麻。当出现业务故障时，团队的权责也因此开始模糊起来。

当业务发生故障的时候，虚拟网络「虚拟网元」成为了故障的盲点。重点行业对于这部分网络和流量的覆盖有明确要求，例如等保要求企业对虚拟网络的拓扑和流量具备采集和展现的能力，并且要求采集的方式要安全可靠。以前的网络拓扑环境中，防火墙的位置是固定的，因此策略的配置也很少出现遗漏，因为我们会有完善的分区，例如DMZ、Web、APP、DB等区域。但现在的网络结构是灵活多变的，由此产生的虚拟机的迁移、容器的创建和销毁，这对海量安全策略的配置下发和验证来说无疑是个挑战。而对于多租户场景，目前仍缺乏全局检测和海量规则下发与验证的手段。

总的来看，业务系统普遍运行在VPC网络里，有许多业务系统会共享这个VPC网络，在这样一个较大的平台上，新业务通常无法判断应该在哪里上线。以往的资产采购有明确的归属，现在企业里申请虚拟机变得十分便捷，但是管理员并不能掌握这些资源的使用情况。遇到故障时，网络运维人员通常没有服务器的管理权限，也不知道该去哪里抓包（需要先定位故障点）。常规的解决方法，是把流量和网络配置全部拿下来。但在虚拟化环境中，分光镜像的手段在云里是无法工作的。我们知道VMware的VDS有镜像能力，但商用的OpenStack环境里OvS通常没有这个能力，而镜像的方案对资源的消耗也是倍增的。

构建云数据中心网络全景图

我们的目标是网络本地的转发和计算的本地处理，那么我们应该怎么实现对虚拟网络盲点数据的全量采集呢？物理网络的关键节点（主要是接入部分）覆盖，例如数据中心出口、防火墙的前后，以及接入交换机等。但是虚拟网络要相对复杂一些，常见的虚拟交换机一般没有流量镜像能力、有镜像能力的资源开销太大、用户也难以接受。

对于不同的环境我们有不同的应对方案，对于KVM这类开放方案，可以进行本地的预处理——在宿主机上将流量转换成（各个维度的）遥测数据。在我们的实践中，GB级别的流量，我们发包头就是M级别，如果再压缩一些，能够到K级别。因此这种方案才能在大规模的网络中落地。在封闭的VMware环境里，我们采取本地SPAN的方式，在虚拟机里做预处理之后发送出去。而在公有云的场景下，我们需要在VM内植入探针，这样能覆盖全部盲点的流量采集场景。

在混合云的场景中，我们的解决方案如上图所示。探针的主要功能是把网络数据包变成遥测数据。在x86上实现该方案，大家比较关注的是资源消耗，主要的消耗在于把包抽取出来和压缩后的发送。我们的优化方案是利用DPDK或者Linux内核实现零拷贝，当然这里也有局限，在追求性能极致的同时还要兼顾对客户系统环境的无扰，我们需要做到仅靠已有的环境来获取自己想要的流量，这在性能优化方面给我们带来了许多的技术挑战。

由于我们是在VPC网络里做流量的采集，所以会面临IP冲突的问题，在复杂环境里这种冲突十分难定位。我们会用Mac地址来定位，但这样还不够，因为任何有偏差的数据对后端分析系统来说都是灾难。我们需要从流量的角度看有偏差的数据，其校正需要和云平台进行联动，例如静态的资源属性，动态的路由表等。通过这些手段我们就能判断和确认流量的对端信息。

接下来的工作要相对容易一些，后续的分析比较好理解。我们把拿到的数据写入时序数据库，然后打一些标签，再通过多种纬度对数据进行解释。例如生成的资源报表，可以解决业务上线的问题、虚拟机迁移的问题、对于僵尸虚拟机的清理也十分有帮助，等等。微服务会产生大量容器到容器、VM到VM的通信，通过对这些通信的分析能发现一些端口扫描等安全隐患。对于采集到的数据，通过标记后，我们可以从不同的维度绘制一个从地域到VPC再到服务器、子网、虚拟机、虚拟机接口、IP等从宏观到微观地刻画云网络的全景视图。

打开云网黑盒

刚才讲的是我们如何利用采集到的数据做一个可视化展现，更多地偏向资源的用量、计量、异常的发现等场景。另一个使用场景是在安全层面，我们可以对新上线业务的端口进行聚类，将这些资源映射为一个服务。针对端口的统计、分析和聚类，我们可以生成一些建议的安全策略，这在后续的业务变更中十分有用。我们将安全策略和采集到的流量mapping对比之后，就能验证策略的有效性。

通过流量采集，做一个从报表展现到搜索、再到安全策略的建议和验证的实现。从流量的角度看，我们把虚拟网络的盲点消除了，今天的重点是在数据侧，有了这些数据之后我们可以通过机器学习实现一个自动化控制。另外一个层面，流量是网络的一个组成部分并且是动态的，但网元自身的配置和状态相对于流量是静态的，虚拟机通常会包含这些静态的配置。我们不但要采集流量，我们还需要采集配置和状态。采集完这些信息之后，我们在一张视图里就能够绘制出流量访问的直观路径。再和控制器上的规则加以比对，就能实现端到端的链路诊断。

但事请远非这么简单，对于取证的问题。传统的方法是抓包，在虚拟网络里这件事比较复杂，我们需要抓包后把他们送出去，这时需要我们打隧道送到后端。考虑到性能和资源开销，我们不能在虚拟网络里全量采集包，这时我们要一步步来，先确定范围，再缩小范围（协议、端口、去重、切片），最后定位之后再把故障点的包按需地、精准地抓出来交给后端的分析工具。通过构建这样一个完整的监控网络，我们实现了打开云网黑盒的目的。

]]>